This post contains the complete text of the Beacon Book: a collection of perspectives from 46 researchers and implementers that worked on the Ethereum Beacon Chain. We hope you enjoy reading it! Join our discord if you'd like to discuss.
The crowdfund for 100 physical prints concluded on Aug 3rd. See the results here.
In addition to the text, the book also features 7 full-spread illustrations, which can be minted as editional NFTs of varying exclusivity. They are placed below according to their position in the printed book. Only 10 full Genesis Edition sets (NFTs 1-7) can be minted. Check out this post for an exploration of the book's Graphics and Narratives.
In line with the goals set in our Dec. 2020 announcement, any ETH from NFT minting and the auctions goes directly to the contributors that made the book possible: see the Split Contract here. Please note that minting NFTs does not grant access to the printed books, nor should it be construed as an investment of any kind. This is a community based project.
Above: the back (left) and front (right) cover of the book
We are a group of community members interested in cultivating patronage culture around public goods. We can be reached at @statefulworks on Telegram or Twitter.
We're excited to continue creating Ethereum culture with all of you - to the merge and beyond.
This project would not have been possible without the time and effort of dozens of contributors, from Eth2 researchers and implementers to the broader Ethereum community.
Thanks as well to Y and C for their companionship.
Thanks to the following photographers for permission to use their work throughout the book: Wesley Tingey, Cytonn Photography, Serge Kutuzov, Luis Quintero, Lawrson Pinson, and Gabriela Fechet.
The Beacon Book began its life in October 2020 as the first project from Stateful Works. While the content and framing has evolved over the past 6 months, the core vision has remained the same: to craft a crypto-native artifact that captures the humanity of the people building the future of Ethereum.
It contains the hopes, fears, and anticipations of the Eth2 researchers and client implementers directly responsible for bringing the Beacon Chain to life on December 1, 2020. The future of the Beacon Chain is the future of Ethereum, and we’re proud to tell part of its story this far.
We prompted contributors with a few questions - you'll find them in order in each response, some but not all answered.
Keep in mind that these responses were gathered both before and after the Beacon Chain launch, so references to launch expectations will vary. Profiles are ordered alphabetically by first name.
Finally, while we made the utmost effort to include as many people as possible, it’s inevitable that we missed or were unable to feature some contributors. Eth2 wouldn’t be what it is without the input of hundreds of community testers and code contributors - thank you.
Let's start with a quick history of what's become known as Eth2, and where it's headed in the future.
Recently, Danny Ryan has announced his intent to deprecate the use of the terms eth1 and eth2. As the creator and curator of “What’s New in Eth2,” this is a bit of a blow!
But, on the whole, I agree that these terms are beginning to outlive their usefulness, and are in danger of becoming quite misleading. It’s not really about fiddling with names; it’s about capturing fundamental changes in direction, and communicating them clearly. Changes in the roadmap are confusing for the community. Clarity in naming aids clarity of understanding.
Here's a brief history of naming things in Ethereum’s roadmap.
As far as I can tell, the first use of the name “Ethereum 2” was by Vitalik in Hacker News, way back in April 2014. He positioned Ethereum 2 as being a future step-change in the capability of Ethereum through the use of “fundamental cryptographic upgrades.”
Ethereum 2 then drops out of view, and the main narrative becomes the familiar Frontier → Homestead → Metropolis → Serenity progression, first described in March 2015. In this scheme, Serenity is the network upgrade to Proof of Stake; Serenity isn’t Ethereum 2 per se. Interestingly, sharding/scaling doesn’t have a clear place in that roadmap, although it was certainly discussed around that time.
Progress largely followed this plan for some years, with Homestead going live in March 2016, and Metropolis (in name at least) in a pair of upgrades in October 2017 and February 2019.
Serenity was to have been delivered via a process of upgrading the existing Ethereum chain to bootstrap Proof of Stake. That upgrade was specified in EIP-1011 and there was even a testnet that went live on December 31st, 2017.
However, the road to Serenity was found to be a dead-end, not least because of the vast amount of Ether that stakers would require - 1500 was the number back then.
So, in mid 2018, we tore up that roadmap and started afresh with Ethereum 2.0. Rather, we reverted to Vitalik’s original idea from 2014 of an Ethereum 2 that was to be a significant cryptographic step-change to the protocol. Calling this Eth 2.0 made sense: we were planning to change pretty much everything about the platform. Ethereum 1 would eventually be brought in as a kind of legacy system. This Ethereum 2.0 roadmap came with neat consecutive phases: Phase 0 for Proof of Stake; Phase 1 for data shards; Phase 2 for executable shards; and, finally, bring Eth1 over to Eth2 after all that.
We’ve now delivered Phase 0, but the rest of the plan has evolved. As per the latest Eth2 pages on the ethereum.org website, “Eth2 [now] refers to a set of interconnected upgrades that will make Ethereum more scalable, more secure, and more sustainable” (emphasis mine). This looks much more like the old Serenity plan! We’re upgrading the Ethereum chain in-place rather than doing the old rip-and-replace.
So, you see, the roadmap narrative has vacillated over the years between effectively doing a replacement of Ethereum 1, referred to at various times as Eth2, and doing in-place upgrades to Eth1. Today, we’re more or less back in upgrade territory.
In view of all this, applying the Ethereum 2.0 moniker to the entire project is now seen as confusing: to some it implies a different chain to today’s Ethereum; to others, even a different coin. It suggests incompatibilities and problems ahead.
The latest naming trend, then, is to limit Eth2 to refer only to the consensus layer upgrade of Ethereum to Proof of Stake, and to refer to all of today’s Ethereum (fka Eth1) as the execution layer.
It's good to see everything moving under a consistent terminology and a shared roadmap. I'm looking forward to a productive rest of 2021 and beyond!
Eth2 promises to deliver a decentralized, scalable, and secure blockchain platform on which stateful applications can live. These three qualities will be the driving force towards the mass adoption of the Ethereum network.
In the quest to satisfy the design requirements, we've also seen some amazing research and engineering progress. We have pushed the frontier of computer science in areas such as Byzantine consensus, signature aggregation, and VDFs. With the launch of Phase 0, we created the largest BFT consensus network in existence, which is an awesome feat in itself!
My favorite bit of work was the "Weak Subjectivity Guide" - a document that outlines the weak subjectivity safety features of the Eth2.0 network. The goal is to prevent long range attacks that appear specifically in PoS consensus.
As for favorite bug, there was a consensus (fork-choice) issue discovered right before the Beacon Chain launch. The first priority was to assess the threat level of the attack -- it was critical and could have lead to a large-scale failure, but was extremely difficult to execute. Fixing this attack vector required a comprehensive review of the fork-choice component, and we had already identified a couple of solutions. At the end, there was agreement among the spec team that the attack didn't pose a critical threat because of its difficult execution, and we decided to publish a fix after further review was completed.
The project has always been ambitious. The early designs were well thought out, but had shortcomings which became apparent when realising them through implementation. The collaboration between researchers and developers constantly iterated on these design specs for years, finally achieving a workable version of the original concept. The process was longer than expected, but it's been amazing to see the coordination and what has been achieved by a globally distributed group of implementers and researchers.
Of all the work put into the Lighthouse client, I've changed and modified various architectures and designs and I'll likely continue to do so. I'm therefore not particularly fond of any individual piece relative to another. But I'm very proud of the end result. The resulting Lighthouse code-base that came together from everyone's hard work is what I'm most proud of.
As for person to give a shoutout to, I'm sure everyone has a similar answer, but for me it's Danny and Proto. Danny for the amazing organisational role and interfacing with all the client teams (especially on contentious topics) has sped up the development immensely. Proto (Diederick) for his relentless troubleshooting, bug-finding and research endeavours. He has been invaluable in interop testing, optimisation improvements and all round improving the general state of all clients and the eth2 ecosystem in general.
Also - there's an Australian saying, which I think applies to all eth2 researchers and developers: We're not here to f$!k spiders!
Eth2 is this big idea that started as a seed right back when Ethereum began and then went on this crazy, messy, long journey as the details were thrashed out through open research and public collaboration. All that messiness and the length of the journey is a result of this unique, highly collaborative and distributed approach to designing it. Multiple times, concepts that had been thought settled were thrown out because a better idea came along. While that has been frustrating for on-lookers, it has led to and continues to lead to huge improvements in the resulting technology.
The interop lock-in in Canada was a major turning point in the progress of Phase 0. It forced the Beacon Chain out of that research mode. Suddenly, client development was less about translating the Python spec to another language and more about engineering all the other components that make a client actually usable. Client teams finally had a stable platform to work from and make clients interoperable. There was an explosion of tools to aid developers in debugging and testing across clients. The Beacon Chain had stopped being a research project and started being an engineering one. The road to Mainnet started to become clear.
Now with the deposit contract launched and deposits flowing into it, the pressure to deliver the rest of Eth2 really amps up. Community pressure to unlock those funds again will become overwhelming and despite all the warnings that it won't be quick, people will be disappointed at how long it takes. But those locked funds will also be the equivalent of the interop lock-in, forcing work out of the research phase and into production. All that time spent researching led people to wonder if Eth2 will ever ship, but with the beacon chain launch and all that money locked in, Eth2 has almost unstoppable momentum.
The future of Ethereum is very bright.
I'm quite proud of my blog post explaining the weak subjectivity period: "Exploring Ethereum 2: Weak Subjectivity Period." It was just me trying to get my head around a concept everyone seemed to be very hand-wavy about and put off solving to the future, yet it's become one of the standard reference points to explain the concept.
I'm proud to have worked with Meredith Baxter and Cem Ozer. They have both been doing all the heavy lifting for Teku, almost entirely behind the scenes. They aren't flashy Twitter personalities, they just put their heads down and do the work.
A few anecdotes to conclude:
I was working at Parity Technologies in 2018 which managed to implement EIP 1011, the "Hybrid Casper FFG" in the Parity Ethereum client. It was a hybrid proof-of-stake approach to the consensus engine and literally my first memory of seeing anything Eth2 related actually being implemented and run. There was Casper testnet up and running with Harmony, Pythereum, and Parity. It was exciting to see the idea of "Serenity" starting to materialize.
However, it was the same year (only a few weeks later) that the Berlin Eth2 workshop decided to completely discard the hybrid Casper ideas in favor of the beacon chain. Admittedly, it was a massive undertaking. After all the ideation and the first implementations and testnets, we basically started from scratch.
Prysmatic Labs first caught my attention when they launched their first public beacon chain testnets at the end of 2019. I was wondering why we had seven Eth2 clients but none of them was able to synchronize to the other clients' testnets. I was hooked and reached out to the Ethereum Foundation and the Goerli Initiative about contributing to multi-client testnets. And that's what I did in 2020, testnet after testnet up to the mainnet launch.
When we launched the Goerli testnet in January 2019, it was not only an important milestone for Eth1 but it was also the perfect chance for Eth2 client teams to use this for their Eth1 integration leading up to the beacon chain genesis. Prysmatic Labs seized this moment and deployed all their Eth2 testnets to date to the Goerli testnet. Coindesk wrote a feature story with the headline "A New Test Network Just Activated and Ethereum 2.0 Will Be Using It."
All my work on Eth2 concluded with the Eth2 mainnet launch in December 2020. The eight multi-client testnets are well documented on Github and received quite some media attention.
As for bugs or missing features, that would be the lack of BLS signature verifications in the deposit contract.
Shoutout to Hsiao-Wei Wang!
What a ride it has been! The launch of the Beacon Chain in 2020 represents the culmination of years of research and development across countless contributors from every corner of the globe, reaching as far back as the Ethereum genesis block.
It has been exhilarating to watch this effort go from a collection of wild ideas (e.g. informal talks on Casper from Devcon 3) to today’s production-scale mainnet. Having been involved before the “casper + sharding” merge and the formation of the eth2 umbrella, I have seen time and again how a dedicated group of individuals adapts and responds to changes both inside and outside the community. It is this resilience that I find most exciting, and that gives me confidence in a very bright future for Ethereum.
We are ready to weather whatever challenges may come our way and I cannot wait as we deploy a scalable Ethereum in 2021 and beyond.
I'll highlight some of the early Casper work that got me involved directly with eth2 in mid-2018. Part of the original proof-of-stake design involved a validator registry contract hosted on the eth1 chain. As part of the deposit process, validators provided an arbitrary smart contract for signature verification. While an interesting application of account abstraction, this smart contract needed to be deterministic so that signatures could be independently verified on-chain. In order to ensure the smart contract had the desired properties, it was processed by another smart contract, the "purity checker" (in the sense of a pure computation), during the initial registration.
An early version of the purity checker was written in a now deprecated smart contract language called Serpent LLL. I created a Gitcoin bounty to port the Serpent LLL to a language stack used in the ethereum/casper project, Vyper LLL.
Most painful bug would definitely have to be debugging cross-client interactions during the eth2 interop event in 2019. Fun times, good people and challenging bugs!
Shoutout to protolambda!
My predominant impression is that Eth2 poses problems, which are perhaps the most challenging from a software engineering point of view, at the moment. This is exciting from a researcher's perspective, but sometimes frustrating from a software engineer's one. We must adapt, in order to survive in the endeavor.
One aspect is that we, as software engineers, are used to optimizing for the common case, largely overlooking rare ones. But the latter ones are exactly what an attacker will thoroughly scrutinize! The habit is difficult to break, especially considering that it demands huge amounts of time to analyze and optimize the worst case behavior.
I'm confident that we have to use Formal Methods, as testing is not able to explore the search space exhaustively (except for rare cases, when the space is relatively small).
Another important aspect is that modern DeFi is demanding on resources. And that is not only data throughput, but EVM/CPU throughput too. ZKP/zkRollups is an obvious example. However, asset pricing can be computation hungry too. And, as we can see now, DeFi asset pricing is an important topic. Unfortunately, EWASM turned to be a much harder idea to implement than initially expected. And it's basically for the same reason - WASM JIT compilers are optimized for a common case, while worst case scenarios can be exploited by an attacker. So, I treat it as another manifestation of the problem discussed above.
While the problems are difficult, I am very excited to investigate and implement potential solutions.
One idea that I'm working on is a (semi-)automated transpilation of Eth2 beacon chain Python specs to Kotlin. The resulting Kotlin code is beautiful, IMHO. Kotlin turned to be a pretty good match for (a statically-typed subset of) Python.
As for a specific bug, it's not yet made public (as it can turn to be a serious vulnerability). But the basic idea is that swapping two lines leaves a function 100% functionally correct, while an attacker can send the code into a practically endless loop.
Shoutout to Danny Ryan!
I could write a book on this, and perhaps one day I will. But the tl;dr is that getting to where we are has been the most incredible journey of my career.
The technology is thrilling, and the distributed development model no less so. But the highlight above all is getting to work every day with such a brilliant, thoughtful, capable, and generous group of people. If it's true that technology reflects the people who build it, then Eth2 is going to be a superb foundation for all the systems of the world.
As for the future, the beacon chain was designed, developed and delivered astonishingly quickly, having been conceived only in June 2018. Things get harder from now on: the beacon chain already carries so much value, and we need to begin taking into account the existing value on the Eth1 chain as we work on a merge. I think our main challenges ahead may not be technical, but more governance related. But I am confident that, with the ethos we've established and momentum we have as a community, we can bring this thing to a successful conclusion.
I've enjoyed writing up regular digests of the latest developments in the spec since October 2018 at eth2.news, really with an audience of just the other Eth2 devs in mind. Over time it's grown and evolved, and now gets between three thousand and ten thousand views per edition. This amazes me.
I am still happy with my one and only ethresear.ch post, co-written with Nicolas Liochon: "Exploring the Proposer Collator split." While more of a design bug than a code bug, some credited it with finally finishing off the old sharding design, and precipitating the move to the beacon chain. I think things may have already been heading in that direction at the time.
As for individual shoutouts, what an incredible group of people - you are all amazing!
Although eth2 has taken longer to get off the ground than I think any of us imagined, the result is extremely robust, secure, and decentralised.
It is incredibly exciting to see how eth2 is evolving and maturing into the backbone of the decentralised future we all dream about.
I'm most proud of the key-derivation EIPs (2333, 2334, 2335). Specifically, the quantum-secure backup keys built into EIP 2333. In the event of a quantum apocalypse, validators should be able to recover using these Lamport signatures.
I'm also really proud of the Launchpad. 🦏 So many validators managed to deposit safely.
Special shoutout to Hsiao-Wei Wang for the attention to detail and diligence she brings to everything she works on.
The past two years have been a blast. Looking back on the progress we've collectively made and the state of the ecosystem, I feel like we're on the cusp of something great. And I'm honored to be a part of it. I anticipate that Ethereum will be of critical importance for the future, as a rock-solid foundation that empowers ultimately successful experiments which aim to resolve many of the hardest problems facing society today.
I'm proud of the typescript implementation of SSZ (a copy of Proto's remerkleable). It fulfills the spec, but in an ergonomic way. You can operate on an ssz merkle tree as if it is a 'normal' javascript object. This required some exotic code, but the result is seamless ssz <-> javascript interoperability.
Huge thanks to Proto and his work! Many of the tools / algorithms / methods he's published are present in Lodestar: remerkleable, eth2-fastspec, protoarray fork choice, etc. the list goes on.
It has been a humbling experience to have witnessed the growth of Prysmatic from a small seedling with a dream to the robust and diverse community it harbours today; equally so for the broader Eth2 ecosystem. Hard work over the past two years has proven that, through all the speculative noise and interindustry drama, the things that truly speak are code and passion.
I'm most proud of my work on the Prysm client usage manual.
Shout out to all the boys here at Prysmatic Labs. You are all fantastic to work with, here's to the future!
Shoot for the stars. Even if you miss, holy fuck you're in space!
I’m blown away that the Eth2.0 beacon chain is now alive and well. For me it was such a complex undertaking, and deep down I was scared it would never launch or be successful.
When I first joined Teku (called Artemis back then) we were almost only working on the state transition. The spec changed pretty rapidly at the time, and as a result we had to update our state transition many times. I found myself leading these changes at Artemis, and it would almost always be a week long intense marathon where we’d change thousands of lines of code as a team, and I’d try to make sure we did not break anything.
Luckily this was in the prototyping phase, this is not how it’s done today in the production phase :). I’m also pretty proud of having worked on the Eth1 Deposit Management of Teku.
My best bug discovery is luckily documented by my team lead Adrian Sutton on his blog: "The Curious Case of the Invisible Fork."
Shoutout to Johnny Rhea, Adrian Sutton, and Protolambda. These three people are all geniuses in their own unique ways. It was an honor and an incredible experience working with them.
I'm glad to be part of Eth2 development. There are too many people; I can't express my gratitude enough. There are lots of beautiful memories that I'll cherish forever.
I'm excited to see what Ethereum will be with fully-fledged PoS as well as sharding.
I'm most proud of introducing the Milagro BLS binding to Trinity. BLS signatures are like the steroids of Eth2. Back then, only one Python library, py_ecc, met the requirements of the Beacon Chain spec. py_ecc is great for research or education purposes, but for things like client implementations, the performance of the library is not on par. The naĂŻve alternative is to find a Python binding of a fast language. Chia's Python binding to C++ code was the low hanging fruit to pursue.
As the Beacon Chain BLS requirements became more specific, and we had to interop with other clients in a short timeframe, we decided to try using Python to wrap "milagro_bls" - Sigma Prime's Rust library. The result is the "milagro_bls_binding" library. I'm proud of it because that's my first Rust-ish project, and it was used in a real use case.
As for most challenging bug, in early 2018 I worked on the Casper prototype testnet that Karl and Vitalik built on pyethapp. Pyethapp had many issues, but the most difficult one to debug was the peer connection issue. I got a lot of help from Dmitry from the Harmony team, he discovered many peer connection issues with the Java client's logs. One of them was pyethapp's catastrophic peer-to-peer bug.
Special thanks to Jannik Luhn - he contributed lots of quality work in peer to peer research/simulation and Trinity.
By historical accident, one of my first ever involvements with Ethereum was the research workshop in Berlin 2018 where the Beacon chain design (and merging of Casper and Sharding) was first decided. I had only come to the workshop because I was in Berlin at the time for my startup and my former colleague and friend, Justin Drake, had invited me to check it out. The concepts that were talked about at this workshop immediately appealed to the nerd inside me -- deep maths and computer science problems, nevertheless approachable and worth exploring to find elegant solutions.
Over the next few months, I tried my luck on some of the problems that were discussed, especially the randomness problem. However, it would only be March 2019 that I left my startup and went to work on Ethereum 2.0 full time, so I would say that the concept of the beacon chain was by then fairly mature and what was left to be done was more tinkering around the edges.
I think it is always worth reminding ourselves that the beacon chain itself, while only one part of Eth2.0, is a very ambitious project. As far as I am aware, Proof of Stake has never been tried on this scale: neither economically nor in the networking sense. What I mean by this is the sheer amount of funds that can be staked on the beacon chain, which due to the Ether market cap can easily approach billions of dollars in value. This is one advantage smaller projects certainly do have over Ethereum -- they can increase stake gradually, whereas Eth2.0 will very quickly go all the way.
Not only that, but most other projects have refrained from actually imposing penalties on validators -- which compromises the security of PoS networks, but obviously makes designing it much easier, because literally nothing is at stake except for some very minor rewards.
Finally, and this is the most important distinction, Eth2.0 is designed so that it can literally accommodate a million validators. That's pretty impressive considering that most other projects only support around 100! Not only that, but this feat is achievable using fairly modest node requirements, in fact it seems perfectly plausible to run a validator on a mobile phone or a Raspberry Pi.
When we do launch the beacon chain, which is now truly imminent (barring extreme surprises), we should keep in mind just how ambitious this project is even on its own.
The beacon chain was essentially frozen 3 months after I joined the team full time, so I would not claim that I have made any major contributions to it. My most important contribution to Eth2.0 that is slated for inclusion so far is re-architecting the Proof of Custody construction so that it is fully suitable for SSVs (Secret Shared Validators). While we weren't too sure of the experimental cryptographic Legendre pseudo-random function (PRF) when we first came across it in March 2019, it has successively improved to a truly impressive construction on all fronts that I am now very proud of:
Finally, I have huge respect for Danny Ryan. He is phenomenal at keeping everything together and making it work.
Surprise! Everything is a bit harder than originally expected (at least from my perspective) - I suppose most of the things worth doing in life are. Today, I am very excited about the project and the progress. Eth2 has an incredibly strong technical background and is ready for the next wave of upgrades. Huge shout-out to the hard work from client teams, as well as to the validator community keeping this thing running.
I'm most proud of my work on the beacon chain spec.
Finally, I don't want to imagine how this would have gone without protolambda's insight and technical contributions over the past couple of years.
Super grueling, but rewarding in terms of overall impact on the different ecosystems, Eth2 itself, the Nim language and libp2p.
I'm most proud of my work on the Nim libp2p implementation.
My journey started with implementing Serenity™. It was an ambitious and abstract concept. We've struggled with the design trade-offs for a long time, but with more and more contributors who devoted their efforts, and years of hard work, we were finally able to divide and conquer Eth2.
It was a fantastic journey to launch Phase 0 finally. I'm so grateful for the broad community support. And, of course, the Ethereum heroes who dove into Ethereum R&D.
I'm very excited about the next Eth2 milestones and the creative ideas that the community will build on Eth2.
I want to mention my admiration for Virgil Griffith, a pioneer that paved the way for Ethereum research work.
Working on Eth2 has been an amazing adventure. It went from contributing in my free time to becoming my longest running full-time job. While there have been a few blocks on the way (unstable spec, implementation problems, testnet drama), it's been an absolute blast and this is just the start! Very excited to release, and move forward with future phases!
I am particularly proud of building our end-to-end testing suite, which has proved incredibly useful for detecting issues before changes reach the canary. I've also helped build a lot of the slasher and optimized it for mainnet usage.
One of the most memorable bugs I encountered would have to be: "Change StreamIndexedAttestations to use target root for state regen #5971."
Shoutout to Terence Tsao! His ability to understand the spec has constantly amazed me (he's the largest contributor to the spec outside of the EF!).
Also.. Danny Ryan is awesome :)
I was fortunate to join Eth2 at the very start - having worked on many open source projects before, for fun, peer-to-peer networks like DC++, compilers like nlvm, as well as high-frequency trading. It all came together at that point like a perfect fit - a giant stroke of good luck. Here we are, years later, with the baby well on its way to being delivered.
The work I'm most proud of is managing to restore sanity and switching Eth2 to Little Endian. It survived several high-profile attempts to swing it back to Big. I guess a more memorable, and certainly more involved feature, was the deep collaboration on the networking protocol that culminated with what we have today - this was quite the achievement made possible by some round-the-world collaboration with Adrian (of Sigma Prime), RaĂşl (of libp2p) and lots of others! Less known is that me and Adrian resorted to flipping an Ethereum block hash coin to see who would get to post the PR :)
I'm most proud of when Paul Hauner and I managed to run a fully independent, self-sufficient multi-client Eth2 network for the first time, at the Canada retreat!
"It was the best of times, it was the worst of times, it was the age of wisdom, it was the age of foolishness, it was the epoch of belief, it was the epoch of incredulity, it was the season of light, it was the season of darkness, it was the spring of hope, it was the winter of despair."
Particularly proud of my Ethresearch post, "Packetology: Validator
Privacy."
Most memorable bug: "DoS Attack on Prysm Stops Finality."
Shoutout to the Russians! (former Harmony team) “You know that if we don't pull this off we are fired, right?” Joe Delong to me before the interop lock-in.
I hope we can move from the Beacon Chain to a practical implementation as fast as possible. Most proud of my implementation of the deposit tree logic in Teku. Toughest bug was getting the "is_valid_merkle_branch" method working in Teku.
Shoutout to Jonny Rhea & Mikhail!
The Beacon Chain launch is like Project Mercury: getting into space/orbit. The equivalents of Project Gemini and Project Apollo are needed next. Rollups and Layer 2 will help improve scalability, but I believe there is much innovation that can and should continue to be done in Layer 1. There is a place for some execution, and cross-shard transactions in Layer 1. I also think that we should be careful about assumptions that we might make, like assuming that cross-shard transactions must be asynchronous. The challenges in the Ethresearch thread “Cross-shard DeFi composability” need tackling with minimal assumptions.
I dream of a system that is more scalable, performant, but preserves the default atomicity and synchronicity of Ethereum. I dream of shards that are transparent and automatically load-balancing. It may sound impossible, but can be used to inspire the engineers of the world to build the ambitious system that we can envision.
Developments like Apollo and the Internet are an encouraging reminder to what humanity can accomplish: where there's a will, there's a way.
Why is this important? Why is a platform for decentralized systems important? John Perry Barlow may have answered it with his “Declaration of the Independence of Cyberspace.”
Personally, I'm delighted that "The Beacon Chain Ethereum 2.0 explainer you need to read first" is usually on the first page of Google for "beacon chain." I'm most proud of forming and recruiting a talented R&D group at ConsenSys that has made numerous Ethereum contributions. For Eth2, these include a review of the deposit contract and influencing an important Solidity implementation. More well known is the Quilt team, which started from R&D of Eth2 Phase 2 (execution, threads [quilting], rather than Plasma). Finally, years ago I helped connect Karl Floersch to the Casper "team" at EDCON Paris.
Shoutout to all of Ethereum Layer 0 -- its people -- without which there would be no Layer 1 or beyond. Layer 0 always welcomes you, and all contributions great and small :)
Looking back, the beacon chain took longer than expected to ship and there is significant work remaining in the coming years. Having said that, I am incredibly optimistic and excited about the future of Ethereum—I could not be more bullish :)
I'm pretty proud of the fact that the beacon chain spec is executable - it's pretty remarkable IMO. How many complex internet protocols have a full executable spec, not to mention four production-grade implementations on day 1?
One of the "design bugs" I was involved with early on was having PoS and sharding be separate cryptoeconomic systems as opposed to one unified design. Another big design flaw was using plain (as opposed to aggregatable) signatures. Looking back, in ~2 years we took a visionary but very rough design and made it orders of magnitude better.
Folks dedicated to Eth2 are a rare breed (less than 100 of us) and I have tremendous respect for the team as a whole, as well as many individuals. I will note that, with where things are headed, we may soon have trillions of dollars running on Eth2 and we will need more manpower. So I want to give a shoutout to you—the reader—to consider joining the Ethereum mission :) Hit me up by email, on Twitter, or on Telegram!
It has been a wild journey to scale Ethereum & we are ridiculously close to realizing the vision after all this time. It's pretty insane. I'm most proud of the early work I did on Casper and initial implementation of Hybrid Casper. As for bugs, the pyethereum p2p layer was absolutely terrible and really crippled the testnet :'''(
Shoutout to Vitalik, Hsiao-Wei Wang, & Justin Drake!
It's been a very busy two years; as only my second job working in IT, the learning curve has been massive. First and most importantly, my understanding of the core technologies around blockchains has matured from seeing them as a secure linked list to the complex beast they are. With the focus of my work being on integrating BLS into Lighthouse, a significant knowledge of pairing based cryptography was needed. The BLS signature scheme is far more complicated than the existing ECDSA used in Eth1. Luckily, there are a lot of good resources out there which explain how to progress from classical elliptic curve cryptography to pairing based cryptography.
I was lucky enough to go to DevCon Osaka in 2019 which was an amazing experience! There were so many keen minds all meeting to relish and enjoy the progress Ethereum has made, but also to provide insights and ideas on how it will be improved and developed over the coming years. Japan itself is also an amazing place with so much to see, until we almost got stuck in a typhoon.
I am most proud of the work done on Milagro BLS. This library was rough around the edges when I first inherited it, being a long way from the standardised signature scheme we have now.
Finally, wanted to give a shoutout to Danny Ryan! The man is a weapon.
I remember reading the "70% ready" spec in july 2018, that was the wild wild west. Things were on a HackMD document, changes were made every 6 hours and very hard to track - as mentioned in the EthCC 2 talk "Tests and Simulations of Eth2.0."
One of the most significant milestones was when, out of nowhere, all 7 clients at the time were able to create a testnet back in September 2019 in Muskoka. Anticipation, apprehension, will the launch work? If yes, that is definitely a huge milestone!
I'm proud of my work on the "Auditors Handbook to Nimbus Beacon Chain." Nimbus uses a dark horse language called Nim. It happens to be easily picked up, and our 3 audit teams were pleasantly surprised by its features, including those related to correctness.
The most infamous bugs we had were related to fork choice / Proof-of-Stake. The most infamous one would be this one-liner hotfix, where some votes were skipped in period of non-finality: "hotfix fork choice score application #2041."
Big respect to Protolambda! He came like the Hagibis storm.
My perspective on eth2 is probably very different from many people who were focused on Phase 0. Although I compartmentalized Phase 0 and Phase 1 to a large degree to allow myself to consider the possibilities of Phase 2, I never considered the possibility that eth2 wouldn't ship. To me, it was not a matter of "if" but "when."
I'm proud of the work I did writing the first Execution Environment for eth2, called "sheth." It was completely stateless and allowed Ether transfers within a shard.
Shoutout to Proto, he has been instrumental in making eth2 happen, I don't know how he manages to be so prolific.
A quick story to wrap up. On the first day of the Canada interop, the Quilt team drove up from Toronto in a 15-person passenger van. It had rained a bit so the area was sort of wet. The venue was tucked away off on a gravel road, right beside the lake. We pulled the van up next to the parked cars and headed in to visit with the eth2 teams.
After catching up with everyone, we returned to the van to drive over to the airbnb we were sharing with the ewasm team. Will Villanueva had driven us there, so he hopped in the driver's seat and began orienting the van forwards to head out. The area we had parked in was sort of a T-intersection and there were small drop-offs (0.5m maybe) into a heavily wooded ditch anywhere there wasn't road. Will backed into one of the legs of the T and started to drive forward to leave. Unfortunately, the exit path was a rather steep gravel hill. The 2WD van didn't have the traction climb out and now we were positioned at an awkward angle in the T. The van was perilously close to tipping over into the ditch. Will backed up to a flatter part to regroup. I offered to give it a shot and he obliged.
At this point, we had drawn a bit of a crowd. I recall having people at each corner of the van, keeping an eye out to help avoid falling off into the ditch. I gave it a few attempts, but realized how difficult of a situation we were in. At this point, it was unclear if we could even return to our starting place, as the front left and back right of the van were less than a foot away from falling into the ditch - a ditch that would no doubt require a tow truck to collect the van from. There was no other option than making it up the hill. Fortunately, there was a bit of flatter ground between the van and the beginning of the hill. Although it would be a tight fit, likely inches on either side into the wooded ditch, I thought that with speed we should be able to build enough momentum to get past the steep portion of the hill. I shared my plan with the spectators. Unsurprisingly, the uninvested patrons were eager to fill me with confidence so they could enjoy the spectacle. I backed up the van as far as the gravel road would allow and then slammed the gas down. The van lurched forward, albeit lethargically, towards the top of the hill. The eth2 gods were almost certainly looking down on us in that moment and guided that van safely to the hill's peak.
At the top of the hill, I collected my emotions and then stepped out to enjoy the laughing and cheering. We inspected the ridiculous situation we had been in, and examined the ruts that the tires had made spinning out on the fail attempts. After the excitement died down and the spectators returned to the venue to continue working on their clients, we headed back up the hill to our van and drove home.
For the rest of the time there, we parked the van at the top of the hill and walked down to the venue.
I find it hard to believe that we're finally launching the beacon chain! So much hard work from so many different entities has gone into this over the past couple of years. I'm extremely proud of what Sigma Prime has accomplished so far and look forward to the Lighthouse crew making Phase 1, Phase 1.5 and Phase 2 a reality.
The structural differential fuzzer I've helped build as part of Beacon Fuzz is definitely something I'm proud of. Over the last few months, Beacon Fuzz helped uncover more than 40+ bugs on all major client implementations, including critical consensus related vulnerabilities.
It's hard to pick one person to recognize, but Diederik Loerakker (aka protolambda) has done such an amazing job helping the client teams navigate the optimisations required to implement the eth2 spec in production. Of course, the coordination job done by Danny Ryan is second to none. I doubt we'd be where we are today without these two exceptional individuals.
Fun fact: Lighthouse releases are named after Rick & Morty characters!
I was fortunate to join the Teku team at an exciting time (about a year ahead of the beacon chain launch) in November of 2019. We had a lot of work ahead of us and we weren't sure whether or not we would meet launch deadline with a fully functional, production-ready client. The learning curve to understanding eth2 is also pretty steep, which only increased the pressure. Luckily, the EF and other eth2 client teams have been an incredible resource for us throughout the development process. The engineers involved across the client teams have been very open and supportive. And the EF researchers have been amazingly welcoming, approachable, and responsive. They've always been there for us to answer questions and provide insights. It has been hugely gratifying to be a part of the successful launch of the beacon chain with the help of this incredible group of people. I'm very excited to continue the work as we look forward to upcoming changes including our first hard fork, sharding, and the merge.
One exciting milestone was getting Teku syncing to a live testnet (Prysm's Sapphire testnet).
I'm also really proud of our checkpoint sync feature which allows new nodes to sync up and become fully operational within minutes. See the issue as well: "Implement sync from a recent state #3063."
The instability on the Medalla testnet in the fall of 2020 was a trying moment across the client teams, but we came out stronger on the other side. We were all working overtime to improve performance and patch issues revealed by the long period of non-finalization. One big fix I managed to push during this time involved putting a hard limit on amount of work required to regenerate states that dropped out of our in-memory cache: "[Issue 2608] Add ability to periodically persist hot states #2611." More context on the network instability can be found here: "Eth2 Implementers’ Call #46 - 2020-08-20."
After a brief foray into the blockchain world in 2017, I developed a taste for it and knew I had to come back. When I saw a job ad from SigP on Twitter for a proof-of-stake client in Rust, I dropped what I was doing and got involved ASAP. At the beginning I got deep into Lighthouse's consensus code which was then very much in flux due to lots of spec changes, and had been written in a gargantuan solo effort by Paul! From that foothold in consensus I then branched out into the database, op pool and slashing -- all of which captured my interest in a way no other project had.
When we ran the first testnets in September 2019 off code I'd contributed to, I was kind of shocked the thing worked at all, and awed by all the hard work done by everyone else involved. This community of researchers, programmers and enthusiasts has been nothing but amazing, and I'm optimistic for a successful Phase 0 launch and the realisation of the Eth2 dream in Phase 1 and beyond. Personally, I can't wait until we can run some transactions, and look forward to getting into the minutiae of WebAssembly execution environments.
I'm very proud of Lighthouse's slasher. I was able to draw inspiration from great foundational research laid by Proto, and dedicate myself to building a fast, concise implementation. Testing the implementation on Medalla and watching the carnage inflicted on other validators brought a perverse form of satisfaction ;)
One of my favorite bugs: "DB inconsistent after restart #1488."
Shoutout to Cem Ă–zer!
I know of at least one core dev who force pushed a commit to master in the EthDenver bathrooms...
It's been exciting to see how Hybrid Casper FFG and the Sharding proposal have been merged into what is now called the Beacon Chain. And how this research is evolving, growing, attracting a lot of new people. And finally the result is about to be shipped pretty soon. This was a big part of my life for two and a half years. I anticipate rapid movement towards Shards and the Merge when Phase 0 is shipped. Though there are many things yet to deal with.
I am proud of the Eth1 Shard Demo that we made together with Guillaume from EF with decent support from EF researchers.
I can give recognition to a bunch of people tbh. But, narrowing down, Danny Ryan and Ben Edgington.
I'd heard a bit about Ethereum before but had not developed a solid understanding.
Although relatively new, I'm glad to play a small part in such a technically impressive undertaking. I am continually appreciative that I can work in such an interesting space, with such friendly and impressive colleagues and community, and contribute to something that has the potential to be profoundly important. I'm excited to see Phase 0 mainnet kick off, the culmination of so much effort!
I look forward seeing the space continue to develop with the incorporation of the EVM chain and Layer 2 solutions, and all the interesting use-cases that I can't begin to imagine.
My primary contribution to the Eth2 ecosystem had been taking on maintenance and development of a differential fuzzer that compares state transitions across the Eth2 clients: beacon-fuzz. In September 2019, Sigma Prime was engaged by the Ethereum Foundation to continue development of Guido Vranken's previous differential fuzzing solution - comparing ZRNT and Pyspec, the Go and Python Eth2.0 executable specifications.
I was primarily responsible for building out the fuzzing framework to include comparison of other client implementations: Lighthouse, Prysm, Nimbus, Teku, Trinity, as well as adding fuzzing targets for additional state transition functions.
As for most painful bug, see the "Beacon Fuzz update 001" on the Sigma Prime blog, section "Golang Library Linking Errors." How to try to get multiple Go implementations running without having their dependencies clash, and dealing with arcane linking issues using existing tooling to build a Go fuzzing library that exercises cgo/C code (as Prysm depends on a C/assembly BLS library).
I want to give a shoutout to Protolambda (Diederik Loerakker). He reliably gets to the bottom of really obtuse fuzzing results. He's our consistent fallback for deciphering complicated results across multiple Eth2 client implementations. From our interactions, he clearly comes across as a friendly, genuine, and technically outstanding individual.
It was a very difficult endeavour to get Eth2 running smoothly. Ultimately, with teams well distributed across the globe, constant communication is always a challenge. However, despite all that, I am really proud of the fact that we have launched Phase 0 with 4 different clients running. I'm very optimistic for the future and am looking forward to the merge. There have been too many bugs to count, and I keep on finding new ones every week.
Shoutout to Proto - cross client compatibility would be nowhere near what it is without him constantly monitoring and working on it.
The Ethereum Foundation has fostered an inclusive, open, and merit-based approach to technical collaboration. Under this environment we've seen many researchers, engineers and communicators flourish. This is a testament to what people can do when they share a common goal and are empowered to work on the things that interest them.
As Eth2 has progressed, Sigma Prime has grown steadily to include a team of talented engineers and computer scientists. I am grateful to work with these people and I learn from them every day.
I hope to see Ethereum evolve into a tool that provides honest utility to everyday people, without jeopardising the sovereignty of their data or selves.
Regarding work I'm proud of, I quite like the minimal-allocation Merkle-tree hasher I built in 2018. It's simpler and more powerful than other algorithms I have seen.
One notable bug: "Manipulating deposit contract to gain an early majority #1446."
I remember reading Vitalik's proof of stake blog posts in early 2018 and thinking that it sounds all good in theory, but no way we'll have a proof of stake protocol for more than a small number of participants which would work well in practice. Needless to say, it's been extremely impressive to see how far the effort has come in just a few years. Kudos to everyone involved, I'm glad to have been a part of the effort for the past year.
Also, a huge shoutout to the SigP crew! It has been an absolute blast working with these guys, learning from them and also indulging in their jolly Aussie humor :) Excited for the Phase 0 launch and geared up to begin work on Phase 1!
Most memorable bug would have to be: "Update state before producing attestation #1596."
Big thanks to protolambda for sure. All his debugging tools have saved me (and many others I'm sure) hours of effort.
The last few years have been an adventure, to say the least. At first, I had just a mild interest in Ethereum. I didn't own any cryptocurrencies or really understand how they worked. After a few months of reading, I started to realize two things: 1) Ethereum was this incredible technology that has an unlimited potential to change the world for the better, and 2) Ethereum is incredibly slow and desperately needed to scale.
Immediately, I looked for ways to help contribute to the scaling effort and then I met Raul Jordan. We met together in NYC for coffee and talked about starting a project to work on sharding for Ethereum. We formed Prysmatic Labs. Since starting the company in January of 2018, I've met some of the most interesting people in the world - many have become close friends. Working in Ethereum continues to fulfill my desire to make a positive impact, and I'm very much looking forward to seeing the completed roll out of Eth2.
Most memorable bug would have to be that time that all of Prysm nodes thought they were 4 hours in the future and thousands of validators were slashed in a testnet: "Roughtime reports clock offset by 4hrs #6825."
The main theme is that we - researchers and client devs - did not make our lives easy. Spec updates have continued to improve the protocol itself, but caused instability in the process of updating implementations. A new network stack was adopted, and many difficult research and implementation problems had to be solved. In the future, I do not think this will change, as Phase 1 and later are complicated too. But the approach can be improved. Exploratory single-client implementation ahead of others could avoid duplicating work for other clients, and enable faster spec updates.
Most memorable bug: "247120: encoding/binary: read at most MaxVarintLen64 bytes in ReadUvarint."
Shoutout to @Butta for his work on the beaconchain explorer.
What struck me most when I joined the project was the seemingly infinite amount of good will and patience from others when onboarding a new contributor. I really appreciate it. As for the future, I fail to see how Eth2 can not succeed when there are so many great people working on it.
Shoutout to the whole Prysmatic team! Everyone is so cool I can't just pick one person.
I planned to visit Japan in the summer of 2020 and start learning Eth2 after coming back. The pandemic ruined my plans so I joined the Prysm project in May as a contributor. Three months later I got invited to be one of the core team members. Pretty cool, huh? I guess 2020 is not that bad after all.
We went from being a bunch of hobbyists and volunteers interested in Ethereum's future, to having a ton of responsibility with a client being used by a large portion of stakers today. Core dev work was indistinguishable from magic to me before starting on this, and it honestly still is. However, I am fortunate to be surrounded by people much smarter than I am, and constantly learning how to write better code. Every day, we feel the weight of the work we do and we foresee it will only keep getting more important, as Phases 1 and 2 develop and eventually Ethereum will be powering world-scale transaction volume, likely using the code we wrote. At some point, the blockchain we are building might have multinational implications, and the hard work from the research team to make it as robust as possible is very encouraging. I could not be any happier with how far it’s come along, and we'll ship it.
I am most proud of our original eth2 API. One day I was hanging out with Preston and Terence and we’re like “whoa! Etherscan built a block explorer using our API for eth2??” and then beaconcha.in popped up and it was honestly mind-blowing. We spent a lot of time putting it together and it contributed to the success of the Prysm client early on.
Our most memorable bug would have to be the Medalla Testnet Incident.
I admire my team at Prysmatic Labs. I look up to them every week in awe of their resourcefulness, prescience, and just overall raw software engineering knowledge.
Our journey with eth2 started with a few of us posting in a go-ethereum gitter channel regarding starting a prototype implementation of Vitalik’s sharding FAQ. Little did we know that just a few months later, we would be neck deep into everything about proof of stake and sharding with Vitalik and the Ethereum Research team in Taipei. Coincidentally, I was visiting New York the same week I met Preston online via gitter, and managed to meet up in his office and start Prysmatic Labs officially within the next few days!
Looking back, one remarkable thing that stands out to me is the unifying culture of optimism and positivity among the people who found Eth and Eth2 and dove into working on it. Kind of by self-selection over time, it's a community that wants to strive for the positive side of things. While it’s not always possible to maintain this, somehow over time it seems to always get back there again.
Moving forward, two themes I look forward to will be the acceleration of innovation and delivery around Eth2, and the growth of bridging among Eth2 and most other crypto communities and protocols that matter.
Shoutout to Casey Detrio — I love how he always seems to find a novel analysis angle to things!
Well, I'm a relative newcomer to Ethereum. I'd been vaguely aware of Ethereum for years, and I had (and still have) a couple hundredths of a bitcoin lying around, but Devcon V was jumping head first into the space.
The Ethereum community, once you get past all the... crap on the fringe, is full of really welcoming people who come from really diverse philosophies. I found that particularly surprising, given how many scammers and hangers on there are.
Eth2, which is actually where I started learning Ethereum, is a huge undertaking being built by an equally huge amorphous conglomeration. Seeing the discussions from execution environments and WASM to pure data availability and minimal execution, and the journey from where we were a year ago to actually getting the beacon chain launched has been one of the most exciting periods of my career so far.
I'm looking forward to the next phases, layers, and whatever else comes with Eth2, but more importantly, I'm excited for the memes, because really, that's what this is all about.
It's hard to compare what I've contributed with the amazing other things going on in the space, but I guess I'd have to say that the write-up on dynamic state access that Ansgar Dietrichs and I put together is probably the most influential thing I've worked on: "State Provider Models in Ethereum 2.0."
Looking back on this past two years makes me feel how this space is being shaped by the people who build it, their values and their convictions. Working in Prysmatic Labs developed my skills and code quality in a way that I cannot describe. Raul Jordan and Preston van Loon make sure to lead by example. All the team members are super motivated and take eth2.0's success as their own responsibility. That kind of dedication comes only from taking part in a project that has higher purpose for each member of the team. Looking forward, I see those bright and enthusiastic figures attracting many more talented people into the eth2.0 effort, while step by step the Ethereum ecosystem becomes the collaboration infrastructure of humanity.
I took part in kickstarting the slasher implementation in Prysm's code base. As context, old POS systems had a major flaw, called the "nothing at stake problem." Policing the set of rules to avoid this on the massive scale of the beacon chain is a challenge. Solving this led to the design and implementation of the Prysmatic Labs slasher. Working with other team members and protolambda from the eth2.0 research team was a great privilege. I got a first hand experience of protolambda’s ingenuity in finding novel solutions to hard problems.
Shoutout goes to Preston Van Loon.
We're moving at what probably looks like a slow pace, from the outside, but I'm confident we'll be able to replace Proof of Work with Proof of Stake. I can't wait to see the estimates for energy consumption reduction in the years to come!
I'm proud of the many changes that lead to reproducible builds. It all started with replacing a language-specific package manager with Makefiles and Git submodules, in order to have a fine-grained control over all our dependencies. Over time, it grew into a somewhat reusable "build system."
I also liked designing and implementing well-defined components like our metrics library or the NAT traversal library. Much messier, but equally rewarding, was changing the Nim compiler and standard library to implement efficient stack traces.
I like hunting down mysterious stack corruptions. A memorable one was due to the wrong calling convention being used in a C library wrapper. Another nice one was triggered by a procedure parameter called "errno" (which the Nim compiler forgot to name-mangle).
It has been an amazing journey, we have learned and accomplished so much along the way. Lots of great memories and friendships were formed.
With Phase 0 heading towards finish line, I'm particular excited about Phase 1 and all its cutting edge research. Go Eth2!
My Ethereum journey started in 2016, when I joined Status in building a censorship-resistant messenger. It quickly became apparent that, despite all the goodness the Ethereum platform and its decentralized network brought, in its current implementation they are relatively limited. So, getting attracted to Ethereum 2, with all its ambitious plans to revamp an already hugely innovative product, was just a matter of time for me. Right now, being part of the amazing crowd of highly motivated, even idealistic, people - with a chance to participate in delivering on the original Ethereum promises - is nothing less than a dream come true. I love the community, the leadership, and even the complexity of the software we're building. With Phase 0 behind us, we have significant momentum, so 2021 will definitely become a year of groundbreaking accomplishments!
One bit of work I am particularly proud of is the "initial synchronization implementation," which absolutely every beacon-node runner relies on. So, whenever you cannot sync, or sync takes forever, you know who to blame for it now!
Regarding nasty bugs, during the "Medalla incident" in August 2020, we had troubles syncing back. While the fix was easy, discovering the problem wasn't.
Shoutout to Diederik Loerakker! (yeah, better known as protolambda)
I'm really happy to see how far the Ethereum ecosystem has come in the last few years! In the dark old days back in 2014-2017, it was just myself, Vlad and a couple other people thinking about proof of stake and sharding, and progress was slow; since then, there has been a rapid growth, professionalization and general improvement in the ecosystem and the team. We have much more sophisticated tools, are dealing with advanced cryptography, and a much better process for creating and refining the spec and the implementations. 2020 eth2 is sooo much better than Casper in 2017!
Now, of course, we enter what may perhaps prove to be the most difficult part of the whole process: getting eth2 actually out the door and running. The whole process reminds me of what we had to deal with back in 2015, except this time there's 10x the complexity, 100x more people watching and 1000x the value at stake. Good luck all :)
If I had to pick one component I'm proud of .. maybe the entire phase 0 spec?
Shoutout to Danny.
Eth2 research was overwhelmingly fun. We explored pushing the boundaries on how the execution layer could operate. We prototyped, researched, and implemented a simpler version of advanced execution (Execution Environments) on eth1, also known as account abstraction.
A lot of the work Quilt pursued is covered in the post titled "Ethereum 2.0 Phase 2 Progress."
Additionally, some of our account abstraction work can be found on Ethresear.ch as "DoS Vectors in Account Abstraction (AA) or Validation Generalization, a Case Study in Geth."
Shoutout to Danny Ryan, all the way!
*Kudos for reading to the end! We hope you enjoyed these perspectives - be sure to thank the people featured for their hard work building core infrastructure. If you'd like to donate directly to this project, please send to the Split contract below. *
The crowdfund for 100 physical prints is live now!! Contribute here to get a physical copy of the book.
The Stateful Works team can be reached at @statefulworks on twitter. Join our discord if you'd like to discuss the project more fully.