Wallet Integration

[thedevbirb]

Context

The first release of Bolt will introduce inclusion preconfirmation on Ethereum mainnet, which can bring a significant UX benefit to every user who is doing a transaction on non-contentious state.

Definition (non-contentious transaction): Let $$S$$ be the current valid Ethereum state, and $$t$$ be a valid transaction from account $$A$$. Let $$T$$ be a set of valid transactions and $$S'$$ the new state after having applied the state transition function $$Y(S,T)$$.
$$t$$ is said to be non-contentious if for every set $$T$$ where $$t\in T$$ in the new state $$S'$$, $$t$$ hasn't reverted unless due to other transactions made by $$A$$ and executed before $$t$$.

In simpler terms, the account $$A$$ is the only entity responsible for making its transaction $$t$$ revert.

Two examples of such transactions are ETH and ERC20 transfers: if protocol rules are satisfied and the user has enough funds they cannot fail¹. It makes sense then to give users a quicker feedback of successful execution, instead of let them waiting an average of ~6 seconds, resembling the UX of existing L2s. Bolt is crucial here to ensure such transactions will be actually included on-chain within a known amount of L1 slots with economic credibility.

Following this reasoning, if a user does mostly non-contentious transactions then it can experience Ethereum mainnet as it if was a rollup in terms of UX.

Why wallet integration is important?

In short, because most users transact using a browser or mobile wallet extension. If such wallets are not aware of this new primitive, they cannot offer an enhanced experience to them.

What wallets need to do in order to integrate Bolt?

At a high-level, it is a matter of knowing which proposers offers preconfirmations, and update the user state immediately after a preconfirmation request has been accepte, without waiting for a transaction to be included in a block.

In the current implementation Bolt-enabled proposers specify a trusted RPC which is responsible for forwarding them transaction and prevent spamming. As such wallets need to be aware of which RPCs can offer this service and how they differ from regular RPCs.

New JSON-RPC endpoint

In order to have maximum backwards compatibility one approach is adding a new JSON-RPC endpoint, such as bolt_sendRawTransaction.
Compared to eth_sendRawTransaction which just returns the transaction hash, this endpoint will return a JSON object { hash: string, commitment?: InclusionCommitment }.
If commitment is null it means the transaction is just sent to the mempool, otherwise the proposer has accepted the request and provided an inclusion commitment to the user, who can use this as a slashing device at a later moment if necessary.

Upon receiving a valid commitment, the wallet software will immediately update part of its local state according to the informations provided by the RPC simulation. This includes the nonce, balance, balance of ERC20s, NFTs, etc... .
The user is then able send subsequent valid transactions leveraging these credible partial state updates before they land on chain.

An overview of alternative approaches

Mocking transaction receipts

Wallets poll the RPC endpoint eth_getTransactionByHash until a transaction receipt is returned in order to give a feedback of inclusion and execution to the user. If a transaction receipt is available it means it has been included in a block.
This flow is used also for different L2 chains who have shorter block times, in general less or equal 2s. As such a fast feedback to user consists of the RPC giving back a transaction receipt quickly.

A natural question then comes: can we return a transaction receipt of a transaction before it has actually be included on-chain?

According to the Ethereum yellow paper a transaction receipt consists of a tuple of five items $$(R_x, R_z, R_u, R_l, R_b)$$:

• the type of the transaction, $$R_x$$,
• the status code of the transaction, $$R_z$$,
• the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, $$R_u$$,
• the set of logs created through execution of the transaction, $$R_l$$,
• the Bloom filter composed from information in those logs, $$R_b$$:

If a transaction is non-contentious then it follows that only $$R_u$$, the cumulative gas used, cannot be simulated by an RPC accurately since the block hasn't been minted yet. Moreover, the eth_getTransactionReceipt endpoint that is called by wallets to know the status of a transaction includes additional fields such as transactionIndex, blockHash that cannot be relied upon. Even the fields effectiveGasPrice and blobGasPrice can be tricky to simulate because the basefee might change between subsequent blocks, and the RPC cannot predict what its exact value will be when the transaction is going to be included.

Even with these possible limitations, it would interesting to know how much wallets rely on such fields for their functionalities. If both transactionIndex and blockHash are not actually used, then the other two fields can be rounded up assuming a maximum basefee increase of $$12.5%$$ for block. The user would then see its ETH balance slightly increase after the preconfirmed transaction have been included, meaning the basefee hasn't increased so much.

MetaMask Snaps

MetaMask Snaps is a powerful update to the MetaMask which allow users to use extra functionalities developed by third parties. These functionalities are wrapped into software packages called Snaps.
In the context of preconfirmation they can be promising. The most interesting functionalities to us is creating custom EVM accounts. As a Snap developer you can create accounts for which usual JSON-RPC requests are proxied and use the logic specified in your extension.

While further work needs to be done on our part to see the feasibility of the integration, an instant drawback of this approach lies on its fundamental assumption: new EVM accounts are created, which means a UX friction step where users need to transfer funds to these new fresh accounts with no on-chain history. Also as the name suggests it is a feature available only on MetaMask while we have an ecosystem flourished of different wallet implementations.

Open Questions / Notes

bolt_sendRawTransaction

• What is the best design for the bolt_sendRawTransaction endpoint?
• Wallets need to verify inclusion commitment signature before actually updating the local state

RPC simulation

• Simulation with RPC needs to be handled carefully by taking into account previous preconfirmation requests

Mocking receipts

• They seem to require almost no work by wallets. Is that really the case?
• They don't provide an inclusion commitment to the user. Where this will be sent then?

Giving instant feedback also to the recipient of a transaction
The sender of a preconfirmation requests gets an instant feedback, but what about its recipient? In order to have a better UX it'd be great if the recipient would receive an instant feedback as well and add accordingly. Some mobile wallets like Rainbow and Zerion provide notifications upon receiving ERC20s, ETH, NFTs etc, and it could be leveraged for this purpose.

There is another challenge with this, because we're doing some assumptions about how the block builder is going to order transactions. In particular, consider an USDC transfer $$t_A$$ sent from account $$A$$ to account $$B$$. After $$B$$ receives a preconfirmation feedback for receiving USDC, it could to a transaction $$t_B$$ where it spends it.
If both $$t_A$$ and $$t_B$$ are supposed to be included in the same block, in order for $$t_b$$ to not fail it is required that the block builder places $$t_B$$ after $$t_A$$ in the block, however this is not enforced in Bolt. The builder is free to re-order preconfirmed transactions in the block as long as they're included and protocol rules are satisfied.

Footnotes

1. Some ERC20 might have additional conditions which can make an user tx fail even if it has enough balance. ↩

[thedevbirb]

Some updates on mocking transactions receipts

Some wallets may be picky about the mocked fields
For instance, they could require a non-null block hash or block number, or they could perform arbitrary validation logic before accepting a receipt. There is no specification about this, the only requirement is adopting Ethereum's JSON-RPC API.

Currently, I cannot satisfy MetaMask requirements for the receipt which shows as "pending" even after several seconds the transaction is included on-chain. However Coinbase Wallet accepts my receipts.
I haven't figured out MetaMask requirements since it is quite a complex codebase to tackle. Coinbase wallet is closed source.

Uniswap wallet doesn't allow changing RPC
Uniswap wallet doesn't support a lot of methods, most notably adding new chains. Also from the UI it is not possible to change RPC endpoint. As such, we cannot use Bolt RPC to send mocked receipts.

Polling interval
After a transaction is sent through the network the wallet doesn't immediately try to retrieve its receipt but waits some time. This time is the polling interval and it is also waited after every eth_getTransactionReceipt request that doesn't return a valid receipt before making the next one.

In wallet UI it is not possible to lower down this polling interval. This is probably mainly to reduce spamming/load on RPCs and avoid rate limiting. For example, even if Arbitrum has a block time of 250ms, MetaMask gives you a feedback of inclusion after several seconds and on the block explorer you can see it was actually included way before.

This pollingInterval is usually hardcoded or configurable in library code used by wallets, as such it requires changes by the teams operating them. Usually, asking for a transaction receipt is handled by library providers like ethers.js'JsonRpcProvider and such classes let you set the pollingInterval. An approach could be ask wallet teams to have a more granular control over it, and for example configure a polling interval of 500ms in case the RPC setted is Bolt. A con to this is when transaction cannot be preconfirmed, resulting in wasted repeated calls.

Where is the inclusion commitment sent then?
This could be an additional, optional field of the transaction receipt but it integration in the wallet would still be TBD. Another "training wheels" approach could be let the Bolt RPC store the inclusion commitments for a certain amount of time and let them be available to users. This requires a bit more trust from users into Bolt RPC.