Bài viết này chủ yếu giới thiệu sự phát triển và nội dung liên quan của tài khoản trừu tượng (AA, tài khoản trừu tượng) trong giải pháp Lớp 2 của zkSync. Trọng tâm sẽ là ba phần:
Hợp đồng tài khoản: loại tài khoản, điểm vào quan trọng và các điểm chính liên quan của hợp đồng tài khoản
Giao dịch: phương thức xác minh, phương thức thực hiện và quy trình giao dịch AA
Phí xử lý: phí giao dịch, Paymaster
Mục lục
lời nói đầu
Tổng quan ngắn gọn về hợp đồng zkSync AA
Mô hình phí và Paymaster trong kỷ nguyên zkSync
Tóm tắt và so sánh
Phần kết luận
lý lịch
Làm quen với ví hợp đồng thông minh và các tính năng chung của nó
Nhận tổng quan về cách hoạt động của giao dịch Ethereum
Tìm hiểu chung về chế độ hoạt động của EIP-4337
Hiểu biết chung về chế độ hoạt động của ZK (tính hợp lệ) Rollup
Nhìn nhanh vào zkSync
Ở đây, để thuận tiện cho việc đọc, không cần thiết phải hiểu sâu về zkSync mà hãy xem lại ngắn gọn những thông tin cơ bản về zkSync. Có hai phiên bản chính của zkSync, phiên bản 1.0 (zkSync Lite) và phiên bản 2.0 (zkSync Era).
zkSync phiên bản 1.0 chỉ hỗ trợ EOA (tài khoản bên ngoài) và không hỗ trợ hợp đồng thông minh (chỉ hỗ trợ chuyển và trao đổi mã thông báo), trong khi zkSync 2.0, cụ thể là zkSync Era, thuộc về AA gốc (tài khoản trừu tượng) (tất cả các loại tài khoản đều là hợp đồng, không có EOA , đây là điểm khác biệt giữa EOA và tài khoản hợp đồng trong Ethereum), đồng thời tương thích với EVM (Máy ảo Ethereum) và hỗ trợ phát triển các hợp đồng thông minh sử dụng Rust, Yul, Vyper, Solidity, v.v.
ZkSync được đề cập bên dưới đề cập đến zkSync 2.0, cụ thể là Kỷ nguyên zkSync, trừ khi có quy định khác.
Trong Kỷ nguyên zkSync, có nhiều hợp đồng, có thể hiểu là chúng triển khai một số chức năng hệ điều hành quan trọng của zkSync trong hợp đồng thông minh. Các hợp đồng này là các hợp đồng được biên dịch trước chưa bao giờ được triển khai (chạy trực tiếp trong nút), nhưng chúng đều có địa chỉ chính thức.
Khi triển khai giao thức AA, zkSync sẽ thực hiện các hoạt động và phán đoán logic thông qua một số hợp đồng. Ví dụ: khi xác minh nonce, nó được đánh giá bởi NonceHolder, trong khi việc thực hiện cơ chế tài khoản trừu tượng và thu phí được đánh giá bởi bootloader. Sau đây sẽ giới thiệu chúng từng cái một.
**Tóm tắt tài khoản **
Khái niệm cốt lõi về trừu tượng hóa tài khoản có thể được tóm tắt thành hai điểm chính: trừu tượng hóa chữ ký và trừu tượng hóa thanh toán.
Mục tiêu của việc trừu tượng hóa chữ ký là cho phép các hợp đồng tài khoản khác nhau sử dụng các chương trình xác minh khác nhau. Điều này có nghĩa là người dùng không bị giới hạn ở thuật toán chữ ký số mà chỉ có thể sử dụng một đường cong cụ thể mà có thể chọn bất kỳ cơ chế xác minh nào họ thích.
Việc trừu tượng hóa thanh toán nhằm mục đích cung cấp cho người dùng nhiều tùy chọn thanh toán giao dịch khác nhau. Ví dụ: thanh toán có thể được thực hiện bằng cách sử dụng mã thông báo ERC-20 thay vì mã thông báo gốc hoặc giao dịch có thể được tài trợ bởi bên thứ ba hoặc thậm chí các mô hình thanh toán đặc biệt khác.
Các tài khoản trong zkSync 2.0 có thể bắt đầu các giao dịch như EOA nhưng cũng có thể sử dụng khả năng lập trình của nó để triển khai logic tùy ý, chẳng hạn như tài khoản hợp đồng. Đây là cái mà chúng tôi gọi là Trừu tượng hóa tài khoản, kết hợp các ưu điểm của hai loại tài khoản trong Ethereum để giúp trải nghiệm sử dụng tài khoản AA linh hoạt hơn, từ đó đạt được hai mục tiêu trên: trừu tượng hóa chữ ký và trừu tượng hóa thanh toán.
Cơ chế AA trong kỷ nguyên zkSync
Trong Kỷ nguyên zkSync, vai trò quan trọng nhất của zkSync AA là bộ nạp khởi động, là Hợp đồng, chủ yếu được sử dụng để xử lý các giao dịch và thực thi cơ chế AA, tương ứng với Hợp đồng EntryPoint của EIP-4337. Người dùng không thể gọi bootloader (nó chỉ có thể được kích hoạt bởi Người vận hành) và nó chưa bao giờ được triển khai (chạy trực tiếp trên nút), nhưng nó có địa chỉ chính thức (có thể được sử dụng để nhận thanh toán).
Toán tử có vai trò quan trọng trong ZK Rollup. Nó là một Máy chủ ngoại tuyến tập trung. Tương tự như Sequencer mà bạn có thể đã thấy, nó chịu trách nhiệm kích hoạt các hợp đồng như bootloader từ bên ngoài.
Các giao thức trừu tượng hóa tài khoản gốc (chẳng hạn như StarkNet, zkSync) về cơ bản được thiết kế có tham chiếu đến EIP-4337. Khi triển khai zkSync, người dùng sẽ gửi giao dịch đến Nhà điều hành và Nhà điều hành sẽ gửi giao dịch đến bộ nạp khởi động và bắt đầu một loạt xử lý.
Từ quan điểm khối:
Khi bootloader nhận đầu vào từ Operator, bootloader trước tiên sẽ xác định một số biến môi trường cho khối (chẳng hạn như giá gas, số khối, dấu thời gian của khối, v.v.). Sau đó, bootloader sẽ đọc tuần tự danh sách giao dịch, trước tiên hãy truy vấn xem hợp đồng tài khoản có đồng ý với giao dịch hay không (nghĩa là gọi hàm xác thực trong cơ chế AA), sau đó đưa chúng vào khối.
Sau khi mỗi giao dịch được xác minh, Người vận hành sẽ xác minh xem khối có đủ lớn để gửi đến người xác minh hay không (hoặc liệu nó có hết thời gian chờ hay không). Nếu nó đủ lớn hoặc hết thời gian, Người vận hành sẽ đóng khối, dừng thêm giao dịch mới vào bộ nạp khởi động và hoàn tất việc thực hiện giao dịch.
Từ góc độ giao dịch, khi Người vận hành kích hoạt bootloader, bootloader sẽ xử lý tuần tự từng giao dịch:
Xác nhận xem nonce tương ứng với địa chỉ hợp đồng của tài khoản người dùng có hợp pháp hay không
Gọi chức năng xác thực trên hợp đồng tài khoản người dùng để xác minh
Sau khi quá trình xác minh được thông qua, hợp đồng tài khoản sẽ chuyển phí gas đến địa chỉ của bootloader (hoặc thông qua Paymaster, sẽ được giới thiệu sau) và bootloader sẽ kiểm tra xem nó đã nhận đủ tiền hay chưa.
Gọi hàm ute trên hợp đồng tài khoản người dùng để thực hiện giao dịch.
Ba bước đầu tiên ở trên tương ứng với vòng xác minh (Vòng xác minh) của EIP-4337 và bước thứ tư tương ứng với vòng thực thi (Vòng lặp ution) của EIP-4337.
Đây chủ yếu là phần giới thiệu tổng quan, chi tiết và vai trò của từng bước sẽ được trình bày chi tiết từng bước một trong phần mô tả chi tiết sau.
Tổng quan nhanh về hợp đồng tài khoản trừu tượng zkSync
Không một lần
Số nonce của tài khoản zkSync được ghi lại trong hợp đồng hệ thống có tên NonceHolder, hợp đồng này ghi nhớ xem mỗi cặp (account_address, nonce) có được sử dụng bằng cách ánh xạ (ánh xạ) để đánh giá xem nonce đó có hợp pháp hay không.
Theo như trên, bước đầu tiên sau khi Operator kích hoạt bootloader là kiểm tra nonce. Do đó, trước khi mỗi giao dịch bắt đầu, NonceHolder sẽ được sử dụng để xác nhận xem tập hợp nonces hiện đang sử dụng có hợp pháp hay không (hiện chỉ kiểm tra xem chúng đã được sử dụng chưa). Nếu nonce hợp pháp sẽ bước vào giai đoạn xác minh (Verification Phase), lúc này nonce sẽ được đánh dấu là đã sử dụng; nếu không hợp pháp thì giao dịch (xác minh) sẽ thất bại.
Các điểm quan trọng về nonce hiện tại của zkSync:
Mặc dù hiện tại người dùng có thể gửi nhiều giao dịch có số non khác nhau tới tài khoản để thực hiện cùng lúc, nhưng do zkSync không hỗ trợ xử lý song song nên các giao dịch có số non khác nhau vẫn sẽ được xử lý tuần tự.
Về lý thuyết, người dùng có thể sử dụng bất kỳ số nguyên khác 0 256 bit nào làm nonce, nhưng zkSync vẫn khuyến nghị sử dụng tăngNonceIfEquals như một cách để quản lý nonce để đảm bảo rằng nó được tăng theo thứ tự (hiện tại cơ chế AA của zkSync chỉ xác nhận nonce không được sử dụng, nhưng cơ chế chính thức tài liệu chỉ ra rằng việc tăng tuần tự có thể được yêu cầu trong tương lai).
Hợp đồng tài khoản
Hợp đồng tài khoản trong zkSync có bốn điểm vào cần thiết sau (Điểm vào), đó là:
validTransaction: Được gọi trong giai đoạn xác minh để xác nhận xem hoạt động có được chủ tài khoản ủy quyền hay không, nơi người dùng có thể tùy chỉnh logic xác minh của riêng họ (chẳng hạn như các thuật toán chữ ký khác nhau, đa chữ ký, v.v.).
payForTransaction: Khi phí giao dịch được tài khoản này thanh toán (thay vì sử dụng paymaster), nhà điều hành sẽ gọi hàm này để thanh toán ít nhất tx.gasprice * tx.gaslimit của ETH vào địa chỉ bootloader.
prepareForPaymaster: Khi Paymaster thanh toán phí giao dịch, nhà điều hành sẽ gọi chức năng này để hoàn tất công việc chuẩn bị trước khi tương tác với paymaster. Ví dụ do zkSync cung cấp là mã thông báo ERC-20 đã được Paymaster phê duyệt.
uteTransaction: Sau khi vượt qua giai đoạn xác minh thành công và phí giao dịch được tính thành công, chức năng này sẽ được sử dụng để thực hiện các hoạt động mà người dùng muốn đạt được (chẳng hạn như tương tác với hợp đồng, chuyển tiền, v.v.).
Giới thiệu về Paymaster, số phí xử lý (tx.gasprice * tx.gaslimit), v.v. sẽ được giải thích trong các chương tiếp theo.
Ngoài ra còn có một chức năng bảo hiểm không cần thiết uteTransactionFromOutside trong tài khoản của zkSync. Tiền có thể được rút về L1 bằng cách sử dụng "cơ chế thoát" khi không thể thực hiện các hoạt động (chẳng hạn như khi trình tạo chuỗi không phản hồi hoặc zkSync được phát hiện là rủi ro pháp lý). Phần này ít liên quan đến giao thức AA nên sẽ không được mô tả chi tiết ở đây, những ai quan tâm có thể kiểm tra các tài liệu chính thức và thông số kỹ thuật của zkSync.
Những điểm chính và hạn chế của chức năng xác thực
Trong hàm validTransaction, nhiều logic tùy chỉnh khác nhau có thể được triển khai. Ví dụ: nếu tài khoản đã triển khai tiêu chuẩn EIP-1271, thì logic xác minh trong EIP-1271 có thể được áp dụng trực tiếp cho validTransaction hoặc tham khảo hợp đồng tài khoản nhiều chữ ký triển khai trong tài liệu chính thức của zkSync.
Đồng thời, để tránh các mối đe dọa DoS trong Giai đoạn xác minh của EIP-4337, có một số hạn chế (không thể liên quan đến mã hoạt động bên ngoài và độ sâu giới hạn, v.v.) và có các hạn chế tương tự trong zkSync, chẳng hạn:
1. Logic hợp đồng chỉ có thể chạm vào vị trí riêng của nó (nếu địa chỉ của hợp đồng tài khoản là A):
slot thuộc địa chỉ A
khe A tại bất kỳ địa chỉ nào khác
Khe keccak256(A||X) của bất kỳ địa chỉ nào khác, có thể sử dụng trực tiếp địa chỉ làm khóa của ánh xạ (chẳng hạn như ánh xạ (địa chỉ=>giá trị)), cũng tương đương với việc cho phép truy cập vào khe keccak256( A||X), để đạt được sự mở rộng. Ví dụ: số dư mã thông báo trên ERC-20.
2. Logic hợp đồng không được sử dụng các biến toàn cục, chẳng hạn như block.number
Những điểm chính và hạn chế của việc thực thi chức năng
Điều cần lưu ý trong hàm uteTransaction là nếu bạn muốn thực hiện lệnh gọi hệ thống (Gọi), bạn cần đảm bảo rằng nó có cờ is. Bởi vì các hợp đồng hệ thống này có tác động lớn đến hệ thống tài khoản. Ví dụ: cách duy nhất để tăng nonce là tương tác với NonceHolder. Để triển khai hợp đồng, bạn phải tương tác với ContractDeployer. Sử dụng cờ is có thể đảm bảo rằng các nhà phát triển tài khoản tương tác một cách có ý thức với các hợp đồng hệ thống.
Tuy nhiên, bạn nên sử dụng thư viện ContractsCaller do zkSync cung cấp để tránh tự mình xử lý cờ is và sử dụng CallWithPropagatedRevert để hoàn thành cuộc gọi hệ thống.
Mẫu mã ở trên liên quan đến việc tương tác với DEPLOYER__CONTRACT. Tình huống hợp đồng hệ thống phổ biến nhất mà các nhà phát triển tài khoản gặp phải là chúng ta muốn sử dụng tài khoản để triển khai hợp đồng, lúc này chúng ta phải tương tác với hợp đồng hệ thống ContractDeployer. Trong trường hợp này, nhà phát triển tài khoản cần liên lạc với hợp đồng ContractDeployer để đảm bảo rằng hợp đồng được triển khai thành công và thực hiện các hoạt động được yêu cầu.
Mô hình tính phí và Paymaster trong kỷ nguyên zkSync
Phí và giới hạn Gas
Mô hình tính phí của zkSync rất giống với Ethereum, token tính phí vẫn là ETH. Tuy nhiên, giống như các giải pháp Lớp 2 khác (chẳng hạn như Arbitrum, Optimism), zkSync cũng cần xem xét chi phí bổ sung khi xuất bản lên L1 (phí bảo mật) ngoài chi phí tính toán cơ bản và chi phí ghi. Do giá gas xuất dữ liệu lên L1 rất không ổn định nên Người vận hành zkSync xác định các tham số động sau khi mỗi khối được mở (bắt đầu ghi lại giao dịch):
gasPrice: giá gas tính bằng gwei, tức là tx.gasprice trong đối tượng giao dịch được đề cập ở trên
gasPerPubdata: Lượng gas cần thiết để xuất bản một byte dữ liệu trên Ethereum
Ngoài ra, không giống như EIP-4337, zkSync không cần xác định ba giới hạn gas: verifyGas, utionGas và preVerificationGas mà chỉ yêu cầu gasLimit để trang trải tất cả các chi phí trên, vì vậy người dùng cần đảm bảo rằng gasLimit đủ để trang trải Giai đoạn xác minh, giai đoạn sử dụng và tải dữ liệu lên Tất cả các chi phí như phí bảo mật cho L1. Chi phí phí này được bao gồm trong tx.gaslimit trong đối tượng giao dịch được đề cập ở trên.
Nhân hai (tx.gasprice * tx.gaslimit) để nhận phí giao dịch được trả cho bộ nạp khởi động.
Người trả lương
Paymaster chủ yếu trả ETH cho bộ nạp khởi động thay vì hợp đồng tài khoản của người dùng ở giai đoạn thanh toán phí giao dịch của người dùng. Người dùng có thể chọn các chế độ thanh toán và Paymaster khác nhau để thanh toán phí xử lý, chẳng hạn như (nhưng không giới hạn):
Thanh toán mã thông báo ERC-20 cho Paymaster trước khi giao dịch được bắt đầu hoặc sau khi giao dịch được thực hiện
Nạp tiền vào hợp đồng Paymaster bằng thẻ tín dụng
Paymaster sẽ tiếp tục thanh toán miễn phí một phần hoặc toàn bộ phí cho người dùng
Cách người dùng tương tác với Paymaster phụ thuộc vào các giao thức khác nhau, nó có thể được tập trung hoặc phi tập trung; có thể trước hoặc sau giao dịch; nó có thể sử dụng mã thông báo ERC-20 hoặc đấu thầu hợp pháp hoặc thậm chí miễn phí.
Hợp đồng Paymaster của zkSync chủ yếu bao gồm hai chức năng, đó là validAndPayForPaymasterTransaction (bắt buộc) và postTransaction (tùy chọn), cả hai chức năng này chỉ có thể được gọi bởi bộ nạp khởi động:
validAndPayForPaymasterTransaction là chức năng duy nhất phải được triển khai trong toàn bộ hợp đồng Paymaster. Khi nhà điều hành nhận được một giao dịch có tham số Paymaster, điều đó có nghĩa là phí xử lý không được thanh toán bởi hợp đồng tài khoản của người dùng mà bởi Paymaster. Tại thời điểm này, nhà điều hành sẽ gọi validAndPayForPaymasterTransaction để xác định xem Paymaster có sẵn sàng trả phí giao dịch hay không. Nếu Paymaster đồng ý, chức năng này sẽ gửi ít nhất tx.gasprice * tx.gaslimit ETH tới bộ nạp khởi động.
postTransaction là một chức năng tùy chọn, thường được sử dụng để hoàn tiền (trả lại gas chưa sử dụng cho người gửi). Tuy nhiên, zkSync hiện tại chưa hỗ trợ thao tác này.
Paymaster trong zkSync sẽ thực thi postTransaction sau khi postTransaction được triển khai, khác với EIP-4337. EIP-4337 sẽ không gọi postOp khi validPaymasterUserOp không trả về ngữ cảnh và ngược lại.
Ví dụ: dựa trên những điều trên, giờ đây người dùng muốn gửi một giao dịch mà phí xử lý do Paymaster thanh toán, quy trình như sau:
Sử dụng NonceHolder để xác nhận xem nonce có hợp pháp hay không
Gọi xác thựcTransaction trên Hợp đồng tài khoản của người dùng để xác minh rằng giao dịch được chủ tài khoản ủy quyền
Gọi prepareForPaymaster trên Hợp đồng tài khoản của người dùng, hợp đồng này có thể thực thi, chẳng hạn như phê duyệt một số lượng Mã thông báo ERC-20 nhất định cho Paymaster hoặc không làm gì cả
Gọi validationAndPayForPaymasterTransaction trên Hợp đồng Paymaster để xác nhận rằng Paymaster sẵn sàng thanh toán và tính phí xử lý, đồng thời Paymaster sẽ tính phí cho người dùng một số tiền nhất định ERC-20 (đã được phê duyệt trước đó)
Xác nhận rằng bộ nạp khởi động nhận được số tiền chính xác (ít nhất là tx.gasprice * tx.gaslimit) phí ETH
Gọi uteTransaction trên Hợp đồng tài khoản của người dùng để thực hiện giao dịch mà người dùng muốn
Nếu Hợp đồng Paymaster triển khai postTransaction và gas vẫn đủ (không có lỗi hết gas), thì thực hiện postTransaction
Ở bước cuối cùng, ngay cả khi postTransaction không thể được thực thi do lỗi hết gas, giao dịch AA này được coi là thành công nhưng hành động gọi postTransaction bị bỏ qua.
Nếu tìm hiểu sâu hơn về Paymaster của zkSync, bạn sẽ thấy rằng Quy tắc xác minh của nó hơi khác so với 4337 (zkSync Paymaster có thể bước lên bất kỳ vị trí hợp đồng nào khác) và cũng có nhiều loại khác nhau (chẳng hạn như dựa trên phê duyệt). để so sánh chi tiết, ai quan tâm có thể tham khảo các tài liệu chính thức hoặc cách thực hiện trước đây của tôi.
Tóm tắt & so sánh
Thông qua các phần giải thích trước đó, chúng ta đã biết được điểm đầu vào quan trọng của hợp đồng tài khoản, cũng như chức năng của chúng và các hạn chế liên quan. Đồng thời, chúng ta cũng đã tìm hiểu về chức năng của hợp đồng hệ thống. Tiếp theo, hãy tóm tắt quy trình giao dịch vận hành tự động (AA) trong zkSync từ khi xây dựng đến khi hoàn thành và tôi cũng sẽ cung cấp tài liệu tham khảo chi tiết hơn cho những ai muốn tìm hiểu thêm:
Người dùng sử dụng SDK hoặc ví cục bộ để xây dựng các đối tượng giao dịch (ví dụ: từ, đến, dữ liệu, giá trị, v.v.).
Người dùng ký giao dịch. Chữ ký ở đây không nhất thiết phải là định dạng EIP-712 truyền thống và chữ ký đường cong ECDSA. zkSync cũng hỗ trợ EIP-2718 và EIP-1559. Chìa khóa để chọn phương thức chữ ký và phương thức xác minh là xác minh thông qua chức năng xác minh trong hợp đồng tài khoản.
Gửi giao dịch đã ký cho nhà điều hành thông qua API RPC. Tại thời điểm này, giao dịch chuyển sang trạng thái chờ xử lý. Người vận hành chuyển giao dịch đến bộ nạp khởi động (gọi hàm processL2Tx trên hợp đồng bộ nạp khởi động) và bắt đầu một loạt quy trình giao thức AA.
Bootloader sẽ kiểm tra xem Nonce có hợp pháp hay không và sử dụng NonceHolder để kiểm tra.
Bootloader sẽ gọi hàm validTransaction trên hợp đồng tài khoản người dùng để xác nhận rằng giao dịch đã được chủ tài khoản ủy quyền.
Có hai cách để Bootloader tính phí và phương thức tính phí cụ thể phụ thuộc vào tham số giao dịch (tham số paymaster có được đính kèm khi xây dựng đối tượng giao dịch hay không):
a. Gọi hàm payForTransaction và hợp đồng tài khoản để tính phí giao dịch;
b. Gọi các hàm prepareForPaymaster và validAndPayForPaymasterTransaction để thu phí giao dịch với hợp đồng Paymaster.
"Gọi payForTransaction để tính phí hợp đồng với Tài khoản" hoặc "gọi prepareForPaymaster và xác thựcAndPayForPaymasterTransaction để tính phí hợp đồng với Paymaster"
Kiểm tra xem bộ nạp khởi động đã nhận được ít nhất phí giao dịch tx.gasprice * tx.gaslimit hay chưa.
Bootloader sẽ gọi hàm uteTransaction trên hợp đồng tài khoản người dùng để thực hiện giao dịch.
(Tùy chọn) Nếu sử dụng Paymaster để thanh toán phí giao dịch, bootloader sẽ gọi hàm postTransaction. Nếu Paymaster không triển khai hậuGiao dịch hoặc hết gas, bước này sẽ bị bỏ qua.
Các bước 4.~7. ở trên là giai đoạn xác minh (được xác định trong l2TxValidation của bộ nạp khởi động) và giai đoạn thực hiện bước 8.~9. (được xác định trong l2Txution của bộ nạp khởi động).
So sánh EIP-4337, StarkNet và zkSync Era
Về cơ bản, quy trình cơ chế AA của cả ba đều tương tự nhau, tất cả đều là giai đoạn xác minh→cơ chế phí xử lý (được thanh toán bằng hợp đồng tài khoản hoặc Paymaster)→giai đoạn thực thi.
Vai trò của việc triển khai cơ chế AA là: sự khác biệt giữa việc mở trong thời đại zkSync và hai AA còn lại là Người vận hành cần hợp tác với bootloader (hợp đồng hệ thống), ví dụ bootloader sẽ mở một khối mới và xác định các tham số liên quan của khối và nhận hoạt động Nhà giao dịch do thành viên gửi và xác minh. Trong 4337, phần này do Bundler và EntryPoint điều phối, còn ở StarkNet, phần này do Sequencer phụ trách.
Gas Cost có cần tính đến phí bảo mật L1 không: L2 AA cần tính đến chi phí tải dữ liệu lên L1, không chỉ ZK (Hợp lệ) Rollups AA gốc được đề cập trong push mà còn cần được đưa vào L1 khi Lạc quan Các bản tổng hợp triển khai Phí bảo mật 4337 (được tính trong preVerificationGas, xem các tài liệu liên quan đến Alchemy để biết chi tiết).
Liệu có thể gửi giao dịch trước khi triển khai hợp đồng tài khoản hay không: Trong thời đại StarkNet và zkSync, không có EntryPoint nào như 4337 có trường initCode cho phép người dùng triển khai hợp đồng tài khoản nên không gửi giao dịch trước khi tài khoản có thể được cấu hình.
So
Vì StarkNet chưa triển khai cơ chế Paymaster và zkSync chưa hoàn thành việc thiết kế cơ chế hoàn trả gas nên một số so sánh chi tiết hơn không được liệt kê ở đây.
Ngoài ra, chúng tôi đã hoàn thành bộ nhớ P2P cho gói 4337 hiện tại, đồng thời Trình sắp xếp và Toán tử của zkRollups cũng là các máy chủ chính thức duy nhất, do đó có một số thành phần tập trung nhất định.
Trong quá trình phát triển, do zkSync không gặp vấn đề khi kết nối với nhiều gói khác nhau (chỉ cần tương tác với API của nhà điều hành) nên 4337 rất dễ sử dụng và trải nghiệm phát triển hợp đồng tài khoản (SDK) cũng tốt hơn; tại đồng thời, zkSync có thể sử dụng Solidity làm ngôn ngữ Phát triển hợp đồng, do đó không cần phải vượt qua ngưỡng Cairo trong quá trình phát triển StarkNet.
Phần kết luận
Vì cả StarkNet và zkSync đều thuộc danh mục AA cục bộ (AA gốc), nên bạn cũng có thể tham khảo phần giới thiệu trước đây của tôi về StarkNet AA, có tựa đề "Giới thiệu về trừu tượng hóa tài khoản StarkNet" (Giới thiệu về trừu tượng hóa tài khoản StarkNet). Ngoài ra, bạn có thể đọc các bài viết khác liên quan đến EIP-4337 để biết thêm thông tin.
Xem bản gốc
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
Giới thiệu về Trừu tượng tài khoản gốc trong zkSync
Tác giả: Viết bởi ChiHaoLu, imToken Labs
Bài viết này chủ yếu giới thiệu sự phát triển và nội dung liên quan của tài khoản trừu tượng (AA, tài khoản trừu tượng) trong giải pháp Lớp 2 của zkSync. Trọng tâm sẽ là ba phần:
Mục lục
lý lịch
Ở đây, để thuận tiện cho việc đọc, không cần thiết phải hiểu sâu về zkSync mà hãy xem lại ngắn gọn những thông tin cơ bản về zkSync. Có hai phiên bản chính của zkSync, phiên bản 1.0 (zkSync Lite) và phiên bản 2.0 (zkSync Era).
zkSync phiên bản 1.0 chỉ hỗ trợ EOA (tài khoản bên ngoài) và không hỗ trợ hợp đồng thông minh (chỉ hỗ trợ chuyển và trao đổi mã thông báo), trong khi zkSync 2.0, cụ thể là zkSync Era, thuộc về AA gốc (tài khoản trừu tượng) (tất cả các loại tài khoản đều là hợp đồng, không có EOA , đây là điểm khác biệt giữa EOA và tài khoản hợp đồng trong Ethereum), đồng thời tương thích với EVM (Máy ảo Ethereum) và hỗ trợ phát triển các hợp đồng thông minh sử dụng Rust, Yul, Vyper, Solidity, v.v.
ZkSync được đề cập bên dưới đề cập đến zkSync 2.0, cụ thể là Kỷ nguyên zkSync, trừ khi có quy định khác.
Trong Kỷ nguyên zkSync, có nhiều hợp đồng, có thể hiểu là chúng triển khai một số chức năng hệ điều hành quan trọng của zkSync trong hợp đồng thông minh. Các hợp đồng này là các hợp đồng được biên dịch trước chưa bao giờ được triển khai (chạy trực tiếp trong nút), nhưng chúng đều có địa chỉ chính thức.
Khi triển khai giao thức AA, zkSync sẽ thực hiện các hoạt động và phán đoán logic thông qua một số hợp đồng. Ví dụ: khi xác minh nonce, nó được đánh giá bởi NonceHolder, trong khi việc thực hiện cơ chế tài khoản trừu tượng và thu phí được đánh giá bởi bootloader. Sau đây sẽ giới thiệu chúng từng cái một.
**Tóm tắt tài khoản **
Khái niệm cốt lõi về trừu tượng hóa tài khoản có thể được tóm tắt thành hai điểm chính: trừu tượng hóa chữ ký và trừu tượng hóa thanh toán.
Mục tiêu của việc trừu tượng hóa chữ ký là cho phép các hợp đồng tài khoản khác nhau sử dụng các chương trình xác minh khác nhau. Điều này có nghĩa là người dùng không bị giới hạn ở thuật toán chữ ký số mà chỉ có thể sử dụng một đường cong cụ thể mà có thể chọn bất kỳ cơ chế xác minh nào họ thích.
Việc trừu tượng hóa thanh toán nhằm mục đích cung cấp cho người dùng nhiều tùy chọn thanh toán giao dịch khác nhau. Ví dụ: thanh toán có thể được thực hiện bằng cách sử dụng mã thông báo ERC-20 thay vì mã thông báo gốc hoặc giao dịch có thể được tài trợ bởi bên thứ ba hoặc thậm chí các mô hình thanh toán đặc biệt khác.
Các tài khoản trong zkSync 2.0 có thể bắt đầu các giao dịch như EOA nhưng cũng có thể sử dụng khả năng lập trình của nó để triển khai logic tùy ý, chẳng hạn như tài khoản hợp đồng. Đây là cái mà chúng tôi gọi là Trừu tượng hóa tài khoản, kết hợp các ưu điểm của hai loại tài khoản trong Ethereum để giúp trải nghiệm sử dụng tài khoản AA linh hoạt hơn, từ đó đạt được hai mục tiêu trên: trừu tượng hóa chữ ký và trừu tượng hóa thanh toán.
Cơ chế AA trong kỷ nguyên zkSync
Trong Kỷ nguyên zkSync, vai trò quan trọng nhất của zkSync AA là bộ nạp khởi động, là Hợp đồng, chủ yếu được sử dụng để xử lý các giao dịch và thực thi cơ chế AA, tương ứng với Hợp đồng EntryPoint của EIP-4337. Người dùng không thể gọi bootloader (nó chỉ có thể được kích hoạt bởi Người vận hành) và nó chưa bao giờ được triển khai (chạy trực tiếp trên nút), nhưng nó có địa chỉ chính thức (có thể được sử dụng để nhận thanh toán).
Toán tử có vai trò quan trọng trong ZK Rollup. Nó là một Máy chủ ngoại tuyến tập trung. Tương tự như Sequencer mà bạn có thể đã thấy, nó chịu trách nhiệm kích hoạt các hợp đồng như bootloader từ bên ngoài.
Các giao thức trừu tượng hóa tài khoản gốc (chẳng hạn như StarkNet, zkSync) về cơ bản được thiết kế có tham chiếu đến EIP-4337. Khi triển khai zkSync, người dùng sẽ gửi giao dịch đến Nhà điều hành và Nhà điều hành sẽ gửi giao dịch đến bộ nạp khởi động và bắt đầu một loạt xử lý.
Từ quan điểm khối:
Khi bootloader nhận đầu vào từ Operator, bootloader trước tiên sẽ xác định một số biến môi trường cho khối (chẳng hạn như giá gas, số khối, dấu thời gian của khối, v.v.). Sau đó, bootloader sẽ đọc tuần tự danh sách giao dịch, trước tiên hãy truy vấn xem hợp đồng tài khoản có đồng ý với giao dịch hay không (nghĩa là gọi hàm xác thực trong cơ chế AA), sau đó đưa chúng vào khối.
Sau khi mỗi giao dịch được xác minh, Người vận hành sẽ xác minh xem khối có đủ lớn để gửi đến người xác minh hay không (hoặc liệu nó có hết thời gian chờ hay không). Nếu nó đủ lớn hoặc hết thời gian, Người vận hành sẽ đóng khối, dừng thêm giao dịch mới vào bộ nạp khởi động và hoàn tất việc thực hiện giao dịch.
Từ góc độ giao dịch, khi Người vận hành kích hoạt bootloader, bootloader sẽ xử lý tuần tự từng giao dịch:
Ba bước đầu tiên ở trên tương ứng với vòng xác minh (Vòng xác minh) của EIP-4337 và bước thứ tư tương ứng với vòng thực thi (Vòng lặp ution) của EIP-4337.
Đây chủ yếu là phần giới thiệu tổng quan, chi tiết và vai trò của từng bước sẽ được trình bày chi tiết từng bước một trong phần mô tả chi tiết sau.
Tổng quan nhanh về hợp đồng tài khoản trừu tượng zkSync
Không một lần
Số nonce của tài khoản zkSync được ghi lại trong hợp đồng hệ thống có tên NonceHolder, hợp đồng này ghi nhớ xem mỗi cặp (account_address, nonce) có được sử dụng bằng cách ánh xạ (ánh xạ) để đánh giá xem nonce đó có hợp pháp hay không.
Theo như trên, bước đầu tiên sau khi Operator kích hoạt bootloader là kiểm tra nonce. Do đó, trước khi mỗi giao dịch bắt đầu, NonceHolder sẽ được sử dụng để xác nhận xem tập hợp nonces hiện đang sử dụng có hợp pháp hay không (hiện chỉ kiểm tra xem chúng đã được sử dụng chưa). Nếu nonce hợp pháp sẽ bước vào giai đoạn xác minh (Verification Phase), lúc này nonce sẽ được đánh dấu là đã sử dụng; nếu không hợp pháp thì giao dịch (xác minh) sẽ thất bại.
Các điểm quan trọng về nonce hiện tại của zkSync:
Mặc dù hiện tại người dùng có thể gửi nhiều giao dịch có số non khác nhau tới tài khoản để thực hiện cùng lúc, nhưng do zkSync không hỗ trợ xử lý song song nên các giao dịch có số non khác nhau vẫn sẽ được xử lý tuần tự.
Về lý thuyết, người dùng có thể sử dụng bất kỳ số nguyên khác 0 256 bit nào làm nonce, nhưng zkSync vẫn khuyến nghị sử dụng tăngNonceIfEquals như một cách để quản lý nonce để đảm bảo rằng nó được tăng theo thứ tự (hiện tại cơ chế AA của zkSync chỉ xác nhận nonce không được sử dụng, nhưng cơ chế chính thức tài liệu chỉ ra rằng việc tăng tuần tự có thể được yêu cầu trong tương lai).
Hợp đồng tài khoản
Hợp đồng tài khoản trong zkSync có bốn điểm vào cần thiết sau (Điểm vào), đó là:
Giới thiệu về Paymaster, số phí xử lý (tx.gasprice * tx.gaslimit), v.v. sẽ được giải thích trong các chương tiếp theo.
Ngoài ra còn có một chức năng bảo hiểm không cần thiết uteTransactionFromOutside trong tài khoản của zkSync. Tiền có thể được rút về L1 bằng cách sử dụng "cơ chế thoát" khi không thể thực hiện các hoạt động (chẳng hạn như khi trình tạo chuỗi không phản hồi hoặc zkSync được phát hiện là rủi ro pháp lý). Phần này ít liên quan đến giao thức AA nên sẽ không được mô tả chi tiết ở đây, những ai quan tâm có thể kiểm tra các tài liệu chính thức và thông số kỹ thuật của zkSync.
Những điểm chính và hạn chế của chức năng xác thực
Trong hàm validTransaction, nhiều logic tùy chỉnh khác nhau có thể được triển khai. Ví dụ: nếu tài khoản đã triển khai tiêu chuẩn EIP-1271, thì logic xác minh trong EIP-1271 có thể được áp dụng trực tiếp cho validTransaction hoặc tham khảo hợp đồng tài khoản nhiều chữ ký triển khai trong tài liệu chính thức của zkSync.
Đồng thời, để tránh các mối đe dọa DoS trong Giai đoạn xác minh của EIP-4337, có một số hạn chế (không thể liên quan đến mã hoạt động bên ngoài và độ sâu giới hạn, v.v.) và có các hạn chế tương tự trong zkSync, chẳng hạn:
1. Logic hợp đồng chỉ có thể chạm vào vị trí riêng của nó (nếu địa chỉ của hợp đồng tài khoản là A):
slot thuộc địa chỉ A
khe A tại bất kỳ địa chỉ nào khác
Khe keccak256(A||X) của bất kỳ địa chỉ nào khác, có thể sử dụng trực tiếp địa chỉ làm khóa của ánh xạ (chẳng hạn như ánh xạ (địa chỉ=>giá trị)), cũng tương đương với việc cho phép truy cập vào khe keccak256( A||X), để đạt được sự mở rộng. Ví dụ: số dư mã thông báo trên ERC-20.
2. Logic hợp đồng không được sử dụng các biến toàn cục, chẳng hạn như block.number
Những điểm chính và hạn chế của việc thực thi chức năng
Điều cần lưu ý trong hàm uteTransaction là nếu bạn muốn thực hiện lệnh gọi hệ thống (Gọi), bạn cần đảm bảo rằng nó có cờ is. Bởi vì các hợp đồng hệ thống này có tác động lớn đến hệ thống tài khoản. Ví dụ: cách duy nhất để tăng nonce là tương tác với NonceHolder. Để triển khai hợp đồng, bạn phải tương tác với ContractDeployer. Sử dụng cờ is có thể đảm bảo rằng các nhà phát triển tài khoản tương tác một cách có ý thức với các hợp đồng hệ thống.
Tuy nhiên, bạn nên sử dụng thư viện ContractsCaller do zkSync cung cấp để tránh tự mình xử lý cờ is và sử dụng CallWithPropagatedRevert để hoàn thành cuộc gọi hệ thống.
Mẫu mã ở trên liên quan đến việc tương tác với DEPLOYER__CONTRACT. Tình huống hợp đồng hệ thống phổ biến nhất mà các nhà phát triển tài khoản gặp phải là chúng ta muốn sử dụng tài khoản để triển khai hợp đồng, lúc này chúng ta phải tương tác với hợp đồng hệ thống ContractDeployer. Trong trường hợp này, nhà phát triển tài khoản cần liên lạc với hợp đồng ContractDeployer để đảm bảo rằng hợp đồng được triển khai thành công và thực hiện các hoạt động được yêu cầu.
Mô hình tính phí và Paymaster trong kỷ nguyên zkSync
Phí và giới hạn Gas
Mô hình tính phí của zkSync rất giống với Ethereum, token tính phí vẫn là ETH. Tuy nhiên, giống như các giải pháp Lớp 2 khác (chẳng hạn như Arbitrum, Optimism), zkSync cũng cần xem xét chi phí bổ sung khi xuất bản lên L1 (phí bảo mật) ngoài chi phí tính toán cơ bản và chi phí ghi. Do giá gas xuất dữ liệu lên L1 rất không ổn định nên Người vận hành zkSync xác định các tham số động sau khi mỗi khối được mở (bắt đầu ghi lại giao dịch):
gasPrice: giá gas tính bằng gwei, tức là tx.gasprice trong đối tượng giao dịch được đề cập ở trên
gasPerPubdata: Lượng gas cần thiết để xuất bản một byte dữ liệu trên Ethereum
Ngoài ra, không giống như EIP-4337, zkSync không cần xác định ba giới hạn gas: verifyGas, utionGas và preVerificationGas mà chỉ yêu cầu gasLimit để trang trải tất cả các chi phí trên, vì vậy người dùng cần đảm bảo rằng gasLimit đủ để trang trải Giai đoạn xác minh, giai đoạn sử dụng và tải dữ liệu lên Tất cả các chi phí như phí bảo mật cho L1. Chi phí phí này được bao gồm trong tx.gaslimit trong đối tượng giao dịch được đề cập ở trên.
Nhân hai (tx.gasprice * tx.gaslimit) để nhận phí giao dịch được trả cho bộ nạp khởi động.
Người trả lương
Paymaster chủ yếu trả ETH cho bộ nạp khởi động thay vì hợp đồng tài khoản của người dùng ở giai đoạn thanh toán phí giao dịch của người dùng. Người dùng có thể chọn các chế độ thanh toán và Paymaster khác nhau để thanh toán phí xử lý, chẳng hạn như (nhưng không giới hạn):
Thanh toán mã thông báo ERC-20 cho Paymaster trước khi giao dịch được bắt đầu hoặc sau khi giao dịch được thực hiện
Nạp tiền vào hợp đồng Paymaster bằng thẻ tín dụng
Paymaster sẽ tiếp tục thanh toán miễn phí một phần hoặc toàn bộ phí cho người dùng
Cách người dùng tương tác với Paymaster phụ thuộc vào các giao thức khác nhau, nó có thể được tập trung hoặc phi tập trung; có thể trước hoặc sau giao dịch; nó có thể sử dụng mã thông báo ERC-20 hoặc đấu thầu hợp pháp hoặc thậm chí miễn phí.
Hợp đồng Paymaster của zkSync chủ yếu bao gồm hai chức năng, đó là validAndPayForPaymasterTransaction (bắt buộc) và postTransaction (tùy chọn), cả hai chức năng này chỉ có thể được gọi bởi bộ nạp khởi động:
validAndPayForPaymasterTransaction là chức năng duy nhất phải được triển khai trong toàn bộ hợp đồng Paymaster. Khi nhà điều hành nhận được một giao dịch có tham số Paymaster, điều đó có nghĩa là phí xử lý không được thanh toán bởi hợp đồng tài khoản của người dùng mà bởi Paymaster. Tại thời điểm này, nhà điều hành sẽ gọi validAndPayForPaymasterTransaction để xác định xem Paymaster có sẵn sàng trả phí giao dịch hay không. Nếu Paymaster đồng ý, chức năng này sẽ gửi ít nhất tx.gasprice * tx.gaslimit ETH tới bộ nạp khởi động.
postTransaction là một chức năng tùy chọn, thường được sử dụng để hoàn tiền (trả lại gas chưa sử dụng cho người gửi). Tuy nhiên, zkSync hiện tại chưa hỗ trợ thao tác này.
Paymaster trong zkSync sẽ thực thi postTransaction sau khi postTransaction được triển khai, khác với EIP-4337. EIP-4337 sẽ không gọi postOp khi validPaymasterUserOp không trả về ngữ cảnh và ngược lại.
Ví dụ: dựa trên những điều trên, giờ đây người dùng muốn gửi một giao dịch mà phí xử lý do Paymaster thanh toán, quy trình như sau:
Ở bước cuối cùng, ngay cả khi postTransaction không thể được thực thi do lỗi hết gas, giao dịch AA này được coi là thành công nhưng hành động gọi postTransaction bị bỏ qua.
Nếu tìm hiểu sâu hơn về Paymaster của zkSync, bạn sẽ thấy rằng Quy tắc xác minh của nó hơi khác so với 4337 (zkSync Paymaster có thể bước lên bất kỳ vị trí hợp đồng nào khác) và cũng có nhiều loại khác nhau (chẳng hạn như dựa trên phê duyệt). để so sánh chi tiết, ai quan tâm có thể tham khảo các tài liệu chính thức hoặc cách thực hiện trước đây của tôi.
Tóm tắt & so sánh
Thông qua các phần giải thích trước đó, chúng ta đã biết được điểm đầu vào quan trọng của hợp đồng tài khoản, cũng như chức năng của chúng và các hạn chế liên quan. Đồng thời, chúng ta cũng đã tìm hiểu về chức năng của hợp đồng hệ thống. Tiếp theo, hãy tóm tắt quy trình giao dịch vận hành tự động (AA) trong zkSync từ khi xây dựng đến khi hoàn thành và tôi cũng sẽ cung cấp tài liệu tham khảo chi tiết hơn cho những ai muốn tìm hiểu thêm:
Người dùng sử dụng SDK hoặc ví cục bộ để xây dựng các đối tượng giao dịch (ví dụ: từ, đến, dữ liệu, giá trị, v.v.).
Người dùng ký giao dịch. Chữ ký ở đây không nhất thiết phải là định dạng EIP-712 truyền thống và chữ ký đường cong ECDSA. zkSync cũng hỗ trợ EIP-2718 và EIP-1559. Chìa khóa để chọn phương thức chữ ký và phương thức xác minh là xác minh thông qua chức năng xác minh trong hợp đồng tài khoản.
Gửi giao dịch đã ký cho nhà điều hành thông qua API RPC. Tại thời điểm này, giao dịch chuyển sang trạng thái chờ xử lý. Người vận hành chuyển giao dịch đến bộ nạp khởi động (gọi hàm processL2Tx trên hợp đồng bộ nạp khởi động) và bắt đầu một loạt quy trình giao thức AA.
Bootloader sẽ kiểm tra xem Nonce có hợp pháp hay không và sử dụng NonceHolder để kiểm tra.
Bootloader sẽ gọi hàm validTransaction trên hợp đồng tài khoản người dùng để xác nhận rằng giao dịch đã được chủ tài khoản ủy quyền.
Có hai cách để Bootloader tính phí và phương thức tính phí cụ thể phụ thuộc vào tham số giao dịch (tham số paymaster có được đính kèm khi xây dựng đối tượng giao dịch hay không):
a. Gọi hàm payForTransaction và hợp đồng tài khoản để tính phí giao dịch;
b. Gọi các hàm prepareForPaymaster và validAndPayForPaymasterTransaction để thu phí giao dịch với hợp đồng Paymaster.
"Gọi payForTransaction để tính phí hợp đồng với Tài khoản" hoặc "gọi prepareForPaymaster và xác thựcAndPayForPaymasterTransaction để tính phí hợp đồng với Paymaster"
Kiểm tra xem bộ nạp khởi động đã nhận được ít nhất phí giao dịch tx.gasprice * tx.gaslimit hay chưa.
Bootloader sẽ gọi hàm uteTransaction trên hợp đồng tài khoản người dùng để thực hiện giao dịch.
(Tùy chọn) Nếu sử dụng Paymaster để thanh toán phí giao dịch, bootloader sẽ gọi hàm postTransaction. Nếu Paymaster không triển khai hậuGiao dịch hoặc hết gas, bước này sẽ bị bỏ qua.
Các bước 4.~7. ở trên là giai đoạn xác minh (được xác định trong l2TxValidation của bộ nạp khởi động) và giai đoạn thực hiện bước 8.~9. (được xác định trong l2Txution của bộ nạp khởi động).
So sánh EIP-4337, StarkNet và zkSync Era
Về cơ bản, quy trình cơ chế AA của cả ba đều tương tự nhau, tất cả đều là giai đoạn xác minh→cơ chế phí xử lý (được thanh toán bằng hợp đồng tài khoản hoặc Paymaster)→giai đoạn thực thi.
So
Ngoài ra, chúng tôi đã hoàn thành bộ nhớ P2P cho gói 4337 hiện tại, đồng thời Trình sắp xếp và Toán tử của zkRollups cũng là các máy chủ chính thức duy nhất, do đó có một số thành phần tập trung nhất định.
Trong quá trình phát triển, do zkSync không gặp vấn đề khi kết nối với nhiều gói khác nhau (chỉ cần tương tác với API của nhà điều hành) nên 4337 rất dễ sử dụng và trải nghiệm phát triển hợp đồng tài khoản (SDK) cũng tốt hơn; tại đồng thời, zkSync có thể sử dụng Solidity làm ngôn ngữ Phát triển hợp đồng, do đó không cần phải vượt qua ngưỡng Cairo trong quá trình phát triển StarkNet.
Phần kết luận
Vì cả StarkNet và zkSync đều thuộc danh mục AA cục bộ (AA gốc), nên bạn cũng có thể tham khảo phần giới thiệu trước đây của tôi về StarkNet AA, có tựa đề "Giới thiệu về trừu tượng hóa tài khoản StarkNet" (Giới thiệu về trừu tượng hóa tài khoản StarkNet). Ngoài ra, bạn có thể đọc các bài viết khác liên quan đến EIP-4337 để biết thêm thông tin.