Phân tích trừu tượng hóa tài khoản đa chuỗi: Thảo luận về tương lai của cơ sở hạ tầng mã hóa
Từ ngày 8 đến 11 tháng 7 năm 2024, sự kiện thường niên về Ethereum lớn nhất châu Âu - Hội nghị cộng đồng Ethereum (EthCC) sẽ diễn ra tại Brussels, Bỉ, tập trung vào phát triển công nghệ và cộng đồng.
Hội nghị cộng đồng Ethereum lần này (EthCC 7) đã mời hơn 350 người lãnh đạo ý kiến hàng đầu trong ngành công nghiệp blockchain tham gia phát biểu. Nhà phát triển Alfred của imToken Labs đã được mời tham gia và đã có bài phát biểu mang tên "Khám phá tương lai: Phân tích trừu tượng hóa tài khoản đa chuỗi".
Tổng quan điểm chính của buổi diễn thuyết
Hai cốt lõi của trừu tượng hóa tài khoản (AA): 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, trong khi trừu tượng hóa thanh toán cung cấp nhiều tùy chọn thanh toán giao dịch khác nhau, cùng nhau nâng cao tính bảo mật và trải nghiệm người dùng.
Hàm điểm vào trong giai đoạn "xác thực" của ERC-4337 và AA gốc đều cố định, nhưng trong giai đoạn "thực thi", chỉ AA gốc giữ điểm vào cố định. Các phương pháp triển khai khác nhau có những đặc điểm riêng trong việc hạn chế giao dịch xác thực và các bước thực thi giao dịch.
Khi 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 về cách tính toán địa chỉ. Những sự khác biệt này dẫn đến một số chi tiết phát triển dễ bị bỏ qua khi thực hiện ERC-4337 giữa L1 và L2.
Trừu tượng hóa tài khoản giới thiệu
1. Định nghĩa trừu tượng hóa tài khoản
trừu tượng hóa tài khoản (AA)主要包含两个关键点：
Trừu tượng hóa chữ ký: Người dùng có thể tự do lựa chọn cơ chế xác thực, không còn bị giới hạn bởi các thuật toán chữ ký số cụ thể (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ư sử dụng tài sản ERC-20 để thay thế tài sản gốc, hoặc do bên thứ ba tài trợ giao dịch.
Sự linh hoạt này đã nâng cao đáng kể tính bảo mật và trải nghiệm người dùng. Trừu tượng hóa tài khoản nhằm đạt được hai mục tiêu cốt lõi này thông qua nhiều phương thức.
2. Phân tích ERC-4337
Hiện tại, tài khoản 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 phương pháp quản lý tài khoản và 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 thông qua việc gọi hàm handleOps.
Hợp đồng EntryPoint: Hợp đồng này giống như hệ điều hành, chức năng chính trong việc xử lý giao dịch bao gồm:
Gọi hàm validate trong hợp đồng tài khoản, đảm bảo userOp được ủy quyền bởi chủ sở hữu 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.
3. Giới thiệu AA gốc
Trong Ethereum, tài khoản được chia thành EOA và tài khoản hợp đồng. Và 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.
Tuân theo trừu tượng hóa tài khoản gốc ERC-4337: StarkNet và zkSync Era
Tài khoản trừu tượng hóa 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
1. 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 được thực hiện phối hợp thông qua Bundler và EntryPoint Contract.
Trong AA gốc, người dùng sẽ gửi userOps của họ cho người điều hành/sắp xếp của máy chủ chính thức, thay vì Bundler và EntryPoint Contract.
Trong StarkNet, Sequencer chịu trách nhiệm xử lý tất cả những nhiệm vụ này.
Sự khác biệt chính giữa zkSync Era và các AA khác là Operator cần làm việc cùng với bootloader (hợp đồng hệ thống). Bootloader mở các 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.
2. 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 tương tự trong các triển khai khác 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 của người dùng
zkSync: xác minh giao dịch, thanh toán giao dịch, thực hiện giao dịch
Trong ERC-4337 và AA nguyên bản, 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 hiện", chỉ có điểm vào trong AA nguyên bản là cố định.
3. Giới hạn của các 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í, kẻ tấn công có thể thực hiện cuộc tấn công DoS vào pool bộ nhớ, từ đó ảnh hưởng đến bộ gói (EIP-4337) hoặc nhà điều hành/sắp xếp (AA bản địa).
EIP-4337 định nghĩa các mã thao tác bị cấm và cách hạn chế truy cập lưu trữ. 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 ngăn chứa 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
Thuộc về bất kỳ khe lưu trữ nào của địa chỉ khác keccak256(A || X): Điều này có nghĩa là sử dụng trực tiếp địa chỉ như một khóa trong bản đồ, tương đương với việc truy cập khe lưu trữ 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 các hợp đồng bên ngoài gọi.
4. Hạn chế các bước thực hiện
Trong zkSync, việc thực hiện cuộc gọi hệ thống cần xác nhận sự tồn tại của các 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 thì cần tương tác với ContractDeployer. Các 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 các hợp đồng hệ thống.
Trong ERC-4337 và StarkNet, giai đoạn thực thi không có giới hạn đặc biệt.
5. Số ngẫu nhiên
Trong ERC-4337, thiết kế của số 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 theo thứ tự 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ể.
6. Sử dụng giao dịch đầu tiên để triển khai
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 cho operator/sorter để 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ừ 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 giống như EOA Ethereum và được kiểm soát bởi khóa riêng của EOA Ethereum tương ứng.
Loại tài khoản này là phiên bản None chứ không phải version1. 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 nhân.
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 khi 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 về 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 của ERC-4337, các khoản phí liên quan đến quá trình tải lên này, như phí an toàn L1 và phí blob, nên được bao gồm trong Gas xác thực trước. Xác định các khoản phí tải lên thích hợp trong Gas xác thực trước là một thách thức lớn.
2. 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 một hàm băm độc đáo để tính toán địa chỉ. Trong bối cảnh ERC-4337 trên các 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 việc triển khai ERC-4337 trên Ethereum và L2.
Vấn đề then chốt là thêm mã vận hành mới vào trong hard fork. Ví dụ, nếu chuỗi L2 không hỗ trợ hard fork Thượng Hải và không chỉ định phiên bản EVM trong quá trình biên dịch, việc giới thiệu push0 sẽ dẫn đến sự thay đổi 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.
7 thích
Phần thưởng
7
4
Chia sẻ
Bình luận
0/400
SigmaValidator
· 15giờ trước
trừu tượng hóa tài khoản này cũng chỉ là để vui vẻ mà thôi
Xem bản gốcTrả lời0
NeverPresent
· 15giờ trước
Thanh toán trừu tượng có tuyệt vời như vậy không?
Xem bản gốcTrả lời0
GateUser-beba108d
· 16giờ trước
Không có ích gì, chỉ nói suông.
Xem bản gốcTrả lời0
StableNomad
· 16giờ trước
hừ, lại một cuộc nói chuyện AA nữa... thật lòng mà nói, nó làm tôi nhớ đến những tuyên bố về "bảo mật" của celsius
Phân tích trừu tượng hóa tài khoản đa chuỗi: Sự khác biệt và thách thức 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: Thảo luận về tương lai của cơ sở hạ tầng mã hóa
Từ ngày 8 đến 11 tháng 7 năm 2024, sự kiện thường niên về Ethereum lớn nhất châu Âu - Hội nghị cộng đồng Ethereum (EthCC) sẽ diễn ra tại Brussels, Bỉ, tập trung vào phát triển công nghệ và cộng đồng.
Hội nghị cộng đồng Ethereum lần này (EthCC 7) đã mời hơn 350 người lãnh đạo ý kiến hàng đầu trong ngành công nghiệp blockchain tham gia phát biểu. Nhà phát triển Alfred của imToken Labs đã được mời tham gia và đã có bài phát biểu mang tên "Khám phá tương lai: Phân tích trừu tượng hóa tài khoản đa chuỗi".
Tổng quan điểm chính của buổi diễn thuyết
Hai cốt lõi của trừu tượng hóa tài khoản (AA): 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, trong khi trừu tượng hóa thanh toán cung cấp nhiều tùy chọn thanh toán giao dịch khác nhau, cùng nhau nâng cao tính bảo mật và trải nghiệm người dùng.
Hàm điểm vào trong giai đoạn "xác thực" của ERC-4337 và AA gốc đều cố định, nhưng trong giai đoạn "thực thi", chỉ AA gốc giữ điểm vào cố định. Các phương pháp triển khai khác nhau có những đặc điểm riêng trong việc hạn chế giao dịch xác thực và các bước thực thi giao dịch.
Khi 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 về cách tính toán địa chỉ. Những sự khác biệt này dẫn đến một số chi tiết phát triển dễ bị bỏ qua khi thực hiện ERC-4337 giữa L1 và L2.
Trừu tượng hóa tài khoản giới thiệu
1. Định nghĩa trừu tượng hóa tài khoản
trừu tượng hóa tài khoản (AA)主要包含两个关键点：
Sự linh hoạt này đã nâng cao đáng kể tính bảo mật và trải nghiệm người dùng. Trừu tượng hóa tài khoản nhằm đạt được hai mục tiêu cốt lõi này thông qua nhiều phương thức.
2. Phân tích ERC-4337
Hiện tại, tài khoản 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 phương pháp quản lý tài khoản và xử lý giao dịch linh hoạt hơn.
3. Giới thiệu AA gốc
Trong Ethereum, tài khoản được chia thành EOA và tài khoản hợp đồng. Và 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
1. 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 được thực hiện phối hợp thông qua Bundler và EntryPoint Contract.
Trong AA gốc, người dùng sẽ gửi userOps của họ cho người điều hành/sắp xếp của máy chủ chính thức, thay vì Bundler và EntryPoint Contract.
Trong StarkNet, Sequencer chịu trách nhiệm xử lý tất cả những nhiệm vụ này.
Sự khác biệt chính giữa zkSync Era và các AA khác là Operator cần làm việc cùng với bootloader (hợp đồng hệ thống). Bootloader mở các 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.
2. 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 tương tự trong các triển khai khác 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 nguyên bản, 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 hiện", chỉ có điểm vào trong AA nguyên bản là cố định.
3. Giới hạn của các 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í, kẻ tấn công có thể thực hiện cuộc tấn công DoS vào pool bộ nhớ, từ đó ảnh hưởng đến bộ gói (EIP-4337) hoặc nhà điều hành/sắp xếp (AA bản địa).
EIP-4337 định nghĩa các mã thao tác bị cấm và cách hạn chế truy cập lưu trữ. zkSync Era đã nới lỏng việc sử dụng một số OpCode:
4. Hạn chế các bước thực hiện
Trong zkSync, việc thực hiện cuộc gọi hệ thống cần xác nhận sự tồn tại của các 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 thì cần tương tác với ContractDeployer. Các 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 các hợp đồng hệ thống.
Trong ERC-4337 và StarkNet, giai đoạn thực thi không có giới hạn đặc biệt.
5. Số ngẫu nhiên
6. Sử dụng giao dịch đầu tiên để triển khai
7. 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 giống như EOA Ethereum và được kiểm soát bởi khóa riêng của EOA Ethereum tương ứng.
Loại tài khoản này là phiên bản None chứ không phải version1. 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 nhân.
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 khi 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 về 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 của ERC-4337, các khoản phí liên quan đến quá trình tải lên này, như phí an toàn L1 và phí blob, nên được bao gồm trong Gas xác thực trước. Xác định các khoản phí tải lên thích hợp trong Gas xác thực trước là một thách thức lớn.
2. 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 một hàm băm độc đáo để tính toán địa chỉ. Trong bối cảnh ERC-4337 trên các 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 việc triển khai ERC-4337 trên Ethereum và L2.
Vấn đề then chốt là thêm mã vận hành mới vào trong hard fork. Ví dụ, nếu chuỗi L2 không hỗ trợ hard fork Thượng Hải và không chỉ định phiên bản EVM trong quá trình biên dịch, việc giới thiệu push0 sẽ dẫn đến sự thay đổi bytecode, ngay cả khi mã Solidity là giống nhau.