Arbiter: A Year in Review
A Year in Review
Recently, Arbiter received Retroactive Public Goods Funding (Retro PGF) in the developer ecosystem. The reception of Retro PGF has inspired the Primitive team to think about how better to serve the Optimism and Ethereum ecosystem with Arbiter. What is Arbiters' end game? How can we better serve the community, provide value, and what does that mean for the future of Arbiter?
It has been over one year since Colin, and I started hacking away at what is now Arbiter. It began at Ethereum San Francisco at one of Jessy's Infamous hacker houses. The LVR paper had recently come out, and Colin and I wanted to meaningfully measure the behavior of different economic actors engaging with the EVM. We tried to measure LP profitability and noticed some arbitrage opportunities on a liquid staking derivative pool at the time. We wanted to poke around with the Rust Ethereum API. We tried to do onchain compute offchain to compute exact arbitrage amounts for constant function market makers. Ts0yu recommended the holy revm repository, and we started hacking away.
Since then, Arbiter has had many iterations. Three months after the hacker house, it evolved to emulate different smart contract interactions with very basic ABI driven APIs and some odd hand-built contract management mechanisms. We provided the same interface over revm that you use to interact with a live network with the ethers middleware with the Rust Ethereum ecosystem three months later and shipped our first versions to crates.io. In the second half of last year, we shipped an example of an Agent Traits and some example agents to make agent design more intuitive for new users. More recently we shipped a forking feature and custom event collectors. The forking feature allows users to specify state that they want to fork from the Ethereum State Trie. Last month, we shipped a Co-processor that allows agents to have a scratch pad revm instance to do the computation in. More recently, Clabby shipped a feature that enables users to load the EVM state from an [anvil state dump] so that you can use forge deploy scripts to initialize your state instead of deploying contracts in Rust, which is less common.
Very recently we added support for the new revm release, added a inspectors to support console logs and greatly simplified the interface for users and contributors. All this and more is part of our new release.
The past year represents building the right abstraction for the arbiter-core components that provide an interface to an in-memory revm instance. This next year, we will focus on building a toolbox around this interface. This path forward will make it easier for users to develop their agents and use the ones we have created.
On the horizon
We have been experimenting with the right abstractions over agent behaviors for some time. We initially designed an unofficial agent trait. However, more recently, we have shipped a more robust abstraction over agent design and behavior that we are excited to share with you. These improvements have been delivered in the new arbiter-engine crate, which will focus on the agent layer abstractions. These new patterns drastically simplify the Arbiter's user experience, reducing complexity for auditors or developers. Some of the design decisions in the arbiter-engine crate that I am excited about are:
Agent-based, event-driven design: We have invested a lot of energy to reduce the complexity of the interface for users. New designs allow users to not worry about designing a simulation but instead a collection of behaviors. To model a system, you only need to think about behavior design. This design path abstracts user complexity and makes for a flexible modeling tool.
EOA authorized automation: with the design of behaviors, it's possible to approve automated agent behaviors to operate on mainnet. For example, this can enable a stop-loss order or other automated trading strategies. Say you want to remove your liquidity when a swap event happens from a particular EOA; you can achieve this with behavior abstractions. This abstraction delivers new flexibility to externally owned accounts on the Ethereum network. We will continue to develop and explore these applications moving forward, they are currently incomplete and experimental.
Arbiter's end game results in a new standard of security practices across the industry that support quantitative risk analysis and game theoretic audits with a systematic agent-based fuzzing approach. We see Arbiter as a robust analysis tool unparalleled in its collective abilities. Arbiter's ability to provide insight into the economic game theory and technical vulnerabilities makes it extremely valuable in measuring and evaluating financial and security risk. The risks of using blockchains are exsitential, so improving the ecosystem's safety and interface is a priority. We foresee a not-so-small opportunity for auditors to offer specialized services with Arbiter that provide unique value to their clients. There is yet to be a standard toolset for auditing the game theoretic assumptions a protocol relies on. Furthermore Arbiter provides a valuable financial analysis toolbox!
Arbiter is in a unique place with an open-source public license. While Primitive has been the primary user of Arbiter, we have come to understand that we need to provide some examples of what an "Arbiter Security Engagement" might look like. As a result, we will be conducting an internal audit of some of our latest smart contracts over the next few months. This audit will serve as an example of the unique insights and value that the tool can provide. If you want to use Arbiter for your security needs, don't hesitate to contact us at [email protected].