Ethereum 2.0 Casper+Sharding Development Update # 12 — Prysmatic Labs
Our biweekly updates written by the entire Prysmatic Labs team on Ethereum 2.0
Research Updates
Simple, Synchronous Cross-shard Transaction Protocol
We all know cross shard communication can be inefficient due to waiting for multiple rounds of confirmations, we have previously discussed train and hotel problems and cross shard yanking. We can even solve such problem but it’s still highly imperfect with high latency. We would like to communicate cross shard in one transaction. As stated in this latest sharding research post, such solution would require data and state separation due to the potential of reorgs. A single reorg on one shard could potentially mess up cross shard communications every shard.
We’ll need a state execution engine as abstraction where a node is aware of the state of all the shards at an arbitrary height N-1. To extend to that, it should know state roots and block hashes of other shards N-1. Given these additional information, if any shard reverts, the node can still execute so the ordering of data on other shards would be preserved.
Layer-2 Should be More Innovative in the Long Run
Vitalik Buterin recently posted about how layer-1 blockchain development should be more innovative in the short term, but less so in the long term recently on his website. The key idea draws parallels to the development of Internet protocols as public goods and how their development has noticeably stagnated (SMTP, DNS, and More). Instead, protocols should reach a complexity and scalability level that is suitable enough for layer-2 innovation to be the norm. That is, Ethereum should stick to its mantra of “having no features”. Layer-2 solutions can leverage the finality and transparency of layer-1 in order to bring innovative applications, better execution engines and more. A key point to note is that we are not yet close in creating a robust enough base layer for this innovation to occur. At Prysmatic Labs, we stand right at the crossroads of all these important considerations. We take it very seriously as a mission within our team to build a robust protocol for Ethereum moving forward that can last the test of time.
Merged Code, Pull Requests, and Issues
Aligned All Our Code With Latest 2.1 Spec
We have implemented a way for beacon nodes to bootstrap from a genesis state. It’s important all the beacon nodes start out with the same global state and share a same common validator set. We also have implemented how nodes should process cycle transition. A cycle is essentially a span of blocks which all eligible validators get one opportunity to make a single vote. During a cycle transition, a beacon node calculates the total set of validators that attested to the span of cycle blocks and determines how much deposit each block has been backed by the validators. With enough deposits, a bock can be called justified, and with enough justified blocks in a a row, a finalized block can occur. A reward factory will be calculated on top of base reward to determine the quadratic penalty quotient. Finally, every beacon node will adjust its validators’ balances.
Store Incoming Blocks and States Into a DAG
As part of a series of PRs in implementing the Beacon Chain fork-choice rule, we started by setting up the structure for determining canonical blocks from a DAG of received block and state tuples. We initially created a simple map that would be used as a DAG tracking lists of received blocks and states for each slot number upon which an updateHead function would be called to finalize and determine what is canonical.
We finished the Pull Request here and used a “naive” fork choice rule, where it selects the first received block in the DAG as canonical for each slot.
Nishant Das from our team then took the initiative to improve the system and instead store all processed, incoming blocks into persistent storage and only keep a simple, in-memory slice of block hashes we have yet to process for the latest slot number and then apply the fork choice rule easily. This approach makes the fork choice rule easier on memory requirements of the running beacon node.
For those unfamiliar, the real fork choice rule we will use is something called “Immediate-Message GHOST” coined by Vitalik in his ETHResearch post here.
Created Casper Package For All Our FFG Rewards/Penalties Logic
Lots of new exciting research developments are coming into the beacon chain v2.1 spec including a well-defined set of rewards and slashing conditions for validators in Ethereum 2.0. For greater visibility and clarity, we abstracted all our casper FFG functionality into pure functions within a Casper package in our repo here.
Persist Blocks and States in DB
We have implemented the ability for beacon-nodes to save blocks and state in the database. Previously, blocks and state were stored in memory and were not persisted across different sessions. With this being done, we now have an actual store of data that we can access and use continuously. Blocks are currently stored simply having the hash of the block referencing the block in the key-value db. With this being accomplished it unblocks development for us to focus more on the chain sync and fork-choice rule as by having a persisted store, we can now send blocks to other nodes and also be able to implement the GHOST fork-choice rule (Greediest Heaviest Observed Sub-Tree). This is elaborated more in this PR.
Upcoming Work
Proposer/Attester Interactions via ShardP2P
A big part of the shard -> beacon node interactions involve attesters and proposers within a shard and a certain slot interacting in order to coordinate the inclusion of attestations that will then be processed by a beacon node during the fork choice rule.
We have opened an issue thread and will begin opening PRs to tackle the items specified in our issue.
Advancing the Beacon Chain from Genesis Without a Simulator
Currently, we have a simple simulator that broadcasts fake, test blocks in order to test the advancement of the beacon chain for development purposes. In order to get to a meaningful demo, we want the chain to advance properly through real proposals and attestations from genesis using a beacon node and a validator client connected via RPC. Many of our upcoming PRs will focus on this, culminating in a meaningful demo and advancement of the beacon chain!
Ethereum Sharding Implementers Call #2
This call had some great discussion from client implementers including Ethereum Foundation, Prysmatic Labs, Lighthouse, Harmony, Pegasys, Nimbus, eWASM, and more. Check it out for client and research updates. There’s great discussions on the latest beacon spec in regards to shuffling algorithm and proposed changes. We brought up two proposals on fork choice testing-lang. Justin gave a great update on latest VDF research and implementations. Cross shard communication, random beacon and validator committee selection were also discussed.
Interested in Contributing?
We are always looking for devs interested in helping us out! If you know Go or Solidity and want to contribute to the forefront of research on Ethereum, please drop us a line and we’d be more than happy to help onboard you :).
Check out our contributing guidelines and our open projects on Github. Each task and issue is grouped into the Phase 1 milestone along with a specific project it belongs to (smart contract related tasks, notary node tasks, etc.).
As always, follow us on Twitter, drop us a line here or on our Discord server and let us know what you want to help with — we need all the collaboration we can get 🎉
Official, Prysmatic Labs Ether Donation Address
0x9B984D5a03980D8dc0a24506c968465424c81DbE
Official, Prysmatic Labs ENS Name
prysmatic.eth
