Nhóm tiền thưởng nghiên cứu DAOrayaki DAO:

Nhóm tiền thưởng nghiên cứu DAOrayaki DAO:

Tiến độ bỏ phiếu: Ủy ban DAO 3/7 thông qua

Địa chỉ tài trợ: DAOrayaki.eth

Tiến độ bỏ phiếu: Ủy ban DAO 3/7 thông qua

Tổng tiền thưởng: 80USDC

Các loại nghiên cứu: DAO, ERC4337, trừu tượng hóa tài khoản, ví thông minh

Tác giả gốc: Vitalik Buterin

Người đóng góp: Dewei, DAOctor @DAOrayaki

Văn bản gốc: ERC 4337: trừu tượng hóa tài khoản mà không thay đổi giao thức Ethereum

Tóm tắt tài khoản từ lâu đã là giấc mơ của cộng đồng nhà phát triển Ethereum. Mã EVM không chỉ được sử dụng để triển khai logic của ứng dụng mà còn để triển khai xác minh logic của ví người dùng cá nhân (nonces, chữ ký...). Điều này sẽ cung cấp rất nhiều ý tưởng cho sự đổi mới trong thiết kế ví và ví có thể cung cấp một số chức năng quan trọng như:

1. Đa chữ ký và phục hồi xã hội

2. Thuật toán chữ ký hiệu quả hơn và đơn giản hơn (chẳng hạn như Schnorr, BLS)

3. Các thuật toán chữ ký an toàn sau lượng tử (ví dụ: Lamport, Winternitz)

Tất cả những điều này có thể được thực hiện ngày nay với ví hợp đồng thông minh, nhưng bản thân giao thức Ethereum yêu cầu mọi thứ phải được đóng gói trong các giao dịch bắt nguồn từ tài khoản bên ngoài bảo mật ECDSA (EOA), điều mà ví hợp đồng thông minh khó đạt được. Mỗi hoạt động của người dùng cần được bao bọc bởi một giao dịch từ EOA, thêm 21000 chi phí gas. Người dùng cần sở hữu ETH trong một EOA riêng biệt để thanh toán gas và quản lý số dư trong cả hai tài khoản hoặc dựa vào các hệ thống chuyển tiếp thường được tập trung hóa.

EIP 2938 là một cách để giải quyết vấn đề này bằng cách thay đổi một số giao thức Ethereum để cho phép các giao dịch Ethereum cấp cao nhất bắt đầu bằng hợp đồng thay vì EOA. Bản thân hợp đồng sẽ có logic xác minh và thanh toán phí, những người khai thác sẽ kiểm tra. Tuy nhiên, khi các nhà phát triển giao thức chú ý đến việc hợp nhất và khả năng mở rộng, họ cần thực hiện những thay đổi đáng kể đối với giao thức. Trong đề xuất mới của chúng tôi (ERC 4337), chúng tôi cung cấp một cách để đạt được những lợi ích tương tự mà không cần thay đổi giao thức lớp đồng thuận.

tiêu đề phụ

Đề xuất này hoạt động như thế nào?

Những gì chúng tôi sửa đổi không phải là logic của chính lớp đồng thuận, mà là chức năng sao chép mempool giao dịch trong hệ thống cấp cao hơn. Người dùng gửi một đối tượng UserOperation, đóng gói ý định của người dùng bằng chữ ký và dữ liệu khác để xác minh. Cả công cụ khai thác và trình đóng gói sử dụng các dịch vụ như Flashbot đều có thể gộp một tập hợp các đối tượng UserOperation vào một "giao dịch theo gói", sau đó được đưa vào một khối Ethereum.

Các gói được thanh toán cho các giao dịch theo gói bằng ETH và được bồi thường thông qua các khoản phí được trả như một phần của tất cả các hành động của người dùng cá nhân được thực hiện. Bundlers sẽ chọn đối tượng UserOperation nào để đưa vào dựa trên logic ưu tiên phí tương tự như cách các công cụ khai thác hoạt động trong mempool giao dịch hiện có. UserOperation trông giống như một giao dịch; đó là một cấu trúc được mã hóa ABI bao gồm các trường sau:

1. Người gửi: ví hoạt động

2. nonce và signature: các tham số được truyền cho chức năng xác minh ví để ví có thể xác minh hoạt động

4. callData: dữ liệu dùng để gọi ví trong các bước thực thi thực tế

Các trường còn lại liên quan đến quản lý phí và khí đốt, bạn có thể tìm thấy danh sách đầy đủ các trường trong đặc tả ERC 4337.

tiêu đề phụ

Ví là một hợp đồng thông minh cần có hai chức năng:

2. OP thực thi chức năng và diễn giải calldata dưới dạng hướng dẫn để ví thực hiện hành động. Cách chức năng này diễn giải calldata và kết quả của nó là hoàn toàn mở; nhưng chúng tôi mong đợi hành vi phổ biến nhất là phân tích cú pháp calldata thành hướng dẫn để ví thực hiện một hoặc nhiều lệnh gọi.

Để đơn giản hóa logic của ví, hầu hết các thủ thuật hợp đồng thông minh phức tạp cần thiết để đảm bảo an ninh không được thực hiện trong chính ví mà trong các hợp đồng toàn cầu được gọi là điểm vào. Các hàm validateUserOp và thực thi dự kiến ​​sẽ được kiểm soát bằng yêu cầu (msg.sender == ENTRY_POINT) để chỉ các điểm vào đáng tin cậy mới có thể khiến ví thực hiện bất kỳ hoạt động nào hoặc trả phí. Điểm vào chỉ thực hiện lệnh gọi tùy ý tới ví sau khi xác thựcUserOp và UserOperation mang dữ liệu của lệnh gọi đó đã thành công, vì vậy điều này đủ để bảo vệ ví khỏi bị tấn công. Điểm vào cũng chịu trách nhiệm tạo ví bằng initCode được cung cấp nếu ví không tồn tại.

tiêu đề phụ

Luồng kiểm soát điểm vào thời gian chạy

Nếu việc xác thực UserOperation được mô phỏng thành công, thì UserOperation được đảm bảo có thể chứa được cho đến khi một số thay đổi trạng thái nội bộ khác xảy ra trên tài khoản người gửi (do UserOperation khác có cùng người gửi hoặc hợp đồng khác gọi người gửi; trong bất kỳ trường hợp nào , kích hoạt điều kiện này cho một tài khoản yêu cầu chi tiêu hơn 7500 gas trên chuỗi).

Ngoài ra, hành động của người dùng chỉ định giới hạn gas cho bước validateUser, các nút mempool và gói sẽ từ chối nó trừ khi giới hạn gas này rất nhỏ (ví dụ: dưới 200000). Những hạn chế này sao chép các thuộc tính chính của các giao dịch Ethereum hiện có, làm cho mempool miễn nhiễm với các cuộc tấn công DoS. Các nút gói và mempool có thể sử dụng logic tương tự như các giao dịch Ethereum ngày nay để xác định xem có bao gồm hoặc chuyển tiếp UserOperation hay không.

tiêu đề phụ

Thiết kế này bổ sung, duy trì và hy sinh những thuộc tính nào so với mempool giao dịch Ethereum thông thường?

Bảo quản tài sản:

1. Không có người tham gia tập trung, mọi thứ được thực hiện thông qua một mempool ngang hàng

2. An toàn DoS (các hành động của người dùng vượt qua kiểm tra mạo danh được đảm bảo có thể ngăn chặn được cho đến khi người gửi có một thay đổi trạng thái khác, điều này sẽ yêu cầu kẻ tấn công trả hơn 7500 gas cho mỗi người gửi)

3. Thiết lập ví phía người dùng không phức tạp: người dùng không cần quan tâm liệu hợp đồng ví của họ đã được "xuất bản" hay chưa; ví tồn tại ở một địa chỉ CREATE2 xác định và nếu ví chưa tồn tại, UserOperation đầu tiên sẽ tự động tạo ra nó

4. Hỗ trợ đầy đủ EIP 1559, bao gồm cài đặt phí (người dùng có thể đặt mức phí cố định và tổng phí cao nhất, đồng thời mong đợi phí bao gồm nhanh và công bằng)

5. Khả năng gửi các hành động mới của người dùng với mức phí cao hơn các hành động cũ để thay thế các hành động hoặc đưa chúng vào nhanh hơn bằng thay thế trả phí

Lợi ích mới:

1. Tính linh hoạt của logic xác minh: chức năng validateUserOp có thể thêm chữ ký tùy ý và logic xác minh nonce (sơ đồ chữ ký mới, đa chữ ký...)

3. Khả năng nâng cấp ví: Logic xác minh ví có thể ở trạng thái, do đó ví có thể thay đổi khóa công khai hoặc (nếu được phát hành bằng DELEGATECALL) nâng cấp hoàn toàn mã của nó.

sự thiếu sót

4. Tính linh hoạt của logic thực thi: ví có thể thêm logic tùy chỉnh cho các bước thực thi, vd. Thực hiện multi-ops nguyên tử (mục tiêu chính của EIP 3074)

sự thiếu sót

1. Bất chấp những nỗ lực tốt nhất của giao thức, vẫn có sự gia tăng nhẹ về các lỗ hổng DoS đơn giản chỉ vì logic xác minh được phép phức tạp hơn so với hiện trạng với một xác minh ECDSA duy nhất.

2. Chi phí gas: Chi phí gas cao hơn một chút so với các giao dịch thông thường (mặc dù trong một số trường hợp sử dụng, điều này được bù đắp bằng hỗ trợ đa hoạt động).

3. Một giao dịch tại một thời điểm: các tài khoản không thể xếp hàng và gửi nhiều giao dịch vào mempool. Tuy nhiên, khả năng thực hiện đa thao tác nguyên tử làm cho chức năng này ít cần thiết hơn nhiều.

Tài trợ với Người trả tiền:

Có một số trường hợp sử dụng chính cho các giao dịch tài trợ. Các trường hợp sử dụng mong muốn được trích dẫn phổ biến nhất là:

2. Cho phép người dùng thanh toán phí bằng mã thông báo ERC20 và hợp đồng đóng vai trò trung gian để tính phí ERC20 và thanh toán bằng ETH

Đề xuất có thể hỗ trợ chức năng này thông qua cơ chế quản trị viên thanh toán tích hợp. UserOperation có thể đặt một địa chỉ khác làm người trả tiền. Nếu quản trị viên thanh toán được đặt (nghĩa là khác không), thì trong bước xác minh, điểm nhập cũng gọi quản trị viên thanh toán để xác minh rằng quản trị viên thanh toán sẵn sàng thanh toán cho UserOperation. Nếu vậy, phí sẽ được khấu trừ từ ETH của giám đốc thanh toán được đặt cược trong điểm vào (việc rút tiền bị trì hoãn để bảo mật) thay vì ví. Trong bước thực thi, ví gọi như bình thường với calldata trong UserOperation, nhưng sau đó gọi người quản lý thanh toán bằng postOp.

tiêu đề phụ

Quy trình công việc ví dụ cho hai trường hợp sử dụng trên là:

2. Quản trị viên thanh toán xác minh xem ví của người gửi có đủ số dư ERC20 để thanh toán cho UserOperation hay không. Nếu vậy, người quản lý thanh toán chấp nhận và thanh toán phí ETH, sau đó yêu cầu mã thông báo ERC20 trong postOp như một khoản bồi thường (nếu postOp không thành công do UserOperation rút số dư ERC20, quá trình thực thi sẽ tiếp tục và postOp sẽ được gọi lại, vì vậy người quản lý thanh toán luôn được trả tiền). Lưu ý rằng hiện tại, điều này chỉ có thể được thực hiện nếu ERC20 là mã thông báo được bao bọc do chính quản trị viên thanh toán quản lý.

Đặc biệt lưu ý rằng trong trường hợp thứ hai, người giám sát thanh toán có thể phản ứng hoàn toàn và đôi khi có thể cân bằng lại và đặt lại các tham số. Đây là một cải tiến lớn so với các nỗ lực tài trợ hiện tại, vốn yêu cầu người trả tiền phải luôn trực tuyến để chủ động xử lý các giao dịch riêng lẻ.

tiêu đề phụ

Đề xuất này diễn ra như thế nào?