Following an extra two months of effort post the launch of the initial Python proof of concept release of Serenity, I am delighted to reveal that Serenity PoC2 is now accessible. While the release remains a considerable distance from a testnet-ready client, let alone a production-ready one, PoC2 introduces several significant advancements. Primarily, the aim of PoC2 was to execute the entire protocol, covering the fundamental corner cases (slashing stakes and deposits), ensuring that we understand every aspect of the protocol and witness it in operation, albeit in a highly limited test environment. This objective has been accomplished. In contrast to PoC1, which only encompassed the essential functionality necessary to operate Casper and EIP 101, PoC2 essentially comprises the entire Casper/Serenity protocol, including EIP 101 and 105.
The distinct features present in PoC2, which were absent in PoC1, include:
- EIP 105 application – EIP 105 is known as the “sharding scaffolding” EIP, which will facilitate somewhat parallel processing of Ethereum transactions and establish the groundwork for a forthcoming sharding methodology (yet to be defined). It employs the binary tree sharding system described here to permit transactions to identify an “activity range” that limits the addresses that transaction execution may access, ensuring that groups of transactions with distinct activity ranges can be executed concurrently. Moreover, it introduces SSTOREEXT and SLOADEXT opcodes, enabling contracts to access storage of the same address across different shards (given that the target shard resides within the activity range); this mechanism effectively signifies that the binary shard tree functions as both a super-contract sharding system and a sub-contract sharding framework simultaneously.
- Gas verification – the method that evaluates a transaction to ensure it appropriately pays gas. Currently, this is achieved by permitting transactions solely directed to accounts possessing a specific piece of “mandatory account code“, which grants the account holder the ability to define two segments of code: the checker code and the runner code. Checker code is intended to execute swift verifications like signature and nonce validation; the pattern-matching method allocates a maximum of 250,000 gas for the checker code to operate. Runner code is designed to carry out any costly actions that the transaction requires (e.g., invoking another contract with more than 250,000 gas). The main pragmatic implication of this is that users will be able to remit gas directly from contracts (e.g., multisig wallets, ring signature mixers, etc.) and will not need to consistently maintain a small quantity of ETH in their primary account for gas payments—as long as the gas charge from the contract stays within 250,000 gas, everything is fine.
- Ring signature mixer – part of the test.py script now includes the creation of a ring signature verification contract designed as a mixer: five participants send their public keys along with a deposit of 0.1 ETH, subsequently withdrawing the 0.1 ETH by specifying the address alongside a linkable ring signature, simultaneously ensuring that (i) each participant who deposited 0.1 ETH can withdraw it exactly once, and (ii) it’s impossible to determine which withdrawal matches which deposit. This process is implemented in a way that complies with the gas verifier, providing the key benefit that the transaction withdrawing the 0.1 ETH need not originate from a separate account that pays gas (a requirement for a ring signature implementation on traditional Ethereum, which risks disclosing privacy at the point of transferring ETH to that account for gas); rather, the withdrawal transaction may be sent independently, and the gas checker algorithm can confirm that the signature is valid and that the mixer will compensate the miner a fee if the withdrawal transaction is incorporated into a block.
- More accurate figures on interest rates and scoring rule parameters – the scoring rule (i.e., the system determining validator remuneration based on their betting) now constitutes a linear combination of a logarithmic scoring rule and a quadratic scoring rule, with parameters such that: (i) betting entirely correctly from the outset and with maximal “audacity” (willingness to approach 100% swiftly) on both blocks and stateroots will result in an expected reward of ~97.28 parts per billion per block, or 50.58% base annual yield, (ii) all participants incur a penalty of 74 parts per billion per block, or ~36.98% annually, hence the anticipated net return for perfect betting is ~22 parts per billion per block, or ~10% annually. Betting entirely incorrectly (i.e., betting with maximum certainty and being erroneous) on any single block or state root will obliterate >90% of your deposit, while partially incorrect betting will yield a significantly less severe but still unfavorable return. These parameters will continue to be fine-tuned to ensure that realistic validators can achieve reasonable profitability.
- More accurate validator induction criteria – a maximum of 250 validators, with the minimum ether requirement starting at 1250 ETH and increasing hyperbolically by the formula min = 1250 * 250 / (250 – v), where v is the current active count of validators (i.e., if 125 validators are active, the minimum escalates to 2500 ETH; if 225 validators are active, it becomes 12500 ETH; if 248 validators are active, it further climbs to 156250 ETH). Upon induction, you can make bets and earn returns for up to 30 million seconds (~1 year), and beyond that point, a unique penalty of 100 parts per billion per block begins accumulating, rendering further validation unprofitable; this encourages validator turnover.
- New precompiles including ECADD and ECMUL (essential for ring signatures), MODEXP, RLP decoding, and the “gas deposit contract” (a system employed in the mandatory account code to cover gas fees; theoretically, it could be coded in EVM if necessary but there may exist efficiency concerns with that)
- Reconstruction of LOG and CREATE as precompiles – the opcodes continue to exist for backward compatibility but simply invoke the precompile addresses. This represents a further advancement towards “abstraction”.
- New approach for betting directly on state roots
- Logic for identifying and punishing double bets and double blocks
- Logic for achieving consensus at a height even if a validator produced multiple blocks at that height
The protocol decisions made here are certainly not final; many are still undergoing active discussion within research circles. The forthcoming rounds of PoC releases will consequently aim toward crafting something akin to a Serenity node implementation, alongside a comprehensive p2p networking layer, with the ultimate goal of operating a Serenity testnet across multiple systems; concurrently, our research team will persist in meticulously refining the finer points of the protocol and ensuring that every single protocol resolution is made accurately and thoroughly justified.
In addition, we will soon be publishing more user-friendly materials concerning the Casper protocol specification and design rationale in the coming weeks, encompassing both the overarching consensus-by-bet concept and specific design choices spanning validator induction guidelines to betting frameworks and block proposer selection.
