# Ziheng Xiao
## [Now updating here](https://hackmd.io/@yezhang/rJo3BA68n)
## Week of 05/29 - 06/04
### 05/29
+ Research
- [x] Read some highly referenced research reports on account abstraction.
+ [Vitalik introduces ERC4337](https:///medium.com/infinitism/erc-4337-account-abstraction-without-ethereum-protocol-changes-d75c9d94dc4a)
+ level: :+1::+1:**should read.**
+ [Cointelegraph's analysis of account abstraction](https://cointelegraph.com/news/ethereum-erc-4337-smart-accounts-launch-at-walletcon-account-abstraction-is-here)
+ level: **good to know.**
+ [Video: Yoav Weiss discussing the implementation of ERC4337](https://www.youtube.com/watch?v=eyT6WzJmWyc)
+ level: :+1:**worth reading.**
+ [Historical work and motivation of account abstraction](https://ethereum-magicians.org/t/implementing-account-abstraction-as-part-of-eth1-x/4020)
+ level: :+1:**worth reading.**
+ [Vitalik's summary of the account abstraction proposal in 2018](https://ethresear.ch/t/a-recap-of-where-we-are-at-on-account-abstraction/1721)
+ level: :+1:**worth reading.**
+ [Vitalik's summary of trade-offs in implementing account abstraction in 2017](https://ethresear.ch/t/tradeoffs-in-account-abstraction-proposals/263)
+ level: :+1:**worth reading.**
+ [Vitalik: Maximally simple account abstraction without gas refunds](https://ethresear.ch/t/maximally-simple-account-abstraction-without-gas-refunds/5007)
+ level: :+1:**worth reading.**
### 05/30
+ Research
- [x] Read some EIPs related to account abstraction.
+ [ERC4337](https://eips.ethereum.org/EIPS/eip-4337)
+ level: :+1::+1::+1:**must read.**
+ [Unified ERC-4337 mempool](https://notes.ethereum.org/@yoav/unified-erc-4337-mempool#What-does-censorship-resistance-require-of-ERC-4337)
+ level: :+1::+1:**should read.**
+ [EIP-2938](https://eips.ethereum.org/EIPS/eip-2938)
+ level: :+1::+1:**should read.**
+ [EIP2718 (required by EIP2938)](https://eips.ethereum.org/EIPS/eip-2718)
+ level: :+1:**worth reading.**
+ [EIP-2938 Discussion](https://ethereum-magicians.org/t/erc-4337-account-abstraction-via-entry-point-contract-specification/7160)
+ level: **good to know.**
+ [EIP-86](https://eips.ethereum.org/EIPS/eip-86)
+ level: **good to know.**
### 05/31
+ Research
- [x] Thoroughly studying ERC4337 and its related discussions.
+ re-read [ERC4337](https://eips.ethereum.org/EIPS/eip-4337)
+ re-read [ERC4337 Discussion](https://ethereum-magicians.org/t/erc-4337-account-abstraction-via-entry-point-contract-specification/7160)
+ [ERC4337 Discussion](https://ethereum-magicians.org/t/erc-4337-account-abstraction-via-entry-point-contract-specification/7160)
+ level: :+1::+1:**should read.**
+ [Stack Up's perspective on EIP-4337](https://docs.stackup.sh/docs/account-abstraction)
+ level: **good to know.**
+ [Interpretation of the ERC4337 audit plan](https://zhuanlan.zhihu.com/p/614490277?utm_source=qq&utm_medium=social&utm_oi=961180409648844800)
+ level: **good to know.**
+ [ERC4337 audit part 1](https://blog.openzeppelin.com/eip-4337-ethereum-account-abstraction-incremental-audit#conclusions)
+ level: :+1:**worth reading.**
+ [ERC4337 audit part 2](https://blog.openzeppelin.com/eth-foundation-account-abstraction-audit)
+ level: :+1:**worth reading.**
### 06/01
+ Research
- [x] Continuing the study of the structure of [ERC4337](https://eips.ethereum.org/EIPS/eip-4337)
+ [Bundler Compatibility Test Suite Announcement](https://hackmd.io/@erc4337/test-suite)
+ level: :+1:**worth reading.**
+ [code: bundler-spec-tests](https://github.com/eth-infinitism/bundler-spec-tests)
+ level: **good to know.**
+ Review
- [x] creating the schematic diagram of its principles and the logical diagram of contract invocation based on the ERC4337 proposal. Starting the production of the PowerPoint presentation.
### 06/02
+ Research
- [x] Reading more materials based on the questions that arose during the research.
+ [source code: account-abstraction](https://github.com/eth-infinitism/account-abstraction/tree/main/contracts)
+ level: :+1::+1::+1:**must read.**
+ Review
- [x] Continuing to create flowcharts, and working on the PowerPoint presentation. Thinking about the approach of implementing account abstraction on Scroll and creating a structural diagram.

## Week of 06/05 - 06/11
### 06/05
+ Research
- [x] Studied the detailed code of the [ERC4337 contract](https://github.com/eth-infinitism/account-abstraction/tree/main/contracts) and [interface](https://github.com/eth-infinitism/account-abstraction/tree/main/contracts/interfaces) design.
+ Review
- [x] Continuing to create and revise the PowerPoint presentation.supplemented the content of the PowerPoint presentation, including:
- the essence of the account abstraction problem
- its historical development
- the security mechanisms of ERC4337
- The impact of ERC4337 on the mainnet.
- the compatibility analysis between ERC4337 and Scroll.
### 06/06
+ Research
- [x] Revisited [ERC4337](https://eips.ethereum.org/EIPS/eip-4337) in conjunction with the [code](https://github.com/eth-infinitism/account-abstraction/tree/main/contracts) and corrected a few previously overlooked points.
+ Review
- [x] Preparing the review content and completing the review with Ye regarding ERC4337. The content includes:
- Existing issues with Ethereum accounts;
- The essence of the problem;
- Account abstraction;
- The development history of account abstraction;
- Inspiration from the development history;
- ERC 4337 Overview;
- Execution process analysis;
- Security mechanisms;
- Impact of account abstraction on the mainnet;
- Compatibility analysis between ERC4337 and Scroll;
- Choice of Scroll for implementing account abstraction;
- One possible design.
### 06/07
+ Research
- [x] Revised the recent plans based on the feedback from the review:
1. Refine the principles of [ERC4337](https://eips.ethereum.org/EIPS/eip-4337) and create a clearer note.
2. Conduct an in-depth analysis of the existing native account abstraction solutions at a low level, compare them with ERC4337, and summarize their advantages and disadvantages.
3. Conduct a thorough analysis of the principles of existing AA wallets and their differences from each other.
4. Summarize the challenges currently faced by various account abstraction solutions.
- [x] Modified the language of the diagrams to English and made modifications to some of the logic..
- [x] Established a daily reporting system and caught up on the missing reports for the previous 8 days.
- [ ] Translating the previous day's review PowerPoint presentation into more concise and clear notes (not finished yet).
## Week of 06/12 - 06/18
### 06/12
+ Research
- [x] Read relevant reports on Ethereum transaction structure.
+ [Ethereum Transaction](https://inevitableeth.com/home/ethereum/blockchain/transaction)
+ level: **good to know.**
+ [EIP-2718:Typed Transaction Envelope](https://eips.ethereum.org/EIPS/eip-2718)
+ level: **good to know.**
+ [EIP-1559: Fee market change for ETH 1.0 chain](https://eips.ethereum.org/EIPS/eip-1559)
+ level: **good to know.**
- [x] Read [EIP-2938](https://eips.ethereum.org/EIPS/eip-2938) and write down a logical summary note [here](https://pricey-basin-89e.notion.site/EIP-2938-7bfbf4f0eaeb46c29dbda6bb62bc82a9). The following components have been completed: Consensus Changes, Execution Flow, Tenant Model, and Security.
- [x] Read the relevant reports on EIP-2938.
+ [EIP-2938 Implementation](https://github.com/quilt/go-ethereum/tree/account-abstraction)
+ level: **good to know.**
+ [ Security Considerations](https://ethresear.ch/t/dos-vectors-in-account-abstraction-aa-or-validation-generalization-a-case-study-in-geth/7937)
+ level: :+1::+1:**should read.**
+ [Implementing account abstraction as part of eth1.x](https://ethereum-magicians.org/t/implementing-account-abstraction-as-part-of-eth1-x/4020)
+ level: :+1:**worth reading.**
### 06/13
+ Research
- [x] Read the relevant reports on EIP-2938.
+ [EIP-2938 Account Abstraction Explained](https://hackmd.io/@SamWilsn/ryhxoGp4D)
+ level: :+1:**worth reading.**
+ [Account Abstraction Beyond EIP-2938](https://hackmd.io/@SamWilsn/S1UQDOzBv)
+ level: :+1:**worth reading.**
+ Discussed some improvement proposals beyond the EIP-2938 proposal.
- [x] Read discussions on account abstraction history, as the related explanations within EIP-2938 are not detailed enough. Expect to find more detailed explanations from relevant historical EIPs.
+ [A recap of where we are at on account abstraction](https://ethresear.ch/t/a-recap-of-where-we-are-at-on-account-abstraction/1721)
+ level: :+1:**worth reading.**
+ [Tradeoffs in Account Abstraction Proposals](https://ethresear.ch/t/tradeoffs-in-account-abstraction-proposals/263)
+ level: :+1:**worth reading.**
- [x] Supplement the note content, organize the overall logic, and create flowcharts and tenant model diagrams. [Check here](https://pricey-basin-89e.notion.site/EIP-2938-7bfbf4f0eaeb46c29dbda6bb62bc82a9).
- [ ] There are still some doubts regarding the discussion section, and it is required to review earlier specific proposals on account abstraction.
### 06/14
+ Research
- [x] Read the relevant reports on EIP-2938.
+ [Account Abstraction Link Tree](https://hackmd.io/enMUrZSzQTaxyQmGGaMPJA)
+ level: :+1::+1::+1:**must read.**
+ A rough overview of the significant contributions made to the account abstraction theme over the years.
- [x] Read the specific implementation documentation of account abstraction and the corresponding test analysis reports.
+ [Account Abstraction, Stateless Mining Eth1.x/Eth 2 Implementation, Rationale Document](https://hackmd.io/y7uhNbeuSziYn1bbSXt4ww?view)
+ level: **good to know.**
+ [DoS Vectors in Account Abstraction (AA) or Validation Generalization, a Case Study in Geth](https://ethresear.ch/t/dos-vectors-in-account-abstraction-aa-or-validation-generalization-a-case-study-in-geth/7937)
+ level: :+1:**worth reading.**
+ [Account Abstraction Case Study: UTXOs on Ethereum](https://hackmd.io/@SamWilsn/B1c0ZdaGP#Bundling-amp-Multiple-Transactions-per-Block)
+ [related code](https://github.com/quilt/utxo-relayer/blob/master/contracts/Dropsafe.sol)
+ level: **good to know.**
+ The specific implementation of account abstraction, but it is outdated and differs from the original proposal.
- [x] Modified the relevant [note](https://pricey-basin-89e.notion.site/EIP-2938-7bfbf4f0eaeb46c29dbda6bb62bc82a9) based on the research findings.
### 06/14
+ Research
- [x] Finished [research on EIP 2938](https://pricey-basin-89e.notion.site/EIP-2938-7bfbf4f0eaeb46c29dbda6bb62bc82a9?pvs=4)
- [x] Finished a [workspace](https://pricey-basin-89e.notion.site/Ziheng-s-Workspace-fd6edae386304471bfa57fe3f7897489?pvs=4)
- [x] Read a series of discussions on the development history of account abstraction
+ [An Optimistic Generic Gas Market Executor for Phase 2](https://ethresear.ch/t/an-optimistic-generic-gas-market-executor-for-phase-2/5429)
+ level: **good to know.**
+ [On Abstraction](https://blog.ethereum.org/2015/07/05/on-abstraction)
+ Vitalik's article on the development of account abstraction in 2015
+ level: **good to know.**
+ [Spending gas from contract's balance](https://github.com/ethereum/EIPs/issues/61)
+ PAYGAS opcode
+ level: :+1:worth reading.
### 06/16
+ Research
- [x] Read an article written by Vitalik on the topic of cross-chain wallet interaction in the context of account abstraction.
- finished a detailed note [here](https://pricey-basin-89e.notion.site/Cross-L2-reading-by-wallets-7ba8845f06c54ea5b16ce54957ec140e)
- finished a feedback [here](https://pricey-basin-89e.notion.site/Feedback-9f1f567317a947b687ff66e26e668025)
- [Deeper dive on cross-L2 reading for wallets](https://notes.ethereum.org/@vbuterin/deeper_dive_on_cross_L2_reading_for_wallets)
+ level: :+1::+1:**should read.**
+ the original article
- [x] Conducted some additional reading
- [Describes the principles of the aggregator in ERC-4337](https://www.stackup.sh/blog/understanding-aggregators-in-erc-4337)
+ level: :+1:**worth reading.**
+ describes the working principle of the aggregator in ERC4337
- [BLSWallet: Fully Embrace 4337 (In Detail)](https://hackmd.io/@voltrevo/BJ0QBy3zi#BLSWallet-Fully-Embrace-4337-In-Detail)
+ level: :+1:**worth reading.**
+ A detailed implementation plan for the ERC-4337.
## Week of 06/19 - 06/25
### 06/19
+ Research
- [x] Finished an article [here](https://pricey-basin-89e.notion.site/A-Preliminary-Exploration-of-AA-Scheme-Design-4905d025f55b4f6dbd9a4d0f7838a870?pvs=4).
- [x] Completed discussions on EIP-2938 and previous account abstraction proposals [here](https://pricey-basin-89e.notion.site/Account-Abstraction-48ab8e1a775b4f5abd39b78c32b557a7?pvs=4).
- [x] Read historical Discussions on Account Abstraction.
- [Account abstraction, miner data and auto-updating witnesses](https://ethresear.ch/t/account-abstraction-miner-data-and-auto-updating-witnesses/332)
+ level: **good to know.**
- [Layer 2 gas payment abstraction](https://ethresear.ch/t/layer-2-gas-payment-abstraction/4513)
+ level: :+1:**worth reading.**
+ A Specific Gas Abstraction Scheme and Relevant Discussions.
- [A new account type in abstraction](https://ethresear.ch/t/a-new-account-type-in-abstraction/1379)
+ level: **good to know.**
+ A Bit Outdated...
- [Application-layer account abstraction](https://ethresear.ch/t/application-layer-account-abstraction/1734)
+ level: **good to know.**
### 06/20
+ Research
- [x] Research on AA Wallet-related Projects.
- [The History and Future of Account Abstraction](https://medium.com/nethermind-eth/the-history-and-future-of-account-abstraction-10cb097ebdc8)
+ level: **good to know.**
+ don't agree with some details
- [How can a Safe hold asset on multiple chains?](https://forum.safe.global/t/how-can-a-safe-hold-asset-on-multiple-chains/2242)
+ level: :+1::+1:**should read.**
+ The earliest discussions about the uniform behavior of multi-chain smart contract wallets.
- [x] Discussed the necessity of the keystore solution and the feasibility of [my ideas](https://www.notion.so/Feedback-9f1f567317a947b687ff66e26e668025) with Suneal from Soul Wallet.
- There are two issues regarding the ideas I proposed:
+ What to do if a user loses their account? One solution is to set a default guardian for the user during the account creation process, but this introduces centralization factors.
+ If the wallet software uses the same key to manage all the chains: a more significant concern is that in order to ensure that the newly created account address is consistent with the existing addresses(use Create2), it would require replaying the actions performed on the old address (such as changing keys, setting guardians, etc.) on the new address.
+ By using a keystore, we can avoid this issue because: We can deploy the wallet by specifying the KeyStore's storage slot. In this case, even if the key is changed, users can retrieve the latest key when deploying a new wallet.
### 06/21
+ Research
- [x] Studied Vitalik's latest post,This post serves as a supplement and expansion to the [previous draft](https://notes.ethereum.org/@vbuterin/deeper_dive_on_cross_L2_reading_for_wallets).
- [Deeper dive on cross-L2 reading for wallets and other use cases](https://vitalik.ca/general/2023/06/20/deeperdive.html).
+ level: :+1::+1:**should read.**
+ The post has updated some content compared to the previous draft, including:
+ An analysis has been added on utilizing Verkle proofs to implement cross-chain proof
+ The importance and detailed process of L2 directly reading and recording L1 state root have been emphasized
- [x] Studied the [source code](https://github.com/proofofsoulprotocol/soul-wallet-contract) of the Soul Wallet project
- [Anonymous guardian with create2](https://github.com/proofofsoulprotocol/soul-wallet-contract/blob/main/doc/anonymous_guardian.md)
+ level: :+1:**worth reading.**
- The design of guardians was emphasized, and it was described that the [guardians in Soul Wallet](https://github.com/proofofsoulprotocol/soul-wallet-contract/blob/main/doc/images/recovery_diagram.png) are private, with the multi-signature contract for guardians being deployed only during social recovery.
- [Contract architecture]()
+ level: **good to know.**
- [x] Created some diagrams to illustrate my understanding of multi-chain account abstraction [here](https://pricey-basin-89e.notion.site/Account-Abstraction-48ab8e1a775b4f5abd39b78c32b557a7?pvs=4).
### 06/25
+ Research
- [x] Discussed with Suneal from Soul Wallet regarding the areas of agreement needed between the wallet and Layer2
- The outcome of the discussion was the need for L2 to provide an interface for directly reading the L1 state, and there may also be a need to transmit L2 information to L1
- [x] Discussed with Suneal regarding keystore-related issues and update the [note](https://pricey-basin-89e.notion.site/Account-Abstraction-48ab8e1a775b4f5abd39b78c32b557a7?pvs=4).
- The keystore and cross-chain proof are implemented by each wallet team individually.
- L2 only needs to focus on how to read the state root of L1 in this matter
- [x] Studied the work of AA Wallet and related infrastructure projects in the field of account abstraction.
- Studied the [keystore source code](https://github.com/proofofsoulprotocol/soul-wallet-contract/compare/v0.6.0.draft...davidinsuomi:soul-wallet-contract:v0.6.0.draft?diff=split) shared by Suneal, specifically designed for OP
- Studied the [documentation](https://docs.pimlico.io/docs) of Pimlico.
- Currently, their services include Paymaster and Bundler.
## Week of 06/26 - 07/02
### 06/26
+ Research
- [x] Studied the cross-chain message propagation in Optimism.
- [Communication Strategies](https://community.optimism.io/docs/developers/bridge/comm-strategies/#)
+ level: :+1:**worth reading.**
+ Illustrated Optimism's communication strategy from the perspectives of speed, cost, and trust assumptions.
- [Sending data between L1 and L2](https://community.optimism.io/docs/developers/bridge/messaging/#fees-for-l2-%E2%87%92-l1-transactions)
+ level: :+1:**worth reading.**
+ Explained the methods, speed, and cost of message communication between Optimism and L1, but did not provide detailed information on the technical implementation of these methods.
- [RFP: Remote Static Call Proof of Concept](https://github.com/ethereum-optimism/ecosystem-contributions/issues/76)
+ level: **good to know.**
- [x] Research on how L2, apart from Op, can access the state of L1.
- [StarkNet Account Abstraction Model](https://community.starknet.io/t/starknet-account-abstraction-model-part-1/781)
+ level: :+1:**worth reading.**
+ Starknet itself has only one type of account model, which is the contract account. The abstract method is similar to an ERC-4337 without the Bundler.
- [Polygon Account Abstraction](https://wiki.polygon.technology/docs/category/account-abstraction)
+ level: **good to know.**
- [ZkSync Account abstraction support](https://era.zksync.io/docs/reference/concepts/aa.html)
+ level: :+1:**worth reading.**
+ ZkSync has implemented its own account abstraction mechanism, which is achieved at the consensus layer.
+ To be continued.
### 06/27
+ Research
- [x] Studied the implementation approach of [zkSync's account abstraction](https://era.zksync.io/docs/reference/concepts/aa.html) and have completed a [summary](https://pricey-basin-89e.notion.site/Account-abstraction-in-zkSync-4dbaf301fc2b4d2795b3490d1c095ba0?pvs=4).
- zkSync has adopted a native implementation approach that aligns with the principles of EIP-2938 and ERC-4337.
- [x] Studied the implementation methods for reading L1 state in zkSync.
- It is similar to the implementation in OP, and there is currently no need to design new reading methods specifically for multi-chain AA.
- [x] Studied the implementation methods for reading L1 state in Polygon.
- The underlying principles are similar to OP and zkSync.