status-im/EIPs
2
0
Fork 0
mirror of https://github.com/status-im/EIPs.git synced 2025-02-22 19:58:06 +00:00
Code Issues Projects Releases Wiki Activity

Update eip-1418.md (#3704)

Browse Source 
* Update eip-1418.md

* typo
This commit is contained in:
William Entriken 2021-08-06 09:32:10 -04:00 committed by GitHub
parent 96cdc83e45
commit cc8e2b42af
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 19 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

31
EIPS/eip-1418.md
View File

@ -122,20 +122,29 @@ Ether converted to rent cannot be converted back. Anybody that works in accounti
Yes, they pay rent. It costs money to keep their balances so we charge them rent.
**You can lose all your money**
**Shouldn't we spend value (Ether balance) when rent is depleted?**
Yes.
* Rename `rentEvictBlock` to `rentUsingValueBlock`
* Update eviction calculation to include `RENT` + `VALUE`. Also update `CALL` (and friends) operations to recalculate eviction date when value is transferred. This is the new `rentEvictBlock`.
* Update `CALL` (and friends), `RENTBALANCE` and `SENDRENT` operations. If `NUMBER` >= `rentUsingValueBlock` then proceed as if rent started paying using value.
Conceptually, you understand how this change works. But putting the details above is a little complicated. So I like the informal definition above until we have some consent around it (do de this before this draft gets to LAST CALL).
**Your contract can be evicted and disappeared**
Yes, if you do not pay rent for your account or contract then you lose it all. User education is required.
Alternative: spend value (Ether balance) when rent is depleted
* Rename rentEvictBlock to rentUsingValueBlock
* Update eviction calculation to include RENT + VALUE. Also update CALL (and friends) operations to recalculate eviction date when value is transferred. This is the new rentEvictBlock.
* Update CALL (and friends), RENTBALANCE and SENDRENT operations. If HEIGHT >= rentUsingValueBlock then proceed as if rent started paying using value.
Actually, we should spend value (Ether balance) when rent is depleted.
This alternative is a good idea, if there is support I can include this part formally in the specification. The specification is a little complicated so I like the informal definition above until we have some consent around it.
**Why do you need a separate rent account?**
Alternative2: do not have a separate rent account -- directly deduct rent from value
* Every time the state is updated (including receiving value) you get a rent subsidity
* Need to review invariants of existing contracts to see what problems and broken assumptions this will cause in real life
Because anybody/everybody can contribute to the rent account. If you depend on a contract, you should be contributing 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.
**Permanent removal**
@ -151,7 +160,7 @@ Hint to implementers: make sure this works:
# Rationale -- 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.
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:
@ -161,8 +170,6 @@ How about:
The rent is priced in cold, hard Ether. It is not negotiated by clients, it is not dynamic. It is linear. Why is this a good idea? Because right now Ethereum is a system with multiple free variables -- Ether/gas price, gas/opcodes costs, Ether/block reward. [Add some note here about reducing a system of equations...] So the end result is that we can peg one of the values and it will be okay.
By setting the RENT price in Ether and by having the existing gas prices set based on the floating rate, there is an implicit price of ~4 gwei set into the Yellow Paper. In other words, if in the future the price of gas goes to 1 Ether then people will be upset because they will say "I paid 20,000 gas for an SSTORE" but I only got 360 days of stipend. If I paid for the rent directly I would have gotten enough rent to last until the Sun explodes." I acknowledge this complaint and do not think it is sufficient to warrant dismissing this proposal.
Q: There is a finite-ish amount of Ether and this proposal introduces a word-price in Ether, do math for me. A: The current size of Ethereum is about ~1 TB, maybe half of that is branch nodes. So that's like 15B words. There is about 100M Ether mined. The answer is that all the Ether can be spent on 400,000 terabyte-years of storage. I'm not sure if it is helpful to look at it that way.
# Backwards compatibility