EIP-1418: Blockchain Storage Rent Payment
At each block, deduct an amount of value from every account based on the quantity of storage used by that account.
| 作者 | William Entriken |
|---|---|
| 讨论-To | https://ethereum-magicians.org/t/eip-1418-storage-rent/10737 |
| 状态 | Draft |
| 类型 | Standards Track |
| 分类 | Core |
| 创建日期 | 2018-09-16 |
| 依赖 | 1559 |
| 英文版 | https://eips.ethereum.org/EIPS/eip-1418 |
目录
Abstract
At each block, deduct an amount of value or rent from every account based on the quantity of storage used by that account.
Motivation
Ethereum is a public utility and we are underpricing the long-term costs of storage. Storage cost can be approximately modeled as bytes × time.
Specification
Updated transaction type
EIP-1559 transaction type 2 is updated so that clients can send a contract’s code as part of a transaction, just the same way as now how clients can send state variables.
New state variables (per account)
- σ[a]_rent – an amount of value, in Wei, this is a signed value
- σ[a]_storageWords – number of words in storage
New constants
RENT_WORD_COST– The rent cost, in Wei, paid for each word-blockRENT_ACCOUNT_COST– The rent cost, in Wei, paid for each account-blockFORK_BLOCK– When implementation starts
New opcodes
RENTBALANCE(address)– G_BALANCE – Similar toBALANCE- This returns the logical
σ[a]_rentvalue which is defined to reduce each block. It is possible for the implementation to calculate this value using the recommended implementation variables, rather than storing an updatingσ[a]_rentevery block for every account.
- This returns the logical
SENDRENT(address, amount)– G_BASE – Convert value to rent and send to accountσ[account]_rent+= amountσ[msg.sender]_balance-= amount
Updated opcodes
A new subroutine, paying for rent, is established as such:
PAYRENT(account)
blocks_to_pay = NUMBER - σ[account]_rentLastPaid
cost_per_block = RENT_ACCOUNT_COST + RENT_WORD_COST * (⌈∥σ[account]_code∥ / 32⌉ + * σ[a]_storageWords)
rent_to_pay = blocks_to_pay * cost_per_block
σ[account]_rent -= rent_to_pay
if σ[account]_rent < 0
σ[account]_value += σ[account]_rent
σ[account]_rent = 0
end
if σ[account]_value < 0
σ[account]_rent = σ[account]_value
σ[account]_value = 0
end
σ[account]_rentLastPaid = NUMBER
σ[account]_rentEvictBlock = NUMBER + ⌊σ[account]_rent / cost_per_block⌋
END PAYRENT
SSTORE(account, key, value)- Perform PAYRENT(account)
- If
accountis evicted (i.e.NUMBER>σ[account]_rentEvictBlock) then transaction fails unless the transaction includes this storage key in EIP-1559 type 2 transaction. - Do normal SSTORE operation
- If the old value was zero for this [account, key] and the new value is non-zero, then
σ[account]_storageWord++ - If the old value was non-zero for this [account, key] and the new value is zero, then
σ[account]_storageWords--, and if the result is negative then set to zero
SLOAD(account, key)- If
accountis evicted (i.e.NUMBER>σ[account]_rentEvictBlock) then transaction fails unless the transaction includes this storage key in EIP-1559 type 2 transaction. - Do normal SLOAD operation.
- If
CALL (and derivatives)- If the target block is evicted (i.e.
NUMBER>σ[account]_rentEvictBlock) then transaction fails unless the transaction includes this account’s code in EIP-1559 type 2 extended transaction. - Do normal CALL operation
- If the target block is evicted (i.e.
CREATE- Set σ[account]_rentLastPaid = NUMBER
- Do normal CREATE operation
- Note: it is possible there is a pre-existing rent balance here
New built-in contract
PAYRENT(address, amount)– CallsPAYRENTopcode- This is a convenience for humans to send Ether from their accounts and turn it into rent. Note that simple accounts (CODESIZE == 0) cannot call arbitrary opcodes, they can only call CREATE or CALL.
- The gas cost of PAYRENT will be 10,000 or lower if possible.
No changes to current opcode gas costs.
Rationale
No call
A contract will not know or react to the receipt of rent. This is okay. Workaround: if a contract really needed to know who provided rent payments then it could create a function in its ABI to attribute these payments. It is already possible to send payments to a contract without attribution by using SELFDESTRUCT. Other blockchains like TRON allow to transfer value to a contract without performing a call.
Eviction responsibility / lazy evaluation
The specification gives responsibility for eviction to the consensus clients. This is the most predictable behavior because it happens exactly when it should. Also there need not be any incentive mechanism (refund gas, bounty) for outside participants (off-chain) to monitor accounts and request removal.
It is possible that an arbitrary number of accounts will be evicted in one block. That doesn’t matter. Client implementations do not need to track which accounts are evicted, consensus is achieved just by agreeing on the conditions under which an account would be evicted.
No converting rent to value
Ether converted to rent cannot be converted back. Anybody that works in accounting and knows about gifts cards should tell you this is a good idea. It makes reasoning about the system much easier.
Accounts pay rent
Yes, they pay rent. It costs resources to account for their balances so we charge them rent.
Why do you need a separate rent account?
Because anybody/everybody can contribute to the rent account. If you depend on a contract, you should contribute to its rent.
But the contract can spend all of its value.
By maintaining a separate rent and value balance, this allows people to contribute to the rent while being confident that this is allowing the contract to stay around.
Economics & constants
An SSTORE executed in 2015 cost 20,000 gas and has survived about 6 million blocks. The gas price has been around 1 ~ 50 Gwei. So basically 4,000 Wei per block per word so far. Maybe storing an account is 10 times more intensive than storing a word. But actually G_transaction is 21,000 and G_sstore is 20,000 so these are similar and they can both create new accounts / words.
How about:
RENT_WORD_COST– 4,000 WeiRENT_ACCOUNT_COST– 4,000 WeiFORK_BLOCK– when implementation starts
The rent is priced in cold, hard Ether. It is not negotiated by clients, it is not dynamic.
A future EIP may change this pricing to be dynamic. For example to notarize a block, notaries may be required to prove they have the current storage dataset (excluding evictions). Additionally, they may also prove they have the dataset plus evictions to earn an additional fee. The relative storage of the evicted accounts, and the other accounts versus the value of the additional fee may be used as a feedback mechanism to set a market price for storage.
FYI, there are about 15B words in the Ethereum Mainnet dataset and about 100M total Ether mined. This means if all Ether was spent on storage at current proposed prices it would be 400 terabyte-years of storage. I’m not sure if it is helpful to look at it that way.
向后兼容性
EIP-1559 already introduces a mechanism for nodes to participate without recording the full network state and for clients to warm cache with storage data in their type 2 transactions.
Users will need to be educated.
Many smart contracts allow anybody to use an arbitrary amount of storage in them. This can limit the usefulness of deploying this proposal on an existing chain.
Recommended implementation variables (per account)
- σ[a]_rentLastPaid – a block number that is set when:
- Value is transferred into an account (
CREATE,CALL,SELFDESTRUCT) - Code is set for an account (
CREATE) - An account’s storage is updated (
SSTORE) - This begins with a logical value of
FORK_BLOCKfor all accounts
- Value is transferred into an account (
- σ[a]_rentEvictBlock – the block number when this account will be evicted
Storage note
For every account that is evicted, clients may choose to delete that storage from disk. A future EIP may make an incentive to keep this extra data for a fee. A future EIP may create a mechanism for clients to exchange information about these storage states.
Security Considerations
Many smart contracts allow anybody to use an arbitrary amount of storage in them.
Copyright
Copyright and related rights waived via CC0.
参考文献
Please cite this document as:
William Entriken, "EIP-1418: Blockchain Storage Rent Payment [DRAFT]," Ethereum Improvement Proposals, no. 1418, September 2018. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-1418.