“`html
This week signifies the conclusion of our fourth hard fork, Spurious Dragon, and the ensuing state clearing process, which are the final phases in the two-hard-fork solution addressing the recent Ethereum denial of service incidents that hindered the network in September and October. Gas limits are currently being raised to 4 million as the network stabilizes, with further increases planned upon the completion of additional optimizations to clients that will enhance the speed of state data retrieval.
Amid these developments, we have observed significant advancements from the C++ and Go development teams, including enhancements to Solidity tools and the launch of the Geth light client. Meanwhile, the Parity, EthereumJ, and other external development teams have also been making strides independently with technologies such as Parity’s warp sync; numerous innovations have already reached the average user, and more are on the way. Concurrently, however, a considerable amount of subtle progress has been underway in the research domain. While some of this work has often been high-level in scope and low-level protocol improvements understandably take time to integrate into the main Ethereum network, we anticipate that the outcomes of this effort will soon yield positive results.
Metropolis
Metropolis represents the next significant anticipated hardfork for Ethereum. Although Metropolis is not as ambitious as Serenity and will not introduce proof of stake, sharding, or any similarly extensive alterations to Ethereum’s functionality, it is expected to encompass a series of smaller enhancements to the protocol that are collectively far more impactful than Homestead. Key advancements include:
- EIP 86 (account security abstraction) – moves the logic for verifying signatures and nonces into contracts, enabling developers to test new signature protocols, privacy-preserving methods, and modifications to sections of the protocol without necessitating further hard forks or protocol-level support. It also permits contracts to cover gas costs.
- EIP 96 (blockhash and state root alterations) – streamlines the protocol and client implementations, facilitating upgrades to light client and fast-syncing protocols, enhancing their security significantly.
- Precompiled/native contracts for elliptic curve operations and large integer calculations, facilitating efficient implementations for applications utilizing ring signatures or RSA cryptography
- Various enhancements to efficiency that enable swifter transaction processing
A substantial portion of this work is part of a long-term strategy to transition the protocol towards what we refer to as abstraction. In essence, rather than having intricate protocol rules dictating contract creation, transaction validation, mining, and various other system behaviors, we attempt to embed as much of the Ethereum protocol’s logic as feasible into the EVM itself, with protocol logic simply functioning as a collection of contracts. This reduces client complexity, minimizes the long-term risk of consensus failures, and simplifies and safeguards hard forks – potentially allowing a hard fork to be defined merely as a configuration file that modifies the code of a handful of contracts. By minimizing the number of “moving parts” at the foundational level of the protocol in this manner, we can significantly lessen Ethereum’s vulnerability to attacks and provide more options for user experimentation within the protocol: for instance, rather than the protocol upgrading to a new signature system simultaneously, users are free to explore and implement their own modifications.
Proof of Stake, Sharding and Cryptoeconomics
Throughout the past year, research regarding proof of stake and sharding has been incrementally progressing. The consensus algorithm we have been developing, Casper, has undergone several iterations and proof-of-concept releases, each contributing valuable insights into the interplay between economics and decentralized consensus. PoC release 2 was introduced at the beginning of this year; however, that approach has since been set aside as it became clear that requiring every validator to dispatch a message every block, or even every ten blocks, imposes excessive overhead to remain viable. The more conventional chain-based PoC3, as outlined in the Mauve Paper, has proven to be more successful; even though there are some issues with the incentive structures, the shortcomings are significantly less severe.
Vlad, myself, and many volunteers from the Ethereum research team convened at the bootcamp at IC3 in July, collaborating with university scholars, Zcash developers, and others to deliberate on proof of stake, sharding, privacy, and various challenges, leading to significant progress in bridging our proof of stake methodology with those of others addressing similar issues. A newer, simplified version of Casper began to take shape, while Vlad and I pursued two distinct pathways: I aimed to develop a straightforward proof of stake protocol that would exhibit favorable properties with minimal deviations from proof of work, while Vlad adopted a “correct-by-construction” methodology to reconstruct consensus from the ground up. Both approaches were presented at Devcon2 in Shanghai in September, marking where we stood two weeks ago.
As November concluded, the research team (temporarily joined by Loi Luu, famed for validator’s dilemma) along with…
“`with some of our long-standing contributors and associates, convened for a fortnight for a research seminar in Singapore, aiming to unify our perspectives on various matters regarding Casper, scalability, consensus incentives, and state size management.
A significant subject of dialogue was developing a rigorous and generalized strategy for establishing optimal incentives in consensus protocols – whether you are formulating a chain-based protocol, a scalable sharding solution, or an incentivized variation of PBFT. Can we devise a generalized method to accurately allocate the appropriate rewards and penalties to all participants, leveraging only verifiable evidence that could be incorporated into a blockchain as input, and in a manner that possesses optimal game-theoretic characteristics? We presented some concepts; one of these, when tested within proof of work as an experiment, immediately facilitated a new approach to countering selfish mining attacks and has also shown considerable promise in addressing persistent concerns in proof of stake.
An essential objective of our approach to cryptoeconomics is to ensure maximum incentive-compatibility even within a framework that accommodates majority collusion: even if an adversary controls 90% of the network, is there a means to ensure that, if the attacker strays from the protocol in any detrimental manner, the attacker incurs losses? At least in certain scenarios, such as short-range forks, the response appears to be affirmative. In other situations, such as censorship, accomplishing this aim is considerably more challenging.
A secondary objective involves constraining “griefing factors” – that is, ensuring that an attacker cannot cause losses to other participants without incurring losses of similar magnitude themselves. A further aim is to ensure that the protocol continues to perform to the best of its ability under various extreme conditions: for example, what occurs if 60% of the validator nodes go offline at once? Traditional consensus protocols like PBFT, and proof of stake protocols influenced by such models, simply cease operating under these circumstances; our goal with Casper is to allow the chain to progress, and even if the chain cannot guarantee all of the assurances it typically provides under these conditions, the protocol should still aim to do as much as possible.
One of the primary productive outcomes of the workshop was bridging the divide between my current “exponential ramp-up” methodology for transaction/block finality in Casper, which incentivizes validators for placing increasingly confident bets and penalizes them if their predictions are incorrect, and Vlad’s “correct-by-construction” methodology, which focuses on penalizing validators only if they equivocate (i.e. sign two contradictory messages). By the workshop’s end, we began collaborating on strategies to merge the strengths of both approaches, and we have already started leveraging these insights to enhance the Casper protocol.
Meanwhile, I have drafted several documents and FAQs that elaborate on the current state of understanding regarding proof of stake, sharding, and Casper to assist in bringing 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; currently slightly outdated but will be updated shortly)
State size management
Another crucial aspect of protocol formulation is state size management – specifically, how can we decrease the volume of state information that full nodes must monitor? Presently, the state is approximately one gigabyte in size (the remaining data that a geth or parity node presently retains is the transaction history; this information could theoretically be pruned when a reliable light-client protocol for retrieving it is established), and we have already witnessed how the utility of the protocol declines in numerous ways if it expands significantly; furthermore, sharding becomes considerably more complex as sharded blockchains necessitate nodes to be capable of swiftly downloading portions of the state as part of their responsibilities as validators.
Some suggestions that have been proposed include removing old non-contract accounts with insufficient ether to initiate a transaction, and executing this securely to prevent replay attacks. Other proposals entail significantly increasing the costs associated with account creation or data storage and doing so in a manner that is more independent from the method of covering other types of expenses within the EVM. Additional recommendations involve implementing time restrictions on the lifespan of contracts, and charging a higher fee for establishing accounts or contracts with extended time limits (the time constraints in this context would be generous; it would still remain economically feasible to establish a contract lasting several years). There is an ongoing discussion within the developer community regarding the optimal strategy to achieve the objective of maintaining a compact state size while simultaneously ensuring that the core protocol remains maximally user and developer-friendly.
Miscellaneous
Further domains of low-level protocol enhancement on the horizon include:
- Several “EVM 1.5” suggestions that enhance the EVM’s compatibility with static analysis, promoting compatibility with WASM
- The incorporation of zero knowledge proofs, probably through either (i) a dedicated ZKP opcode/native contract, or (ii) an opcode or native contract for the primary computationally intensive elements in ZKPs, especially elliptic curve pairing calculations
- Greater degrees of abstraction and simplification of the protocol
Anticipate more comprehensive documents and discussions on all these subjects in the forthcoming months, particularly as efforts to transform the Casper specification into a functional proof of concept release that could operate on a testnet continue to advance.