After an additional two months of work after the release of Serenity’s first Python proof-of-concept version, I am pleased to announce that Serenity PoC2 It is now available. Although the release is still far from a testnet-ready client, let alone a production-ready one, PoC2 brings with it a number of important improvements. First of all, the goal of PoC2 was to implement the full protocol, including the basic corner cases (slashing stakes and deposits), to make sure that we have an idea of every detail of the protocol and see it in action even if in an environment highly restricted test. This objective has been achieved. While PoC1 included only the minimal functionality needed to run Casper and EIP 101, PoC2 essentially includes the full Casper/Serenity protocol, EIP 101 and 105 included.
Specific features that can be found in PoC2 that were not available in PoC1 are as follows:
- EIP 105 Implementation – EIP 105 is the “sharding scaffolding” EIP, which will allow Ethereum transaction processing to be somewhat parallelized, and lay the groundwork for a later sharding scheme (which has yet to be determined). It uses the binary tree fragmentation mechanism described here to allow transactions to specify an “activity range” that restricts the addresses that transaction execution can touch, ensuring that sets of transactions with disjoint activity ranges can be processed in parallel. also introduces STOREEXT Y SLOADEXT opcodes to allow contracts to access storage of the same address in other shards (as long as the destination shard is within range of activity); this mechanism essentially means that the binary shard tree serves as both a supercontract sharding mechanism and a subcontract sharding mechanism at the same time.
- gas check – the algorithm that matches the pattern of a transaction to make sure you pay for gas correctly. Currently, this is accomplished by only accepting transactions that go to accounts that have a particular portion of “account code required“, which gives the account holder the freedom to specify two pieces of code: the verifier code and the broker code. The verifier code is designed to perform quick verifications, such as signing and nonce verification; the Pattern matching algorithm gives a maximum of 250,000 gas for the verifier code to execute.The broker code is meant to perform whatever expensive operation the transaction needed to perform (for example, calling another contract with more than 250,000 of The main practical consequence of this is that users will be able to pay for gas directly from contracts (e.g. multisig wallets, ring signature mixers, etc.) and will not need to always separately have a small amount of ETH in your main account to pay gas, as long as the contract gas payment is made within 250,000 gas everything is good.
- Ring Signature Mixer – part of the test.py script now includes instantiation of a ring signature verification contract which is designed as a mixer: five users submit their public keys along with a deposit of 0.1 ETH and then withdraw the 0.1 ETH by specifying the address with a bindable ring signature, simultaneously guaranteeing that (i) everyone who deposited 0.1 ETH will be able to withdraw 0.1 ETH exactly once, and (ii) it is impossible to know which withdrawal corresponds to which deposit. This is implemented in a gas-verifier-compliant way, providing the key advantage that the transaction withdrawing the 0.1 ETH does not need to be sent from an additional account that pays for gas (something that a ring signature implementation in addition to the current ethereum would have to do it, and that causes a possible privacy leak at the moment you transfer the ETH to that account to pay for the gas); instead, the withdrawal transaction can simply submit itself, and the gas verifier’s algorithm can verify that the signature is correct and that the mixer will pay a fee to the miner if the withdrawal transaction is included in a block.
- More accurate figures on interest rates and scoring rule parameters – the scoring rule (i.e. the mechanism that determines how much validators are paid based on how they bet) is now a linear combination of a logarithmic scoring rule and a quadratic scoring rule, and the parameters are such that : (i) staking absolutely correctly immediately and with maximum “bravery” (willingness to converge 100% quickly) on both blocks and stateroots will yield an expected reward of ~97.28 parts per billion per block, or 50.58 % base annual return, (ii) there is a penalty of 74 parts per billion per block, or ~36.98% per year, which everyone pays, so the expected net return from staking perfectly is ~22 parts per billion per block, or ~10% per year. Betting the absolute wrong way (i.e. betting with the highest certainty and being wrong) on any individual block or root state will destroy >90% of your deposit, and betting the slightly wrong way will result in a much less extreme but still negative return. These parameters will continue to be tuned to ensure that realistic validators can be reasonably profitable.
- More precise validator induction rules – maximum 250 validators, the minimum amount of ether starts at 1250 ETH and increases hyperbolically with the formula min = 1250 * 250 / (250 – v) where v is the current active number of validators (i.e. if there are 125 active validators the minimum becomes 2500 ETH, if there are 225 active validators it becomes 12500 ETH, if there are 248 active validators it becomes 156250 ETH). When admitted, you can place bets and profit for up to 30 million seconds (~1 year), and after that point, a special penalty of 100 parts per billion per block begins to apply, making subsequent validation not be profitable; this forces rotation of the validator.
- new precompiles including ECADD and ECMUL (critical for ring signatures), MODEXP, RLP decryption, and the “gas deposit contract” (a mechanism used in mandatory account code to pay for gas; could theoretically be written in EVM code if necessary, but there may be efficiency issues with that)
- Redesign of LOG and CREATE as precompiles – the opcodes still exist for backward compatibility purposes, but they simply call the precompile addresses. This is one more step in the direction of “abstraction”.
- New mechanism to bet directly on state roots
- Logic to detect and cut double bets and double blocks
- Logic for reaching consensus at a height even if a validator produced multiple blocks at that height
The protocol decisions made here are not final; many of them are still being actively discussed within research channels. Future rounds of PoC releases will move towards creating something semblance of a Serenity node implementation, along with a proper p2p network layer, with the ultimate goal of running a Serenity testnet between multiple computers; At the same time, our research team will continue to work on the finer details of the protocol and ensure that each protocol decision is made correctly and well justified.
In addition, we will be posting more accessible materials on the Casper protocol specification and design rationale in the coming weeks, covering both the broad concept of consensus by betting as well as specific design decisions ranging from validator induction rules to betting mechanisms. and selection of block proponents.
