Welcome to the third installment of eth2 quick update.

tldr;

• Harden fork choice defences in response to audits
• Introducing challenges.ethereum.org
• Herumi grant for a super-fast BLS implementation

Fork choice defenses

This week, we hardened the defenses of the Phase 0 fork choice rule. Much of our time is spent analyzing eth2 to ensure that the system can remain stable even under adverse conditions (e.g. a large attacker, a major network outage or partition, etc). With any large engineering project, the aim is to find as many potential issues and harden against these scenarios prior to release. This is why we’ve engaged with many external teams and researchers to perform audits, economic analysis, and formal verification of eth2, but at the same time as we move toward release, we must remain vigilant and flexible to respond to unforseen attacks in production (e.g. the Shanghai DoS attacks of 2016).

Helping in this effort, a consensus researcher, Ryuya Nakamura, has analyzed eth2’s consensus algorithm (Casper FFG) and fork choice rule (LMD GHOST) to better determine how these two pieces of the protocol can in some scenarios be exploited. He has a number of excellent write-ups on ethresearch.ch discussing in detail some attack vectors and recommended solutions. Check out Decoy-flip-flop attack on LMD GHOST, Analysis of bouncing attack on FFG, and Prevention of bounding attack on FFG for some informative and fun reads.

Fortunately, the recommended solutions to the decoy-flip-flop and bouncing attacks are both simple modifications to the fork choice specification of Phase 0. The decoy-flip-flop attack is solved by only considering validator attestations from the current and previous epoch when adding attestations to the view of the fork choice. You can see the PR making this change to the spec here. The bounce attack is solved by only updating the latest justified checkpoint within the fork choice during the first k slots of an epoch. After k slots, you defer the inclusion of a new justified checkpoint into the fork choice until the next epoch boundary. You can check out this modification here.

A number of other components of the Phase 0 specification are out for audit currently. Although we don’t expect anything major, we do expect to a small number of additional post-audit suggested changes to make it to PRs in the coming months.

challenges.ethereum.org

We just released challenges.ethereum.org. This site is a single source for all of the current bounties hosted by the Ethereum Foundation and/or related to Ethereum research and development. The bounties range from finding vulnerabilities in existing Ethereum infrastructure to finding collisions in new hash functions. Something for everyone

We will continue building out EF’s bounty program in the coming months so check back for more opportunities.

Herumi BLS grant

We’ve given out a grant to Shigeo Mitsunari, the maintainer of the super-fast Herumi pairing library and BLS signature library. This grant is to bring the libraries up to spec with the new BLS standard (new hash-to-G2, constant-time signing, etc) as well as to help accomplish some more practical items for eth2 usability (Rust integration, fuzzing work, etc).

In addition to the feature component of the grant, there is also a performance component. The Herumi library is already 2-3x faster than the next best BLS option, but because signature verification is one of the main bottlenecks in eth2, any additional gains here would be excellent, enabling eth2 to run under even higher load and in more adverse scenarios. Shigeo will spend some additional time and effort further optimizing the library to ensure it runs as fast as possible .

Welcome to the fourth installment of eth2 quick update. There are a lot of moving pieces to talk about this week. Other than the heroic eth2 client development going on, these are the highlights:

tldr;

Differential fuzzing grant

Sigma Prime has been awarded a grant to lead the differential fuzzing effort for eth2 clients. This effort is critical to the success of launching a multi-client network by aiding in catching consensus issues prior to mainnet.

The act of “fuzzing” is the act of throwing many random inputs at a piece of software to see how it reacts. When fuzzing a single piece of software, the goal is often to find inputs that lead to unexpected crashes. When we find such inputs, we then figure out what went wrong and harden the software to this type of input.

Differential fuzzing is a bit different. Instead of explicitly looking for crashes, we look for instances in which different implementations of a protocol have a different output for the same input. In a blockchain context, we use differential fuzzing to find cases in which a series of blocks leads to a different resulting state on two different clients. Ideally in production there are no such cases.

Light client task force

Chainsafe/Lodestar, the recipients of an Ethereum Foundation grant for research and development on eth2 light clients, has formed the Light Client Task Force. This group has tasked themselves with ensuring that light clients are first class citizens in eth2. To this end, they are hosting a monthly call aimed at driving light client research, standards, specs, and education.

The need for a rich ecosystem of light clients and light client servers is only amplified in a sharded protocol like eth2. Even if a client is syncing some subset of the protocol (e.g. just a couple of shards), a user will very often need to get information about accounts, contracts, and the general state of things on another shard. A client could inefficiently sync the entire additional shard, but more often than not, lightly requesting information about specific accounts on the shard with succinct proofs will be the way to go.

Tune in to the next Light Client Task Force call to stay up-to-date on all things light in eth2.

eth1 -> eth2

In the early days of eth2, the transfer of ether from the existing ethereum chain (eth1) into the new beacon chain (eth2) will be uni-directional. That is, the ether moved into staking on eth2 will not be transferable (to start) back to eth1. The choice of a single directional transfer into validation is in an effort to minimize the risk profile that eth2 induces upon eth1, and to allow for a quicker development cycle on eth2 without having to fork eth1 in the process. There is some movement around creating a bi-directional bridge, but I’ll save discussion of the bridge mechanics and the trade-offs for a later post. Today, I’d like to get more into how this uni-directional transfer works and how it can be safely implemented without changing eth1.

On the existing ethereum PoW chain, we will deploy the eth2 validator contract. This contract has a single function called deposit which takes in a number of parameters to initialize a new validator (e.g. public key, withdrawal credentials, an ETH deposit, etc). There is no withdrawal function on this contract. Barring a fork to add in a bi-directional bridge, this deposited ETH now only exists in eth2 on the beacon chain.

It is then the validators’ responsibility on the beacon chain to come to consensus on the state of this contract such that new deposits can be processed. This is done by eth2 block proposers embedding recent eth1 data into a beacon block field called eth1_data. When enough block proposers during a voting period agree on recent eth1_data, this data is enshrined in the beacon chain state allowing for new deposits to be processed.

An important note about this mechanism is that the eth1_data is deep in the eth1 PoW chain — ~1000 blocks of “follow distance”. This follow distance induces a high latency in processing new validator deposits, but provides a high degree of safety in the coupling of these two systems. The eth1 chain would have to re-org deeper than 1000 blocks to break the link, and in such a case would require some manual intervention to overcome.

We are researching and prototyping the utilization of the beacon chain to finalize eth1 (i.e. the finality gadget). This would require eth1 to defer its fork choice ultimately to the beacon chain, gaining security from the PoS validators, and allowing for a much quicker eth1 to eth2 deposits. The finality gadget also opens up other fun things such as the bi-directional bridge and exposing the eth2 data-layer to eth1. More on all of this in a later post .

Welcome to this week’s eth2 quick update!

tldr;

Shasper joins Prysmatic’s testnet

Parity’s eth2 client, Shasper, successfully joined Prysmatic’s Sapphire Testnet marking the first public multi-client eth2 testnet. This is the exciting start of many multi-client testnets to come in the next month.

You can now pull down the Shasper codebase and with a few commands, and connect to the Sapphire testnet. If you want to give it a shot, follow the instructions here.

Eth2 block explorers launch

Not one but two (!) eth2 block explorers recently launched. Both of these block explorers currently monitor Prysmatic Labs’ Sapphire Testnet, providing slot-by-slot info as validators build the beacon chain.

Bitfly launched their beaconcha.in block explorer a couple of weeks ago and continue to add exciting features by the day. Etherscan just launched their block explorer yesterday, and it, too, looks packed with cool features and data. Both will be great options to monitor Prysmatic’s and other testnets as they come online.

We’re excited to see more and more user/developer tooling being built around eth2 clients and testnets

First eth2 networking call

Up until this point, we’ve relied upon github issues/pull-requests, adhoc chats, the main eth2 call, and in person meetings to organize the networking components of the eth2 spec. This has largely worked well enough, but researching and architecting a network to support a sharded blockchain protocol is an issue that increasingly deserves some more specific attention and resources.

To this end, we had our first eth2 networking-specific call this week. Although this call is not live-streamed like the general eth2 call, it is public and open to all contributors. Thank you to the p2p networking experts across the various eth2 teams that pushed for this call. I was originally resistant due to the additional coordination overhead, but the first call proved very fruitful and I look forward the next.

As always Ben Edgington (call notes) and Mamy Ratsimbazafy (call notes) took excellent notes. We still have plenty to dig into, and our next call will be in approximately 2 weeks time.

Thank you Will Villanueva from the Quilt team for organizing the first eth2 phase2 community call. Similar to the new networking and light client calls, phase 2 has enough going on to warrant a regular call to keep the research and development more organized.

This first call acted as a general update and survey of the various on-going threads across the many teams and individuals involved. You can read up on the notes here. Subsequent calls are intended to be deeper work sessions on specific technical issues.

A major goal for Phase 2 is to get through the initial wave of stateless protocol research and to use the findings to narrow the scope into a more concrete plan to execute in 2020. These calls are an excellent step forward toward this goal.

Forkchoice state fix

Researchers at San Jose State University led by Yan X Zhang have been diligently working to formalize the joint properties of eth2’s consensus mechanics (Casper FFG) and fork choice rule (LMD GHOST). Before publishing their work, they found a corner case in the interworkings of FFG+GHOST in which a branch of the block tree might include the latest justified/finalized blocks but not actually show those blocks as justified/finalized in the on-chain state. To leave such “non-viable” branches in the fork choice can lead to situations in which a validator’s vote might not be coherent with local finality info and might, in certain scenarios, lead to liveness failures. You can read more about this particular scenario and the proposed solution here.

To address this scenario, we have a fix under review in the specs repo. We expect this fix to be released within the week.

Specification and implementation of the new BLS standards

The long-awaited BLS standards were recently presented for public comment at the IETF Meeting 106. You can check out the presentation and slides for yourself. The presentation went as planned and the standard is expected to be adopted by a number of blockchain projects and (eventually) into IETF. To more semi-officially enshrine this standard before the long IETF process finsihes, I expect the EF and many other projects to more officially announce intended usage soon.

There are two draft pull-requests ([1] [2]) under review in the specs repo, as well as an implementation of the new standard under review in py_ecc. Once review is complete, we will generate the new BLS test vectors for general consumption by eth2 clients. The intention is to switch testnets over to the modified BLS scheme come January.

The BLS standards also remove one of the final blockers for launching the eth2 deposit contract. Runtime Verification is currently finishing up their report on the formal verification and analysis of the deposit contract bytecode. This report is expected to be published by the end of the month for public review, after which we can finally launch this thing .

Welcome to the first eth2 quick update of 2020! This is going to be an exciting year.

tldr;

• Release of v0.10.0 spec as stable target for multi-client testnets and security reviews
• @paulhauner and @sigp_io team hard at work building Lighthouse
• Relaunch of Prysm testnet, now with aggregators and mainnet configuration
• A new proposal for an expedited merging of eth1+eth2 (aka Phase 1.5)

Release of v0.10.0 for security reviews and multi-client testnets

v0.10.0 — 404 Not Found was released last week. Read the release notes for the technical details (integration of IETF BLS, simpler eth1 caching, etc), but what does it actually mean for eth2?

v0.10.0 is the culmination of changes introduced to the Phase 0 spec after the unfreezing following deVcon as well as the integration of the new IETF BLS standards. For some time, these new spec changes disrupted the smooth development cycle of the eth2 client teams and postponed the release of testnets that were imminent. With the release of v0.10.0, we are now entering back into a smooth rhythm.

New and updated resources

With the release of v0.10.0, we once again have a very stable target both for client testnets as well as third party audits and security reviews.

To this end, we recently updated a number of onboarding resources (and created a few new ones). If you are looking to better understand the eth2 Phase 0 specs, you should definitely give these a look!

Audits underway

Least Authority kicked off their security review this Monday and are currently digging deep. We have high expectations and are enthusiastic to be working with a team of such caliber!

Another exciting piece of news is in the form of an audit and formalization of the Phase 0 cryptoeconomics led by a new EF team — Robust Incentives Group (RIG).

RIG has constructed a cadCAD environment to simulate the eth2 economic models and explore a diverse range of attacks: including timing attacks, the potential effects of different sized cartels, and more!

Check out the core of their work in the form of an easy to understand python notebook.

What’s next?

While I’ll just give you a glimpse here, I promise to dive into more detail in subsequent posts.

In parallel to ongoing audits, clients will code up to v0.10.0, integrate new BLS standards, and get some steady testnets running. Once initial stability in v0.10.0 is achieved, multi-client activity will begin.

With respect to this activity, I first expect a small number of multi-client tests against largely single-client testnets. By this I mean I expect to see some clients joining what were previously single-client testnets — as minority nodes — to test initial interopability.

Once we have success here, we’ll orchestrate a shared genesis with 2+ clients from the start. I expect some level of chaos and a lot of learning in this phase. Ambiguities in the spec might become apparent with minor clarifying changes integrated. We might even find out something was broken that we previously thought was fine — large testnets are their own form of audit.

Once audit results begin to roll in throughout February, we expect to make a wave of changes to the Phase 0 spec. The extent of these changes and the implications they might have on client development and timelines is still to be determined. Regardless, a post-audit v0.11.0 release will drop near the start of March.

If the changes are small, clients will integrate the changes, patch testnets, and continue forward. If deeper, the integrations might take longer, require additional testing, and full restarts to existing nets. After sufficient time at a stable v0.11.x, a final v1.0.0 will be cut for mainnet release: the exact length of time will depend on the depth of the changes.

This is a high level look at the coming months. I’ll keep you updated and fill in more details as we go.

Lighthouse on an optimization tear

Although Sigma Prime has been relatively quiet since they took down their first public testnet, the team has been hard at work! Lighthouse lead, Paul Hauner, just dropped a exciting tweetstorm filled with juicy details of recent optimizations and gains on their eth2 client.

Apparently they’ve been running a not-so-publicized public testnet for the past 4 weeks making impressive gains on everything from BLS to block processing to DB reads/writes. Pull it down and try it yourself!

Oh and if you have some frontend chops and want to get involved, Sigma Prime just put out an RfP for a Lighthouse User Interface. This kind of work is important to ensure that validating is readily accessible to all types of users.

Prysmatic’s testnet relaunches with mainnet config and aggregators

Prysmatic Labs recently restarted their public testnet now with the mainnet configuration and the attestation aggregation strategy! As discussed in prior posts, the mainnet configuration has larger caches, longer epochs, and is generally a bit more hefty than the initially used minimal config. Operating a stable testnet with this configuration and 10s of thousands of validators is an important milestone that Prysmatic is currently working through.

If you want to get your hands dirty, become a validator or join the conversation on discord.

Oh, and they’re hiring! Working remotely with Prysm is a great opportunity for an experienced dev. Help build the future!

Phase 1.5

Over the holidays, Vitalik posted a new proposal on how we might expedite the eth1+eth2 merger and begin reaping the benefits of the new eth2 infrastructure much sooner. This proposal suggests migrating eth1 into a shard of eth2 after the Phase 1 infrastruture (shard data chains) is added but before a full Phase 2 (featuring extensible EEs and all the cross-shard bells and whistles) — thus Phase 1.5!

A phase 1.5 has many potential benefits to the ethereum protocol and to its developers and users.

1. Eth1 living inside of eth2 allows for native access to the scalable sharded data layer. Some of the most exciting constructions being built on ethereum today are layer 2 protocols that scale with the amount of data available to layer 1. These will pair beautifully with eth2 even with just a single chain with native computation (i.e. eth1 as shard). Broadly, these constructions are called “rollups”. They come in many flavors and I expect this general design space to continue to expand and be fruitful.
2. Eth1 migrating to a shard of eth2 eliminates PoW from the protocol, greatly reducing issuance and halting energy intensive mining on ethereum once and for all.
3. Finally, integrating eth1 into eth2 on an earlier schedule reduces the amount of moving parts — unifying the system, the community, and the development of the core protocol. Although the eth2 infrastructure is being developed first in parallel to the existing ethereum chain, an earlier integration of eth1 into eth2 (beyond just the technical wins) helps ensure the community of protocol developers, application developers, random contributors, and end-users remains united within a single, cohesive Ethereum.

Based upon initial discussions and reactions, developers and community members are excited by this proposal. Phase 1.5 as it currently stands largely relies upon the success of two independent components — Phase 1 of eth2 and Stateless Ethereum on eth1. The relative timelines of each of these components will inform as to how and when this proposal might come to fruition. Over the coming months, we will do due diligence on better spec’ing and understanding the technical challenges at hand so that we are prepared to move on this if/when the time is right .

Keep it coming

tldr;

Runtime Verification audit and verification of deposit contract

Runtime Verification recently completed their audit and formal verification of the eth2 deposit contract bytecode. This is a significant milestone bringing us closer to the eth2 Phase 0 mainnet. Now that this work is complete, I ask for review and comment by the community. If there are gaps or errors in the formal specification, please post an issue on the eth2 specs repo.

The formal semantics specified in the K Framework define the precise behaviors the EVM bytecode should exibit and proves that these behaviors hold. These include input validations, updates to the iterative merkle tree, logs, and more. Take a look here for a (semi)high-level discussion of what is specified, and dig in deeper here for the full formal K specification.

I want to thank Daejun Park (Runtime Verification) for leading the effort, and Martin Lundfall and Carl Beekhuizen for much feedback and review along the way.

Again, if this stuff is your cup of tea, now is the time to provide input and feedback on the formal verification — please take a look.

The word of the month is “optimization”

The past month has been all about optimizations.

Although a 10x optimization here and a 100x optimization there doesn’t feel so tangible to the Ethereum community today, this phase of development is just as important as any other in getting us to the finish line.

Beacon chain optimizations are critical

(why can’t we just max out our machines with the beacon chain)

The beacon chain — the core of eth2 — is a requisite component for the rest of the sharded system. To sync any shard — whether it be a single shard or many, a client must sync the beacon chain. Thus, to be able to run the beacon chain and a handful of shards on a consumer machine, it is paramount that the beacon chain is relatively low in resource consumption even when high validator participation (~300k+ validators).

To this end, much of the effort of eth2 client teams in the past month has been dedicated to optimizations — reducing resource requirements of phase 0, the beacon chain.

I’m pleased to report we’re seeing fantastic progress. What follows is not comprehensive, but is instead just a glimpse to give you an idea of the work.

Lighthouse runs 100k validators like a breeze

Lighthouse brought down their ~16k validator testnet a couple of weeks ago after an attestation gossip relay loop caused the nodes to essentially DoS themselves. Sigma Prime quickly patched this bug and looked to bigger and better things — i.e. a 100k validator testnet! The past two weeks have been dedicated to optimizations to make this real-world scale testnet a reality.

A goal of each progressive Lighthouse testnet is to ensure that thousands of validators can easily run on a small VPS provisioned with 2 CPUS and 8GB of RAM. Initial tests with 100k validators saw clients use a consistent 8GB of RAM, but after a few days of optimizations Paul was able to reduce this to a steady 2.5GB with some ideas to get it even lower soon. Lighthouse also made 70% gains in the hashing of state which along with BLS signature verification is proving to be the main computational bottleneck in eth2 clients.

The new Lighthouse testnet launch is imminent. Pop into their discord to follow progress

Prysmatic testnet still chugging and sync massively improved

A couple of weeks ago the current Prysm testnet celebrated their 100,000th slot with over 28k validators validating. Today, the testnet passed slot 180k and has over 35k active validators. Keeping a public testnet going while at the same time cranking out updates, optimizations, stability patches, etc is quite a feat.

There is a ton of tangible progress ongoing in Prysm. I’ve spoken with a number of validators over the past few months and from their perspective, the client continues to markedly improve. One especially exciting item is improved sync speeds. The Prysmatic team optimized their client sync from ~0.3 blocks/second to more than 20 blocks/second. This greatly improves validator UX, allowing them to connect and start contributing to the network much faster.

Another exciting addition to the Prysm testnet is alethio’s new eth2 node monitor — eth2stats.io. This is an opt-in service that allows nodes to aggregate stats in single place. This will allow us to better understand the state of testnets and ultimately eth2 mainnet.

Don’t trust me! Pull it down and try it out for yourself.

Everyone loves proto_array

The core eth2 spec frequently (knowingly) specifies expected behavior non-optimally. The spec code is instead optimized for readability of intention rather than for performance.

A spec describes correct behavior of a system, while an algorithm is a procedure for executing a specified behavior. Many different algorithms can faithfully implement the same specification. Thus the eth2 spec allows for a wide variety of different implementations of each component as client teams take into account any number of different tradeoffs (e.g. computational complexity, memory usage, implementation complexity, etc).

One such example is the fork choice — the spec used to find the head of the chain. The eth2 spec specifies the behavior using a naive algorithm to clearly show the moving parts and edge cases — e.g. how to update weights when a new attestation comes in, what to do when a new block is finalized, etc. A direct implementation of the spec algorithm would never meet the production needs of eth2. Instead, client teams must think more deeply about the computational tradeoffs in the context of their client operation and implement a more sophisticated algorithm to meet those needs.

Lucky for client teams, about 12 months ago Protolambda implemented a bunch of different fork choice algorithms, documenting the benefits and tradeoffs of each. Recently, Paul from Sigma Prime observed a major bottleneck in Lighthouse’s fork choice algorithm and went shopping for something new. He uncovered proto_array in proto’s old list.

It took some work to port proto_array to fit the most recent spec, but once integrated, proto_array proved “to run in orders of magnitude less time and perform significantly less database reads.” After the initial integration into Lighthouse, it was quickly picked up by Prysmatic as well and is available in their most recent release. With this algorithm’s clear advantages over alternatives, proto_array is quickly becoming a crowd favorite, and I fully expect to see some other teams pick it up soon!

Ongoing Phase 2 research — Quilt, eWASM, and now TXRX

Phase 2 of eth2 is the addition of state and execution into the sharded eth2 universe. Although some core principles are relatively defined (e.g. communication between shards via crosslinks and merkle proofs), the Phase 2 design landscape is still relatively wide open. Quilt (ConsenSys research team) and eWASM (EF research team) have spent much of their efforts in the past year researching and better defining this wide open design space in parallel to the ongoing work to specify and build Phases 0 and 1.

To that end, there has been a flurry of recent activity of public calls, discussions, and ethresear.ch posts. There are some great resources to help get the lay of the land. The following is just a small sample:

In addition to Quilt and eWASM, the newly formed TXRX (ConsenSys research team) are dedicating a portion of their efforts toward Phase 2 research as well, initially focusing on better understanding cross-shard transaction complexity as well as researching and prototyping possible paths for the integration of eth1 into eth2.

All of the Phase 2 R&D is a relatively green field. There is a huge opportunity here to dig deep and make an impact. Throughout this year, expect more concrete specifications as well as developer playgrounds to sink your teeth into.

Whiteblock releases libp2p gossipsub test results

This week, Whiteblock released libp2p gossipsub testing results as the culmination of a grant co-funded by ConsenSys and the Ethereum Foundation. This work aims to validate the gossipsub algorithm for the uses of eth2 and to provide insight into the boundaries of performance to aid followup tests and algorithmic enhancements.

The tl;dr is that the results of this wave of testing look solid, but further tests should be performed to better observe how message propogation scales with network size. Check out the full report detailing their methodology, topology, experiments, and results!

Stacked Spring!

This Spring is stacked with exciting conferences, hackathons, eth2 bounties, and more! There will be a group of eth2 researchers and engineers at each of these events. Please come chat! We’d love to talk to you about engineering progress, validating on testnets, what to expect this year, and anything else that might be on your mind.

Now is a great time to get involved! Many clients are in the testnet phase so there are all sorts of tools to build, experiments to run, and fun to be had.

Here is a glimpse of the many events slated to have solid eth2 representation:

Strange times. I hope you are all well and continue to take care of yourselves, your families, and your communities.

We’re a bit overdue on a quick update. My apologies. I’ll keep them coming at a regular clip after this one. Eth2 is looking good — Phase 0 is stable, client teams are crushing it, and some promising research was published for our stateless future.

tl;dr

v0.11.0 post-audit release

Spec version v0.11.0 — Lan party — was released last week. This release represents a “post-audit” Phase 0 spec, ready for long-standing multi-client testnets.

It contains limited changes to the core consensus, instead with much of the focus on refining the network protocol — e.g. cleaner sync protocol, DoS hardening, better network/chain separation, etc. Checkout the release notes for more details.

Clients are working hard to incorporate these changes while continuing forward with stability, optimizations, and multi-client experimentation. In fact, client teams are working through March to lay the foundation for the coming multi-client testnets. Today — Teku syncs Prysm, Prysm syncs Lighthouse, and most of the DiscoveryV5 implementations can find eachother.

Release of Combining GHOST and Casper paper

This week, we released Combining GHOST and Casper on arXiv. This work formalizes the core consensus components of eth2 — Casper FFG and LMD-GHOST — showing how they work together to form a safe and live system. This paper builds upon concepts initially presented in the original Casper the Friendly Finality Gadget paper, layering them onto a more concrete Proof-of-Stake, slot-based context (i.e. that of the eth2 beacon chain).

This paper was created in parallel to the development of the Phase 0 specs. It not only influenced the spec design but also highlighted some critical corner cases that had to be addressed. We are excited to release it to the world for public consumption, comment, feedback, and critique.

This work spawned from a “mini-spec” presented by Vitalik, but the lion’s share of work was driven and completed by Yan X. Zhang and his students at San Jose State University. We want to offer a special thanks to Yan and his students — Diego Hernandez, Thor Kamphefner, Khiem Pham, Zhi Qiao, Juhyeok Sin, and Ying Wang — for completing this critical milestone for eth2.

Polynomial commitments promising for statelessness

Vitalik recently published an exciting ethresearch post, Using polynomial commitments to replace state roots. This post proposes the utilization of polynomial commitments as a replacement to the traditional merkle-tree accumulator for blockchain state and data. If this research direction proves fruitful, we could reduce “witnesses” (i.e. proofs about the state required to process a block) from ~0.5MB to on the order of 1 to 10 kB, solving one of the core issues in the Stateless Ethereum research.

To state a bit more clearly — Ethereum is pushing hard to move to a more “stateless” model (see the 1x research and updates. Polynomial commitments could be the major breakthrough we’ve been looking for to make this statelessness a reality by significantly reducing the overhead of statelessness on block size.

Although incredibly promising, some of this research and magic math is very new. We need to spend more time better understanding the complexities and tradeoffs, as well as just getting more eyes on this new and exciting technique.

A bit of IETF BLS instability

The IETF BLS standard recently incorporated a last minute change into the spec based upon external feedback concerning different applications and domains. The previous hash_to_base was not friendly to embedded systems, applications requiring certain types of domain separation, and those utilizing SHA-3 instead of SHA-2.

In light of these concerns, hash_to_base was replaced with the new and improved hash_to_field. Spec maintainers do not expect any more substantive changes to the spec, and this change is to be formally released as a “Draft 6” soon.

As far as cryptographic standards go, we do not want to be in the position of eth1 with the Keccak256 hash function — that is, one of the only major applications using it. Being in a cryptographic island hinders the ease of cross-application interoperability as well as stifles the development of a wide set of robust implementations.

We are closely monitoring the development of the IEFT standard, but in light of this recent change we are not rushing to deploy the mainnet deposit contract (which would in-effect lock us into a BLS spec) before there is a target eth2 launch date. We will continually evaluate the stability of the IEFT standard going forward and do not expect this to become a bottleneck for launch.

In other news, we will soon release a deposit interface and deploy a deposit contract for the coming long-standing multi-client testnet, but more on that next time .

Have some fun announcements for y’all this week

Other than the items below, client teams continue to move toward production. More on that next week!

tl;dr

Least Authority Phase 0 audit complete

As discussed many months ago, we engaged with Least Authority to conduct a full audit of the Phase 0 specifications. The audit was comprehensive with a deep look at potential DoS attacks, misuse of resources, unintended forks/chains, and attacks impacting funds.

The audit is now complete and available for public review .

The Least Authority audit helped us patch a few DoS vectors in gossip messages with additional validation conditions (Issues A & B), highlighted a known concern about the public block proposer leader election (Issues C & D), and spurred further investigation into potential DoS attacks using libp2p gossipsub control messages (Issue G).

Beyond these concrete issues, the audit made some suggestions for cleaning up the p2p spec, investigating techniques for tightening up gossip, and getting the core consensus papers/proofs peer reviewed.

A big thank you to Least Authority. It was a pleasure to work with their many auditors on this project!

Phase 0 Pre-Launch Bounty Program

We’re excited to announce the Phase 0 Pre-Launch Bounty Program!

This program is designed to incentivize you (rewards up to $10k!) to find and report bugs in the core Eth2 Phase 0 specs prior to mainnet launch .

The Ethereum Foundation will run this program from now until just prior to the Phase 0 mainnet launch. After Phase 0 is in production, we will transition Phase 0 bounties to the standard Ethereum Bounty Program.

Read more for details about the rules, how to report, severity levels, and rewards.

To kick off the program, we’re excited to award the first three bug bounties!

Happy hunting!

Unification of eth1+eth2 communications

Something magical has been happening since deVcon in Osaka. Under the wrangling of Piper, the vague eth1x research initiative has blossomed into the Stateless Ethereum movement with a concrete roadmap and wide participation across the ecosystem.

This movement is complementary to the eth2 scaling efforts, and the research, specs, development, and conversation of both eth1+eth2 increasingly overlap. To aid in this collaborative effort driving the future of Ethereum, eth1+eth2 communications were recently merged into the Eth R&D discord server

Join us! You’re welcome to lurk, ask questions, propose new sync protocols, prototype the eth1+eth2 unification, optimize witnesses, or otherwise just keep up to speed on the future of the Ethereum protocol

We’ve all been pretty busy with all the things! I’ll try to keep these posts rolling out, but in the meantime, be sure to checkout Ben Edgington’s What’s New in Eth2 to get your fix.

Tune into Ethereal Virtual Summit this Thursday and Friday! It’s full of excellent eth2 content and it’s 100% FREE. Thank you to all the organizers for their hard work in making the switch to online. I’m super excited

tl;dr

Doubling bounty rewards

Starting today all rewards in the Phase 0 Pre-Launch Bounty Program are being doubled for a maximum of $20k for critical bugs!

This program is designed to incentivize you to find and report bugs in the core Eth2 Phase 0 specs prior to mainnet launch .

The Ethereum Foundation will run this program from now until just prior to the Phase 0 mainnet launch. After Phase 0 is in production, we will transition Phase 0 bounties to the standard Ethereum Bounty Program.

Read more for details about the rules, how to report, severity levels, and rewards.

Happy hunting!

Schlesi multi-client testnet

On April 17th, the first eth2 multi-client testnet — Schlesi — was born!

Schlesi is an eth2 multi-client effort led by Afri Schoedon, and this current iteration of the net is the first ever persisted multi-client testnet. Huge shoutout to Afri for his work in getting various clients to interop, filing detailed bug reports along the way, and managing to stand up a net that has already lasted for multiple weeks!

The network’s backbone was started with Prysm and Lighthouse, but since then both Nimbus and Teku have managed to sync and are in the process of getting their validators to play nicely. Check out the graffiti in the testnet blocks, many are tagged with the client/build and while others have some fun messages.

Schlesi might very well turn into the multi-client testnet in a couple of iterations, but for now, expect the net to be restarted every week or two as bugs are found, versions are bumped, and more clients come online.

Join us in the Eth R&D schlesi channel if you want to join the net and get more involved!

Preparing for v0.12

Much of my time has recently been spent preparing the eth2 specs for a semi-major version bump to v0.12. Unless security critical items are found, this is planned to be the last breaking spec change prior to mainnet. The release will include Draft 7 of the IETF hash-to-curve for BLS, continued refinements of the network spec, and some non-substantive changes to the state transition to aid in testing.

The IETF BLS standard has been both a point of excitement and of stress in the eth2 process. On the one hand, we are eager to adopt a well-vetted industry standard and benefit from more robust tooling and cleaner interoperability. But on the other hand, the standardization process is an external dependency that we can’t entirely manage. Each update introduces a breaking change into the eth2 specs, requires some development work to get the implementations up to spec, and brings uncertainty into our timelines.

The IETF spec maintainers are pleased with Draft 7 and have no more expected changes in the queue. Eth2 teams, along with a number of other blockchain projects, plan to adopt Draft 7 at this point and will only consider subsequent changes in the event that security critical issues are found.

As for networking, we had a very productive call this morning to hash out some of the finer details of initial sync, peer discovery of particular capabilities, type-based message size limits, and more. Check out Ben Edgington’s excellent notes for a recap