Giải thích chi tiết về đề xuất mới nhất của Vitalik EIP-7702: nó có thể thay thế EIP-3074

Tác giả: Vitalik, người sáng lập Ethereum; Bản dịch: xiaozou@金财经

1, Tổng quan

Thêm loại giao dịch mới (loại giao dịch) có thêm trường mã_hợp đồng và chữ ký, đồng thời sẽ ký vào tài khoản trong quá trình giao dịch (không nhất thiết phải giống như txt .origin) Đã chuyển đổi thành thông minh ví hợp đồng, mục tiêu là cung cấp chức năng tương tự như EIP-3074.

2, động lực

Thêm các cải tiến chức năng ngắn hạn sang EOA, tăng khả năng sử dụng của ứng dụng và trong một số trường hợp hỗ trợ cải thiện bảo mật, điều được nhiều người rất quan tâm. Ba ứng dụng cụ thể như sau:

• Xử lý hàng loạt: cho phép cùng một người dùng thực hiện nhiều thao tác trong một giao dịch nguyên tử. Một ví dụ phổ biến là ERC-20 được sử dụng lại sau khi được phê duyệt, đây là quy trình làm việc phổ biến trong các sàn giao dịch phi tập trung ngày nay yêu cầu hai giao dịch. Các trường hợp sử dụng nâng cao để xử lý hàng loạt đôi khi liên quan đến sự phụ thuộc: đầu ra của thao tác đầu tiên là một phần đầu vào của thao tác thứ hai.

• Tài trợ: Tài khoản X thay mặt Tài khoản Y thanh toán phí giao dịch. Tài khoản

• Hạ cấp đặc quyền: Người dùng có thể ký các khóa con và cấp cho họ các quyền cụ thể yếu hơn quyền truy cập toàn cầu của tài khoản. Nhiều hơn thế nữa. Ví dụ: bạn có thể tưởng tượng quyền này được thanh toán bằng mã thông báo ERC-20 thay vì ETH hoặc chi tiêu 1% tổng số dư của bạn mỗi ngày hoặc chỉ tương tác với các ứng dụng cụ thể.

EIP-3074 giải quyết tất cả những thách thức trong trường hợp sử dụng này, nhưng vẫn còn những lo ngại về khả năng tương thích trong tương lai:

• Nó giới thiệu hai mã opcode AUTH và AUTHCALL, vô dụng trong Thế giới "kết thúc trừu tượng hóa tài khoản" nơi tất cả người dùng cuối cùng đều sử dụng ví hợp đồng thông minh (điều này dường như cuối cùng cũng xảy ra, ít nhất là vì cuối cùng máy tính lượng tử sẽ chấm dứt ECDSA được EOA sử dụng).

• Nó sẽ dẫn đến sự phát triển của hệ sinh thái "hợp đồng người gọi", độc lập với Ví "hợp đồng thông minh"" hệ sinh thái, dẫn đến những nỗ lực rải rác và không có sức mạnh tổng hợp.

Mục tiêu của EIP này là cho phép tất cả các trường hợp sử dụng EIP-3074 không gặp phải hai vấn đề này.

3, thông số kỹ thuật

Từ khóa trong tài liệu này "PHẢI ", "PHẢI KHÔNG", "BẮT BUỘC", "SHALL", "SHALL KHÔNG", "NÊN", "KHÔNG NÊN", "ĐỀ XUẤT", "CÓ THỂ" và "TÙY CHỌN" được diễn giải nhất quán như được mô tả trong RFC 2119.

Thông số:

• FORK_BLKNUM = TBD

• TX_TYPE = TBD

• MAGIC = TBD

• PER_CONTRACT_CODE_BASE_COST = 5000

Bắt đầu từ FORK_BLOCK_NUMBER, giao dịch EIP-2718 mới được giới thiệu, Loại giao dịch = TX_TYPE(TBD).

Tải trọng giao dịch EIP-2718 của giao dịch này là:

rlp([chain_id, nonce , max_priority_fee_per_gas, max_fee_per_gas, gas_limit, đích, dữ liệu, access_list, [[contract_code, y_parity, r, s], ...], signature_y_parity, signature_r, signature_s])

Chi phí vốn có của các giao dịch mới được kế thừa từ EIP-2930, cụ thể là: 21000 + 16 * byte dữ liệu cuộc gọi khác 0 + 4 * byte dữ liệu cuộc gọi bằng 0 + 1900 * số lượng khóa lưu trữ danh sách truy cập + 2400 * số địa chỉ danh sách truy cập

Ngoài ra, chúng tôi thêm 16 * byte dữ liệu cuộc gọi khác 0 + 4 * byte dữ liệu cuộc gọi bằng 0 trên mỗi mã_hợp đồng, cộng với PER_CONTRACT_CODE_BASE_COST nhân với độ dài của mảng mã_hợp đồng.

Khi bắt đầu thực hiện giao dịch, với mỗi [contract_code, y_parity, r, s] tuple:

• Đặt người ký = ecrecover(keccak(MAGIC + Contract_code), y_parity, r, s] < /p>

• Xác minh rằng mã hợp đồng của người ký có trống không

• Đặt mã hợp đồng của người ký thành Contract_code

Khi kết thúc giao dịch, đặt lại hợp đồng_code của mỗi người ký Trống

Lưu ý rằng người ký tên của bất kỳ chữ ký hợp đồng nào và .origin của giao dịch có thể khác nhau

4, nguyên tắc cơ bản

(1)EIP-3074Chuyển đổi các trường hợp sử dụng

Trong thiết kế này, các quy trình công việc EIP-3074 hiện có có thể được chuyển đổi mà không cần nỗ lực nhiều. Cụ thể là AUTH và AUTHCALL. sẽ được thay thế bằng lệnh gọi tới EOA này, hợp đồng_code sẽ là ví của người dùng (để tiết kiệm xăng, có thể là người chuyển tiếp DELEGATECALL) và sẽ hiển thị hai chức năng, xác minh và thực thi ul class=" list-paddingleft-2" style=. "list-style-type: disc;">

Do đó, việc chuyển đổi từ "quy trình làm việc EIP-3074 hiện có" sang quy trình làm việc theo sơ đồ mới này là rất đơn giản.

(2) Chuyển tiếp tương thích với các bản tóm tắt tài khoản trong tương lai

EIP được thiết kế để có mức độ tương thích rất cao với tương lai của việc trừu tượng hóa tài khoản mà không lưu giữ quá mức bất kỳ chi tiết nào của ERC-4337 hoặc RIP-7560.

Chi tiết như sau:

• Mã hợp đồng mà người dùng cần ký có thể là mã ví ERC-4337 hiện có.

• Các "đường dẫn mã" được sử dụng trong nhiều trường hợp (mặc dù có lẽ không phải tất cả) vẫn tiếp tục trong lĩnh vực ví hợp đồng thông minh thuần túy Mã những con đường "chỉ hoạt động".

• Do đó, nó tránh được vấn đề "tạo ra hai hệ sinh thái mã độc lập" vì ở một mức độ lớn chúng sẽ là cùng một hệ sinh thái. Có thể có một số quy trình công việc cần được kết hợp trong giải pháp này để có thể hoạt động tốt hơn trong nhiều môi trường "bản địa hơn" khác nhau trong phần Kết thúc trừu tượng tài khoản, nhưng đó chỉ là một phần tương đối nhỏ.

• Nó không yêu cầu thêm bất kỳ opcode nào và sẽ trở nên vô dụng trong thế giới hậu EOA.

• Nó cho phép EOA tạm thời chuyển đổi thành hợp đồng để đưa vào gói giao dịch ERC-4337.

• Sau khi được triển khai, EIP-5003 sẽ "chỉ là một dòng mã": chỉ cần thêm cờ và không thêm cờ khi kết thúc giao dịch Cài đặt mã trống.

5, khả năng tương thích ngược

EIP này phá vỡ định kiến ​​rằng số dư tài khoản chỉ có thể bị giảm bởi các giao dịch bắt nguồn từ tài khoản đó. Điều này có ý nghĩa đối với việc thiết kế nhóm bộ nhớ và các EIP khác, chẳng hạn như danh sách bao gồm. Tuy nhiên, những vấn đề này thường xảy ra với bất kỳ đề xuất nào cung cấp chức năng tương tự, bao gồm cả EIP-3074.

6, mối lo ngại về bảo mật

Giới thiệu về EIP-3074 Nhiều mối lo ngại về an ninh là phổ biến. Đặc biệt, ví người dùng cần hết sức thận trọng khi ký hợp đồng_code.