OP Anvil initial sync

[roninjin10]

UX - OP

• [ ] Implement toml config and validation
• [ ] Github action for mocktimism
• [ ] Publish on NPM
• [ ] CLI App
• [ ] Documentation

OP Anvil - OP

• [ ] Wire up networking options
• [ ] Wire up state dumps
• [ ] Add extra validation

Low level - Base

• [ ] Engine API in anvil
• [ ] OP Node integration
• [x] Deposit tx support in anvil
• [ ] connect real or mock op-proposer
• [ ] connect real or mock op-batcher

Periphial - Outside contributors (P2)

• [ ] OP Viem test actions
• [ ] op_foo rpc methods (P0 set base fee)
• [ ] anvil.js support

Integration - OP

• [ ] Integrate with OP indexer
• [ ] Integrate with op-viem for testing

Questions and goals:

1. What does base want to work on and bandwith? Does working on the lower level work make sense?
2. Coordination. Weekly meeting?
3. Go over the design doc questions

[roninjin10]

Engineering design doc

Note: each sub project deserves it's own mini design doc as they kick off. This design doc may be just a few sentences and a api of how it integrates into other stuff.

Problem Statement

Developers working with the OP Stack face several challenges:

1. Unexpected Gas Fee Nuances: L1 Gas fees on the OP Stack chain often catch developers off-guard.
2. Tooling Gaps: Tools like Anvil and Hardhat don't support Optimism native bridging, limiting functionality.
3. Complex Devnet Setup: Creating multiple devnets, especially for cases like Evo-online, is tedious.
4. Devnet Limitations: The Optimism devnet, reliant on Docker, lacks essential features like impersonation.

These issues hinder efficient local development and testing on the OP Stack. There's a clear need for a tool like Mocktimism, which would function as a Docker-compose equivalent for blockchain, allowing developers to easily configure multiple chains. This tool should provide a streamlined development experience, be compatible with existing tools, and adapt to the evolving OP Stack landscape.

Requirements

1. Versatility: Mocktimism should be capable of mimicking the Optimism devnet from the command line and handle cross-chain messages.
2. Gas Fee Simulation: The tool should accurately replicate the behavior of OP's L1 Gas fees.
3. Integration with Anvil: Mocktimism must be seamlessly integrated with Anvil, ensuring existing Anvil users can transition with minimal friction.
4. No Additional Dependencies: The solution should not rely on additional software, such as Docker or Node.js.
5. Local and E2E Development: Mocktimism should cater to both local development and end-to-end testing scenarios.
6. Adaptability: As the OP Stack becomes more modular, Mocktimism should be flexible enough to adapt to these changes, ensuring its continued relevance.

Non-Goals

1. Updating Hardhat: Given Hardhat's ongoing rewrite to incorporate opreth, direct updates or integrations with the current version of Hardhat are not a priority for Mocktimism.
2. Replacing Optimism Devnet: Mocktimism is a development tool and is not intended to replace the production-ready Optimism devnet.
3. Support for Every Possible OP Stack Configuration: While Mocktimism should be adaptable, it's not expected to cater to every possible OP Stack chain variant immediately upon release. There is a potential high value future project here.

System overview

Mocktimism is a wrapper around anvil that can be configured to run

• A single l2
• An l2 and an l1
• many l2s

This is distinct from anvil because anvil is simply the containers mocktimism is wrapping.

The services spun up (if spinning up an l1 and an l2) will match the current l2 infra in [our docker-compose](https://github.com/ethereum-optimism/optimism/blob/develop/ops-bedrock/docker-compose.yml) and some extras that enable the anvil devnet

• l1 - (replaced with anvil)
• l2 - (replaced with another instance of anvil)
• op-node - Either golang op-node or op-erigon
• Engine api - Currently a proxy but we want to get this into anvil natively via a —engine-api flag
• op-proposer
• op-batcher
• grafana - Spun up to give extra visibility into what the devnet is doing

Detailed Design

Mocktimism is broken up into many sub projects with an estimate of the time to implement. The individual designs are purposefully vague so to let the implementer treat each subtask as a subproject with it’s own short design.

1. Swarming - 1 week

Objective: Establish multiple network environments without relying on Docker.

This is the most risky part of the project and should happen earlier in case any blockers come up or the approach fails to work.

Design:

• Utilize the [swarm package](https://pkg.go.dev/github.com/docker/docker/api/types/swarm) from Docker's Go API.
• Implement network orchestration to spin up, manage, and tear down multiple network instances.
• Design a mechanism for inter-network communication, facilitating cross-chain interactions.

2. Configuration Loading & Validation - 2 days

Objective: Ensure configurations are correctly loaded and provide informative error messages during misconfigurations.

Design:

• Parse TOML configuration files using Go's encoding libraries.
• Implement layered validation:
  1. Schema validation - Ensure all mandatory fields are present.
  2. Logic validation - Ensure that given combinations of fields are coherent.
• In case of errors, throw descriptive exceptions indicating which configuration entry caused the error and why.

3. op-reth+anvil Compatibility - (external work)

Objective: Update op-reth for compatibility with op-node.

Design:

• Collaborate with Michael and anika from Base, leveraging preliminary work done.
• Ensure compatibility with the op-node's interfaces and message formats.
• Perform rigorous testing to ensure smooth operations between op-reth and op-node.

4. Engine API Integration - (external work)

Objective: Integrate the working engine API proxy into Anvil.

This is blocked by chatting with anvil team who is currently on vacation. The dev will be back next week. Goal is for us to externalize this work

Design:

• Merge the GoLang engine API proxy with Anvil.
• Add a command-line flag -engine-api to Anvil to enable/disable this feature.
• Ensure the integration does not disrupt other Anvil functionalities.

5. Service Integration in op-anvil (3 weeks)

Objective: Integrate the production services into op-anvil.

The other riskiest part of mocktimism so will happen early

Start via just integrating the existing services. Profile and replace with lighter weight versions if necessary (most likely not necessary).

Lighter weight versions can take advantage of the fact we can listen to every state update to the chains trivially.

Design:

• For each service (l1, l2, op-node, etc.), incorporate the actual production service code into op-anvil where feasible.
• Use the TOML configurations as the sole user-exposed customization interface.
• Ensure that services are sandboxed and interact seamlessly.

6. CLI Application (3 days)

Objective: Offer a user-friendly command-line application for Mocktimism.

Design:

• Design intuitive command structures with meaningful names.
• Provide detailed help texts for each command and flag.
• Implement error handling that guides users on correct usage.

7. GitHub Action for Mocktimism (.5 days)

Objective: Facilitate CI/CD operations using Mocktimism.

Design:

• Create a GitHub Action that triggers Mocktimism setups based on repository events.
• Ensure the action is configurable via .yml files.
• Provide detailed logs and outputs to facilitate debugging.

8. Distribute Binary on NPM (.5 days)

Objective: Allow easy installation of Mocktimism via NPM.

Design:

• Create an NPM package that contains the Mocktimism binary.
• Implement post-install scripts that set up Mocktimism for immediate use.

9. TypeScript (TS) Entrypoint (1 day + external work)

Objective: Provide a TypeScript interface similar to anvil-js for integration into projects.

Design:

• Create a TypeScript wrapper that communicates with Mocktimism.
• Consult with the anvil-js maintainer to ensure coherence and synergy.

10. op-viem Test Actions (.5 days)

Objective: Implement basic test actions for op-viem.

Design:

• Design actions that allow operations like setting base fees.
• Ensure that these actions are easily callable and provide meaningful feedback.

11. Implement mocktimism_foo (external work)

Objective: Implement features such as setting the base fee.

Design:

• Create a command or API within Mocktimism named mocktimism_foo.
• Initially, allow operations like setting base fee information.

12. Documentation (1 week)

Objective: Provide clear and concise documentation in Markdown. This documentation also includes the secondary scope of clearly defining any APIs that are needed to be defined to allow base to collaborate.

Design:

• Document each module and its functionality.
• Include example use cases and configurations.
• Ensure that error-handling mechanisms are well-documented to guide users.]

14. Integration with op-anvil & Indexer (1 week)

Objective: Ensure Mocktimism operates seamlessly with op-anvil and the indexer as first use cases

Design:

• Develop integration tests that simulate real-world interactions between Mocktimism, op-anvil, and the indexer.
• Address and rectify any identified discrepancies or issues.

---

15. Logging and visibility work (5 days)

Objective: Ensure error handling, logging, and visibility into what mocktimism is doing is polished

For any dev tool to be good extra time must be given to making sure error handling and logging are solid

Design:

• This polish work is just trying to break mocktimism and making sure error messages are good
• May include adding a UI such as grafana dashboards if appropriate
• Non blocking to the rest of the work and not risky should happen last

Estimate 10 weeks

Note: this estimate assumes external work from base engineers working part time will knock out the marked external sections.

Project Sequencing and Collaboration

Project Approach:

To achieve the desired outcome of Mocktimism, the following strategic collaboration and sequencing plan is recommended:

1. Collaborative Effort with Base:

Base will provide crucial engineering assistance for specific sections of the project. Their expertise, particularly in low-level tasks, is expected to accelerate progress in areas such as Anvil modifications, engine API adjustments, and Rust-based developments.

2. Repository Management:

Mocktimism's development will commence in a separate repository distinct from the primary monorepo. This choice is influenced by the following factors:

• Ease of Collaboration: External repositories tend to simplify the contribution process, particularly for external collaborators.
• Focused Development: A standalone repo ensures that Mocktimism-related developments are distinct, making it easier to manage and review code changes.
• Upstreaming: Once Mocktimism reaches a mature stage of development, it will be upstreamed into the primary monorepo, integrating it with the broader ecosystem.

3. Issue Tracking:

To maintain transparency and foster community engagement, issue tracking will be managed publicly within the Mocktimism repository. This approach will ensure that both internal teams and external contributors are aligned on project developments.

4. Task Ownership:

• Base: The team will primarily oversee the project's low-level tasks. This includes modifications to Anvil, adjustments to the engine API, and other Rust-based work. Given their expertise, Base is also likely to manage developments related to op-node and areas closely related to Anvil.
• Will: Task ownership will gravitate towards components closer to the end user, such as the CLI app. Additionally, Will will tackle the substantial challenge of configuring swarming and setting up OP services not managed by Base.
• Other: Task ownership of dependent and small tasks are reserved for outside contributors. This includes very small S tasks like updating op-viem to have a test action. These tasks should never be critical.

5. Inter-team Coordination:

Whenever tasks are externalized (i.e., handed off from one team to another), a detailed specification outlining the interoperability of services across team boundaries will be mandatory. This approach ensures clear communication and minimizes potential misalignments.

6. Regular Updates:

Weekly op-anvil meetings will be conducted to assess progress, discuss challenges, and align on next steps. Furthermore, Will will provide internal updates every Friday, ensuring that stakeholders are kept informed on the project's status.

Milestones with Approximate Dates:

Note these are subject to change pending syncing with Base on October 13th.

Internal Milestones:

1. Milestone 1 - Swarming Implemented:
   • Description: Establish multiple network environments without relying on Docker. The most risky part of the project and should happen earlier in case any blockers come up or the approach fails to work.
   • Start: October 14th
   • End: October 21st
2. Milestone 2 - Configuration Loading:
   • Description: Ensure configurations are correctly loaded and provide informative error messages during misconfigurations.
   • Start: October 22nd
   • End: October 24th
3. Milestone 3 - Op-anvil Spinning Up:
   • Description: Integrate the production services into op-anvil. This involves replacing l1 and l2 with anvil instances and ensuring smooth orchestration of services.
   • Start: October 25th
   • End: November 17th
4. Milestone 4 - CLI App Completion:
   • Description: Offer a user-friendly command-line application for Mocktimism with intuitive commands and detailed help texts.
   • Start: November 18th
   • End: November 21st
5. Milestone 5 - op-viem/indexer Integration:
   • Description: Ensure Mocktimism operations and functionalities are smoothly incorporated into op-viem or the indexer.
   • Start: November 22nd
   • End: November 29th
6. Milestone 6 - Polish and Documentation:
   • Description: Finalize error handling, logging, and documentation. Ensure comprehensive documentation in Markdown format and polish Mocktimism for optimal user experience.
   • Start: November 30th
   • End: December 7th

External Milestones (for Base contributors):

1. Milestone A - Anvil Modifications:
   • Description: Modify Anvil to support the functionalities required by Mocktimism, ensuring that the adjustments are coherent with the overall system design.
   • Start: October 14th
   • End: October 28th
2. Milestone B - Engine API Adjustments:
   • Description: Integrate the working engine API proxy into Anvil, and ensure seamless communication between Anvil and the Engine API.
   • Start: October 29th
   • End: November 12th
3. Milestone C - op-node Compatibility:
   • Description: Update op-reth for compatibility with op-node. This involves adapting to op-node's interfaces and message formats.
   • Start: November 13th
   • End: December 2nd
4. Milestone D - Final Testing & Verification:
   • Description: Ensure that all modifications and functionalities work as expected and that there are no breaking changes or inconsistencies.
   • Start: December 3rd
   • End: December 7th

[roninjin10]

Mocktimism PRD

*This project has been referenced by other names in the past including OP-Anvil. Mocktimism is an internal name and the product+devrel teams should decide what the appropiate GTM name(s) is(are) after alpha.

*This is NOT an engineering design doc and even though it will contain some code and API/Usage examples it will not go into any implementation details. The engineering design doc will be linked below when it exists.

Links

• put
• some
• important
• links
• here

What is Mocktimism?

TODO make a diagram (omit implementation details for engineering design doc)

Mocktimism is a batteries included OP stack development tool analogous to hardhat and anvil that can be used by OP Stack developers in local and e2e developments.

Local development and test harnesses are vital to all forms of software development. It is a part of the larger "just works" initiative to make existing ethereum tooling work with Optimism.

Developing on the OP Stack has the following challenges:

• L1 Gas fee is a suprising nuance of an OP stack chain that developers are often suprised by
• Anvil and hardhat don't support Optimism native bridging
• For future use cases such as Evo-online the spinning up many devnets for a single app is very tedious
• The optimism devnet is extremely heavy, depends on docker, and doesn't support hardhat/anvil features such as impersonation

A good analogy for what Mocktimism is doing is docker-compose for hardhat/anvil. Docker is how one configures a single container. Docker-compose is how one configures multiple containers. Similarly anvil/hardhat are how devs configure a single chain. Mocktimism is how op-chain developers configure multiple chains.

Product requirements

TODO is it clear why these product requirements were chosen

Product Requirements P0

• Spins up an mockable optimism devnet from the command line with a very familiar api to anvil/hardhat
• Should be able to process cross chain messages for native l1<>l2 and l2<>l1 bridging
• L1 Gas fee should work just like OP
  • Things like the L1 Base Fee should be configurable
• Upstreamable to anvil/hardhat
• Able to do basic anvil/hardhat features such as:
  • Fork a live network
  • Impersonate accounts
  • Run in different mining modes (e.g. run on the bedrock 2 second block times or run in automine mode)
• Has anvil_foo rpcs to control rollup specific things such as posting a state batch (both manually and automatically)
• Does NOT depend on any additional dependencies than the existing tech stack. e.g. no dependencies on docker or node.js
• Should "just work" with hardhat and anvil as compatibility is added. Should just work with 1 or both upon beta release.
  • If anvil doesn't work upon beta release a forked version of anvil with op-reth upstreamed into it should work (see blockers section)
  • Alternatively pending engineering design a proxy in front of these tools should allow it to work

There are also P0 requirements peripheral to the core product

• should have a mocktimism feedback command that allows any user to easily submit feedback about mocktimism including positive feedback
• should have usage documentation
• should have --help cli documentation
• should be distributed as widely as practical e.g. github actions, npm, golang package, downloadable binary etc.

Product requirements P1

P1 requirements could get prioritized or cut based on engineering timeline estimates or determined to be worth outsourcing to outside contributors

• Github action should be able to easily set up mocktimism
• Should be able to configure op-anvil with a toml file to make configuration of many op chains less tedius
• Should have basic presets for chains listed in the superchain registry for further ease of use (similar to op-viem and optimism indexer)
• Should be integrated into the Optimism starterkit
• Kick off partnerships conversations with both hardhat and anvil to get this tooling to Just work in the core tools
• Should be able to modify some rollup config options such as challenge window etc.

Product requirements P2

There are many other product requirements that can be a stretch goal or great additions for outside contributors would be great to add or could be prioritized in a future project should we find them to be a priority.

These requirements though P2 are expected to be targed for in the making of the engineering doc. Anything out of scope will be listed in the out of scope section

• Should have a cli tool for interacting with mocktimism
  • You could call this OP cast
• Should have a javascript API for interacting with Mocktimism
  • This is within scope for op-viem
• Support for op-chains not following the law of chains
• Support for easily spinning up isolated mocktimism environments in TypeScript tests
  • the anvil equivelent to this is viem/anvil
• First-class support in testing frameworks such as synpress

Out of scope

Support OP stack protocol developers

Mocktimism does not address the needs of OP Stack component builders such as OP arrogon building a component in the OP stack. The best tool for this job is the existing heavy docker based devnet that can be ran in the monorepo via running make devnet up

Note: this route was strongly considered and worth future exploration.

A better improved optimism devnet can potentially both improve the velocity/quality of core OP stack developers including OP Labs and can consolidate our stack via replacing simple optimism node. This work would also generally show off the modularity of the OP stack.

There is a LOT of overlap between a dockerized modular OP stack devnet and mocktimism. Just like RETH and anvil are two different tools for two different use cases so should be the optimism devnet and mocktimism/op-anvil-hardhat

Simple optimism node

Mocktimism is not meant to be used in production environments and thus is not a suitable replacement for simple optimism node

OP-Cast and OP-Forge

Natural follow ups to the optimism version of anvil/hardhat are to add the analogous tooling that compounds even more value onto anvil/hardhat today. While this functionality will exist in Mocktimism it won't be productionized into it's own product as it likely should eventually. The reasons are following:

• Reduces the cognitive load of go-to-market via having 1 simple easy to understand tool rather than multiple
• Cuts scope
• Doesn't require multiple implementations e.g. writing a just works version in rust for cast and then another just works version in JS for hardhat.
  • OP-Forge should still have a rough spec because it will help with the partnerships efforts to get this tool to just work in the foundry toolchain

Fully delivering on partnership efforts

Though we plan on kicking off partnership efforts this work is not required nor expected to be delivered within the scope of this project for following reasons

• Just like op-viem, we want the tool to exist as a one-off in beta for enough time to get user feedback before the GA Just works version is upstreamed
• We cannot be confident about these partners being able to match our timelines of 1 quarter fot this project
• It's generally easier to do this work after mocktimism beta has been successful

Support for non native bridging

e.g. layer zero bridging or connext bridging

Note that should we implement l2 to l2 bridging interface that is used by tools such as connext in the future, mocktimism should also support this functionality via a mocktimism bridge that does l2 to l2 in a lightweight way with an easy way to mock any bridge that plugs into the interface

Product success criteria

What we can measure will be easier to nail down after the engineering doc is done. But broadly we want to measure

• Total external usage
  • Downloads/uses (e.g. if this ended up on npm via an npx command we can measure npm downloads)
  • Usage of external tools such as custom github actions
  • Results in github searches
  • Metrics collected from running mocktimism feedback
• Internal usage success
  • Ask devs internal to optimism if they use mocktimism and their satisfaction
  • Take note of any potential quality wins like being able to test mainnet without spending real eth or faster running tests
• Github insights
  • Can we measure how many people looked at the package on github?
  • Can we measure how many people read the docs?
• Hackathon
  • Does the devrel team report success in their chats with developers and hackathon participants?
• Major partners
  • Do any P0 major a partners report success using the product?
• Outside contributors
  • Is the product important enough to users for them to take the time to report issues and/or contribute features/bug fixes?
• Compounding success?
  • Does the product help with the quality/velocity and development of other devx tools such as op-viem or the indexer?

Successful product should see these numbers trending upwords overtime as more and more folks onboard onto using the product and continue to use it

Why are we building it?

Mocktimism was identified as

• A core building block for the rest of our dev tooling stack including the indexer, op-viem, op-ethers, superchain bridging, and the open source bridge UI
• Mocktimism is a major developer productivity boost internally
• Mocktimism was identified as a solution to user problems at beginning of the doc and also explained later in the User Stories section of this doc

User personas and OKRs

TODO annie to add how this fits into any user personas okrs etc. that product team might require

Relation to other OP stack tooling

To understand how mocktimism fits in with other op tooling we simply need to look at how anvil/hardhat fit into existing tooling.

op-viem

Viem has the concept of test clients. Test clients are very basic wrappers around anvil and hardhat to do things like

• impersonate other accounts
• mint eth
• etc.

Collaboration with Base should happen to include any op-viem specific actions that don't already exist in viem proper to later be upstreamed as a op-viem testing decorator. This has already been discussed with Wilson from base and he is bought in to this idea.

User stories

Hackathon participants

For hackathon participants they need not be blocked by permision issues such as:

• not having sepolia eth
• not having permission to mint a specific token
• not being able to bridge to optimism
• Having to wait long periods of time for things like withdrawal periods or any other time bottlenecked actions
• A contract or protocol they need that exists on mainnet not existing on goerli

Because Mocktimism provides a fully hackable environment where the user can arbitrarily do whatever they want including sending themselves eth or impersonating any account none of these things are issues for hackathon particippants.

1. User runs mocktimism
2. User gets a local fork of Ethereum mainnet and an arbitrary number of OP chains
3. User impersonates any account such as vitalik.eth to unblock themselves

To run mocktimism just use the command line. This will look very familiar if you have used anvil in the past.

# To fork a chain registered in the superchain registry simply provide a preset
mocktimism --preset=10 --fork-urls https://example.infura.alchemy.eth-mainnet,https://mainnet.optimism.io

You can now do anything you want on your devnet. Impersonate accounts, deposit from l1 etc.

opViemTestClientL1.impersonateAccount('vitalik.eth')
opViemWalletClientL1.depositETH({
  value: BigInt(420),
  from: 'vitalik.eth',
  to: 'hackathon-user.eth'
})
opViemTestClientL1.mintEth({amount: BigInt(420)})
opViemTestClientL2.impersonateAccount('haydenadams.eth')
opViemWalletClientL2.sendTransaction({
    abi: uniswapErc20Abi,
    address: uniswapERc20Address,
    functionName: 'transfer',
    args: {
      to: 'hackathon-user.eth',
      from: 'haydenadams.eth',
      amount: 420
    }
})

OP Stack developer wants to build cross-chain onboarding experience

For better ux many apps such as friend.tech will start offering an onboard-from-l1 experience. In future when superchain bridging is solved they will want to offer an onboard-from-op-chain experience. Doing this breaks the dev experience of single chain apps but not so with Mocktimism.

1. User drops in mocktimism as a near 1 to 1 replacement for anvil
2. Their testing and local dev environment "just work" as intended

First op stack developer writes the code to do this cross-chain onboarding experience.

let mintNft

const onboardFromL1 = hasEthOnL1 && !hasEthOnL2
if (onboardFromL1) {
  mintNft = () => opViemWalletClientL1.writeContract({
      ...zoraConfig,
      address: zoraNft,
      abi: zoraAbi,
      functionName: 'mint',
    })
} else {
  mintNft = () => opViemWalletClientL2.writeContract({
      address: zoraNft,
      abi: zoraAbi,
      functionName: 'mint',
    })
  }

return (
  <button
    onclick={mintNft}
  > 
    Mint NFT on zora
  </button>
)

Configuring a devnet via command line is convenient but this dev likely wants to use a config file so they can consistently spin up the expected environment

[mocktimism]
preset=zora
forkUrls=["https://mainnet.example.infura.alchemy", "https://zora.example.infura.alchemy"]
forkBlockNumber=90053
automine=true

They can now trivially run this in locally

mocktimism --config ./op.toml

They can also run this in github CI. Note that the more this gets embedded into hardhat and/or anvil in future the more this usage goes from feeling like these tools to literally using their tools

# setup mocktimism. 
uses: https://github.com/ethereum-optimism/action-mocktimism

...

# Now just run tests as normally
runs: mocktimism --config ./op.toml & pnpm run test
...

OP Stack developer wants to surface gas fees including L1 Gas fees to user

In the fee-estimation project we created tooling for implementing this features and it is currently rolling out to existing tooling such as web3.js ethers.js and viem. We did not however complete the developer story of being able to test these features. In fact, even our @eth-optimism/fee-estimation package does not have the quality of testing one would want for this feature.

TODO link the github issue of user being unable to test this

1. User integrates OP fee estimation into their application
2. User finds very clear and easy documentation on how to implement and test fee estimation with their chosen tech stack
3. Mocktimism "just works" for being able to test fee estimation

Usage is same as the above story

OP Stack operator wants mocktimism to work with their custom chain

For anticipated use cases the engineering design should be modular enough to support them swapping in a new mocktimism module that follows the correct interface (just like the OP stack)

1. Read the Mocktimism developer documentation and implementation
2. Plugin their necessary changes to Mocktimism
3. Offer their modified Mocktimism to their developers

Hard to know what this looks like before engineering design is complete

Sophisticated OP stack users or developers want to debug the OP stack or try out something on the OP stack without paying gas

OP Stack developer

Why does this matter to Optimism?

TODO this was in the template but I think we can just nuke this section

Our Devx thesis is a major component of creating the best in class developer experience is to make the existing tools that most improve developer experience "just work". Devnets such as Hardhat and Anvil are one of the most important pieces to this puzzle. Mocktimism delivers value to Optimism internally, externally, and compounds via adding value to our other devx efforts such as superchain bridging and op-viem. It is a major foundation to everything we build.

Internal usage

Mocktimism is not only an external need but also an internal need. Examples of internal usage include the following:

Ecopod

The ecopod test setup and development envioronment is split into three use cases which decrease with 1 being the best developer experience and 3 being the worst but necessary.

1. Anvil testing and development - This is the preferred environment because of all the development features anvil offers
2. 2 anvils - This is a little more tedius to set up but works well if no cross chain messages are needed.
3. Goerli testing and optimism devnet testing - This is not preferred as it does not come with all the features of anvil but is required in certain use cases

Mocktimism unifies all three use cases into one with the best features of each.

OP Devnet

In the monorepo the OP Devnet is the most common way to run testing but is quite heavy and slow. In certain situations Mocktimism is more practical and we should be able to easily plug in OP anvil or the devnet trivially. Examples include Indexer testing or Optimism ethers-v5 SDK testing and local development.

Comparisons to other multichain ecosystems

Support for multichain is pretty new. Foundry only recently added support for testing multichain in foundry testing. Arbitrum and polygon do not have an equivelent product. In short term until these other ecosystems catch up this will be a differentiator.

Known issues and blockers?

Anvil does not support OP chains at this moment and thus would not be able to support Mocktimism. This will be unblocked once OP-RETH gets upstreamed into anvil. OP Anvil should be built to plug into anvil in future while providing a reasonable alternative in the meantime

Development timeline

TODO this is out of scope for this doc and should be in eng doc and scoped correctly but will keep it here for now and copy it over later since it is useful

Very rough engineering timeline. This will be explored in more detail in the engineering doc

1. September - Product documentation
2. October (week 1) - Engineering design doc
3. October (weeks 2-4) - OP-Anvil Alpha
4. November (week 1-3) - alpha testing polish and partnerships after creating a demo of alpha 4a. Kick off alpha testing internally at OP via integrating with optimism monorepo CI and local dev environment. Enable ecopod onboarding via a short demo 4b. Kick off conversations with hardhat and anvil to see how receptive they are to integrating into their tooling 4c. Fix bugs and feedback
5. November/December (week 4-2) - Implement features missing for Beta release 4a. This includes things like a github action, very simple cli tooling to do basic things like deposit and withdraw (similar to op-viem. Can be thought of as op-cast) 4b. As a stretch goal do a proof of concept of forge cheat codes for contract testing
6. Prepare comms blast and documentation 4a. Final reviews and prepare marketing materials + developer documentation 4b. Code freeze for end of december 4c. Soft release in december 4d. Comms blast and larger release in January after holidays 4e. Create issues for P2 work that outside contributors can take up

Launch timeline

Mocktimism is such a vital piece that it should follow the entire alpha-beta-GA release schedule. This doc is focused on Mocktimism Beta but we will touch on Mocktimism GA

Mocktimism Alpha release (mid q4)

Mocktimism alpha releases should happen before it's feature complete as soon as it's usable by internal teams

• Devx team (indexer and possibly bridge project)
• OP-Viem
• Optimism Ecopod team
• Monorepo CI/CD processes such as the optimism ethersv5 sdk

All three of these use cases have such a high need for a tool like Mocktimism that it should be a clear priority for all three if successful. This should require minimal resources to integrate into either local dev flows and/or test flows to be considered successful as Mocktimism is meant to be as easy as spinning up anvil.

Mocktimism Beta release (soft release end of q4)

Mocktimism should GA in beta so we have the ability to make breaking changes to the API should user feedback require it. Mocktimism is a long term tool and we don't want to start it's stable release on the wrong foot.

Mocktimism GA release (early q2)

Mocktimism beta should have all of Q1 to gather feedback before planning a GA release. GA release should involve working with partners such as Anvil and hardhat to as much as possible embed mocktimism directly into their tooling in the spirit of making existing tools "just work"

Mocktimism

Future plans

Because Mocktimism is such a foundational piece to the OP stack we should be very aware of future work that needs to be prioritized as the OP stack evolves

• Since it serves a vital role in the stack we should expect to be making updates to it every quarter based on user feedback.
• Mocktimism's importance will increase as the superchains importance increases from Apps becoming more and more multichain

We should chat with Hardhat and Foundry after initial Mocktimism release to see if they are receptive to further embedding mocktimism into their tooling.

More modular OP Stack chains

Mocktimism is focused on solving the developer experience of the next 12 months. As OP stack chains become more and more modular and customized it may start to degrade in it's usefulness for chains that are more and more unlike the OP stack. For example, if an OP chain swaps out the EVM for a different execution environment, Mocktimism may not work for this use case. We should monitor this situation and prioritize modularizing Mocktimism along with the OP stack as the need arises such that different mocktimism modules can be swapped in for these use cases. We should do so in the way that creates the least amount of overhead which often will mean running the actual op stack module as is. For our plan to capture the market in 12 months we should not prioritize this just yet however and instead focus in on specifically superchain chains following the law of chains.

Marketing plan

Why this is useful can sometimes not be immediately obvious to developers until after than run into an issue. Marketing should highlight "why" this tool exists and why OP stack developers should use it. Recomendations for marketing include the following

• Video overview using mocktimism in local environment and test environment
• Dev blog
• Tweet thread

Outside team dependencies

• While the devx team owns writing the initial documentation their ultimate owner is the devrel team
• Ecopod is needed as one of the best dogfooders of the product
• Marketing resources are needed for the rollout

[roninjin10]

Moving this issue to seperate issues