Skip to content
This repository has been archived by the owner on Aug 13, 2024. It is now read-only.

Commit

Permalink
Merge pull request #160 from yoomee1313/update-of-kip103
Browse files Browse the repository at this point in the history
Propose KIP-160 Update of Treasury Fund Rebalancing
  • Loading branch information
yoomee1313 authored Apr 24, 2024
2 parents feed532 + 9ffd1e3 commit 9798317
Show file tree
Hide file tree
Showing 2 changed files with 93 additions and 2 deletions.
4 changes: 2 additions & 2 deletions KIPs/kip-149.md
Original file line number Diff line number Diff line change
Expand Up @@ -31,7 +31,7 @@ Between the popular proxy patterns `Transparent` and `UUPS`, all system contract

### Definitions

- System contract: A contract that is read by the Klaytn core protocol or directly affect the protocol. The currently deployed system contracts are as follows: [**AddressBook**](https://github.com/klaytn/klaytn/blob/dev/contracts/reward/contract/AddressBook.sol), [**GovParam**](https://github.com/klaytn/klaytn/blob/dev/contracts/gov/GovParam.sol), **Voting**([KIP-81](https://github.com/klaytn/kips/blob/main/KIPs/kip-81.md)), **TreasuryRebalance**([KIP-103](https://github.com/klaytn/kips/blob/main/KIPs/kip-103.md))
- System contract: A contract that is read by the Klaytn core protocol or directly affect the protocol. The currently deployed system contracts are as follows: [**AddressBook**](https://github.com/klaytn/klaytn/blob/dev/contracts/contracts/system_contracts/consensus/AddressBook.sol), [**GovParam**](https://github.com/klaytn/klaytn/blob/dev/contracts/contracts/system_contracts/gov/GovParam.sol), **Voting**([KIP-81](https://github.com/klaytn/kips/blob/main/KIPs/kip-81.md)), **TreasuryRebalance**([KIP-103](https://github.com/klaytn/kips/blob/main/KIPs/kip-103.md))

- System contract upgrade: The process of updating an existing logic contract while maintaining a proxy contract. The upgraded logic contract must be compatible with the previous interface and its storage layout.

Expand Down Expand Up @@ -352,7 +352,7 @@ The existing system contracts will not be registered in the Registry, since they

## Implementation

- A reference implementation for the Registry contract: [Implementation](https://github.com/klaytn/klaytn/blob/dev/contracts/system_contracts/registry/Registry.sol)
- A reference implementation for the Registry contract: [Implementation](https://github.com/klaytn/klaytn/blob/dev/contracts/contracts/system_contracts/kip149/Registry.sol)
- A reference implementation for core logic: [Implementation](https://github.com/klaytn/klaytn/blob/dev/blockchain/system/registry.go)

## References
Expand Down
91 changes: 91 additions & 0 deletions KIPs/kip-160.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,91 @@
---
kip: 160
title: An Update of Treasury Fund Rebalancing
author: Yumiel (@yoomee1313) and Ollie (@blukat29)
status: Final
type: Standards Track
category: Core
created: 2024-04-22
requires: 103
---

## Simple Summary
An update of treasury fund rebalancing.

## Abstract
The treasury fund rebalancing is updated, resulting in updates to the treasury rebalance contract v2 and the related core logic.

## Motivation
According to KIP-103, the treasury rebalancing refers to the act of burning existing fund balances and minting new funds. This event happens at a reserved time, such as a hard fork block number. Through the TreasuryRebalance contract, the disclosure of the treasury fund activities can be conducted transparently and verifiably. However, there are a few shortcomings of KIP-103; (1) it only permits the decrease in the total balance of the funds, (2) its rebalance blocknumber is immutable.

To address those above, this proposal made some improvements. First of all, this proposal expands to the general cases so that we don't have to consider whether the final result is burn or mint. The other improvement is about making rebalanceBlocknumber in the RebalanceContract editable. The rebalanceBlocknumber should be matched with the related hardfork block number.

## Specification
Before proceeding, this proposal will first organize and clarify the terminology. Here, the previous/new fund addresses are referred to as `Zeroed`, `Allocated` unlike in KIP-103. `Retired`, `Newbie` were ambiguous and did not clearly indicate that the previous fund balance is zeroed and the new fund balance is allocated, which degraded the readability.

### To consider both total burn/total mint cases
In KIP-103, rebalancing is limited to cases where the total balance decreases. This proposal aims to generalize the process by removing the requirement that the total balance of `Zeroeds` should exceed the total minting amount of `Allocateds`. Consequently, the checking code is eliminated from the contract and core code.

In the `TreasuryRebalanceV2` contract, the `finalizeApproval` method has been revised as follows. Initially, this `require` statement, `require(getTreasuryAmount() < sumOfZeroedBalance())`, was present. However, it has been removed to accommodate all cases.

```solidity
/**
* @dev finalizeApproval sets the status to Approved,
* After this stage, approvals will be restricted.
*/
function finalizeApproval()
public
onlyOwner
onlyAtStatus(Status.Registered)
{
checkZeroedsApproved();
status = Status.Approved;
emit StatusChanged(status);
}
```

The next validation has also been removed from the core logic. It previously ensured that the total balance of `Zeroeds` was greater than the total balance of `Allocateds`. However, it has been removed to support all cases.
* totalZeroedAmount >= totalAllocatedAmount

### To enable editing of RebalanceBlocknumber defined in treasury rebalance contract
Within the treasury rebalance contract, there exists a storage value named `RebalanceBlocknumber`, which ideally should correspond to the associated hard fork block number. Despite being able to update the hard fork block number, the `RebalanceBlocknumber` field was immutable. To align the behavior of this field with that of the hard fork block number, this proposal advocates for making the `RebalanceBlocknumber` field editable.

The next method is added to the TreasuryRebalanceV2 contract.
```solidity
/**
* @dev updates rebalance block number
* @param _rebalanceBlockNumber is the updated target block number of the execution the rebalance in Core
*/
function updateRebalanceBlocknumber(
uint256 _rebalanceBlockNumber
) public onlyOwner {
require(block.number < rebalanceBlockNumber, "current block shouldn't be past the currently set block number");
require(block.number < _rebalanceBlockNumber, "rebalance blockNumber should be greater than current block");
rebalanceBlockNumber = _rebalanceBlockNumber;
}
```

## Rationale
While executing the core logic of the KIP-103 treasury rebalance, the unintended increase in the nonce of the '0x0' address occured. In KIP-160, this issue can be resolved by replacing the usage of `kip103ContractBackend` with `BlockchainContractBackend`. For your reference, `ContractBackend` facilitates the interaction between the core and contracts.

The following pseudocode illustrates how to define a contract callers for each rebalancing.
```golang
RebalanceTreasury() {
if current block number is equal to KIP-160 hard fork block number {
// Define the caller for the NewTreasuryRebalanceV2 contract
caller, err = rebalance.NewTreasuryRebalanceV2Caller(chain.Config().Kip160ContractAddress, backends.NewBlockchainContractBackend(chain, nil, nil))
}
if current block number is equal to KIP-103 hard fork block number {
// Define the caller for the NewTreasuryRebalance contract
caller, err = rebalance.NewTreasuryRebalanceCaller(chain.Config().Kip103ContractAddress, &Kip103ContractCaller{state: state, chain: chain, header: header},
}
if err != nil {
stop
}
}
```
## Test cases
TBD

## Reference
TBD

0 comments on commit 9798317

Please sign in to comment.