I’ve fallen back a lot on my Vyper series. There are actually more than one reasons, including mental health, life management, relationships, work, schoolwork… But really, the part that will be interesting to you, the readers who have been waiting for the type system article for a quarter of a year, is the part about Vyper itself, and about Ethereum.
The great gas crisis of Ethereum
So you might have heard of Gastoken. It has sent the Ethereum community into an uproar. While “tokenizing gas” sounds quite harmless at first, when you examine what it actually does, it will definitely start looking a lot more diabolical.
The EVM has a relatively new feature that was meant to incentivize releasing unused Storage, and thus reduce the size of State. When you release Storage (by setting it to zero), you get some gas refunded. Enter gascoin. Gascoin is minted by spamming State with useless data, thus “deep freezing” the gas paid for the operation — later, by setting these fields back to zero, users can thaw the gas. Well… you can guess whether the gas refund feature has thus made State smaller… or bigger.
So… Enter the Ethereum developer community, and a revolutionary proposal to deal with Gastoken once and for all: rent, aka pay-to-stay. In the indefinite future, all Ethereum contracts will require regular rent payments, and contracts that fall behind on their rent will be evicted from State.
Now, to ensure that value isn’t destroyed by eviction, interested parties will be able to resuscitate evicted contracts by paying a fee. Now the deep specifics of this is not entirely worked out yet as far as I understand, I’m pretty sure that resuscitating a contract with megabytes in Storage (ie. any sufficiently popular ERC20 token) will cost a pretty penny.
So… this pretty much means that current Ethereum development practice, based on central registry contracts, is dead. ERC20 is dead. ENS is dead. Cryptokitties are… actually no, Cryptokitties aren’t dead.
Corporate, privately owned central registries, with a clear offchain owner who gets a cut of the money flowing through their DApp can of course keep working, as the owner will be able to take some of their profits, and pay the rent from it. It’s decentralized, unowned registries, you know the kind that Ethereum was built to create, that will have issues.
A question raised on Ethresear.ch was, after I argued the point above, was what technical shortcomings central registries have, beyond the rent issue. Well, the rent issue is the issue. Or rather, it’s similar to CO2 emission taxes — it’s not emission taxes that make hydrocarbon fuels unsustainable, it’s global warming. Emission taxes are only a measure attempting to limit the issue.
Central registry contracts are unsustainable because they rely on free access to a very limited resource — Ethereum State size — that is currently subsidized in an unsustainable way. Just leaving everything as it is is no longer an option. Not after Gascoin.
You’re in Limbo, you just don’t know it
Now, while I’m sure we’ll come up with something to make sure the existing wealth that is tracked by Ethereum doesn’t become unacessible, what this means is that any decentralized token, any truly decentralized contract that contains an address registry recording ownership, is pretty much a dead man walking.
There IS a fix to save ERC20 (the interface, not the implementation), and in general the ability of Ethereum to do all the stuff we took for granted. Vitalik mentioned it in the Ethresear.ch thread linked above — a stateless central contract, and independent child contracts for each individual owner. With a central provenance check mechanism, this actually is viable!
Too bad you cannot use it yet. You see, for this to really, nicely, seamlessly work, we’ll need CREATE2. An EVM opcode that will allow the creation of child contracts with a custom nonce, as opposed to the TxCount of the parent. Thus, the creation nonce could be derived from the owner’s address, making for a star schema of contracts implementing a “mapping”. The central, stateless contract can still expose the ERC20 interface, and users can still use it as they expect it to work.
And CREATE2 doesn’t exist yet. Now you can still build tokens that use a similar multi-contract structure, only one that uses random child contract addresses, and results in a UTXO-like user experience… But this isn’t all that pretty either, as the EVM currently offers no access to a contract’s own TxCount (which means additional Storage writes for keeping track, and an additional point of failure). Also, provenance checking in a contract is less than comfortable at the moment (maybe I’ll do a separate article on that). For those curious, this is how you do it in Solidity, to my best knowledge:
function childAddress(uint256 _nonce) public view returns (address)
{
//if(_nonce == 0x00) return address(keccak256(byte(0xd6), byte(0x94), address(this), byte(0x80))); // no 0 nonce on contracts
if(_nonce <= 0x7f) return address(keccak256(byte(0xd6), byte(0x94), address(this), byte(_nonce)));
if(_nonce <= 0xff) return address(keccak256(byte(0xd7), byte(0x94), address(this), byte(0x81), uint8(_nonce)));
if(_nonce <= 0xffff) return address(keccak256(byte(0xd8), byte(0x94), address(this), byte(0x82), uint16(_nonce)));
if(_nonce <= 0xffffff) return address(keccak256(byte(0xd9), byte(0x94), address(this), byte(0x83), uint24(_nonce)));
if(_nonce <= 0xffffffff) return address(keccak256(byte(0xda), byte(0x94), address(this), byte(0x84), uint32(_nonce)));
revert(); // more than 2^32 nonces not realistic
}So any contract you write with currently workable practices is unsustainable. Practices that would result in sustainable contracts are either unworkable or extremely uncomfortable (for the user too, not just for the developer). You’re in limbo, you just didn’t realize it yet.
Well now you know.
So what?
I dunno. Lobby your local representative for the inclusion of CREATE2 in the next hardfork. It’s pretty bad as it looks in my opinion, and people’s total indifference in the face of impending doom is quite similar to how oil conglomerates treat global warming.
We’ll see. I think pay-to-stay, CREATE2, and a good, reliable and cheap way to do provenance checks will make Ethereum much better and more sustainable, and Ethereum contracts much prettier from an engineering standpoint. But that needs all of this implemented, and that doesn’t change that none of this is implemented, and that doom is coming to Sarnath whether pay-to-stay becomes reality or not.
ps. This is not an “Ethereum is dead, long live EOS / NEO / fuckcoin / whatever else” shitpost. I’m invested in Ethereum, both financially and personally. I love the vibrant dev community, the ethos of decentralization, the intellectual depth of development discussions. I’m sure Ethereum will not only survive, but thrive. Great things are on the way. That said, there will be bumps along the road. This is one of them.
