Introducing Opclave: An Op Stack chain that enables to turn iPhone's into a hardware wallet with fully Account Abstraction support. ethglobal.com/showcase/opcla…
In Apple Slicon, there is one processor that has abstracted from other components of the phone: Secure Enclave. Secure enclave is designed to protect the users keys and sensitive data which can be reached by only biometric identification (Face ID - Touch ID)
So, we have a fully abstracted TEE in our phones. If we can use it for Private Key storing, that can improve our mobile wallet security level nearly to hardware wallet.
But we have a problem: 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 could write a solidity verifier for secp256r1 but this verifier consumes too much gas. So we decided to configure the Op Stack and implemented a precompile verifier for secp256r1. Precompile implementation helps us to prove the ownership of the user account.
So we have a fully secure mobile wallet but we still have lots of problem that makes the UX poor. For this reason, we've implemented various Account Abstraction features such as Paymasters, Social Recovery, Daily spend limits.
Here is the summary of what we've built for this hackaton. User sign the message with their face id, than the bundler takes the UserOperation and precompile verifier verifies the transaction's validity.
So we have a fully Secure Enclave and Account Abstraction support in OpClave
We also have a PoC demo video live and absolutely all of our codes are open sourced! We are discussing for our future as we want to improve our project with new Account Abstraction features and supporting with new chains that have protocol level AA support ethglobal.com/showcase/opcla…
We, Opclave team, had so much fun while developing the Opclave. We want to take this PoC to the next levelop and develop it for the mainnet.
1/ Batch Transactions (AA) and State Diffs are more powerful than you think. With Clave's batchcaller Contract , users can perform batch transactions while reducing data availability fees tanks to state diffs!
2/ If you're not familiar with state diffs, you can refer to my previous blog post where I have explained the details of state diffs and why Account Abstraction is more powerful with state diffs.
3/ The TLDR of state diff is, some of rollups such as @zkSync and @Starknet only post state differences to L1 instead of sending all transaction data. This reduces the calldata costs, which make up almost 90% of a transaction's total cost.
In AMMs, there are two main parties involved. On one hand, we have traders who aim to exchange their assets for another asset, and they pay fees to liquidity providers (LPs). On the other hand, we have LPs who seek to generate profits from their assets.
3/ But why they're dumb?
Let's imagine a scenario where the price suddenly spikes to 8 USDC, while the pool price remains at 2 USDC. This spike creates an opportunity for bots to make money. However, the price quickly drops back down to 2 USDC again.
1/ Everyone talks Sovereign Rollups and how they vary differ Smart Contract-based Rollups, but no one discusses "how do they actually work?"
So, here's a quick summary of how Sovereign Rollups work:
2/ Before we deep dive into rollups, we should understand how "classic blockchains" and "modular blockchains" work. I've recently written a thread about it, so please read it if you're unfamiliar with the basics.
3/ Rollups perform three main functions:
A) Performing out the verifiable computation: The rollups computations are all verifiable by using integrity proofs: Zero Knowledge or Fraud Proofs.
This means that Rollup transactions can easily be verified by 3rd party actors.
1/You want to know how Aggregators work and why they are necessary at EIP 4337. Here is the explainer:
in normal Ethereum transactions, Priv Key's sign creates the signature.
by calculating the PubKey+ Message+ Signature together, we can determine whether or not it is true.
2/ The normal Ethereum transaction's verification cost is too low (3k for ecrecover) since the signature verification rules are hardcoded at the Consensus Layer.
Yet, in most cases, the UserOperation's signature verification cost is extremely expensive cause it is not optimized.
3/ You can modify GETH and add some precompiles (predefined functions) to optimize the gas cost of verification the defined signatures but it needs changes from the Consensus layer and it is hard to use it at the generalized chains. (We are looking for a ways to get over with it)