Safety Transaction

Transaction Simulation

Image source

Transaction simulation, often referred to as "dry runs," is a method used to predict the outcome of a blockchain transaction before broadcasting it on-chain. This process is especially useful for smart contracts and decentralized applications (dApps) to ensure transactions perform as intended.

Transaction simulation plays a critical role in enhancing security and mitigating malicious activity in the Web3 ecosystem. By simulating a transaction, you can inspect it for unexpected or harmful behavior prior to execution. For instance, when interacting with a new dApp or calling a smart contract function, a simulation may reveal unauthorized token transfers or wallet access that were neither disclosed nor expected. This capability is invaluable for identifying and avoiding scams or malicious contracts designed to compromise user funds.

Designed Use Cases

1. Understanding Transaction Outcomes Blockchain transactions, particularly those involving complex smart contracts or DeFi protocols, often yield outcomes that aren't immediately apparent. Simulations clarify the consequences of executing a transaction, providing users with a detailed preview of what they are signing. For instance, in DAO voting or executing intricate financial strategies, transaction simulation can illuminate the implications of a decision, leading to safer and better-informed choices.

2. Gas Fee Estimation and Cost Savings Ethereum transactions incur gas fees, which can vary significantly based on network congestion and transaction complexity. Simulating transactions provides an accurate gas estimate, helping users avoid issues like overpaying or underpaying gas fees.

Overpaying unnecessarily increases transaction costs. Underpaying risks leaving transactions stuck in the mempool. By simulating a transaction beforehand, users can set appropriate gas limits and prices, minimizing costs and avoiding failures.

Transaction Simulation Spoofing

While transaction simulation is a powerful tool, it is inherently limited—it only predicts outcomes based on current blockchain states, without actual execution on-chain. This limitation can be exploited by attackers in what is known as transaction simulation spoofing.

In a typical spoofing scenario:

1. The attacker lures the victim to a malicious website disguised as a legitimate platform.

2. transaction simulates outputs, such as a "Claim" function, which deceptively shows that the user will receive a small amount of ETH.

3. Trusting the wallet's simulation result, the victim signs the transaction, unknowingly allowing the attacker to drain their wallet.

4. Between the simulation and actual execution, the attacker alters the on-chain contract state, causing the approved transaction to perform a different, malicious action.

Real-world Example

A victim signed a fraudulent transaction 30 seconds after an on-chain state change, resulting in the loss of 143.35 ETH.

Phishing transaction hash

This incident highlights the limitations of transaction simulations: on Ethereum and many other blockchains, simulation is not equivalent to "What You See Is What You Sign" (WYSIWYS).

Safety Switch in Endless Wallet

To address the limitations of transaction simulations, Endless Wallet introduces the Safe Transaction feature, equipped with a Safety Switch.

When enabled, the Safety Switch ensures that the simulation result (transaction output) is embedded within the transaction itself.

Here's how it works:

• The Safety Switch hashes the user's balance change(specifically refers to user's balance deduction) resulting from the transaction and embeds the hash into a transaction field.

• Nodes executing the transaction validate the user's actual balance change by recalculating the hash and comparing it to the embedded value.

• If the two hashes do not match, the transaction is reverted.

By default enabling the Safety Switch, users can make their transactions deterministic, effectively mitigating the risk of simulation spoofing.

Designing Dapp Considerations

Any decentralized application (Dapp) that may submit non-deterministic transactions, such as those involving dynamic deduction of the sender's account balance, should be carefully considered. Examples include:

• Liquidity pool swaps in Endless Swap, where the results depend on real-time asset ratios.

• Any contract interaction that leads to variable deductions from the sender's transaction balance.

It is crucial to address the potential impact of the "Safety Transaction" feature, which may block transaction submissions. Possible solutions include:

• Remind the end user to disable the "Safety Transaction" feature when submitting transactions via the wallet.

• Alternatively, modify the program logic to adopt a "deterministic transaction" design.