Phân tích trừu tượng hóa tài khoản đa chuỗi: Khám phá tương lai của cơ sở hạ tầng mã hóa
Gần đây, hội nghị cộng đồng Ethereum (EthCC 7) đã diễn ra tại Brussels, Bỉ, đây là sự kiện hàng năm lớn nhất về Ethereum ở châu Âu, tập trung vào công nghệ và cộng đồng. Hội nghị năm nay có hơn 350 lãnh đạo tư tưởng hàng đầu trong ngành công nghiệp blockchain phát biểu, trong đó một nhà phát triển đã có bài phát biểu với tiêu đề "Khám phá tương lai: Phân tích trừu tượng hóa tài khoản đa chuỗi."
Điểm chính của 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 là 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ý cho phép người dùng chọn bất kỳ cơ chế xác thực nào mà họ thích, trong khi trừu tượng hóa thanh toán cho phép sử dụng nhiều tùy chọn thanh toán giao dịch khác nhau. Sự linh hoạt này cung cấp trải nghiệm người dùng an toàn và tốt hơn.
Trong ERC-4337 và AA gốc, hàm điểm vào của giai đoạn "xác thực" là cố định, trong khi ở giai đoạn "thực thi", chỉ có điểm vào trong AA gốc là cố định. Các hạn chế của giao dịch xác thực 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 triển khai khác nhau.
Triển khai ERC-4337 trên chuỗi tương thích EVM có hai sự khác biệt chính: sự khác biệt về giao thức trong thiết kế Rollup và sự khác biệt trong cách tính toán địa chỉ, dẫn đến những chi tiết phát triển khó nhận thấy khi triển khai ERC-4337 giữa L1 và L2.
Trừu tượng hóa tài khoản giới thiệu
gì là trừu tượng hóa tài khoản
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ý: Người dùng có thể chọn bất kỳ cơ chế xác thực nào họ thích, không chỉ giới hạn ở một số thuật toán chữ ký số (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, chẳng hạn như sử dụng tài sản ERC-20 thay thế cho tài sản gốc để thanh toán, hoặc để bên thứ ba tài trợ giao dịch.
Sự linh hoạt này mang lại trải nghiệm người dùng an toàn và tối ưu hơn. Mục tiêu của trừu tượng hóa tài khoản là đạt được hai điểm chính này thông qua nhiều cách khác nhau.
Giới thiệu về ERC-4337
Hiện tại, tài khoản được sở hữu bên ngoài (EOA) trong giao thức Ethereum có một số hạn chế, chẳng hạn như phương pháp 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 quản lý tài khoản và phương pháp xử lý giao dịch linh hoạt hơn.
cấu trúc userOp: Trong ERC-4337, người dùng gửi cấu trúc userOp đến Bundler. Bundler thu thập nhiều userOp và gửi chúng đến hợp đồng EntryPoint bằng cách gọi hàm handleOps.
Hợp đồng EntryPoint: Hợp đồng này xử lý giao dịch giống như hệ điều hành, các chức năng chính bao gồm:
Gọi hàm validate trong hợp đồng tài khoản, đảm bảo userOp nhận được quyền ủy quyền của chủ tài khoản.
Thu phí.
Gọi hàm execute trong hợp đồng tài khoản, thực hiện thao tác mục tiêu của userOp.
Giới thiệu AA nguyên bản
Trong Ethereum, tài khoản được chia thành EOA và tài khoản hợp đồng. Tuy nhiên, trong AA gốc, mỗi tài khoản đều 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.
Trừu tượng hóa tài khoản gốc tuân theo ERC-4337: Thời đại StarkNet và zkSync
Tính trừu tượng hóa tài khoản gốc với thiết kế bảo mật: Aztec
Sự khác biệt giữa ERC-4337 và AA gốc
vai trò hệ điều hành
AA OS cần giải quyết các vấn đề sau:
Ai quyết định giá Gas?
Ai quyết định thứ tự giao dịch? Bộ nhớ ở đâu?
Ai đã kích hoạt hàm điểm vào?
Điều gì quyết định quy trình xử lý giao dịch?
Trong ERC-4337, các vai trò này hoàn thành phối hợp thông qua Bundler và EntryPoint Contract.
Trong AA gốc, người dùng gửi userOps của họ cho nhà điều hành/sắp xếp của máy chủ chính thức, thay vì Bundler và Hợp đồng EntryPoint.
Trong StarkNet, Sequencer chịu trách nhiệm xử lý tất cả những nhiệm vụ này.
Trong zkSync, sự khác biệt chính giữa Era và các AA khác là Operator cần phải làm việc với bootloader (hợp đồng hệ thống). Bootloader mở một khối mới, định nghĩa 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 giao dịch từ Operator để xác thực.
giao diện hợp đồng
Do sự tồn tại của ba bước, giao diện hợp đồng tài khoản trong các triển khai khác nhau là tương tự nhau, các hàm điểm vào này chỉ có thể được gọi bởi AA OS:
ERC-4337: xác thực thao tác người dùng
zkSync: xác thực giao dịch, thanh toán giao dịch, thực thi giao dịch
StarkNet：thực thi、xác thực、xác thực công bố、xác thực triển khai
Trong ERC-4337 và AA gốc, hàm điểm vào của giai đoạn "xác thực" là cố định, trong khi ở giai đoạn "thực thi", chỉ có điểm vào trong AA gốc là cố định.
giới hạn bước xác minh
Do vì việc xác thực giao dịch không có giới hạn chi phí (về bản chất, việc xác thực giao dịch là gọi hàm xem), kẻ tấn công có thể thực hiện tấn công DoS vào pool bộ nhớ, từ đó phá hủy bộ đóng gói (EIP-4337) hoặc nhà điều hành/sắp xếp (AA gốc).
EIP-4337 định nghĩa các mã lệnh nào bị cấm và cách hạn chế truy cập bộ nhớ. zkSync Era đã nới lỏng việc sử dụng một số OpCode:
Logic hợp đồng chỉ có thể truy cập vào kho 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, nó có thể truy cập:
Khe lưu trữ thuộc về địa chỉ A
Khe lưu trữ thuộc về bất kỳ địa chỉ A nào khác
Khe lưu trữ keccak256(A || X) thuộc về bất kỳ địa chỉ nào khác: điều này có nghĩa là sử dụng trực tiếp địa chỉ làm khóa trong bản đồ (ví dụ, bản đồ (address => value)), tương đương với việc truy cập khe keccak256(A || X). Ví dụ, số dư tài sản trong hợp đồng ERC-20.
Logic hợp đồng không thể truy cập biến toàn cục, chẳng hạn như số khối. StarkNet cũng không cho phép hợp đồng bên ngoài gọi.
giới hạn bước thực hiện
Trong zkSync, việc thực hiện các cuộc gọi hệ thống cần xác nhận sự tồn tại 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 cần tương tác với ContractDeployer. Cờ hệ thống đảm bảo rằng các nhà phát triển tài khoản có ý thức tương tác với hợp đồng hệ thống.
Trong ERC-4337 và StarkNet, giai đoạn thực thi không có hạn chế đặc biệt.
số ngẫu nhiên
Trong ERC-4337, thiết kế giá trị ngẫu nhiên điểm vào phân biệt giữa giá trị khóa 192 bit và giá trị ngẫu nhiên 64 bit.
Trong zkSync, hợp đồng hệ thống NonceHolder quản lý nonce, đảm bảo tăng dần một cách nghiêm ngặt, tức là tăng số ngẫu nhiên lên 1.
Trong StarkNet, nonce cũng tăng dần một cách nghiêm ngặt, nhưng không có nonce trừu tượng để được quản lý bởi hợp đồng cụ thể.
sử dụng giao dịch đầu tiên để triển khai
ERC-4337 trong cấu trúc userOp bao gồm trường initcode để 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 cho nhà điều hành/sắp xếp để triển khai hợp đồng tài khoản.
thiết kế đặc biệt trong zkSync
Nếu bạn chuyển ETH trực tiếp từ EOA Ethereum sang zkSync mà không cần 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 với cùng địa chỉ. Tài khoản này có thể hoạt động như EOA Ethereum và cũng được kiểm soát bởi khóa riêng tương ứng của EOA Ethereum.
Loại tài khoản này là phiên bản None thay vì version1. Bạn không thể gọi hàm của 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
Việc triển khai ERC-4337 trên chuỗi tương thích EVM có hai sự khác biệt chính: sự khác biệt về giao thức và sự khác biệt về địa chỉ.
sự khác biệt trong giao thức
Trong thiết kế Rollup, L2 cần phải tải dữ liệu lên L1 để đảm bảo an toàn và thanh toán. 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í an toàn L1 và phí blob, nên được bao gồm trong Gas tiền xác thực. Xác định các khoản phí tải lên thích hợp trong Gas tiền xác thực là một thách thức lớn.
sự khác biệt địa chỉ
Cách mã hóa địa chỉ trong hàm create của zkSync ERA khác với Ethereum và OP tổng hợp. Ngoài ra, StarkNet sử dụng hàm băm độc đáo để tính toán địa chỉ. Trong bối cảnh ERC-4337 trên chuỗi tương thích EVM, chúng ta thường giả định rằng việc tính toán địa chỉ là 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ể dẫn đến địa chỉ hợp đồng tài khoản khác nhau giữa các triển khai ERC-4337 trên Ethereum và L2.
Vấn đề chính là việc thêm mã lệnh mới trong 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 trong quá trình biên dịch, việc giới thiệu push0 sẽ dẫn đến sự thay đổi của bytecode, ngay cả khi mã Solidity là giống nhau.
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.
17 thích
Phần thưởng
17
2
Chia sẻ
Bình luận
0/400
OnChainArchaeologist
· 07-09 19:30
Nhiều yêu thích làm phiền những điều này
Xem bản gốcTrả lời0
PriceOracleFairy
· 07-09 19:30
meh, aa chỉ là toán fancy eth... nhưng sự trừu tượng chữ ký trông có vẻ hấp dẫn thật sự ngl
Giải thích trừu tượng hóa tài khoản đa chuỗi: Sự khác biệt chính giữa ERC-4337 và AA gốc
Phân tích trừu tượng hóa tài khoản đa chuỗi: Khám phá tương lai của cơ sở hạ tầng mã hóa
Gần đây, hội nghị cộng đồng Ethereum (EthCC 7) đã diễn ra tại Brussels, Bỉ, đây là sự kiện hàng năm lớn nhất về Ethereum ở châu Âu, tập trung vào công nghệ và cộng đồng. Hội nghị năm nay có hơn 350 lãnh đạo tư tưởng hàng đầu trong ngành công nghiệp blockchain phát biểu, trong đó một nhà phát triển đã có bài phát biểu với tiêu đề "Khám phá tương lai: Phân tích trừu tượng hóa tài khoản đa chuỗi."
Điểm chính của 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 là 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ý cho phép người dùng chọn bất kỳ cơ chế xác thực nào mà họ thích, trong khi trừu tượng hóa thanh toán cho phép sử dụng nhiều tùy chọn thanh toán giao dịch khác nhau. Sự linh hoạt này cung cấp trải nghiệm người dùng an toàn và tốt hơn.
Trong ERC-4337 và AA gốc, hàm điểm vào của giai đoạn "xác thực" là cố định, trong khi ở giai đoạn "thực thi", chỉ có điểm vào trong AA gốc là cố định. Các hạn chế của giao dịch xác thực 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 triển khai khác nhau.
Triển khai ERC-4337 trên chuỗi tương thích EVM có hai sự khác biệt chính: sự khác biệt về giao thức trong thiết kế Rollup và sự khác biệt trong cách tính toán địa chỉ, dẫn đến những chi tiết phát triển khó nhận thấy khi triển khai ERC-4337 giữa L1 và L2.
Trừu tượng hóa tài khoản giới thiệu
gì là trừu tượng hóa tài khoản
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ý: Người dùng có thể chọn bất kỳ cơ chế xác thực nào họ thích, không chỉ giới hạn ở một số thuật toán chữ ký số (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, chẳng hạn như sử dụng tài sản ERC-20 thay thế cho tài sản gốc để thanh toán, hoặc để bên thứ ba tài trợ giao dịch.
Sự linh hoạt này mang lại trải nghiệm người dùng an toàn và tối ưu hơn. Mục tiêu của trừu tượng hóa tài khoản là đạt được hai điểm chính này thông qua nhiều cách khác nhau.
Giới thiệu về ERC-4337
Hiện tại, tài khoản được sở hữu bên ngoài (EOA) trong giao thức Ethereum có một số hạn chế, chẳng hạn như phương pháp 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 quản lý tài khoản và phương pháp xử lý giao dịch linh hoạt hơn.
cấu trúc userOp: Trong ERC-4337, người dùng gửi cấu trúc userOp đến Bundler. Bundler thu thập nhiều userOp và gửi chúng đến hợp đồng EntryPoint bằng cách gọi hàm handleOps.
Hợp đồng EntryPoint: Hợp đồng này xử lý giao dịch giống như hệ điều hành, các chức năng chính bao gồm:
Giới thiệu AA nguyên bản
Trong Ethereum, tài khoản được chia thành EOA và tài khoản hợp đồng. Tuy nhiên, trong AA gốc, mỗi tài khoản đều 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 các mạng blockchain khác nhau:
Sự khác biệt giữa ERC-4337 và AA gốc
vai trò hệ điều hành
AA OS cần giải quyết các vấn đề sau:
Trong ERC-4337, các vai trò này hoàn thành phối hợp thông qua Bundler và EntryPoint Contract.
Trong AA gốc, người dùng gửi userOps của họ cho nhà điều hành/sắp xếp của máy chủ chính thức, thay vì Bundler và Hợp đồng EntryPoint.
Trong StarkNet, Sequencer chịu trách nhiệm xử lý tất cả những nhiệm vụ này.
Trong zkSync, sự khác biệt chính giữa Era và các AA khác là Operator cần phải làm việc với bootloader (hợp đồng hệ thống). Bootloader mở một khối mới, định nghĩa 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 giao dịch từ Operator để xác thực.
giao diện hợp đồng
Do sự tồn tại của ba bước, giao diện hợp đồng tài khoản trong các triển khai khác nhau là tương tự nhau, các hàm điểm vào này chỉ có thể được gọi bởi AA OS:
Trong ERC-4337 và AA gốc, hàm điểm vào của giai đoạn "xác thực" là cố định, trong khi ở giai đoạn "thực thi", chỉ có điểm vào trong AA gốc là cố định.
giới hạn bước xác minh
Do vì việc xác thực giao dịch không có giới hạn chi phí (về bản chất, việc xác thực giao dịch là gọi hàm xem), kẻ tấn công có thể thực hiện tấn công DoS vào pool bộ nhớ, từ đó phá hủy bộ đóng gói (EIP-4337) hoặc nhà điều hành/sắp xếp (AA gốc).
EIP-4337 định nghĩa các mã lệnh nào bị cấm và cách hạn chế truy cập bộ nhớ. zkSync Era đã nới lỏng việc sử dụng một số OpCode:
Logic hợp đồng chỉ có thể truy cập vào kho 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, nó có thể truy cập:
Logic hợp đồng không thể truy cập biến toàn cục, chẳng hạn như số khối. StarkNet cũng không cho phép hợp đồng bên ngoài gọi.
giới hạn bước thực hiện
Trong zkSync, việc thực hiện các cuộc gọi hệ thống cần xác nhận sự tồn tại 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 cần tương tác với ContractDeployer. Cờ hệ thống đảm bảo rằng các nhà phát triển tài khoản có ý thức tương tác với hợp đồng hệ thống.
Trong ERC-4337 và StarkNet, giai đoạn thực thi không có hạn chế đặc biệt.
số ngẫu nhiên
sử dụng giao dịch đầu tiên để triển khai
thiết kế đặc biệt trong zkSync
Nếu bạn chuyển ETH trực tiếp từ EOA Ethereum sang zkSync mà không cần 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 với cùng địa chỉ. Tài khoản này có thể hoạt động như EOA Ethereum và cũng được kiểm soát bởi khóa riêng tương ứng của EOA Ethereum.
Loại tài khoản này là phiên bản None thay vì version1. Bạn không thể gọi hàm của 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
Việc triển khai ERC-4337 trên chuỗi tương thích EVM có hai sự khác biệt chính: sự khác biệt về giao thức và sự khác biệt về địa chỉ.
sự khác biệt trong giao thức
Trong thiết kế Rollup, L2 cần phải tải dữ liệu lên L1 để đảm bảo an toàn và thanh toán. 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í an toàn L1 và phí blob, nên được bao gồm trong Gas tiền xác thực. Xác định các khoản phí tải lên thích hợp trong Gas tiền xác thực là một thách thức lớn.
sự khác biệt địa chỉ
Cách mã hóa địa chỉ trong hàm create của zkSync ERA khác với Ethereum và OP tổng hợp. Ngoài ra, StarkNet sử dụng hàm băm độc đáo để tính toán địa chỉ. Trong bối cảnh ERC-4337 trên chuỗi tương thích EVM, chúng ta thường giả định rằng việc tính toán địa chỉ là 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ể dẫn đến địa chỉ hợp đồng tài khoản khác nhau giữa các triển khai ERC-4337 trên Ethereum và L2.
Vấn đề chính là việc thêm mã lệnh mới trong 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 trong quá trình biên dịch, việc giới thiệu push0 sẽ dẫn đến sự thay đổi của bytecode, ngay cả khi mã Solidity là giống nhau.