Creation of new accounts (both contracts and non-contracts) requires a fixed one-off rent prepayment. Pre-existed accounts require the same prepayment upon
the first modification. The act of rent prepayment causes the addition of an extra field to accounts, called rentbalance. This field becomes part of state.
This is part of the State Rent roadmap. This particular change introduces a fixed charge for state expansion that comes from adding new accounts to the state. Theoretically, it puts a bound on the number of accounts that can be ever created, because that fixed charge cannot be recycled via mining.
The penalty is levied to the transaction sender. Rather than raising the gas cost of account creation (that would direct levy towards the miner), this change directs prepayment into the account's special field, rentbalance. It addresses several shortcomings of the simple raising of the gas cost:
rentbalance upon self-destruction - when contract is self-destructed, both balance and rentbalance are returned.On and after block H, every newly created account gets a new field rentbalance of type unsigned 256-bit integer.
On and after block H, any operation that leads to the creation of a new account, deducts the amount ACCOUNT_PREPAYMENT from tx.origin. This amount is added to the rentbalance field of the created account.
On and after block H, any operation that modifies an account that does not yet have rentbalance field, deducts the amount ACCOUNT_PREPAYEMENT from tx.origin. This amount is added to the rentbalance field of the modified account. This is an anti-hoarding measure.
Operations leading to the creations of a new account:
coinbase pointing to an address with no associated accountSELFDESTRUCT with the argument being an address with no associated accountCREATE or CREATE2. This can result in either converting a non-countract account into a contract account, or creation of a contract account.After prepayments are introduced, there can be two reasons for ether to be deducted from tx.origin: purchasing and spending gas, and spending gas for prepayments. Gaslimit of a transaction currently plays a role of safety limit, where gaslimit * gasprice represents the maximum amount of wei the sender (tx.origin) authorises the transaction to deduct from its account.
After prepayments are introduced, gaslimit * gasprice will still represent the maximum amount of wei spend, but it will be used for both gas purchases and prepayments, as necessary.
Prior to rent prepayments, other alternatives were considered:
An alternative approach to limiting the prepayments (instead of the using gaslimit * gasprice as the limit) is to introduce a new dedicated field prepaymenlimit into the transaction. This field would only limit prepayments. Such approach would require changes in the transaction format, as well as changes in the user interface for transaction sender, and having two counters during the transaction execution - one for gas, and one for prepayments.
This change is not backwards compatible and requires hard fork to be activated. It might have some adverse effects on the existing contracts, due to more gas needed to be allocated for the creation of new accounts. These adverse effects need to analysed in more detail.
Tests cases will be generated out of a reference implementation.
There will be proof of concept implementation to refine and clarify the specification.
Copyright and related rights waived via CC0.