SEAL Battlenet Initiative Proposal

The SEAL Battlenet initiative developed through discussions with SEAL members at the SEAL Assembly 2024.

Concept Overview

SEAL Battlenet is a live adversarial environment where teams can deploy and test new protocol versions with realistic network behavior prior to deploying on public main networks. Battlenet allows for rapid iteration to improve web3 security by creating a feedback loop between protocols, attackers, and security professionals in a controlled environment.

What does success look like?

We stop seeing the same types of exploits and vulnerabilities make their way into production because they are caught at an earlier stage, preventing harm to users and protocols. Alternatively, more unique bugs, exploits, and failure conditions means that Battlenet is working.

What does failure look like?

We continue to see the same issues exploited on Battlenet over and over, and continue to see them on mainnet chains as well. This would indicate that the feedback loop is not working, protocol teams are not improving, and we have not improved the safety of crypto.

Why do we need a Battlenet?

For Protocols

Before deploying new protocol versions, teams currently perform internal testing, deploy to testnets, work with external auditors, and set up bug bounties for security disclosures. Many teams also configure some sort of monitoring, paging, and incident response processes but the approach varies widely.

Despite all of these precautions, serious bugs still make their way into production. These may be due to overlooked issues in the smart contracts, unexpected situations caused by behavior of the network or changes to dependencies outside of the control of the protocol team.

A realistic Battlenet provides an environment in which these types of network conditions and behaviors could be incentivized leading to discoveries that would otherwise be missed. This environment would also be an ideal place to configure monitoring first, and test out incident response systems and procedures.

For Researchers

When researchers propose novel MEV mitigation strategies, market structures, and other protocol enhancements they lack an environment outside of mainnets and simulations to test them. A Battlenet would be an ideal place to test out these ideas.

For Whitehats

A Battlenet could provide a useful environment for whitehats to develop their own detection, rescue scripts, and frontrunning tools in a controlled environment.

For SEAL

In the future, Battlenet can act as a unified testing grounds for multiple SEAL initiatives including Wargames, Safe Harbor, and SEAL 911. To be successful, Battlenet requires collaboration between SEAL members, protocols, community whitehats, communications experts, legal, and infrastructure providers.

Naming Disclaimer

Recently we learned that:

Battle.net is an Internet-based online game, social networking service, digital distribution, and digital rights management platform developed by Blizzard Entertainment.
https://en.wikipedia.org/wiki/Battle.net

We might need to adjust the name to avoid confusion.

Background

Technology Development Stages in Defense

The Department of Defense and many other agencies, industries, and nations use Technology Readiness Levels (TRLs) to aid in development and assessment of systems.

An adaptation of this model for decentralized protocols is an effective way to evaluate the resiliency of blockchain applications and identify gaps that may contribute to security failures throughout the ecosystem.

Technology Readiness Levels in the Department of Defense (DoD)

DoD (2010), Defense Acquisition Guidebook

Technology Readiness Level	Description
1. Basic principles observed and reported	Lowest level of technology readiness. Scientific research begins to be translated into applied research and development. Examples might include paper studies of a technology's basic properties.
2. Technology concept and/or application formulated.	Invention begins. Once basic principles are observed, practical applications can be invented. Applications are speculative and there may be no proof or detailed analysis to support the assumptions. Examples are limited to analytic studies.
3. Analytical and experimental critical function and/or characteristic proof of concept.	Active research and development is initiated. This includes analytical studies and laboratory studies to physically validate analytical predictions of separate elements of the technology. Examples include components that are not yet integrated or representative.
4. Component and/or breadboard validation in laboratory environment.	Basic technological components are integrated to establish that they will work together. This is relatively "low fidelity" compared to the eventual system. Examples include integration of "ad hoc" hardware in the laboratory.
5. Component and/or breadboard validation in relevant environment.	Fidelity of breadboard technology increases significantly. The basic technological components are integrated with reasonably realistic supporting elements so it can be tested in a simulated environment. Examples include "high fidelity" laboratory integration of components.
6. System/subsystem model or prototype demonstration in a relevant environment.	Representative model or prototype system, which is well beyond that of TRL 5, is tested in a relevant environment. Represents a major step up in a technology's demonstrated readiness. Examples include testing a prototype in a highfidelity laboratory environment or in simulated operational environment.
7. System prototype demonstration in an operational environment.	Prototype near, or at, planned operational system. Represents a major step up from TRL 6, requiring demonstration of an actual system prototype in an operational environment such as an aircraft, vehicle, or space. Examples include testing the prototype in a test bed aircraft.
8. Actual system completed and qualified through test and demonstration.	Technology has been proven to work in its final form and under expected conditions. In almost all cases, this TRL represents the end of true system development. Examples include developmental test and evaluation of the system in its intended weapon system to determine if it meets design specifications.
9. Actual system proven through successful mission operations.	Actual application of the technology in its final form and under mission conditions, such as those encountered in operational test and evaluation. Examples include using the system under operational mission conditions.

Cryptocurrency Technology Readiness Levels (CTRL)

While some parallels exist with existing TRLs and blockchain protocols, it is important to adapt them to the unique properties of decentralized applications, and the operational realities of development teams in web3.

Cryptocurrency Technology Readiness Level	Description	Example
1. Basic Principles are Reported	Exploration of core principles used in the technology.	An early description of a Constant Function Market Maker is published by economist Robin Hanson in 2002. The idea of an automated market maker floats around, entirely unrelated to crypto.
2. Theorized Applications of the Basic Principles	Applications of the basic principles are speculated but limited to theoretical applications.	In September 2016, Nick Johnson proposes the idea for "Euler" on reddit, a decentralized token exchange. One week later, Vitalik iterates on this in his Reddit thread, getting closer to the constant product AMM idea. 5 months later, Alan Lu is the first to conceive the x*y=K AMM for Ethereum.
3. Package and stack selection	Selection of packages to use in order to build the theorized application.	This example now get's handed over to Hayden Adams. This is the point at which he decides to make a react site (instead of any other framework), and write his contracts in Solidity (instead of Vyper). At this point he may be evaluating the various alternatives to the packages and frameworks he uses.
4. Local Proof of Concept on a Devnet	The selected packages are used to create a representation of the basic principle(s), with the goal of fulfilling the theorized application. This may look entirely different from the finished product.	This is the time where Hayden is composing the code contained in his "first commit". A complete implementation of a constant product AMM, kept local, probably has issues that Hayden is aware of.
5. Proof of Concept on Public Testnet	The local proof of concept is improved, unit and integration tested so that it can be deployed onto a testnet. This version may look much more like the final product.	This stage corresponds to the creation of Uniswap V0. This exact CTRL would correspond to the time at which Hayden was preparing the first demo release commit.
6. Prototype Demonstration on a Public Testnet	The proof of concept is circulated and improved upon. The goal is to gather insights on how to prepare the proof of concept for deployment into an high fidelity environment, like mainnet. This will represent a significant change from CTRL 5.	This is when Hayden toured the world, talking about Uniswap. A number of issues with the demo surfaced. It only worked for an ETH/ERC20 pair, only supported one LP, the frontend sucked, Vitalik recommended the contracts be written in Vyper, and the contracts needed to be audited. Most of these were fixed during this stage.
7. Protocol Demonstration in an Operational Environment	The technology is at or near production level as a result of the siginificant changes during the prior stage. Although this stage is about deployment into a production environment, this is done for testing purposes and should not encompass the production deployment of the protocol. This is where final changes are made to prepare the protocol for it's official deployment.	There is no documented test deployment of Uniswap. It is likely that the protocol was deployed onto mainnet though, but simply done privately.
8. Mainnet Launch	The protocol as being new and "untested", but still operational. The protocol is now (most likely) interacting with smart contracts that hold "real" value. At this stage, the protocol essentially needs to "build trust".	For Uniswap V1, this CTRL starts November 2nd 2018, and transitions to the next at a somewhat abstract point in time1 that is described by the following CTRL.
9. Long Term Resiliency	Every configuration2 of the protocol has held a significant amount of funds for extended periods of time without incident no matter the environmental conditions. It has never behaved unexpectedly, despite having incentives to do so, and "never" is both a large length of time and a countless number of operations.	Uniswap V1 in it's current state is something I would consider to be in this CTRL. Of course, you never complete being battle tested, but it has seen a wide range of market conditions and never seems to have substantially misbehaved.

1. I will leave this defining break point to be discussed and agreed upon. The correct solution will probably need to be a function of TVL, time, transaction count, transaction payload diversity, and diversity of economic conditions. Whatever this framework decides will probably have to be applied as a ratio of discrete configurations to date over total configurations possible (see below).
2. Please note the words every configuration. Every combination of possible changes permitted by the protocol's design should be considered a discrete protocol, where each must be battle tested for the overarching protocol to be considered battle tested. This may be controversial, but I believe you could say "the current state of xyz protocol is battle tested" but I don't think it is true that xyz is battle tested, because you haven't seen it in all of it's possible states.

Sources
https://blog.uniswap.org/uniswap-history
https://en.wikipedia.org/wiki/Constant_function_market_maker

Today's CTRL Problem

Simnet vs Devnet vs Testnet vs Mainnet: What Do They Mean for Web3 Developers?
Max Efremov, Hiro
https://www.hiro.so/blog/devnet-vs-testnet-vs-mainnet-what-do-they-mean-for-web3-developers

The problem is that the gaps between testnet and mainnet are too broad. There are few ways to simulate the economic forces that are omnipresent on a production blockchain. The network traffic experienced by the protocol is limited to test users and bots, there is no MEV, and ultimately there is little adversarial activity trying to break the protocol.

There are a number of actors who operate in the CTRLs 1 to 6 including economists, researchers, developpers, and auditors. But there are not many options to test a new protocol against realistic production conditions without putting protocol users at risk.

Battlenet

Battlenet is a proposed solution to bridging the gap between testnet and mainnet, and fits into the "Level 7" step in the Crypto Technology Readiness Levels (CTRL) described above.

Design Goals of Battlenet

1. Create a feedback loop between protocols, attackers, security professionals to rapidly improve crypto security
2. Incentivize protocols teams to deploy and operate experimental projects on the network
3. Incentivize attackers to exploit protocols in a controlled and legal manner.
4. Incentivize attackers to exploit now on Battlenet rather than later on mainnet.
5. Incentivize attackers to reveal the exploits so they can be handled before mainnet.
6. Incentivize real or simulated user behavior interacting with deployed protocols
7. Gather data and insights from network activities
8. Foster an adversarial and volatile environment
9. Ensure legal protection for the entire network under the Safe Harbour agreement
10. Reduce the pain; revealed exploits should 'cost' the ecosystem less than if they were executed on mainnet

The Proposed Solution

Some of the key challenges of deploying a new network and gaining adoption are to minimize the work needed to get realistic behavior on the chain, deploy standard protocols, and distribute test resources to users.

In order to shortcut many of these steps, each SEAL Battlenet exercise is proposed to start as an Ethereum hard fork that will diverge from the original Ethereum state for a set period of time.

Nonces & Chain IDs

With each new deployment of Battlenet it is important to modify the Chain ID to remove the possibility of transaction replays between Battlenet transactions and other networks.

Escrow

Rescued funds must be sent to this Asset Recovery Address if the attackers want to receive credit. The attacker must submit a report, and this must be validated as a legitimate attack. This serves the purpose of gathering data and insights from network activities and identifying legitimate attacks.

Stakeholders

Users

Network participants simulating regular blockchain traffic.

Goals for Battlenet

• Encourage a wide variety of transaction types and activity

Benefits

• More investigation needed. What might be an incentive model to encourage more utilization by users or simulated behavior than we normally see on testnets?

Attackers

These members perform attacks on protocols. They may be auditors, researchers, white hats, or maybe even black/grey hat hackers.

Goals for Battlenet

• Identify exploits and vulnerabilities in deployed protocols.
• Send rescued assets to the Asset Recovery Address.
• Submit exploit report.
• Incentive must be high enough to justify exploiting now on Battlenet rather than later on mainnet.

Benefits

• Prestige within the security community
• Legal protection
• Potential financial incentives based on the value of identified and reported exploits
• Potential support with existing bug bounty programs

Operators

This is the operator of Battlenet, so if not decentralized, this is SEAL.

Goals for Battlenet

• Collect high quality data on how attacks occur in a controlled yet realistic environment.
• Learn and establish best practices for incident response and training.
• Tweak parameters so that incentives are optimal across the board.
• Keep Battlenet running in a realistic manner.

Benefits

Fulfilling our goal to reach $1B Total Value Saved.

Deployers

Protocol developers and teams and DAOs testing proposals.

Goals for Battlenet

• Reveal exploits and problems at a lower cost
• Practice incident response
• Incentivize activity on their contracts
• Incur risk by putting capital at stake
• Allow hacks to occur with informed consent

Benefits

• Incident response and detection training.
• Realistic yet safer testing environment.

Service Providers

Auditors, Incident response teams, economic experts, legal experts.

Goals for Battlenet

• Provide feedback and insights to deployers for system improvements.
• Use insights to innovate new security solutions for deployers.

Benefits

• Contracts for services rendered to deployers.

Proposed SEAL Battlenet Event

For the first iteration of Battlenet, we propose to hold an event in November 2024 hosted by the Security Alliance (SEAL) & Tenderly.

Logistics

Date: Between Defi Security Summit (November 7-9) and Devcon (November 12-15)

Capacity: 100-150 (depending on venue capacity)

Venue: TBD

About The Event

SEAL Battlenet is a live adversarial environment where teams can deploy and test new protocol versions or governance proposals with realistic network behavior prior to deploying on public main networks. Battlenet allows for rapid iteration to improve web3 security by creating a feedback loop between protocols, attackers, and security professionals in a controlled environment.

In this event SEAL and Tenderly will pilot the first public Battlenet using Virtual Testnets to simulate security incidents based on existing mainnet smart contracts and upcoming protocol upgrades. Developers, whitehats, protocols, and other security professionals will be encouraged to participate in stress testing the resiliency of on chain applications.

Protocol Partners

SEAL is inviting protocol teams to participate in the event with scenarios and challenges related to their smart contracts and infrastructure. Battlenet is an ideal forum for testing out novel & unstable protocol ideas, or see how existing protocols and infrastructure operate under pressure. SEAL Wargames team members will help protocols design and test scenarios and challenges for the event.

Seal and Tenderly will sponsor some prizes for teams and protocols may also sponsor prizes related to scenarios related to their specific challenges.