Hey, fellow Biconauts.
We’re currently making plenty of developments for our Modular Smart Account ecosystem.
We’d love to hear your feedback on it and discuss it with you.
Today let’s talk about Biconomy Multichain Module
We all witness the three transitions happening in Web3 right now, making the space much more mature and friendly for mainstream users.
One of those Transitions implies that everyone moves from EOAs to Smart Accounts (or Smart Contract Wallets). Biconomy is at the forefront of this transition pioneering Modular Smart Accounts development.
Another transition means that most users will be active on several chains. It makes the multichain and cross-chain features important for Web3 infrastructure builders who want to deliver seamless UX to their customers.
Biconomy’s latest development in this area is the Multichain Validator module which significantly reduces user friction for multichain operations.
What it enables
Biconomy’s Multichain Validator module enables use cases that require several actions to be authorized for several chains with just one signature required from the user.
Basically, it enables Sign once, Execute on multiple chains use case.
This approach works best for actions that are the same in nature but vary with some details from chain to chain.
Let’s take a real use case that inspired us to build such a module.
Let’s assume there is a dApp that helps users manage their crypto investments. It does it in a way, that when a user comes to the platform, she allows dApp to perform some operations on her behalf. To make this happen, dApp deploys a new Smart Account for the user and enables Session Keys for this smart account. So the user can issue Session Keys and give them to the dApp, so dApp can perform only user-selected operations: like only protocol A and for not more than amount X. Now imagine the user wants to invest in several chains. There are various protocols on various chains, and users may want to set various permission for the session keys on various chains. Also, the user doesn’t have a Smart Account yet, so dApp wants to deploy the SA for the user and enable session keys for it.
To ensure the best UX, dApp wants users to sign in as less times as possible. It means, that we need to protect userOps on several chains with various calldata with as less signatures as we can, ideally with just one.
However, userOps on several chains may have various nonces, various gas values, and of course, various chainIds packed into userOpHash. Don’t forget about calldata which varies from chain to chain depending on the session key permissions for this chain.
With the Biconomy Multichain Validator module, it is possible to protect any amount of such userOps build for various chains with just one signature!
How it works
There is an efficient way to prove that a blob of data has been included in a list of trusted blobs without going over the entire list or even knowing the entire list. This is done using Merkle Trees.
How do we use Merkle Tree here?
-
We take all the userOps which we need to sign.
-
We get userOpHash’es from those userOps.
-
Every userOpHash is now a leaf of a Merkle Tree.
-
Instead of signing several userOpHash’es separately, the user signs one Merkle Root.
-
Now we can reliably prove on-chain that a userOp is a leaf of a tree whose root has been signed by an authorized user.
That’s exactly what we need. Now users can authorize any amount of userOps with just one signature over the Merkle Root of those userOps.
Every userOp is included in the leaf as userOpHash+validUntil+validAfter, so users can define various validity timeframes for userOps they want to authorize.
You may notice, that in theory, such an approach enables one signature experience not only for the several chains but generally for the several totally different userOps even on the same chain.
And this is true.
However, we expect this module to be less likely used in this way. It is because signing several userOps on the same chain involves knowing nonces for all the userOps in the Merkle tree in advance. Of course, it is easy to calculate those nonces by just incrementing. However, if even one userOp not from the tree will be created and processed between those from the tree, the userOp from the tree with the same nonce will become invalid.
So despite the fact that in theory this Validation module can be used as a general-purpose multi-userOp validator, it is most convenient and reliable to use it as a Multichain validator.
UX Impact
The Biconomy Multichain Validator module significantly improves UX for deploying and setting up Smart Accounts on several chains.
It allows for a user to only sign once and authorize any amount of userOps with this signature.
It reduces user friction for dApps which for example want to quickly and seamlessly deploy and configure Smart Accounts on several chains or issue session keys with permissions that vary from chain to chain.
More use cases with web2 like UX can be enabled with the described module.
It also allows for a very simple devX, as the concept of signing a Merkle Tree of userOps instead of signing userOpHash’es for several chains one by one is straightforward and not overengineered, so even developers who just start their journey in the web3 won’t be confused with what happens in the module and why
Security assumptions
Since the user signs the Merkle tree root of userOps, there is trust needed to be placed into the dApp which creates this Merkle root. Users should trust that dApp would not put the hash of a malicious userOp as one of the leaves. However, even when a user signs a single userOp, she signs its hash, which is not human-readable. So the trust assumption is present even for the general ERC-4337 flow.
In both cases, if the user wants to verify what she is signing, it is required that she performs some operations on the original userOp(s) to check that what dApp proposes her to sign is actually the result of hashing an original userOp(s).
Thus the Multi userOp approach introduced by the described module does not introduce any additional security trade-offs compared to the vanilla ERC-4337 flow.
Conclusion
With the Multichain Validation module described above we start building the tools for the rollup-centric transition described by Vitalik. Even this simple module significantly improves UX for deploying and setting up Smart Accounts on several chains. It can be used not only with Biconomy Smart Account but with any Smart Account which follows the EIP-6900 interface for validation modules. We’re looking forward to building more tools that enable the best multi-chain UX for the users of Biconomy-powered dApps.
Please do share your feedback on Biconomy Multichain Validator and your thoughts on the future of Multichain operations in Ethereum Ecosystem here.
