Discussion on Casper, scalability, abstraction and other low-level protocol research topics
Apr 06 2018 21:05
@holiman banned @PhunioBCC
Oct 21 2017 21:22
@jpitts banned @vickyissabox_twitter
Oct 10 2017 22:29
@jpitts banned @etherchamp2
Tracking how much to charge that contract over time would prove difficult I suspect.
Well, any storage-increasing transaction could increase a counter of just how large the total state-size is for that contract
Since things are constantly coming and going.
@mjdillon good point, could reuse "gas" - to keep your contract going
@mjdillon Hmm, interesting thought. If I understand correctly you are suggesting that rent is "charged" anytime state changes and then the new state size is stored for the account until the next time a state change occurred?
Yeah, that would work.
that there is a "cost", whatever it is, for holding part of the state
and it's determinable at the end of any change of any kind, up or down
so a contract has a dynamic size, but doesnt change between actions
if "rent" is done deterministically, then the next time the contract is accessed, a validator would check if there is enough Eth to pay the rent since the last activity at that then-current size
Unless you store a full history of that, you will need to make sure to deduct anytime a state change occurs.
any activity, even if it's a 0 change in size, would update that amount to the current amount
and a validator could delete it from state if the rent is due
I still don't like the idea or rent, but if it's calculable, people could determine long in advance when it would be deleted
and any account could just send Eth to a contract to keep it alive
ironically, updating/checking the state counter by doing that.
perhaps there could be a financial incentive to the miners to delete stale state entries.
it really would need to be infantesimally small for it not to destroy the idea of interconnected smart contracts
and frankly, the involatile gas market, even after the surge in the price of Eth scares me that the network would be too expensive to function properly
@ankitchiplunkar_twitter the develop branch of pyethereum/pyethapp doesn't yet have EIP155 support. try the state_revamp_with_p62 branch
@mjdillon Gas prices aren't a function of ETH price. They are a function of miner/validator rewards and block time.
So IF you believe that moore's law allows us to "ignore the state bloat problem" then you necessarily must believe that the cost to store something on chain for "longer than anyone will care" must necessarily be cheaper than current storage costs (assuming current storage costs are accurately priced). So either a no-rent system will fail, or a rent system will succeed indefinitely for the same price.
I don't believe that it logically makes sense to believe that "infinite storage duration" is going to be cheaper than "insanely long storage duration".
IMO this leaves the only remaining arguments for non-rent solutions:
solution complexity costs
risk that someone forgets to pay rent on some storage they depend on
From what I have heard, the second is the one everyone is afraid of, and I do believe it will happen.
I also believe that working in blockchains is a place filled with dragons and that is something that I accept in exchange for having a truly free economy, including free from leechers, attackers, bad engineers, etc. because the system has a mechanism for culling them over time (by causing them to bleed money).
I'm not looking to smart contracts for happy pony space where anyone can put whatever badness they want up and expect it to probably generally work. If you want that go write code on the internet.
@All, looking for getting industry certification on Ethereum. Can you suggest the best ones?
@MicahZoltu I don't disagree with the way you feel about dragons and danger, but part of the appeal of these systems is on chain elements working with one another. Bits and bobs dissappearing over time adds another level of potential problems, and rightly scares people.
Yeah, I recognize the fear. I remember the left-pad issue. :)
None the less, I do not think that it is fair to punish the entire ecosystem (storage prices are way higher than necessary) because some people are afraid.
True, but while something is being designed is the time to ask "is there a better way to do this?"
Yeah, I am looking forward to hearing of a solution to the storage problem that doesn't punish everyone but also isn't rent. :)
What I still don't understand is what validator selection algo will be chosen. Nothing proposed is as elegant as Hashcash. It is especially interesting because deterministic pseudorandom selection means I can predict the next validators. If I can predict them then I can coerce/ bribe them.
ok ty. Last thing what happen if a validator propose an hash that can not be finalised? Are there consequences?
No, not as a slashing condition anyway, but I don't know the current details of block generation. There would probably be something to keep people from spamming bad blockhashes out of order. Probably would keep other nodes from even accepting it.
you're not rewarded for generating blockhashes (I believe), just from sending valid prepares and commits.
And it is done on chain. There's a work in progress casper contract somewhere around here. Let me see if I can find it