Hey everyone,
I’m Tony from Ideal Labs along with @carloskiron, @colemanirby and @juangirini. We’re currently building the ETF Network as part of our participation in the Decentralized Futures program. This post is part proposal, part call-for-input-and-critique from the community. We have been exploring several ideas for applications of our timelock encryption scheme which we’ve developed as part of the ETF network. The primary goal of the network is to act as an interoperable publicly verifiable randomness beacon, on top of which we have implemented a timelock encryption scheme and a secure delayed transactions mechanism. You can read more about the project here: https://etf.idealabs.network (docs slightly outdated) and our involvement in the DF program.
We’re exploring a keyless wallet solution based on timelock encryption that would allow users to use the wallet using a time-based OTP code. We’re considering applying for treasury funding for developing the solution further, but we want test the waters first. Since there has been an influx of new wallet solutions lately we want to ensure we don’t go down a dead-end road.
Some interesting features of this approach:
- truly keyless: it is a new kind of proxy account based on a pure proxy, so keyless and with a non-deterministically generated account id.
- origin-agnostic capabilities: this kind of wallet could optionally be able to be called from any origin who can provide valid OTP codes.
- anonymous: by default this wallet is anonymous (due to origin agnosticism).
- simple + familiar end-user experience: From a user perspective, they would be able to provide valid OTP codes to sign transactions.
ETF Network Overview
To briefly outline what the ETF network is:
- A Solochain: ETF consensus uses a post-finality gadget inspired by BEEFY to build a chain of publicly verifiable threshold IBE signatures.
- A randomness beacon: by subscribing to block headers of blocks created by the ETF finality gadget, consumers receive a stream of publicly verifiable random values produced through threshold IBE (identity based encryption). The finality-gadget approach also makes it possible to more easily bridge to other networks that use other curves.
- Enables timelock encryption and delayed transactions: The initial use cases we built on the network were to construct a timelock encryption scheme (using AES-GCM + IBE) along with which we developed a delayed transactions framework wherein call data is timelock encrypted.
With that said, since we are relegated to the land of solochains, we intend to make our solution available to the DOT-ecosystem by bridging to an AppChain. We’ll start with a one-way bridge but have plans to explore a bi-directional one later on, which would allow us to produce signatures following the bridged chain’s finality. That is, we essentially want to produce a “stream of randomness” in sync with the target chain.
Our Solution
Finally, getting to the idea…
Our idea is a generalization of the ideas presented in Hours of Horus by Zindros [2]. While the scheme in the paper was only theoretical when proposed due to a lack of practical witness encryption scheme, we are able to realize this scheme in practice using our timelock encryption implementation. We have already developed a PoC to verify the feasibility of this.
The idea is that a user generates future OTP codes for future blocks, commits to them with an MMR, and then creates an onchain pure proxy account, so a keyless, non-deterministic account. We can modify the pure proxy to have NO DELEGATE, meaning any origin can invoke it. With this, later on the user can use ANY ORIGIN to call their wallet, where they must provide a valid timelocked OTP code and merkle proof in order to authenticate. The “keyless account” is essentially a proxy with an extra authentication step.
Benefits/Implications
-
Users must generate and store MMR (merkle mountain range) data that represents a commitment to their future OTP codes. The data itself can be publicly available, but it must be available to users (in order to generate proofs later on when using the wallet). The data can be stored anywhere as long as a user can access it. While onchain storage is possible, a more efficient solution could be to leverage something like IPFS/Crust/etc.
-
It really is keyless, unlike other MPC solutions. There isn’t a key that is sharded and shared that can be recovered;the key never exists. In this sense, the OTP generator seed is the key and we will need to further explore secure/recovery, or perhaps something like a fuzzy extractor.
-
This implies that such a wallet can be safely called agnostic from the origin. That is, many users could use the same wallet keys (e.g. via the same browser window with the polkadotjs extension) to safely interact with their OTP-based wallets.
-
Optionally, usage of these accounts can be made semi-anonymous by allowing any origin to try to act on behalf of the account. We could also investigate the usage of ring signatures for semi-anonymous solution where we want to define a delegate or group of delegates who can call on behalf of the proxy.
-
You must still have access to a standard, valid, funded keypair/wallet in order to call the OTP based wallet.
The Broader picture
Ultimately, we are envisioning a seamless, keyless ‘wallet-as-a-service’ experience for users where wallet usage looks like providing correct OTP codes. Point #5 in the list above makes this difficult to achieve, as a properly funded wallet is still needed to call the OTP-authenticated wallet but we want to provide a keyless experience.
By implementing this as an AppChain bridged to ETF finality and developing an on-chain paymaster scheme, we can allow users to pay for transactions in USDC or other on-chain assets beyond the native token. We intend for this to act as an ‘entry point’ to other parachains (via XCM). Our solution should also be easy to integrate into existing wallet architectures.
The latest account abstraction solution developed for EVM-like chains is ERC-4337. While we can rely on native account abstraction for our solution and ERC4337 largely exists to account for Ethereum’s lack thereof, there are some aspects of ERC-4337 that we would incorporate into the solution. Specifically the idea of a ‘paymaster’ who can sponsor transactions. So along with an AppChain to which we would bridge ETF finality as a randomness beacon, we would also implement a Paymaster scheme, wherein users of the chain can sponsor other users’ transactions.
To summarize, we would need to build an AppChain:
- bridged to the ETF Network
- with the OTP wallet implemented
- with an on-chain paymaster scheme that allows for users to sponsor other users’ transactions. This could probably be useful independent of the OTP wallet solution
Conclusion
We presented some high level ideas on a new kind of keyless crypto wallet based on timelock encryption and time-based OTP codes. We also discussed an AppChain, bridged to the ETF network, where this wallet can be implemented and allow users to use their OTP-based wallets to make cross-chain calls via XCM. Lastly, we discussed the need of an on-chain paymaster scheme that allows users to exchange assets other than the native token (e.g. USDC) to sponsor their transactions. With this all combined, we can enable a keyless, self-custodial wallet-as-a-service scheme for Polkadot.
Thanks for reading! Does this seem like something worth exploring? Your feedback is very appreciated.
Tony Riemer
Ideal Labs