Hard Medium Problems in Cryptocurrency Ethereum
Vitalik gave a great talk on Hard Problems in Cryptocurrency http://vitalik.ca/files/problems.pdf
(which also apply to Ethereum).
I've been working with Ethereum smart contracts on an intimate level for several weeks now while creating EtherScripter
. I've been taking note of (what I see as) Ethereum's "medium size" problems. These are problems with approachable solutions that Ethereum still has time to address. My notes:Byte arrays are yucky
. Starting in POC-4 each contract must expose a unique non-standard API defined in terms of bytes
. This is a rather low level and complex way for contracts to define their inputs
. Arbitrary byte arrays are unfriendly to high-level programmers and impossible to transparently expose as a simple list by high-level languages
. The simple list of 32-byte inputs in POC-3 was much easier to work with for a contract developer. However there was some memory overhead for the "unused bytes" per item and it didn't offer an elegant way to send a chunk of data > 32 bytes.
. Suggest: provide a standard mechanism for contracts to define their expected inputs and return values as part of the contract itself (like a "function signature"). Then calling contracts and contract UI's can deal with these as a list of parameters rather than a mess of bytes. Large values in contracts are ambiguous
. Each contract must separately decide if large values represent big numbers or negatives.
. (If a contract has stored my "balance" as 2^255, I don't know if I'm really rich or "owe 1")
. A key benefit of smart contracts is they (should) unambiguously define the agreement
. Suggest: Define upper range numbers as being negative for all contracts and remove unsigned operators from EVM to enforce consistency
. (the largest 16-byte postive number is still super big and the very rare applications that require bigger numbers [universe simulation??] can always internally define their own 'bignum' using multiple values) Market pricing of "compute" is not granular enough
. In POC-4 the cost of contract execution s driven by market forces (via "gas") but...
. The various components of compute that gas buys (processor, storage, memory) are hard coded to arbitrary ratios of a single gas price.
. Currently a storage step costs 100x that of a compute step(?). This probably grossly underestimates the cost difference since storage must persist forever and a compute step is only scarce for an instant.
. In the real world storage and memory and compute cycles will vary dramatically against each other and a long term solution would accommodate fluctuating market values of these resources against each other -- otherwise weird incentives develop for miners. Cost of consensus is always linear but its benefit plateaus
. When there are just a few nodes, the benefit of another node is large, but when there is a million, the additional benefit of another node is negligible. Yet the millionth node imposes the same additional cost on use of the network as the 2nd one.
. Currently there is no way for a smart contract author to select for the amount of consensus that is appropriate for their particular application.
. A single blockchain will inevitably be a size that's too expensive for many applications and supports insufficient consensus for many others. Also, it's not clear that current incentives drive a single block chain toward a size that represents an ideal balance.
. Suggest: consider a sharded blockchain approach where a contract author has a choice among different levels of consensus. Example: contract author can choose a network of 1, 10, 100, 1000, 100000 or 1000000+ nodes (to the extent they are available). Costs would of course be proportional and this would effectively make Ethereum useful for a much broader range of uses. The market cost for contract storage is infinity
. The market cost for 32-bytes of storage is theoretically Infinity.
. That's because the miner (or the mining network collectively) is expected to store this value forever.
. Looking at the problem another way, imagine the Ethereum blockchain is 10 TB after a year. Under the current model, a prospective miner must invest in a 10 TB hard drive before he can even begin... and he receives no fees for storing this data... those fees were earned by previous miners when the contract ran and stored the data initially. Imagine 3 years later, it's 100 TB, 6 years 1000 TB. There's increasing cost for mining participation that is not directly incentivized by any revenue under the current model. This will eventually lead to miners dropping out of the network until none are left.
. Suggest: Contract storage should cost the contract some fee --every single block-- for proper market incentivization.
. This is the only way to ensure balance, but will entail huge costs for contracts unless some mechanism is introduced to let storage exist on a subset of nodes (for correspondingly less ongoing cost)