Last month, we at Eyna Inc announced our Engineering Roadmap that spans from August 2022 until the end of 2023 (in case you haven’t seen it, be sure to see the awesome stuff we’re working on). One of those items is Boba v3, “Anchorage”, so let’s talk about why it’s a major milestone for the Boba Ecosystem.
Refresh My Memory, What’s a Client and How Does it Relate to a Server?
Now before we go any further, let’s clear up some terminology here. So, what exactly is a client? Whether you’re using an L1 or using an L2 (such as the Boba Network), a client is the software stack that runs on a server. A server, of course, is the actual/physical computer that joins a Blockchain. Now with the definitions out of the way, let’s analyze some problems we’ve observed in the web3 space.
Problem 1: There’s a Dirty Secret About Rollup Architectures That Few are Talking About
Ok, now let’s get serious and talk about Rollup Architectures. Every L2 (and their mother) will claim that their network/ecosystem is inherently secure because they are simply another layer that leverages the security of the L1.
Well… that’s not entirely, purely true.
The best way to look at it is like this. Several of these Rollups are still like a child in their development phases, and would occasionally need guidance and correction to ensure that they are on the right path.
These Rollup architectures lean on upgradeability for updates and the keys of which rests with either an individual or a multisig controlled by a small set of people from the same team. This upgradeability generally involves access to the L1 rollup contracts that make up the protocol, its security, and in turn, the assets locked on it. So even though the Rollup may have protocol security and fault proofs in place, they are only truly valuable as long as the upgrade keys aren’t able to freely modify the protocol. Therefore, you cannot have L1 level security until you’ve resolved this problem.
And to make matters worse, no L2 will throw away or destroy their upgrade keys because of the possibility of two conditions:
- You’ve discovered a bug in your smart contract (AND)
- You want to upgrade your L1 contract to resolve the bug
Problem 2: Everyone Using/Leveraging the Same Client Can Be Bad for an Ecosystem
Without getting into all the details of the types and flavors of clients out there (execution clients, consensus clients, and rollup clients), it should be easily understood that any network/ecosystem can benefit from the diversified use of clients, from a security point of view.
In the same way that Ethereum needs client diversity (Geth, Erigon, OE, Nethermind, etc.), Rollups also need client diversity. Why? Because with Rollup client diversity, a bug becomes a fork and can be resolved. Without Rollup client diversity, a bug has the potential to become a critical security incident. Client diversity also gives us proof diversity, thanks to Bedrock.
Look at it from this perspective; what if every web browser available (Chrome, Safari, Edge, and Firefox) all used or leveraged exactly the same code underneath? This would lead to two immediate problems:
- An attack that targets a vulnerability or bug in one browser is 100% effective against every browser (which is a pretty scary thought!)
- (Web) Protocols and standards become meaningless. Web2 developers will simply implement web sites that they know that will run on the common codebase
The same thing applies to web3. Everyone should not be using or leveraging the same execution, consensus, or Rollup clients.
So, we’ve analyzed these two issues, and we’re pleased to introduce you to Boba V3 “Anchorage”.
The Solution: Boba v3 “Anchorage” is All About Client Diversification!
So, what is Boba v3 “Anchorage”? It is an execution client that leverages Erigon (instead of the overused Geth client). Boba v3 also includes fraud detection and fraud proofing. Last of all, Boba v3 is a Rollup client that is compliant with Optimism’s Bedrock specification.
Optimism is developing a reference implementation of their Bedrock specification using a modified implementation of Geth as their execution engine. Our contribution to the open source rollup ecosystem is that we’re going to develop a Bedrock client based on the Erigon codebase. Our Anchorage platform will be compatible with Optimism but will use Erigon instead of Geth.
We recognize that client diversity directly contributes to the overall safety, security, and stability of the Optimistic Rollup Bedrock community. We also recognize that having multiple implementations of a common set of protocols will thereby increase the chances of discovering and fixing any issues or vulnerabilities in both the specifications and the implementations.
This is literally why web browsers and web standards have improved and evolved over the last 3 decades.
Final Thoughts on Anchorage and Erigon
So, in addition to the overall benefit of diversity that Anchorage will bring to the table, (both to Ethereum and to the Optimistic Rollup community), we are also in the process of contributing source code to the Erigon community to help improve L1 clients. We are closely watching the Erigon roadmap to make sure that we fully leverage all the features of Erigon (both now, and in future releases).
Anchorage is a huge step in the path toward removing upgrade keys, and this is a path that we are committed to. Our next article in this series will provide more details on what we’re contributing to Erigon, and why it’s important. Stay tuned!
