Tác giả: Alfred, nhà phát triển imToken Labs
Từ ngày 8 đến ngày 11 tháng 7 năm 2024, Hội nghị Cộng đồng Ethereum (EthCC) được tổ chức tại Brussels, Bỉ. Đây là sự kiện Ethereum thường niên lớn nhất ở Châu Âu, tập trung vào công nghệ và cộng đồng.
Tại Hội nghị Cộng đồng Ethereum (EthCC 7) này, hơn 350 nhà lãnh đạo quan điểm hoạt động trong ngành blockchain đã phát biểu. ImToken Labs Alfred đã được mời tham gia và phát biểu tại hội nghị với chủ đề "Tiết lộ Tương lai: Phân tích Trừu tượng về Đa- Bài phát biểu về Tài khoản Chuỗi" ".
Tóm tắt nhanh bài phát biểu:
Trừu tượng hóa tài khoản (AA) chủ yếu bao gồm hai điểm chính: trừu tượng hóa chữ ký và trừu tượng hóa thanh toán. Việc trừu tượng hóa chữ ký cho phép người dùng chọn bất kỳ cơ chế xác minh nào họ thích và việc trừu tượng hóa thanh toán cho phép thực hiện nhiều tùy chọn thanh toán giao dịch. Tính linh hoạt này mang lại trải nghiệm người dùng an toàn hơn và tốt hơn.
Trong ERC-4337 và AA gốc, chức năng điểm vào trong giai đoạn "xác minh" là cố định, trong khi ở giai đoạn "thực thi", chỉ có điểm vào trong AA gốc là cố định. Những hạn chế của việc xác minh giao dịch và các bước thực hiện giao dịch có những đặc điểm và hạn chế riêng trong các cách triển khai khác nhau.
Có hai điểm khác biệt chính khi triển khai ERC-4337 trên chuỗi tương thích EVM: sự khác biệt về giao thức trong thiết kế Tổng hợp và sự khác biệt trong cách tính địa chỉ, dẫn đến các chi tiết phát triển khó nhận thấy khi triển khai ERC-4337 giữa L1 và L2.
Sau đây là toàn văn bài phát biểu:
Xin chào mọi người, tên tôi là Alfred và tôi hiện là nhà phát triển blockchain tại imToken Labs. Hôm nay, tôi sẽ giới thiệu với các bạn khái niệm về ERC-4337 và Native AA, thảo luận về sự khác biệt giữa chúng và tập trung phân tích sự khác biệt chính giữa tiêu chuẩn 4337 của L1 và L2.
Giới thiệu về trừu tượng hóa tài khoản
1. Trừu tượng hóa tài khoản là gì?
Trừu tượng hóa tài khoản (AA) chủ yếu bao gồm hai điểm chính: trừu tượng hóa chữ ký và trừu tượng hóa thanh toán.
Trừu tượng hóa chữ ký: Người dùng có thể chọn bất kỳ cơ chế xác minh nào họ thích, không chỉ giới hạn ở một số thuật toán chữ ký số nhất định (chẳng hạn như ECDSA).
Trừu tượng hóa thanh toán: Người dùng có thể sử dụng nhiều tùy chọn thanh toán giao dịch khác nhau, chẳng hạn như thanh toán bằng tài sản ERC-20 thay vì tài sản gốc hoặc nhờ bên thứ ba tài trợ cho giao dịch.
Tính linh hoạt này mang lại trải nghiệm người dùng an toàn hơn và tốt hơn. Mục tiêu của việc trừu tượng hóa tài khoản là đạt được hai điểm chính này theo nhiều cách khác nhau.
2. ERC-4337 là gì
Hiện tại, có một số hạn chế đối với tài khoản thuộc sở hữu bên ngoài (EOA) trong giao thức Ethereum, chẳng hạn như phương thức chữ ký cố định và thiết kế thanh toán. ERC-4337 giải quyết những vấn đề này bằng cách giới thiệu một cách tiếp cận linh hoạt hơn để quản lý tài khoản và xử lý giao dịch.
Cấu trúc userOp: Trong ERC-4337, người dùng gửi cấu trúc userOp tới Bundler. Bundler thu thập nhiều userOps và gửi chúng đến hợp đồng EntryPoint bằng cách gọi hàm handOps.
Hợp đồng EntryPoint: Hợp đồng này xử lý các giao dịch giống như một hệ điều hành. Các chức năng chính của nó bao gồm:
Gọi hàm xác thực trong hợp đồng tài khoản để đảm bảo rằng userOp được chủ tài khoản ủy quyền.
Tính phí.
Gọi hàm thực thi trong hợp đồng tài khoản để thực thi thao tác mục tiêu của userOp.
3. AA bản địa là gì?
Trong Ethereum, tài khoản được chia thành tài khoản EOA và tài khoản hợp đồng. Tuy nhiên, trong AA gốc, mỗi tài khoản là một hợp đồng và cơ chế xử lý giao dịch được nhúng trực tiếp vào giao thức blockchain.
Thiết kế AA trong mỗi mạng blockchain:
Tóm tắt tài khoản ERC-4337: Ethereum, Arbitrum, Optimism, Base, Linea, Scroll, Polygon PoS
Sự trừu tượng hóa tài khoản gốc tuân theo ERC-4337: Kỷ nguyên StarkNet & zkSync
Trừu tượng hóa tài khoản gốc với quyền riêng tư theo thiết kế: Aztec
Nếu bạn quan tâm đến AA gốc của Aztec hoặc EIP-3074, EIP-7702, hôm nay chúng tôi sẽ tập trung vào AA gốc sau ERC-4337. Để biết thông tin chi tiết, vui lòng tham khảo bài viết tôi đã viết, được liệt kê ở cuối bài viết.
Sự khác biệt giữa ERC-4337 và AA gốc
1. Vai trò của hệ điều hành
AA OS cần trả lời các câu hỏi sau:
Ai quyết định giá xăng?
Ai quyết định thứ tự giao dịch? Bể nhớ ở đâu?
Ai kích hoạt chức năng điểm vào?
Điều gì quyết định luồng xử lý giao dịch?
Trong ERC-4337, các vai trò này được thực hiện một cách cộng tác thông qua Hợp đồng Bundler và EntryPoint.
Trong AA gốc, người dùng gửi userOps của họ tới nhà điều hành/trình sắp xếp trình tự của máy chủ chính thức thay vì Hợp đồng Bundler và EntryPoint.
Trong StarkNet, Sequencer xử lý tất cả các tác vụ này.
Trong zkSync, điểm khác biệt chính giữa Era và các triển khai AA khác là Người vận hành cần làm việc với bộ tải khởi động (hợp đồng hệ thống). Bootloader mở một khối mới, xác định các tham số của nó (bao gồm các tham số khối và các tham số Gas khác) và nhận các giao dịch từ Nhà điều hành để xác minh.
2. Giao diện hợp đồng
Do tồn tại ba bước nên giao diện hợp đồng tài khoản tương tự nhau trong các cách triển khai khác nhau. Các chức năng điểm nhập này chỉ có thể được gọi bởi AA OS:
ERC-4337: Xác minh hành động của người dùng
zkSync: xác minh giao dịch, thanh toán giao dịch và thực hiện giao dịch
StarkNet：thực hiện、xác thực、xác thực_khai báo、xác thực_triển khai
Trong ERC-4337 và AA gốc, chức năng điểm vào trong giai đoạn "xác minh" là cố định, trong khi ở giai đoạn "thực thi", chỉ có điểm vào trong AA gốc là cố định.
3. Hạn chế của các bước xác minh
Vì không có giới hạn chi phí để xác thực một giao dịch (về cơ bản, xác thực một giao dịch đang gọi một hàm xem), kẻ tấn công có thể thực hiện một cuộc tấn công DoS trên vùng bộ nhớ, do đó phá vỡ bộ đóng gói (EIP-4337) hoặc toán tử/bộ sắp xếp (gốc) AA).
EIP-4337 xác định những mã opcode nào bị cấm và cách hạn chế quyền truy cập bộ nhớ. Kỷ nguyên zkSync giúp giảm bớt một số cách sử dụng OpCode:
Logic hợp đồng chỉ có thể truy cập vào khe lưu trữ của chính nó. Nếu địa chỉ của hợp đồng tài khoản là địa chỉ A thì có thể truy cập:
Khe lưu trữ thuộc địa chỉ A
Một khe lưu trữ thuộc về bất kỳ địa chỉ A nào khác
Khe lưu trữ keccak256 (A || Ví dụ: số dư tài sản trong hợp đồng ERC-20.
Logic hợp đồng không thể truy cập các biến toàn cục như số khối. StarkNet cũng không cho phép các cuộc gọi hợp đồng bên ngoài.
4. Hạn chế về các bước thực hiện
Trong zkSync, việc thực hiện lệnh gọi hệ thống yêu cầu xác nhận sự hiện diện của cờ hệ thống. Ví dụ: cách duy nhất để tăng nonce là tương tác với NonceHolder, trong khi việc triển khai hợp đồng yêu cầu phải tương tác với ContractDeployer. Cờ hệ thống đảm bảo rằng nhà phát triển tài khoản có chủ ý tương tác với hợp đồng hệ thống.
Trong ERC-4337 và StarkNet, không có hạn chế đặc biệt nào đối với giai đoạn thực thi.
5. Số ngẫu nhiên
Trong ERC-4337, điểm vào nonce được thiết kế để phân biệt giữa các giá trị khóa 192 bit và giá trị nonce 64 bit.
Trong zkSync, hợp đồng hệ thống NonceHolder quản lý số nonce và đảm bảo mức tăng nghiêm ngặt, nghĩa là số nonce được tăng thêm 1.
Trong StarkNet, nonces cũng tăng lên một cách nghiêm ngặt, nhưng không có nonce trừu tượng nào được quản lý bởi một hợp đồng cụ thể.
6. Triển khai bằng giao dịch đầu tiên
ERC-4337 Bao gồm trường initcode trong cấu trúc userOp để triển khai người gửi (hợp đồng tài khoản) trong userOp đầu tiên của nó.
Trong StarkNet và zkSync, người dùng phải gửi giao dịch đầu tiên đến nhà điều hành/người sắp xếp chuỗi để triển khai hợp đồng tài khoản.
7. Thiết kế đặc biệt trong zkSync
Nếu bạn chuyển ETH trực tiếp từ Ethereum EOA sang zkSync mà không triển khai hợp đồng tài khoản tùy chỉnh, bạn sẽ nhận được một tài khoản mặc định có cùng địa chỉ. Tài khoản hoạt động giống như Ethereum EOA và cũng được kiểm soát bởi khóa riêng của Ethereum EOA tương ứng.
Loại tài khoản này là phiên bản Không thay vì phiên bản1. Bạn không thể gọi hàm DefaultAccount vì nó không triển khai bất kỳ mã nào trong không gian kernel.
Sự khác biệt giữa 4337 của L1 và 4337 của L2
Có hai điểm khác biệt chính trong việc triển khai ERC-4337 trên chuỗi tương thích EVM: sự khác biệt về giao thức và sự khác biệt về địa chỉ.
1. Sự khác biệt trong thỏa thuận
Trong thiết kế Rollup, L2 cần tải dữ liệu lên L1 để bảo mật và giải quyết. Trong bối cảnh ERC-4337, các khoản phí liên quan đến quá trình tải lên này, chẳng hạn như phí bảo mật L1 và phí blob, phải được bao gồm trong khí xác thực trước. Việc xác định phí tải lên thích hợp trong khí xác thực trước là một thách thức đáng kể.
2. Địa chỉ khác biệt
Mã hóa địa chỉ trong chức năng tạo của zkSync ERA khác với các bản tổng hợp Ethereum và OP. Ngoài ra, StarkNet sử dụng hàm băm duy nhất để tính toán địa chỉ. Trong bối cảnh ERC-4337 trên các chuỗi tương thích với EVM, chúng tôi thường giả định rằng các phép tính địa chỉ nhất quán trên các chuỗi. Tuy nhiên, có một chi tiết khó nhận thấy có thể khiến địa chỉ hợp đồng tài khoản khác nhau giữa Ethereum và việc triển khai ERC-4337 trong L2.
Vấn đề chính là thêm các mã opcode mới vào hard fork. Ví dụ: nếu chuỗi L2 không hỗ trợ hard fork Thượng Hải và phiên bản EVM không được chỉ định tại thời điểm biên dịch, việc giới thiệu push0 sẽ khiến mã byte thay đổi, ngay cả khi mã Solidity giống nhau.
Phần kết luận
Dưới đây là một số tài nguyên để bạn tìm hiểu thêm về việc trừu tượng hóa tài khoản. Vui lòng liên hệ với tôi và nếu bạn có bất kỳ câu hỏi nào, bạn có thể tìm thấy tôi trên Twitter (@murmurlu).
"Giới thiệu về Trừu tượng tài khoản Aztec", vui lòng kiểm tra:
https://medium.com/@ChiHaoLu/introduction-of-aztec-account-abstraction-98535c9edf2e
"Giới thiệu tóm tắt tài khoản StarkNet", vui lòng kiểm tra:
https://medium.com/taipei-ethereum-meetup/introduction-of-starknet-account-abstraction-2c343b561d6e
"Giới thiệu về Trừu tượng tài khoản zkSync", vui lòng kiểm tra:
https://medium.com/taipei-ethereum-meetup/zksync-%E4%B8%AD%E7%9A%84%E5%8E%9F%E7%94%9F-account-abstraction-%E4%BB% 8B%E7%B4%B9-bc7269f8893a
"Starknet và zkSync: Phân tích so sánh", vui lòng xem:
https://medium.com/nethermind-eth/starknet-and-zksync-a-comparative-analysis-d4648786256b
