The work of the last two weeks has focused on thinking about contract deployment in DApp. Most of the time, I am learning the contract development of zkRollup Layer2 and studying their network design characteristics. Among them, the Cairo programming language designed by StarkNet can help us better develop application-rich DApps and reduce Gas consumption by an order of magnitude.
In StarkNet, all addresses are contract addresses, and there is no concept of external account (EOA). Its wallet account is composed of an "account contract" signed and deployed by the user. Only the signature of the private key can operate the transfer of this "account contract". This is a very interesting idea. We know that in the Ethereum mainnet, EOA and contract accounts are one of the historical legacy issues. From the EIP86 draft to the EIP-2938 draft, they are all committed to abstracting account logic from EOA Come out and apply its logic to the account managed by the smart contract to realize the "smart contract wallet".
Argent X, StarkNet's mainstream wallet solution, is an implementation of a "smart contract wallet". The community also provides a corresponding JS SDK to help developers implement smart contract wallets locally or in their own deployed DApps.
If we turn our attention to multi-signature contracts, we will find that the smart contract wallet as a service has received more attention and has been used more times than the role of an Inject Provider. Among them, the most popular service is Gnosis Safe*. But in turn, the smart contract wallet as an independent wallet has not been widely used, especially in the L1/L1s solution, which cannot compete with traditional EOA wallets (such as MetaMask).
*Note: Here, the wallet provided by Gnosis Safe is a multi-signature contract programming paradigm, not the contract account abstraction mentioned in EIP86 and EIP-2938.
In my opinion, although the smart contract wallet has obvious technical and experience advantages, it introduces the additional complexity and security risk of the contract in the asset-heavy L1/L1s network, and cannot change the trouble of remembering the mnemonic ( Since it is still necessary to set permissions for the smart contract wallet), users cannot perceive its technical advantages. In addition to the innovative products represented by Argent Guardians that allow users to use three-party confirmation to retrieve the authority of the smart contract wallet, most users only use it in the context of multi-signature contracts, as an open asset or additional confirmation management mode.
In a Layer2 network similar to StarkNet, there is no historical burden on the smart contract wallet, so it may be able to bring some technical architectural advantages to the DApp to the public.
In fact, with the launch of Ethereum's Layer 2 network, especially the zkRollup network, the smart contract wallet will probably allow us to design a multi-layer asset relay network (Multi-layer Asset Relay Network) to help our users use L1 The EOA account controls all application layer assets.
Multi-layer Asset Asset Relay Network (hereinafter referred to as MARN) is a product vision of mine, which does not exist in the current reality. In the rest of this article, I will explain what MARN is and why we need it.
1. Large-scale user product requirements
Going back to my initial requirements in developing the Checks Finance DApp, I need it to support the following functions:
- Non-external wallet SDK : Users do not need to download a third-party wallet, and can directly create a wallet in the DApp.
- Non-custodial wallet model : users do not need to escrow their private keys outside my service or a third party, but we need to provide a feasible process for users to regain control of their wallets.
- No Gas Fees : Users do not feel that they have paid Gas fees, which is especially necessary for new users since they have no convenient channels to obtain gas tokens.
- Fast block confirmation : users will not get stuck or wait too long when operating blockchain transactions.
- Safe and good asset liquidity : users can transfer their assets through a wide range of bridge contracts that are safe, fast and rich in transaction depth.
By observing most of the DApps on the market, I found that they can do a good job in the 4th and 5th points, but in the first 3 points, since they are mainly aimed at Crypto Native users, generally, these teams will not spend Too much cost to consider optimizing.
Undoubtedly, these difficulties limit the scale of users entering Web3 to a large extent. If the problem is not fundamentally solved, it is difficult for me to convince myself that Web3 products can achieve an order of magnitude of user growth in the next cycle.
In order to solve problems 1-3, I started looking for possible solutions in the industry.
First of all, the wallet solution is an important threshold we must first pass. At present, for DApp developers, there are probably several popular wallet solutions:
- External Wallet Connection: Most popular, but has the highest barrier to entry for new users. We do not consider this scenario in this paper.
- Local wallet SDK: The integration is simple, but once the user deletes the App data, they will not be able to retrieve the private key and face a great risk of loss.
- Managed wallet service: A managed wallet service that bypasses the DApp application logic and directly uploads the private key to Secrets Service for management, uses the local SDK for transaction signing, and some services can support exporting the private key.
Among the solutions for large-scale user products, the third hosted wallet solution is the solution used by most products at present, and Web3Auth and MagicLink are representative products of this kind of solution. It is very clear that users can use email, mobile phone or other social login methods to manage and retrieve their private keys. In this way, it can bring enough external users, but its shortcomings are also very obvious: it This brings potential security risks, which may not be limited to AWS's private key storage service, but may also involve security risks in the design of the managed wallet platform.
Secondly, there are currently several mainstream paradigms for the design of zero gas fees:
- Use the Gas Relayer to proxy the user's Gas when creating a transaction: use the Gas Relayer provided by GSN or OpenZeppelin to create a Meta Transaction (Meta Transaction)
- Use L2 solutions (such as IMX or StarkNet) to proxy Gas: Create meta-transactions through smart contract wallets, and the transaction party contract that receives the message can pay Gas fees on behalf of the user.
- Use the robot EOA to proxy the user's request on the server side: This solution is the simplest, but it will bring additional security risks, and it cannot show the real transaction between the user and the contract.
Considering the additional handling fee of the Gas Relayer and the base Gas fee, using the latter (L2 solution) to deploy our DApp contract is obviously a more effective and less costly way. Among them, some L2 solutions even support the use of specific ERC-20 tokens to pay Gas fees (such as zkSync2.0). Such a fee model will become part of the DApp economic model and increase the value of the governance token we issue, just like DeFi Kingdoms Crystalvale did.
As a summary, in terms of product design for large-scale users, we need to find a product design idea that can support the above requirements at the same time. At present, the more feasible way seems to be to use the Layer2 solution.
2. Problems with External Accounts (EOA)
Using the Layer 2 solution, we can simply implement meta-transactions based on smart contract wallets. Taking StarkNet as an example, although the implementation of its wallet is a smart contract wallet, because we need a clear control authority, the product design idea of Argent X still follows Following the concept of EOA wallet MetaMask: when the wallet is initialized (for StarkNet, when deploying the account contract), we need to remember the mnemonic words of the wallet.
This brings up a concept that is easy to confuse: How many networks does our DApp support, and how many EOA wallets do users need to create?
Unfortunately, most DApps on the market follow this stupid but helpless way of thinking. I call this product design a "multi-wallet nightmare". From the perspective of users, it is not only useless to understand the difference between Web3 and Web2 products, but even greatly increases the security risks of using products on the user side.
I understand that on the one hand, this helpless method is in line with the current design ideas of the EOA wallet. On the other hand, such a design of rights and responsibilities is very clear, and the contract and wallet development teams do not need to pay for the mistake of the user losing the private key. . But I think we should be able to find a more understandable and natural way from the smart contract wallet.
A simple hypothesis is, can we allow smart contract wallets to operate through specific L1 EOA wallets? Alternatively, can we design the guide contract wallet as a privileged operator of a multi-signature wallet, and set trusted L1/L2 accounts as EOA operators, allowing them to change the daily operation of this contract in an emergency member permissions?
The fact is that the infinite imagination brought by the smart contract wallet, for the EOA wallet, the programmability it provides can not only support the meta-transaction of the agency Gas fee, but also completely liberate the wallet from the EOA single key : And I think this is one of the necessary conditions for Web3 to be applied on a large scale.
3. Thoughts on multi-layer asset relay network (MARN)
Before coding the Mobile DApp launched by Checks Finance for the Japanese market, I repeatedly thought about a question. If in the future we are faced with hundreds of DApps in mobile phones, and they are deployed in multiple different networks, what should we do? How to manage my wallet?
Will we link all wallets using MetaMask? Are our assets equally important in all DApps, whether it is DeFi, games, or NFT trading markets? Will all our assets be exposed on the Internet for anyone to view? Would we allow ourselves to lose a wallet? These questions lingered in my mind and could not go away for a long time.
These questions point to the same two cores that need to be answered:
- What exactly is an ideal Web3 product?
- How do we manage our complex assets? (Membership Card, Points, Change, Savings, Funds and Stocks)
We are in a multi-chain and multi-layered Web3 world, and there is no doubt that this will continue for a long time, which means that NFT players will operate their MetaMask wallets on the mainnet, fitness enthusiasts will operate their MetaMask wallets on Solana Participating in the daily activities of StepN, DeFi users will shuttle in different networks, own dozens of EOA wallets at the same time, and manage their complex asset types, and DAO will become a cross-network asset contract.
However, when Web3 really enters the public eye and users grow by more than an order of magnitude, will DApps and wallets maintain their status?
My opinion is that with the gradual development of Layer 2 and other application layers, the wallet will definitely become more fragmented, and the accounting assets kept by the wallet will also become fragmented accordingly. If all wallets are EOA wallets, it will definitely bring about a "multiple wallet nightmare" hundreds of times more serious than the current one.
However, if we move all assets in the real economy to Web3, we will find that some assets are significantly less important than others. We will allow the change in our wallets to be lost, but we probably cannot tolerate the loss of our savings in the bank. Simple and easy-to-use wallets will occupy some market positions, and they may be embedded in some popular DApps, unlike EOA wallets, such as MetaMask, which are widely used.
I think that these "less important" wallets distributed in the "application layer" can be created by a network of permissions. In this preliminary idea, I call it a multi-layer asset relay network (Multi- layer Asset Relay Network)
MARN means that we can create and control the L2 (or LN) smart contract wallet through the L1 EOA wallet, and allow these LN wallets to become its asset cache layer.
This means that, through L1 → LN communication, we have the ability for users to use one wallet, manage all contract wallets, and, without relying on private key escrow, support the use of recovery operators to dominate some of the LN wallets. permission.
For example, when a user logs into a DApp, most of our contract logic is based on L2 (such as StarkNet), we can automatically create a wallet contract for the user, and record its operator private key locally (as a local cache that can allow loss) When creating this contract, we need the user to provide an L1 external account (login with MetaMask) and provide an alternate mailbox or a specific recovery operator. In this way, when the user's local private key is lost, the communication of the L1 EOA account, or the authentication of the backup mailbox, can help the smart contract wallet modify a new operator, that is, the locally randomly created operator is recoverable , replaceable. In terms of product design, this kind of recovery can not be perceived by the user, regardless of whether the user remembers the private key, he can operate the LN wallet at any time.
Through this design, the assets of the LN wallet can be used as the asset cache of the L1 EOA wallet. Using specific communication, the user can withdraw the assets of the LN wallet from L1 at any time (for StarkNet, this behavior will be completed within < 30 minutes) On the other hand, this strengthens the security of assets in the contract wallet, and endows flexible cross-layer authority management.
MARN has brought clear benefits: for users, it is no longer necessary to record more than one EOA mnemonic, and they have no perception of LN services; The cost and security risks of Secrets Service can be said to serve multiple purposes.
The ultimate design goal of MARN should be to help users use a single external wallet to achieve seamless authority control and asset transfer across multi-layer networks. From the perspective of this goal, LN should be the preferred infrastructure for application services, because Layer 2 technology can guarantee the security of cross-chain assets to the greatest extent, without handing over this security risk to application developers who write cross-chain bridge contracts (like what happened to Axie).
At the moment, I'm still in the early stages of thinking about this concept, but I've implemented this idea in the DApp coding of Checks Finance L2, hoping to provide its users with a seamless and secure wallet experience. For MARN, if you have similar ideas or have constructive suggestions, welcome to discuss with me on Twitter. I will also gradually update my specific practice of this idea in Mirror, and open source the final product and code.
I have a hunch that the large-scale application of Web3 may happen in the next cycle, let us continue BUIDL to witness this profound global change.
Miyuki
Alex
Brian
Weiliang