Ethereum 2.0 Casper+Sharding Development Update # 13 — Prysmatic Labs
Our biweekly updates written by the entire Prysmatic Labs team on Ethereum 2.0
Research Updates
Batched Cross-Shard Transaction Fee Payment
An important question was raised, what if users want to send transaction on any shard? do they need to store ETH on all the shards to pay the fees? As Vitalik mentioned in this research post, we can build facilitate this type of service in protocol or as a layer 2 system.
A fee settlement contract was brought up by Vitalik. Users that want to send transaction must deposit ETH into the contract. There’s also a fee forwarding contract in every shard. When a user sends a transaction from shard 1 to shard 99 with fee, the following happens:
- When executing the transaction, the block producer makes a call to the fee forward contract of current shard with the fee amount as argument
- The fee forward contract will record the fee amount, the address of the block producer, and the fee payer.
- At the end of every cycle, fee settlement contract sends a single cross shard call containing all the previously gathered records to the main fee settlement contract.
- The main fee settlement contract will process all the records and increments/decrements all the account balances.
This type of layer 2 solution provides an efficient yet scalable way to facilitate cross shard transactions. Ping us if you are interested to work on it!
Merged Code, Pull Requests, and Issues
Proposer Validator Responsibility
A critical piece of Ethereum 2.0 is the notion of a proposer, which is a validator that has been assigned the right to create a block including shard cross-links in the beacon node. Validators are shuffled in a given beacon node cycle of 64 slots and can propose blocks to the node which are then voted on by attesters. In our current code, we have finished implementing the proposer responsibility which acts upon an assigned slot, aggregates attestation records, and packages up shard-cross links into a structure that will then become a beacon block.
Our proposer connects to a running beacon chain node and submits the package via an RPC call through our gRPC library.
Attester Validator Responsibility
Another critical piece of Ethereum 2.0 is the notion of a Attester. An attester is a type of validator that has been assigned the right to vote/sign off on a block at a given slot. When an attester attests for a block, it needs to verify that the block is valid and needs to be locally seen as the head of the chain. If the block is valid, then presumably means the attester has already processed the block, processed all the attestations in the block, and applied the fork choice rule on the block. To reiterate, to process a block, the following must hold true during block validation:
1.) Ensure parent block processed
2.) Ensure PoW chain reference points to a processed block on the PoW chain
3.) Ensure local time is large enough to process this block’s slot
4.) Verify that the parent block’s proposer’s attestation has been included in the chain
We have finished implementing the attester responsibility which acts upon on an assigned slot, it receives incoming head block from beacon node, then insert its shard ID, index in the bitfield block hash and create the attestation. The attestation is then send back to the beacon chain node via an RPC method.
RPC Validator Interactions
Validators will need to communicate with the beacon node in order to exchange blocks and attestations. Proposers aggregate attestations of previous blocks into a proposed block and then send the proposal block to the beacon-node. The beacon node then takes the proposed block and sends it to the attesters for the block to be attested to. After the attester validates the block and then attests to it, they send their attestations back to the beacon-node.
Initially for the validator interactions with the beacon-node, we had decided on using p2p but after much discussion we decided that proposers and attesters should only interact with the beacon-node through gRPC. The reasons primarily were from a security perspective as having the validator clients using p2p for communicating block and attestation data would open up security issues as any malicious actor could spam invalid attestations or blocks to a validator client. With that in mind we have decided to implement messaging between validator client using gRPC instead of p2p. This functionality has been merged in this PR.
Beacon Chain Processing & Fork Choice
In Ethereum 2.0, the interval of time in which a block can be proposed is known as a slot, and it is provisionally defined to be exactly 8 seconds. When running a client, it is critical that the notion of time is consistent across sessions and other clients, so we will be utilizing a monotonic clock to track the number of seconds since the genesis timestamp and divide by 8 to determine the current slot a client is in. In particular, this allows us to run the fork choice rule at the start of each new slot interval if any blocks are pending processing. In production, it will be important to ensure all clients validate their timestamps vs. some NTP server to ensure everyone is in sync.
We have refactored our beacon node and validator client to leverage the temporal nature of slots for their runtimes here.
Upcoming Work
Meaningful Demo of Beacon Chain + Validator System
A big motivation for our latest work has been wrapping up a local development demo of a beacon chain + validator client. We want contributors and community members to be able to spin up a node on their computers and see the chain advancing according to the different pieces of the system including fork choice, block sync, validator shuffling, and state transitions.
We are making good progress towards this goal and have created a tracking issue here
Benchmarking various DBs
One piece of software we inherited from our days as a Geth fork is the storage engine, LevelDB. As a simple, embedded key/value store written in Go, LevelDB worked well. However, after seeing an implementation of Badger in Geth and database corruption issues, we decided to set aside time to survey other options ourselves.
Our first requirement was that the storage engine was embedded. Validating needs to be simple, and a separate database process would hinder that goal. The second requirement was that the database be written in Go. RocksDB and LMDB look good on paper, but we felt that the overhead of using C bindings would be too high. After considering those requirements, we decided to do a deeper dive into three options: Bolt, Badger, and LevelDB. Bolt uses a B+tree to index key value pairs, whereas LevelDB and Badger use an LSM-tree as the underlying data structure. One difference between LevelDB and Badger is that only the keys are indexed in the LSM-tree and values are written to an append-only log. In practice this results in faster reads and writes, particularly on SSDs and with large values.
After testing and benchmarking all three options, we decided that Bolt would be the best option for our use case. Although LevelDB and Badger performed better in write-heavy benchmarks as expected for an LSM-tree, the difference wasn’t substantial. On the other hand, Bolt performed much better on read-heavy benchmarks. We also noticed that Bolt consumed more space on disk compared to our other two options. However, a critical requirement was that writes to the database weren’t lost, and Bolt provides the strongest guarantees there. LevelDB has longstanding issues with data corruption and lost writes. One requirement when migrating to Bolt will be to make extending the data layer possible in the future. We’re still open to other options but we’re happy with our choice for now! Take a look at the benchmarks if you want to see how we tested each database.
Misc
New contributors, good first issues, and bounties
We’ve opened dozens of new issues and received pull requests from several new contributors over the last two weeks. We’re very excited to engage the community and a special thanks to Gitcoin for helping us bounty three new issues. As always, we are looking for new contributors to help build Ethereum 2.0 and bring their own perspective to the project. If you have any ideas or suggestions, create an issue or reach out on discord.
Ethereum Sharding Implementers Call #3
This call had some great discussion from client implementers from various ETH 2.0 implementer teams including Ethereum Foundation, Prysmatic Labs, Lighthouse, Harmony, Pegasys, Nimbus, eWASM, and more. Lots of great discussions around client and research updates. Take a listen if you haven’t yet!
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
