Rent Collection for Blockchain Data #755

nagydani · 2017-11-01T19:03:12Z

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.

Arachnid · 2017-11-01T19:12:31Z

EIPS/rentcollector.md

+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 


Forfeiting the reward for the present block, or for all subsequent blocks?

The idea was for only the present block, because doing it for all subsequent blocks would mean that miners would have no incentive to increase the rent at all, as the sum of the increased rent and decreased mining reward would get smaller (if the proportion is smaller than 1, as it should be).
Should I make it explicit?

Arachnid · 2017-11-01T19:12:47Z

EIPS/rentcollector.md

+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 


Does the rent get credited to the miner?

So, if the rent is X, and the balance is Y, and X > Y, does the miner get X or Y? Creating new money or not?

If rent exceeds lease, only lease is credited to the miner (no money created) and the account is removed.

Arachnid · 2017-11-01T19:13:30Z

EIPS/rentcollector.md

+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 


Limiting this to one per block seems likely to make the effective probability of having rent levied extremely low. It also means that every new account created actually decreases the expected rent-per-account.

As for the first objection, the probability would be proportional to the accounts' state in the total state. That is, if one contract had a state that takes up half the state space, it would be taxed on average in every other block. Externally controlled accounts would, indeed, have a rent levied on them extremely rarely, but that corresponds to those imposing an essentially negligible cost.
However, there is a better argument in favor of taxing more than one account in a block; assuming that nobody pays rent, there can only be one account removed per block, which would be too slow, given the huge number of accounts. In other words, deadbeat accounts would have a very long time before they get evicted.

As for the second objection, I do not see why that would be a problem. Does it create any perverse incentives?

Arachnid · 2017-11-01T19:14:09Z

EIPS/rentcollector.md

+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 


Choosing accounts weighted by their storage usage is going to require another consensus disk structure - one that has to be updated for every new storage slot allocated or unallocated.

Not necessarily. If miners are full nodes, they can keep track of contract sizes in a canonical way off-consensus; after all the information is part of consensus implicitly and it is cheap to keep it up to-date.

An alternative solution could assume that state tries are balanced (deliberately unbalanced tries would only increase expected rent due to Jensen's inequality) and the size of each contract is assumed to be an exponential function of the length of a deterministically random branch in their state trie. In this case, the taxed account would be picked with uniform probability, but the levied rent would be rent multiplied by the estimated size of the state, going down the state trie along a deterministically random branch.

MicahZoltu · 2017-11-04T04:10:15Z

This Pull Request needs a much better title.

MicahZoltu · 2017-11-04T04:17:12Z

EIPS/rentcollector.md

+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 


Why have a separate lease balance rather than just using eth balance? Should the lease balance run out and the contract is pruned it seems wasteful to have any ETH the contract was holding suddenly be black holed when that ETH could have gone to paying rent. Similarly, adding a separate source of ETH adds complexity and I don't see any advantage to separating the balance.

Agreed. The lease balance is redundant.

As pointed out by reviewers, there is no need for a separate balance for paying rent.

VoR0220 · 2017-11-10T18:25:02Z

So far this is the simplest example of creating rent collection I have seen and thus far imo the best. Still...I can't help but feel that the node shouldn't be random but rather chosen by economic factors of tx fees that flow from the address compared to the fee that could be given by a deposit to destruct the state of the contract. In a way I think it shouldn't be rent but rather a bribe from end users to miners to destruct said contract via a special balance appended to the state of every contract (this could be thought of as rent in a way but at any time consumable by a miner) and be dividended a reward for all previous users of that contract + miner (to prevent people just bribing miners blowing up just any contract to screw over users).

Unfortunately that may not scale...this could work though...just would like to see some other means of being able to value the state.

VoR0220 · 2017-11-13T16:29:55Z

EIPS/rentcollector.md

+forfeited to raise it back.
+
+With each new block, an account is chosen in a deterministically random 
+fashion with a probability proportional to the amount of storage that 


How do you enforce deterministically random choosing of an account with storage on it? This seems like a detail that's being handwaved over, when there may be a means to create an economic incentive to focus on "useless" accounts (accounts that have are outdated, low use, etc.)

alexvandesande · 2018-02-08T16:40:46Z

Is this valid for accounts only or contracts too?

If it's valid for contracts then it seems we can fall in an issue where a very important contract with 0 ether can be deleted and therefore delete or freeze other people's funds.

If it's valid for accounts only then it creates a weird scenario that might make people prefer to use more complex wallets or even to use a wrapped eth token instead

Arachnid · 2018-03-27T15:02:06Z

This is a courtesy notice to let you know that the format for EIPs has been modified slightly. If you want your draft merged, you will need to make some small changes to how your EIP is formatted:

Frontmatter is now contained between lines with only a triple dash ('---')
Headers in the frontmatter are now lowercase.

If your PR is editing an existing EIP rather than creating a new one, this has already been done for you, and you need only rebase your PR.

In addition, a continuous build has been setup, which will check your PR against the rules for EIP formatting automatically once you update your PR. This build ensures all required headers are present, as well as performing a number of other checks.

Please rebase your PR against the latest master, and edit your PR to use the above format for frontmatter. For convenience, here's a sample header you can copy and adapt:

---
eip: <num>
title: <title>
author: <author>
type: [Standards Track|Informational|Meta]
category: [Core|Networking|Interface|ERC] (for type: Standards Track only)
status: Draft
created: <date>
---

nicksavers

There are a lot of TODO's in this EIP
And it's also missing a new required discussions-to URL.

nicksavers · 2019-03-08T17:13:35Z

EIPS/eip-755.md

+an unreasonable waste of a scarce resource.
+
+## Specification
+### TODO


nicksavers · 2019-03-08T17:13:53Z

EIPS/eip-755.md

+with acceptance by miners.
+
+## Test Cases
+### TODO


nicksavers · 2019-03-08T17:13:57Z

EIPS/eip-755.md

+### TODO
+
+## Implementation
+### TODO


axic · 2019-05-24T10:35:11Z

@nagydani @zsfelfoldi are you still pursuing this EIP in the light of #1418, #1682 and #2026 / #2027 / #2029 / #2031 ?

axic · 2019-06-28T00:06:06Z

Ping @nagydani @zsfelfoldi

github-actions · 2020-09-22T20:09:17Z

There has been no activity on this pull request for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

github-actions · 2020-09-29T20:09:22Z

This pull request was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.

EIP: Initial writeup

5d840a9

Arachnid reviewed Nov 1, 2017

View reviewed changes

MicahZoltu reviewed Nov 4, 2017

View reviewed changes

nagydani changed the title ~~EIP: Initial writeup~~ Rent Collection for Blockchain Data Nov 9, 2017

EIP: Removed lease balance

8fbac63

As pointed out by reviewers, there is no need for a separate balance for paying rent.

VoR0220 reviewed Nov 13, 2017

View reviewed changes

pirapira added the EIP label Dec 1, 2017

fulldecent mentioned this pull request Sep 16, 2018

Blockchain rent: fixed cost per word-block #1418

Closed

4 tasks

nicksavers added 2 commits March 8, 2019 18:12

Update rentcollector.md

93c1682

Rename rentcollector.md to eip-755.md

372a08b

nicksavers suggested changes Mar 8, 2019

View reviewed changes

Agusx1211 mentioned this pull request Apr 1, 2019

ERC20D: rent-compatible ERC20 migration #1892

Closed

axic added the follow-up-with-author label Jun 28, 2019

github-actions bot added the stale label Sep 22, 2020

github-actions bot closed this Sep 29, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Rent Collection for Blockchain Data #755

Rent Collection for Blockchain Data #755

nagydani commented Nov 1, 2017

Arachnid Nov 1, 2017

nagydani Nov 1, 2017

Arachnid Nov 1, 2017

nagydani Nov 1, 2017

holiman Nov 1, 2017

nagydani Nov 2, 2017

Arachnid Nov 1, 2017

nagydani Nov 1, 2017

nagydani Nov 1, 2017

Arachnid Nov 1, 2017

nagydani Nov 1, 2017

MicahZoltu commented Nov 4, 2017 •

edited

Loading

MicahZoltu Nov 4, 2017

nagydani Nov 9, 2017

VoR0220 commented Nov 10, 2017 •

edited

Loading

VoR0220 Nov 13, 2017

alexvandesande commented Feb 8, 2018

Arachnid commented Mar 27, 2018

nicksavers left a comment •

edited

Loading

nicksavers Mar 8, 2019

nicksavers Mar 8, 2019

nicksavers Mar 8, 2019

axic commented May 24, 2019

axic commented Jun 28, 2019

github-actions bot commented Sep 22, 2020

github-actions bot commented Sep 29, 2020

Rent Collection for Blockchain Data #755

Rent Collection for Blockchain Data #755

Conversation

nagydani commented Nov 1, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MicahZoltu commented Nov 4, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

VoR0220 commented Nov 10, 2017 • edited Loading

Choose a reason for hiding this comment

alexvandesande commented Feb 8, 2018

Arachnid commented Mar 27, 2018

nicksavers left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

axic commented May 24, 2019

axic commented Jun 28, 2019

github-actions bot commented Sep 22, 2020

github-actions bot commented Sep 29, 2020

MicahZoltu commented Nov 4, 2017 •

edited

Loading

VoR0220 commented Nov 10, 2017 •

edited

Loading

nicksavers left a comment •

edited

Loading