From 5d840a924bb901148a450a8b4efe20312629b7b1 Mon Sep 17 00:00:00 2001 From: "Daniel A. Nagy" Date: Wed, 1 Nov 2017 19:52:42 +0100 Subject: [PATCH 1/4] EIP: Initial writeup --- EIPS/rentcollector.md | 73 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 73 insertions(+) create mode 100644 EIPS/rentcollector.md diff --git a/EIPS/rentcollector.md b/EIPS/rentcollector.md new file mode 100644 index 0000000000000..6f5ab6a50d33c --- /dev/null +++ b/EIPS/rentcollector.md @@ -0,0 +1,73 @@ +## Preamble + + EIP: + Title: Rent Collection for Blockchain Data + Author: Daniel A. Nagy , Zsolt Felfoldi + Type: Standard Track + Category: Core + Status: Draft + Created: 2017-11-01 + + +## Simple Summary +Introducing a way to collect rent from accounts that is proportional +to the cost that they impose on the network by storing a large state +over a long period of time. + +## Abstract +A new global parameter called `rent` similar to `gasLimit` that can be +modified by miner vote is introduced. It is initialized at 0 and is +assumed to have been zero before its introduction. The miner validating +a particular block can increase rent in a bounded way at the cost of +forfeiting a proportional part of the mining reward. Similarly, if +`rent` is more than zero, one can decrease it in a bounded way and +receive the same additional mining reward that would need to be +forfeited to raise it back. + +Each contract account gets a new balance called `lease` used for paying +rent that is initialized at 0 and is assumed to have been zero before +its introduction. For externally controlled accounts, their `lease` +balance is the same as their normal balance. With each new block, an +account is chosen in a deterministically random fashion with a +probability proportional to the amount of storage that they use. The +current value of `rent` is subtracted from their `lease` and if the +result is negative, the account gets removed from the state. Otherwise, +`lease` is updated by the result. + +## Motivation +Currently, contracts storing a large state over a long period of time +impose considerable cost on the network and do so for free, having +insufficient incentives to keep their state small. This results in +an unreasonable waste of a scarce resource. + +## Specification +### TODO +Both `rent` and their own `lease` are available as readable +environment to contracts. Contracts can transfer part or whole of their +normal balance to their `lease`. + +## Rationale +The proposed rent control mechanism creates a *tragedy of commons* type +coordination problem between miners, privatizing the costs of raising +`rent` while the benefit is common and, conversely, privatizing the +benefit of reducing `rent` while the cost is socialized. It is up to +miners to coordinate through smart contracts; it is not part of the protocol. +In general, this bias towards reducing the rent is intended to keep +rent in check and make it difficult for miners to raise rent beyond +the actual cost of storing the state. + +## Backwards Compatibility +The fact that both `rent` and `lease` are initialized as zero and assumed +to have been zero before introducing the protocol change, the entire +history of the blockchain is conforming to the rules introduces in this +protocol change. Since miners are beneficiaries of the change, no +difficulty is expected with acceptance by miners. + +## Test Cases +### TODO + +## Implementation +### TODO + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From 8fbac636666a8cb5f2da7b8d169824d97458bc04 Mon Sep 17 00:00:00 2001 From: "Daniel A. Nagy" Date: Thu, 9 Nov 2017 03:30:45 +0100 Subject: [PATCH 2/4] EIP: Removed lease balance As pointed out by reviewers, there is no need for a separate balance for paying rent. --- EIPS/rentcollector.md | 28 +++++++++++----------------- 1 file changed, 11 insertions(+), 17 deletions(-) diff --git a/EIPS/rentcollector.md b/EIPS/rentcollector.md index 6f5ab6a50d33c..07b2705ca2031 100644 --- a/EIPS/rentcollector.md +++ b/EIPS/rentcollector.md @@ -24,15 +24,11 @@ forfeiting a proportional part of the mining reward. Similarly, if receive the same additional mining reward that would need to be forfeited to raise it back. -Each contract account gets a new balance called `lease` used for paying -rent that is initialized at 0 and is assumed to have been zero before -its introduction. For externally controlled accounts, their `lease` -balance is the same as their normal balance. With each new block, an -account is chosen in a deterministically random fashion with a -probability proportional to the amount of storage that they use. The -current value of `rent` is subtracted from their `lease` and if the -result is negative, the account gets removed from the state. Otherwise, -`lease` is updated by the result. +With each new block, an account is chosen in a deterministically random +fashion with a probability proportional to the amount of storage that +they use. The current value of `rent` is subtracted from their balance +and if the result is negative, the account gets removed from the state. +Otherwise, account balance is updated by the result. ## Motivation Currently, contracts storing a large state over a long period of time @@ -42,9 +38,7 @@ an unreasonable waste of a scarce resource. ## Specification ### TODO -Both `rent` and their own `lease` are available as readable -environment to contracts. Contracts can transfer part or whole of their -normal balance to their `lease`. +Both `rent` is available as readable environment to contracts. ## Rationale The proposed rent control mechanism creates a *tragedy of commons* type @@ -57,11 +51,11 @@ rent in check and make it difficult for miners to raise rent beyond the actual cost of storing the state. ## Backwards Compatibility -The fact that both `rent` and `lease` are initialized as zero and assumed -to have been zero before introducing the protocol change, the entire -history of the blockchain is conforming to the rules introduces in this -protocol change. Since miners are beneficiaries of the change, no -difficulty is expected with acceptance by miners. +The fact that both `rent` is initialized as zero and assumed to have been +zero before introducing the protocol change, the entire history of the +blockchain is conforming to the rules introduces in this protocol change. +Since miners are beneficiaries of the change, no difficulty is expected +with acceptance by miners. ## Test Cases ### TODO From 93c16829f35b280b7b3d25798a7d7ecf81ca4ab1 Mon Sep 17 00:00:00 2001 From: Nick Savers Date: Fri, 8 Mar 2019 18:12:37 +0100 Subject: [PATCH 3/4] Update rentcollector.md --- EIPS/rentcollector.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/EIPS/rentcollector.md b/EIPS/rentcollector.md index 07b2705ca2031..8105f2f7964cf 100644 --- a/EIPS/rentcollector.md +++ b/EIPS/rentcollector.md @@ -1,13 +1,13 @@ -## Preamble - - EIP: - Title: Rent Collection for Blockchain Data - Author: Daniel A. Nagy , Zsolt Felfoldi - Type: Standard Track - Category: Core - Status: Draft - Created: 2017-11-01 - +--- +eip: 755 +title: Rent Collection for Blockchain Data +author: Daniel A. Nagy , Zsolt Felfoldi +discussions-to: +status: Draft +type: Standards Track +category: Core +created: 2017-11-01 +--- ## Simple Summary Introducing a way to collect rent from accounts that is proportional From 372a08b2a39a8dfcb06f4eb03918dc850fa42323 Mon Sep 17 00:00:00 2001 From: Nick Savers Date: Fri, 8 Mar 2019 18:12:55 +0100 Subject: [PATCH 4/4] Rename rentcollector.md to eip-755.md --- EIPS/{rentcollector.md => eip-755.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename EIPS/{rentcollector.md => eip-755.md} (100%) diff --git a/EIPS/rentcollector.md b/EIPS/eip-755.md similarity index 100% rename from EIPS/rentcollector.md rename to EIPS/eip-755.md