Since their first introduction, the topic Casper FFG (Friendly Finality Gadget) vs. Casper CBC (Correct by Construction) has been widely discussed. CBC is a method to reason about consensus protocol while FFG is a precise proposal for a Proof of Stake-based consensus protocol execution.
CBC may have high overhead in protocol efficiency and complexity despite its safety. However, Vitalik explained how Ethereum 2.0 Serenity clients could benefit from CBC without sacrificing much efficiency. CBC fork choice rule is a major difference since it is highly inefficient in time requiring many validators compared to the FFG’s model.
Vitalik suggests that users can modify the fork-choice rule letting it run on a pseudorandomly chosen subset of validators to cap the fork-choice rule’s overhead while sacrificing a little fault tolerance. Eventually, this can give users the robustness of CBC while making a trade-off that could be worthwhile.
Ethereum 2.0 Test 100% Done, Says ETH Developer. https://t.co/kxmoLl8KBf @raulitojordan #ETH #Ethereum #Crypto #Cryptocurrency #Blockchain #Future #Tech
— Crypto_Vibes (@Crypto_Vibes) December 30, 2018
The Changes
The changes has been made to the validator deposit contract here to fulfill Solidity 0.51 rules and entirely align with the Vyper sample code in Ethereum 2.0 development. In its latest specification, there is a beacon chain state transition that features three major scenarios. They include block processing, regular slot processing without any received block, and epoch processing.
Even though there is no block for a particular slot, the beacon chain still performs some bookkeeping. But, some of the most essential details of the chain change whenever a block is received. Various things also happen within a state transition in a particular order during block processing. The implementation of block processing has acquired 100% test coverage as a best practice for critical code paths.
The latest operations show that epoch processing is the subsequent part of the state transition which occur every 64 slots of time in the entire beacon chain. The current changes in the state transition function required the team to refactor most of their core operations to get updated with the changes. The state transitions are now divided into per-epoch and per-slot transitions.
Functions
Per-epoch transitions are accountable for validator registry alterations, block justification management and finalization. On the other hand, per-slot transitions focus on saving temporary records and aggregate signature verifications. Balances are adjusted for penalties or rewards while validators are exited or validated during epoch transitions.
The big changes in the spec prompt the development team to refactor most of their blockchain services to accommodate them. The node’s internal clock is reliant on the block processing ensuring that no state transitions occur until blocks are received.
Other updates in the Merged Code, Pull Requests, and Issues category of the announcement include the full Simple Serialize specification complete with tree hashing algorithm. The whole specification for Simple Serialize (SSZ) was completed and joined via a series of PRs for an issue thread. The merged Merkle tree hashing algorithm will make state access and light client significantly easier and efficient with the help of proper serialization.
In the same update, it was announced that the Go-BLS Signatures project is ready for use. The project will be used for signature verification and aggregation on the beacon chain as per the Ethereum 2.0 Serenity specification.
Also, the progress in the pure state transition function was highlighted with the help of end-to-end tests. The extensive tests will ensure that the internal beacon chain logic will run on all clients to guarantee conformity.
Future Work. Starting Q1 2019
The team doesn’t specify the exact day when Ethereum 2.0 could be released, but the document states that starting from the first quarter of 2019, the plan at Prysmatic is to develop and launch an Ethereum 2.0 Serenity phase 0 testnet.
The team is working relentlessly to deliver a large and strong implementation which has nearly no missing components from the actual thing. They also aim to complete validator rotation after some small rework and optimization in the spec.
Most of the spec changes are fully cosmetic or optimizations-based with the primary Serenity Phase 0 being set with reasonable changes. A batched sync mode for beacon blocks features a merged PR that will let nodes request blocks in batches instead of one at a time.
Thus, it will enhance efficiency since a single broadcasted message can send multiple blocks reducing the required time for a node to sync to the current head. Various service health checks for testnet preparation are also scheduled for the near future.
The current changes in the spec made the team to reconsider their validator client architecture. The new changes will need validator clients to sign the proposal data whenever they are proposing a block and then send the same block to the beacon mode.
The proposers will also require approval for the chosen state root from the beacon node for block proposals. For enhanced security and efficiency, new RPC methods are necessary to send and receive data structures between the involved clients.
The Upcoming Constantinople Hard Fork
Currently, the date is not precisely set, but the sources suggest, that Constantinople hard fork will most likely activate on Wednesday, Jan 16th, probably around 7am UTC. Current average block time is 14.48 seconds. 104407 blocks to go[/responsivevoice] (6975593/7080000.
Upcoming Ethereum’s Constantinople Hard Fork – All You Need To Know. https://t.co/nbjMsTEvVY @ethereum #Ethereum #ETH #Hardfork #Constantinople #Crypto #Cryptocurrency #Blockchain
— Crypto_Vibes (@Crypto_Vibes) December 28, 2018
Follow us on Facebook , Twitter and Telegram
