Find the full conversation below:
Sogol:
“Dear @yoavw , thank you so much for your consideration. Apologies for my delay, have been in montenegro for Edcon + ZuZalu till yesterday with intense schedule. Initially wanted to post my answers in this group but i ended up with a writing which published on Mirror and hopefully can give some clear insight on your brilliant questions.
https://mirror.xyz/0xbBFEb6968F818Ae75F8765f24457c5414BCb9Af3/Em8l2WayiDezR_tANZ3RiVO2xNFXbLMmhHcqfPPxNJc
Just wanted to emphasize, we are still in R&D phase and love to improve our iterations based on ideas, suggestions and comments of key-opinioned leaders like you and other Ethereuem researchers in my network before consider it as a final proposal version. Ill make sure to share more concrete details soon with you and Really appreciate your invaluable thoughts and comments.”
Yoav responds:
“I hope you had a good time in Zuzalu. I tried to read the post but I still don’t have a grasp of the model. I see a lot of off-chain operations, e.g. MPC (who actually executes the computations? Is it still trustless Ethereum nodes or does the model introduce some trusted MPC participants?), but I’m can’t quite understand how at works at the network level.
Replay protection – unless these MPC participants are no longer trustless ethereum nodes, but some parties trusted by the account owner, how does replay protection work at the account level (on-chain)?
Mass-invalidations – regardless of which off-chain hash algorithms are used, there is still O(n) off-chain work to be performed by the nodes handling N pending transactions. The account is turing-complete, has access to storage, and could do anything. The only way to know that pending transactions don’t invalidate each other is to simulate all of them. Even if off-chain validations can be extremely fast and efficient, an attack at O(1) that invalidates N transactions could grind the nodes to a halt.
It would be helpful to see an actual simple account implementation in Solidity. Doesn’t have to be a full Safe like what I suggested in my previous message, but a simple account that is replay-protected and has an updateKey(newKey) function allowing the current key to change to a new key. It’s easier to reason about code.
That is, if the model actually implements account abstraction (on-chain) rather than a separate MPC based network like LIT protocol where the user depends on 3rd party nodes in order to access the account. If the latter is the case and the user doesn’t have the key that directly controls the account without involving other parties, then the on-chain code is less relevant.”
Sogol:
“Thank you so much @yoavw 😊 Truly enjoy our thread and appreciate your brilliant comments. 🚀🙏🏻
Actually the proposed model aims to enhance replay protection for stateless account abstraction. The use of DVC, MPC, cryptographic commitments,nonce management (earleir mentioned in the writing) and MPC for State Computation: ( By collectively computing state changes, the participants prevent individual inputs from being replayed in a malicious manner.) collectively work towards preventing the unauthorized replay of transactions and maintaining the integrity of the system’s state transitions.
We would think of a Rotational Key Management, where The participants of the MPC protocol can manage rotational keys off-chain. These keys are periodically rotated or changed to limit exposure and mitigate potential compromises. The key rotation schedule is agreed upon and followed by the participants. The following can be imagined to aim our goal:
MPC Execution and Secure Communication: The MPC participants, acting as light clients, engage in secure communication to exchange their private inputs and perform the computation. To ensure confidentiality and integrity during communication, the participants utilize encryption techniques along with ZK proofs.
ZK Proofs for Secure Communication: Each participant generates a ZK proof attesting to the correctness and privacy of their private inputs without revealing them. These proofs are shared among the participants as part of the communication process, enabling them to verify the validity of each other’s inputs without exposing any sensitive information.
Light Client Interaction and Ethereum Data Access: The MPC participants, as light clients, interact with the Ethereum network to access the necessary data for the computation. They retrieve current state information, fetch smart contract code, and verify transaction status using the light client’s simplified verification techniques.
Result Verification and Recording on Ethereum: Once the MPC computation is completed, the participants generate ZK proofs to validate the correctness of the result without revealing any sensitive information. These proofs are then submitted to the Ethereum network as part of on-chain transactions or interactions with smart contracts, allowing for the validation and recording of the result.
By incorporating ZK proofs into the secure communication process, the proposed setup ensures that the privacy of the participants’ inputs is preserved while enabling the verification of correctness by other participants and the Ethereum network.
At the end, I would like to mention that we are currently in the process of verifying a final model. If the stateless AA is implemented correctly, it has the potential to bring about a paradigm shift. Therefore, I would highly appreciate your further insightful comments and suggestions, as well as any additional opinions from other top-tier cryptographers, including those from the Ethereum Foundation that I met at Zuzalu, to further enhance the model.”
Yoav:
“Thanks. I guess we’re talking about different things when we say Account Abstraction. What I mean is an on-chain implementation of arbitrary account logic, with censorship resistance (the user can always access the account without relying on 3rd party). If I understand correctly, the model you’re describing is an MPC model where the logic is executed off chain by a set of specialized nodes.
A couple of questions to make sure I understand the trade offs:
- Are the MPC nodes permissionless? Can anyone add nodes to increase availability, and they’ll serve all the accounts, or does the account need to trust a permissioned list of such nodes?
- If all MPC nodes are down/censoring, can the user transact with the account independently?
- What’s the process for switching account implementation and adding arbitrary functionality? E.g. if I want to add a deadman’s switch to my account (or any other feature I come up with), do I only change something on-chain, or do I need to work it out with the MPC nodes?
- What is the computational load required of nodes? Ethereum’s decentralization depends on nodes being able to use cheap hardware, as opposed to ZK rollups for example, where an expensive prover is needed. Would the nodes in your model be able to run on the same Intel NUC alongside an Ethereum node (EL+CL), or would it require additional hardware?
- I still don’t quite understand how the MPC nodes protect themselves against mass invalidation attacks. E.g. someone implements an account that accepts transactions until block N, and then stops accepting them. 10000 such accounts are deployed, accepting transactions in the next block only, and 10000 transactions are sent to the MPC nodes. All transactions are currently valid and the nodes spend CPU processing them, but they can’t all be included on chain in the next block. Some are included, the rest wait for the next block. By then, they are no longer valid and cannot be included but the nodes already spent CPU on them. Regardless of how cheap the processing is made, it’s still O(n) unpaid computations. In 4337 these things are handled through restrictions such as not allowing access to the block number during validation (but allowing it during execution). Without such restrictions, how do the nodes prevent this O(n) cost?”
Sogol:
“Thanks so much @yoavw , yes i believe we are talking about same concept, however we took a different architecture than 4337 to realize AA in stateless format. We want a mixture of MPC+AA for more secure SAA model.
In our model, MPC, DVC, and cryptographic commitments are utilized to facilitate the secure stateless account abstraction.
I’m working on our FLow to declare the whole architecture and will share it soon to answer all questions. I’d gladly share a whole and complete version of flow that may answer most of questions in more details.just may take quite few time to get it done. Really appreciate if you would have suggestions improving /replacing some parts of our design with better solutions.
Your insightful questions are very interesting and i want to make sure we’d have proper answer for all of them,Meanwhile quickly sharing my thoughts on accessing the accounts without realying on third party,one share, known as the Personal Share, is stored on the user’s mobile device. The Personal Share contains the user’s private input or secret necessary for the computation. It is securely stored and protected within the mobile device’s secure enclave or other trusted hardware mechanisms.
The other share is stored in the light client. The light client, acting as a participant in the MPC protocol, holds this share and collaborates with other participants to jointly compute the desired function.
When the MPC protocol is executed, the user’s mobile device and the light client interact to contribute their respective shares and perform the computation. The light client, along with other participants, can collectively compute the function while preserving the privacy of the user’s Personal Share stored on the mobile device.
By distributing the shares in this manner, the user maintains control over their private input while actively participating in the computation process.”
Source: The Telegram 4337 Mafia group
Get In Touch:
Website | Twitter | Discord | Github | Telegram
Powered by Etherspot
BUIDLer React Component | TransactionKit | Pillar Wallet | AirdropMe