If you're an Ethereum user, I'm sure you were confused about how to store your 12 words when you set up your first wallet. Also, if you set up a wallet and made transactions during the bull period, the gas fees you paid may surprise you. We, the Opclave team, have created a smart contract wallet that implements the most optimal solution by leveraging the capabilities of Account Abstraction, Apple enclave, and OP Stack to offer a better user experience on blockchains. Our wallet can initiate transactions on OP Stack compatible rollups by Apple’s Face-Id and Touch-Id.
Optimism just announced OP Stack, a development stack that lets anyone spin up their rollup or app chain. One of the most significant benefits of OP Stack for app chain developers is the simplicity with which the rollup can be configured, as well as the availability of a scalable application-specific chain without the need for crypto-economic security. Nonetheless, OP Stack's user experience is still very similar to Ethereum's. As even banking applications are still not adopted by end users, we are aware that we can not onboard 1 billion customers with the poor UX of EOA wallets and the necessity to securely keep 12 words. It's clear that we must improve the wallet experience securely.
Ownership in EOA wallets is proven with a set of hardcoded transaction validity rules. Account Abstraction is a couple of updates aimed at making this validity rules programmable. While many EIPs have been proposed over time for account abstraction, EIP 4337 has been adopted by the Ethereum community and is now available on the mainnet. Users can send batched transactions, set guardians for their wallet, and have many more benefits with EIP-4337 enabled smart contract wallets. Although EIP 4337 enables many features of account abstraction, there were some points where it fell short for our application. Another development we are working on is a trust score for the paymasters while one of the biggest problems that account abstraction is trying to solve is potential DoS vectors. To prevent these DOS attacks, we are proposing a scoring mechanism that uses the OP Attestation Station SDK.
Apple Secure Enclave:
One of our core concepts is to turn our Apple devices, iPhones and Macbooks, into hardware wallets, but how? Apple Secure Enclave is a subsystem that is implemented into Apple’s Chip System. The Secure Enclave is isolated from the main processor to create an isolated secure area for users’ important data. The main use case of the Secure Enclave is to keep user data even if the main processor becomes compromised. It also has a Public Key Accelerator which enables developers to build asymmetric cryptography operations at the Secure Enclave. Since the Secure Enclave can’t be accessed by the main processor and other components of the hardware, performing ECC (Elliptic Curve Cryptography) at the Secure Enclave could turn our device into a hardware wallet.
The Secure Enclave is a great security solution to implement to the wallets and abstract the accounts by the signatures as it can be reached by only Face-Id or Touch-Id. We can use faces to initiate transactions instead of using a private key derived from 12 words of seed phrase to verify your identity and initiate the transactions. The Secure Enclave only supports the “secp256r1 curve”, whereas Ethereum supports the “secp256k1 curve”. So, we needed some custom solutions to implement Apple signatures to blockchain.
We have configured the op-geth and added a precompile verifier to initiate and verify the Secure Enclave’s public key to our blockchain to solve the gas cost problem. We could use a verifier written in Solidity with an EIP-4337 compatible wallet, but in our tests we saw that gas costs are increasing too much (1M gas for each verification) in the Solidity verifier. Precompile helps us to decrease the gas cost of verification and turn it to a chain native support.
Using the custom precompile allows us to abstract wallet ownership with Apple’s signatures and get an ERC-4337 compatible wallet which is interacting with the precompile contract. So now, we have a wallet that can initiate transactions from a Trusted Execution Environment (Secure Enclave) with guaranteed security. Even so, it’s not enough to improve the UX of the wallets. Still, we can implement more features to account abstraction wallet to enrich the capabilities of the EOA wallets. We have implemented several futures to our wallet implementation to reach a secure account model with rich experience.
Our Account Abstraction Implementation Details: Account Abstraction via EIP 4337 opens the door to build smart contract wallets without any trust assumption. So we have developed various applications that use AA.
Social Recovery: Imagine that you lost your phone and don't have access to it, which prevents you from accessing your secure enclave and preventing you from recovering your funds. We created a social recovery mechanism for this situation, wherein you can set an Inheritor that can sign to recover the user's assets if the wallet hadn't made any transactions for X days.
Transactions Batching Users can batch their transactions to publish on chain in only one transaction. For example, token approving and swapping or claiming and staking operations can be sent in one transaction.
Paying Fees with Any ERC20 Token (Just OP Support in Our Demo): Custom actors are able to sponsor user transactions in 4337. Let's say you've bridged OP to your Opclave chain and want to use OP tokens to pay fees. Our paymaster pays your gas fee and accepts OP token. Also we’ve used Optimism’s “Attestation Station SDK” to score paymaster’s secure level.
Daily Spend Limits: Users can set their daily spend limit to prevent hacks - even if the malicious transaction is sent on chain, our contracts won’t let it execute without M of N Guardian’s sign.
Bringing OP Stack to the next level, Opclave:
We have combined the best solutions with minimal trust assumptions to improve OP Stack chains by building a strong solution for OP Stack developers. For example, the base chain can use our implementations to onboard their users with smooth user experience or a DeFi app chain that uses OP Stack can use our configured OP Stack chain to make the superior user experience possible.
The reason why business chains have become unsuccessful is that they didn’t have any solution about crypto-economic security. Thanks to rollup and integrity proof technology, we don't need any crypto-economic assumptions. So it is not surprising that Coinbase is launching their own chain using OP Stack technology. So we think that the businesses are going to choose rollup for this reason. Yes, we have no problem with security, but UX is still a silly problem and we have solved it with our implementations. Business chains, appchains and absolutely the core Optimism chain can use these configurations to bring the superior UX to their OP Stack chain. Note that the things that you can do with are unlimited. Coinbase can use email login or 2FA to show good user experience in their chain as their CEX.
Future: We want to develop more account abstraction features in our implementation such as 2FA, email login and we want to release our implementations as a product. Also, we want to support other chains in the future such as Starknet, zkSync, and Fuel. Starknet and zkSync have a EIP 4337 type protocol level solutions for account abstraction and Fuel has predicates which allows developers to program spend rules of UTXO also Nick (CEO of the FuelLabs) has told us that Fuel is going to have support for Secure Enclave.
We needed an environment that presents a proof-of-concept application of AA by Apple Secure Enclave. We runned a custom rollup which contains our “secp256r1 verifier” precompile contract in the standards of Optimism’s Bedrock Release and obtained this environment that we can apply Face-Id and Touch-Id verified transactions. Our customized op-geth client, op-node, and op-batcher softwares are running as a L2 in Goerli testnet. So, the account contracts can be deployed to the network and mobile apps can be used to operate these wallets.
Mobile wallets are being used with poor experience and less security, but mobile devices can provide “cold wallet level security” for the blockchain accounts. Our mobile phones, which enter every point of our daily life, will create an efficient usage area when our blockchain wallets are included.
New generation Apple devices have a hardware security component called “Secure Enclave” which is able to store keys or sign data. Even if wallet private keys can be stored in the Enclave, using wallets with private keys is not needed because signing the transactions can be operated directly by Enclave’s signing mechanism. Then, verifying these signatures will be possible in blockchains and smart contracts after the security step by Face-Id or Touch-Id is passed. It should be noted that the “Secure Enclave” can only be accessed via Face ID, Touch ID, or password. Everything runs in the hardware and can not be accessed online, similar to hardware wallets.
The Secure Enclave has its own unique ID and is responsible for generating and storing cryptographic keys used for encryption and decryption, as well as signing and verifying data. The Secure Enclave uses a combination of digital signatures and encryption to securely sign data and ensure its authenticity. When we implement this signing mechanism for the transaction data, we guarantee the biometric ownership of published transactions proved by Face-Id and Touch-Id from the accounts.
Standart EVM implementation is able to make recoveries for “ECDSA secp256k1 curve” signatures with its precompile contract which we are familiar as “ecrecover”, but this specification is not compatible with the Apple Enclave signatures. A custom recovery or verification algorithm is needed to use in smart contracts. Apple’s signature outputs allow us to verify data and its signature directly in curves, but operating this verification by Solidity consumes too much gas. So, implementing this verification process by a precompile contract is the most efficient way to verify Apple signatures.
Our precompile contract takes the public key of the signer, hash of the transaction, and “secp256r1 curve” signature for the hash to return true if the signature is valid for the given transaction. So that transactions from smart contract wallets with prespecified public keys by Enclave can be verified in smart contracts.
Account Contract: Our account contract verifies transactions with the provided secp256r1 curve signature via our custom precompile. It lets its user send batched transactions, set inheritors in case of health problems or device loss and pay gas fees with tokens.
Paymaster: Our paymaster enables paying gas fees with OP tokens. It pays Ethers on behalf of the account and transfers the corresponding amount of OP tokens to itself.
Attestations: Normally paymasters are required to stake Ether as they can invalidate large sets of transactions which opens up a DOS attack vector. We are proposing an attestation based system instead of staking which is inefficient because it is not possible to prove malice in EIP-4337 and there is no slashing. An attestation based system that uses Optimism’s “Attestation Station SDK” is much better than a stake based system.
Our implementations and demo products combine at Opclave Mobile Wallet to create a fully secure user experience in an OP Stack rollup. In the mobile wallet, the users can experience that they can obtain account ownership on top of the Apple iPhones and Macbooks.
Smart Contracts: Opclave gets the strength of smart contract wallets which are compatible with the ERC-4337 account abstraction standard. We developed this wallet smart contract, and also implemented required ERC-4337 contracts to our custom rollup like “Paymaster” and “Entry Point”. Lastly, we implemented Optimism’s “Attestation Station SDK” Smart Contracts to verify the Paymasters are not sybil. We used Solidity to develop smart contracts and benefited from Foundry and Ethers tools.
Mobile Development: Opclave mobile wallet is the heart of our implementations which enables users to reach our features. The mobile app has 2 main parts. The first part written in “Swift” language is the signature manager which interacts with the Apple Secure Enclave and signs transactions to be executed on chain. The second part written in “React Native” framework is the wallet interface in which users interact to operate their transactions.
Rollup Development: Opclave runs in our custom “OP Stack” rollup which is allowed with the “Bedrock Release”. We have modified the “op-geth” execution client software to add our custom precompile contract written in GoLang to be able to verify “secp256r1” curve signatures easily, also run with op-node and op-batcher.
Backend Development: Smart contract wallet operations need “bundler” and “paymaster” software to be run separately. We have implemented our services written in Typescript.