@vbuterin how would a fungible token work in this one contract per point of interest approach? To me it seems we’ll need to retire the entire ERC-20 concept, and go for something that looks more like UTXOs…
But then, what about token authenticity? Similarly to Bitcoin UTXO structure, the only way to validate a “coin” contract is to track it back to the issuer. Now if the contracts in its provenance chain are no longer in the state trie, you’d need an archival node to differentiate between 10000 fake Raiden tokens, and 10000 real Raiden tokens. (And even so, it would be impossible from within the EVM!)
This goes for non-fungible assets too… I could totally “make” myself a cryptokitty. Copy or reverse-engineer the contract code, put in the identifiers… Without a central registry, the only difference between that and one that got created as part of the cryptokitty ecosystem is provenance… and central registries will be impossible to maintain in the new fee model.
ENS uses a central registry to keep track of individual resolver contracts. Who would be paying for that, and most importantly how? The only thing that gives an ENS resolver contract value is that it’s in the registry. The individual name contract by itself is worthless.
And I really wonder how much that would cost, or it would even be possible, if the state size of that contract is measured in megabytes or even gigabytes. (For central registries, this could totally happen, either by spamming, or by legitimate use.)
And contract state spamming as a DoS attack shouldn’t be discounted. Especially government entities, or even corporations could use this to “murder” contracts they don’t like. Just bloat the state until the community is unable to keep paying the fees, and nobody will be able to afford a reactivation.
nb. I’m not trying to detract the idea of storage rent, it’s something we probably really need, as otherwise there is no check on state growth. However, this would fundamentally shift the way Ethereum operates, and the way we need to program for it. There might need to be changes to client software and the EVM itself as well, to accomodate for these new ways.
Reactivation for example, in my opinion, should be possible by simply “asking” an archival node for a certain convenience fee. Eg. light or “fast” node submits reactivation request, archival node snaps it up, gets paid, extracts proofs and last known state from the chain archive, and reactivates the contract. (This would also, finally, provide a real incentive for running an archival node.)
I’m quite eager to see how we can make Ethereum work in this new paradigm.