Traditional DApp development tutorials, such as DApp University's guide, often recommend tools like Ganache - a tool now deprecated - or Hardhat, as highlighted in Chainlink's tutorial. A newer alternative, Foundry, has also emerged as a powerful and efficient toolkit. These tools enable developers to set up a local testnet to simulate and interact with the Ethereum Virtual Machine (EVM), streamlining the development process.

The typical workflow involves repeatedly deploying contracts to a local chain, interacting with them via an application UI, and iterating. For those following a test-driven development approach, writing and executing tests becomes an integral part of refining the contract until all tests pass.

These approaches are effective when the developed contracts operate in isolation. However, complications arise when external contracts are involved. Developers must not only deploy these external dependencies to their testnet but also populate their states, making the process significantly more complex and error-prone. Managing these externalities introduces overhead, often detracting from the core development process.

One common external dependency for applications is the Ethereum Name Service (ENS). Setting up all ENS contracts and replicating their state on a testnet is not only time-consuming but also tedious and prone to mistakes, especially when dealing with numerous contracts that need to work seamlessly in tandem with your own.

The solution to this challenge lies in the combination of the The Interceptor browser extension and the eth_simulateV1 JSON-RPC method.

The Interceptor (Install for Firefox or Chrome) is a powerful browser extension that leverages the eth_simulateV1 method to simulate transactions directly on the blockchain you're developing for. You can read more about the features of eth_simulateV1 from The JSON-RPC Method eth_simulateV1 is now available on multiple networks.

Whenever you attempt to send a transaction while using The Interceptor in simulation mode, the transaction is not sent to the network. Instead, it’s added to a simulation stack. The blockchain view provided to your application then reflects the current state of the chain, augmented with the simulated transactions on top.

This feature is very handy when building a new application. It allows you to send numerous transactions and observe how the UI responds to various scenarios - without altering the actual blockchain. Moreover, The Interceptor enables you to simulate transactions using any account, without requiring a private key. This means you can test your application with the real state of any account. Furthermore, The Interceptor can transfer large amounts of funds to your account, which you can use to directly test your application or purchase assets on decentralized exchanges, allowing you to explore and test diverse scenarios.

PetalLock is a DApp built using the simulation-driven development paradigm enabled by The Interceptor and eth_simulateV1. The application allows users to create almost immutable ENS domains and subdomains, almost ensuring their permanence and reliability (Unfortunately it's impossible to create truly immutable domains on ENS as ENS DAO and security council can always rug you).

During PetalLock's development, it was crucial to test its functionality on Ethereum Mainnet. This required verifying its behavior with existing ENS names, which can have highly diverse initial states. By leveraging The Interceptor, we could simulate transactions and interactions with live ENS data, streamlining the testing process and ensuring robust performance across real-world scenarios.

To start developing with The Interceptor, simply install the extension and connect it to your website, just as you would with any browser-based wallet. Let’s walk through the process using PetalLock as an example. Select 0x6D6054F7745a3Aaf4d1E4ac5830E4ABDc328Ab6B as your address in The Interceptor. This will allow you to make 3.horswap.eth almost immutable, as horswap.eth is owned by this address (darkflorist.eth).

Type 3.horswap.eth to the input field:

PetalLock allows you to deploy it's contracts directly from the UI if they are not deployed already (more about this later). The deployment happens simply by clicking the "Deploy PetalLock contract" button. This action triggers The Interceptor’s dialog:

Since PetalLock requires two contracts, you will see two dialogs to approve. After deploying the contracts, you can set the resolution address to any value, and the "Make Almost Immutable" button will activate:

After you press the button, The Interceptor displays the entire sequence of operations that PetalLock performs to make the domain almost immutable:

After approving this operation, PetalLock confirms that the domain is now almost immutable:

And all of this is done in a simulated environment, no actual transactions is being sent.

The beauty of this process lies in its simplicity and efficiency: no testnet setup, no external contract deployment, no manual chain configuration. Everything runs seamlessly on top of the latest Ethereum Mainnet state through The Interceptor's simulation stack. If your application requires interactions with other websites, you can also send transactions within those sites and then return to observe how they have influenced your application's view of the blockchain.

The Interceptor brings a whole new dimension to the popular meme: "test in prod"

PetalLock utilizes the CREATE2 deterministic deployment paradigm, which enables the application to predict contract addresses prior to deployment. This feature allows the UI to check at startup whether the necessary contracts already exist. If any contracts are missing, users are promptly notified and given the option to deploy them directly through the UI.

This design makes the deployment process simple and accessible, removing the need for technical expertise. It also ensures that deployed contracts align with expectations, enhancing both the reliability and security of the application. Whenever possible, we recommend building DApps with the capability to deploy contracts directly from the UI.

However, there are important considerations to keep in mind. Applications may depend on external systems (like PetalLock requires ENS), and attempting to deploy on networks that lack these dependencies could result in broken contracts. To address this, the deployment process could incorporate automated checks to ensure that required contracts or dependencies are available on the target chain before proceeding.

The eth_simulateV1 method can also be directly integrated into an application's testing framework. Instead of deploying contracts to a local testnet, tests can directly use eth_simulateV1 to set up the testing environment and execute the necessary checks. This approach significantly simplifies the testing process, particularly for applications that interact with live blockchain states. Additionally, testing across multiple EVM-compatible chains becomes effortless—simply point the RPC endpoint to the desired network to run your tests.

PetalLock’s tests are implemented using this method. You can explore the test implementation in PetalLock's GitHub repository.

A key strength of this approach is its ability to support both dynamic and historical state testing. By default, eth_simulateV1 operates on the latest block, ensuring that tests reflect the most current blockchain state. However, it also allows testing against a specific historical snapshot by querying an archive node and specifying a block number. This flexibility ensures that developers can validate their applications against both the evolving blockchain and stable, consistent snapshots from the past.

Despite its advantages, there are certain challenges to consider. Testing against historical states requires access to an archive node, which can be resource-intensive to operate and maintain. Meanwhile, tests using the latest block are subject to variability, as changes in the blockchain state over time may affect the outcomes.

As a future work, the eth_simulateV1-based testing methodology could be abstracted into a reusable testing library, streamlining its adoption in other applications.

Traditional DApp development tutorials, such as DApp University's guide, often recommend tools like Ganache - a tool now deprecated - or Hardhat, as highlighted in Chainlink's tutorial. A newer alternative, Foundry, has also emerged as a powerful and efficient toolkit. These tools enable developers to set up a local testnet to simulate and interact with the Ethereum Virtual Machine (EVM), streamlining the development process.

The typical workflow involves repeatedly deploying contracts to a local chain, interacting with them via an application UI, and iterating. For those following a test-driven development approach, writing and executing tests becomes an integral part of refining the contract until all tests pass.

These approaches are effective when the developed contracts operate in isolation. However, complications arise when external contracts are involved. Developers must not only deploy these external dependencies to their testnet but also populate their states, making the process significantly more complex and error-prone. Managing these externalities introduces overhead, often detracting from the core development process.

One common external dependency for applications is the Ethereum Name Service (ENS). Setting up all ENS contracts and replicating their state on a testnet is not only time-consuming but also tedious and prone to mistakes, especially when dealing with numerous contracts that need to work seamlessly in tandem with your own.

The solution to this challenge lies in the combination of the The Interceptor browser extension and the eth_simulateV1 JSON-RPC method.

The Interceptor (Install for Firefox or Chrome) is a powerful browser extension that leverages the eth_simulateV1 method to simulate transactions directly on the blockchain you're developing for. You can read more about the features of eth_simulateV1 from The JSON-RPC Method eth_simulateV1 is now available on multiple networks.

Whenever you attempt to send a transaction while using The Interceptor in simulation mode, the transaction is not sent to the network. Instead, it’s added to a simulation stack. The blockchain view provided to your application then reflects the current state of the chain, augmented with the simulated transactions on top.

This feature is very handy when building a new application. It allows you to send numerous transactions and observe how the UI responds to various scenarios - without altering the actual blockchain. Moreover, The Interceptor enables you to simulate transactions using any account, without requiring a private key. This means you can test your application with the real state of any account. Furthermore, The Interceptor can transfer large amounts of funds to your account, which you can use to directly test your application or purchase assets on decentralized exchanges, allowing you to explore and test diverse scenarios.

PetalLock is a DApp built using the simulation-driven development paradigm enabled by The Interceptor and eth_simulateV1. The application allows users to create almost immutable ENS domains and subdomains, almost ensuring their permanence and reliability (Unfortunately it's impossible to create truly immutable domains on ENS as ENS DAO and security council can always rug you).

During PetalLock's development, it was crucial to test its functionality on Ethereum Mainnet. This required verifying its behavior with existing ENS names, which can have highly diverse initial states. By leveraging The Interceptor, we could simulate transactions and interactions with live ENS data, streamlining the testing process and ensuring robust performance across real-world scenarios.

To start developing with The Interceptor, simply install the extension and connect it to your website, just as you would with any browser-based wallet. Let’s walk through the process using PetalLock as an example. Select 0x6D6054F7745a3Aaf4d1E4ac5830E4ABDc328Ab6B as your address in The Interceptor. This will allow you to make 3.horswap.eth almost immutable, as horswap.eth is owned by this address (darkflorist.eth).

Type 3.horswap.eth to the input field:

PetalLock allows you to deploy it's contracts directly from the UI if they are not deployed already (more about this later). The deployment happens simply by clicking the "Deploy PetalLock contract" button. This action triggers The Interceptor’s dialog:

Since PetalLock requires two contracts, you will see two dialogs to approve. After deploying the contracts, you can set the resolution address to any value, and the "Make Almost Immutable" button will activate:

After you press the button, The Interceptor displays the entire sequence of operations that PetalLock performs to make the domain almost immutable:

After approving this operation, PetalLock confirms that the domain is now almost immutable:

And all of this is done in a simulated environment, no actual transactions is being sent.

The beauty of this process lies in its simplicity and efficiency: no testnet setup, no external contract deployment, no manual chain configuration. Everything runs seamlessly on top of the latest Ethereum Mainnet state through The Interceptor's simulation stack. If your application requires interactions with other websites, you can also send transactions within those sites and then return to observe how they have influenced your application's view of the blockchain.

The Interceptor brings a whole new dimension to the popular meme: "test in prod"

PetalLock utilizes the CREATE2 deterministic deployment paradigm, which enables the application to predict contract addresses prior to deployment. This feature allows the UI to check at startup whether the necessary contracts already exist. If any contracts are missing, users are promptly notified and given the option to deploy them directly through the UI.

This design makes the deployment process simple and accessible, removing the need for technical expertise. It also ensures that deployed contracts align with expectations, enhancing both the reliability and security of the application. Whenever possible, we recommend building DApps with the capability to deploy contracts directly from the UI.

However, there are important considerations to keep in mind. Applications may depend on external systems (like PetalLock requires ENS), and attempting to deploy on networks that lack these dependencies could result in broken contracts. To address this, the deployment process could incorporate automated checks to ensure that required contracts or dependencies are available on the target chain before proceeding.

The eth_simulateV1 method can also be directly integrated into an application's testing framework. Instead of deploying contracts to a local testnet, tests can directly use eth_simulateV1 to set up the testing environment and execute the necessary checks. This approach significantly simplifies the testing process, particularly for applications that interact with live blockchain states. Additionally, testing across multiple EVM-compatible chains becomes effortless—simply point the RPC endpoint to the desired network to run your tests.

PetalLock’s tests are implemented using this method. You can explore the test implementation in PetalLock's GitHub repository.

A key strength of this approach is its ability to support both dynamic and historical state testing. By default, eth_simulateV1 operates on the latest block, ensuring that tests reflect the most current blockchain state. However, it also allows testing against a specific historical snapshot by querying an archive node and specifying a block number. This flexibility ensures that developers can validate their applications against both the evolving blockchain and stable, consistent snapshots from the past.

Despite its advantages, there are certain challenges to consider. Testing against historical states requires access to an archive node, which can be resource-intensive to operate and maintain. Meanwhile, tests using the latest block are subject to variability, as changes in the blockchain state over time may affect the outcomes.

As a future work, the eth_simulateV1-based testing methodology could be abstracted into a reusable testing library, streamlining its adoption in other applications.