This week marks the completion of our fourth hard fork, spurious dragonand the subsequent state compensation processthe final steps in the two-fork solution for recent Ethereum denial of service attacks which slowed down the network in September and October. Gas limits are in the process of being increased to 4 million as the grid returns to normal, and will be further increased as additional customer optimizations are completed to enable faster reading of health data.
Amid these events, we’ve seen great progress from the C++ and Go development teams, including improvements to Solidity tools and the launch of the Geth thin clientand Parity, EthereumJ, and other third-party development teams have continued to push forward on their own with technologies like Parity’s. warp sync; Many of these innovations have already reached the hands of the average user, and still others soon they will come At the same time, however, there has been a great deal of quiet progress on the research side, and while that progress has in many cases been rather blue in nature and low-level protocol improvements necessarily take a while to achieve . on the Ethereum mainnet, we hope that the results of the work will start to bear fruit very soon.
Metropolis
Metropolis is the next big hard fork planned for Ethereum. While Metropolis is not as ambitious as Serenity and will not include proof-of-stake, sharding, or any other similar sweeping changes to how Ethereum works, it is expected to include a number of small improvements to the protocol, which together are much more substantial. that Homestead. The main improvements include:
- EIP 86 (Account Security Abstraction) – Moving the logic for verifying signatures and nonces to contracts, allowing developers to experiment with new signature schemes, privacy-preserving technologies, and modifications to parts of the protocol without the need for further forks or protocol-level support. It also allows contracts to pay for gas.
- EIP 96 (blockhash and state root changes) – simplifies protocol and client implementations, and allows upgrades to thin client and fast sync protocols that make them much more secure.
- Precompiled/native contracts for elliptic curve operations and large integer arithmetic, allowing applications based on ring signatures or RSA cryptography to be implemented efficiently
- Various efficiency improvements that allow for faster transaction processing
Much of this work is part of a long-term plan to move the protocol toward what we call abstraction. Essentially, instead of having complex protocol rules that govern contract creation, transaction validation, mining, and other aspects of system behavior, we try to put as much of the Ethereum protocol logic as possible into the EVM itself, and make the protocol logic simply a set of contracts. This reduces client complexity, reduces the long-term risk of consensus failures, and makes forks easier and safer; Potentially, a hard fork could simply be specified as a configuration file that changes the code of some contracts. By reducing the number of “moving parts” at the bottom level of the protocol in this way, we can greatly reduce Ethereum’s attack surface and open up more parts of the protocol to user experimentation: for example, instead of upgrading the protocol to a new signature scheme all at once, users are free to experiment and implement their own.
Proof of stake, sharding and cryptoeconomics
Over the past year, research on proof-of-stake and sharding has moved on quietly. The consensus algorithm we have been working on, Casper, has gone through several iterations and proof-of-concept versions, each of which taught us important things about the combination of economics and decentralized consensus. PoC version 2 it arrived earlier this year, though that approach has now been abandoned as it has become obvious that requiring each validator to send a message every block, or even every ten blocks, requires too much overhead to be sustainable. The most traditional string-based PoC3as described in the mauve paper, has been more successful; Although there are imperfections in the way incentives are structured, the flaws are much less serious in nature.
Myself, Vlad and many volunteers from the Ethereum research team met at the training camp at IC3 in July with university academics, Zcash developers, and others to discuss proof-of-stake, sharding, privacy, and other challenges, and substantial progress was made in bridging the gap between our proof-of-stake approach and that of others who They have been working on similar problems. . A newer, simpler version of Casper began to solidify, and myself and Vlad continued down two separate paths: myself aiming to create a simple proof-of-stake protocol that would provide desirable properties with as few proof changes as possible of work, and Vlad taking a “fix-by-build” approach to rebuilding the consensus from scratch. Both were featured at Devcon2 in Shanghai in September, and that’s where we were two weeks ago.
In late November, the investigation team (temporarily joined by Loi Luu from validator’s dilemma fame), along with some of our old volunteers and friends, came together for a two-week research workshop in Singapore, with the goal of gathering our thoughts on various topics related to Casper, scalability, consensus incentives, and control of file size. condition.
A major topic of discussion was the development of a rigorous and generalizable strategy for determining optimal incentives in consensus protocols: whether you’re building a chain-based protocol, a scalable sharding protocol, or even an incentivized version of PBFT, what about? can we think of something? with a generalized way of correctly assigning the correct rewards and penalties to all participants, using only verifiable evidence that could be placed on a blockchain as input, and in a way that would have optimal game-theoretical properties? We had some ideas; one of them, when applied to proof-of-work as an experiment, immediately led to a new path to solving selfish mining attacks, and has also shown extremely promise in addressing long-standing problems in proof-of-stake.
A key goal of our approach to crypto is to ensure as much incentive compatibility as possible, even in a model with majority collusion: even if one attacker controls 90% of the network, is there a way to ensure that if the attacker deviates from the protocol in a harmful way, the attacker loses money? At least in some cases, like short-range forks, the answer seems to be yes. In other cases, such as censorship, achieving this goal is much more difficult.
A second goal is to limit “duel factors,” that is, to ensure that there is no way for an attacker to cause other players to lose money without losing close to the same amount of money. A third goal is to ensure that the protocol continues to perform as well as possible under other types of extreme conditions: for example, what if 60% of the validator nodes go offline simultaneously? Traditional consensus protocols, such as PBFT, and proof-of-stake protocols inspired by such approaches, simply stop at this point; our goal with Casper is to keep the chain going, and even if the chain can’t provide all the guarantees it normally does under such conditions, the protocol should still try to do as much as it can.
One of the main beneficial outcomes of the workshop was bridging the gap between my current approach of “exponentially increasing” transaction/block finality in Casper, which rewards validators for placing bets with greater confidence and penalizes them if their bets are incorrect. , and Vlad’s “correct by construction” approach, which emphasizes penalizing validators only if they make a mistake (ie, they sign two incompatible messages). At the end of the workshop, we started working together on strategies to combine the best of both approaches and have already begun to use these insights to improve the Casper protocol.
In the meantime, I’ve written a few documents and FAQs detailing the current state of thinking regarding proof-of-stake, sharding, and Casper to help bring anyone interested up to speed:
https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQ
https://github.com/ethereum/wiki/wiki/Sharding-FAQ
https://docs.google.com/document/d/1maFT3cpHvwn29gLvtY4WcQiI6kRbN_nbCf3JlgR3m_8 (Mauve paper; now a bit outdated but will update soon)
state size control
Another important area of protocol design is state size control, ie how can we reduce the amount of state information full nodes need to keep track? Right now, the size of the state is about a gigabyte (the rest of the data that a geth or parity node currently stores is transaction history; in theory, this data can be removed once there is a robust protocol of thin client to get them), and we’ve already seen how the usability of the protocol degrades in various ways if it grows much larger; Additionally, sharding becomes much more difficult as sharded blockchains require nodes to be able to quickly download parts of the state as part of the process of serving as validators.
Some proposals that have been raised have to do with delete old accounts without contract without enough ether to send a transaction, and doing so safely to avoid replay attacks. Other proposals involve simply making it much more expensive to create new accounts or store data, and to do it in a way that is more decoupled from how we pay other types of costs within EVM. Other proposals include putting time limits on the length of contracts and charging more to create accounts or contracts with longer time limits (time limits here would be generous; it would still be affordable to create a contract that lasts multiple years). There is currently an ongoing discussion in the developer community about how best to achieve the goal of keeping the state size small while keeping the core protocol as user and developer friendly as possible.
Miscellaneous
Other low-level protocol improvement areas on the horizon include:
- Several Proposals “EVM 1.5” that make the EVM more friendly to static analysis, facilitating compatibility with WASM
- Integration of zero-knowledge proofs, likely via (i) an explicit ZKP native opcode/contract, or (ii) a native opcode or contract for the computationally intensive key ingredients in ZKP, particularly the pairing computations of elliptic curves
- Greater degrees of abstraction and simplification of protocols
Expect more detailed documents and conversations on all of these topics in the coming months, especially as work progresses to turn the Casper specification into a viable proof-of-concept version that could be run by a testnet.
