by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 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
Micah Zoltu
@MicahZoltu
A token for example will always have state, but state associated with accounts that no longer hold any of that token could be cleaned up.
Tracking how much to charge that contract over time would prove difficult I suspect.
MJ Dillon
@mjdillon
Well, any storage-increasing transaction could increase a counter of just how large the total state-size is for that contract
Micah Zoltu
@MicahZoltu
Since things are constantly coming and going.
Josef Jelacic
@JosefJelacic_twitter
@mjdillon good point, could reuse "gas" - to keep your contract going
Micah Zoltu
@MicahZoltu
@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.
MJ Dillon
@mjdillon
partially
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
Micah Zoltu
@MicahZoltu
Unless you store a full history of that, you will need to make sure to deduct anytime a state change occurs.
MJ Dillon
@mjdillon
right
Micah Zoltu
@MicahZoltu
:+1:
MJ Dillon
@mjdillon
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.
err, state-size
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
Ankit Chiplunkar
@ankitchiplunkar_twitter
I wanted to download the whole blockchain in humanreadable format, but I get an error after EIP155.
Link below is a detailed question:
https://ethereum.stackexchange.com/questions/15849/scraping-ethereum-blockchain-in-human-readable-format-csv
cdetrio
@cdetrio
@ankitchiplunkar_twitter the develop branch of pyethereum/pyethapp doesn't yet have EIP155 support. try the state_revamp_with_p62 branch
Micah Zoltu
@MicahZoltu
@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:
  1. solution complexity costs
  2. 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.
Micah Zoltu
@MicahZoltu
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.
Mahen Rathod
@MahenRathod_twitter
@All, looking for getting industry certification on Ethereum. Can you suggest the best ones?
MJ Dillon
@mjdillon
@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.
Micah Zoltu
@MicahZoltu
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.
MJ Dillon
@mjdillon
True, but while something is being designed is the time to ask "is there a better way to do this?"
Micah Zoltu
@MicahZoltu
Yeah, I am looking forward to hearing of a solution to the storage problem that doesn't punish everyone but also isn't rent. :)
Roland Kofler
@rolandkofler
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.
Filippo Merli
@Fi3
I do not understand how the proposal mechanism illutstrated here https://medium.com/@VitalikButerin/minimal-slashing-conditions-20f0b500fc6c works.
For example: must the validator use a message like PREPARE and COMMIT to propose an hash? Something like [PROPOSE, epoch, HASH, epoch_source]
SE question: https://ethereum.stackexchange.com/questions/15837/casper-proposal-mechanism
Ben Mahala
@Lisk115
you prepare and commit an existing blockhash to finalize it. validators generate new blockhashes depending on the selection algo. Every validator can prepare and commit (and get rewards) every block.
Filippo Merli
@Fi3
ty. If a validator propose a bockhash that is not finalised the validator is slashed?
Ben Mahala
@Lisk115
No, you're only slashed if you equivocate (eg send conflicting prepares and commits).
Filippo Merli
@Fi3
ok ty. Last thing what happen if a validator propose an hash that can not be finalised? Are there consequences?
Ben Mahala
@Lisk115
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