BTC

$96,000

5.73%

ETH

$3,521.91

3.97%

HTX

$0.{5}2273

5.23%

SOL

$198.17

3.05%

BNB

$710

3.05%

简体中文

繁體中文

English

Tiếng Việt

한국어

日本語

ภาษาไทย

Türkçe

Partnered With:

Vitalik: Con đường dẫn đến sự trừu tượng hóa tài khoản trong Ethereum

Vitalik Buterin

Đọc bài viết này mất 24 phút

Một con đường thực tế để đạt được kết quả tối ưu là bắt đầu hỗ trợ mạnh mẽ ERC-4337 trong thời gian ngắn và sau đó bổ sung EIP theo thời gian để giải quyết các điểm yếu của nó.

Tiêu đề gốc: "Vitalik: Con đường dẫn đến sự trừu tượng hóa tài khoản trong Ethereum"

Tác giả gốc: Vitalik Buterin

Bản tổng hợp ban đầu: Cháo qua đêm, đường đến metaverse

Tính trừu tượng của tài khoản cho phép chúng tôi sử dụng logic hợp đồng thông minh để chỉ định tác động của giao dịch cũng như việc thanh toán phí và logic xác minh. Điều này mang lại một số lợi ích bảo mật quan trọng, chẳng hạn như ví phục hồi thông minh và đa chữ ký, khả năng thay đổi khóa mà không cần thay đổi ví và bảo mật lượng tử.

Nhiều phương pháp trừu tượng hóa tài khoản đã được đề xuất và triển khai ở các mức độ khác nhau, xem: EIP-86 , EIP-2938‌ và bài viết này từ hai năm trước‌. Ngày nay, sự phát triển của các EIP này đang đi vào bế tắc khi các nhà phát triển muốn tập trung vào việc hợp nhất và phân chia, trong khi ERC-4337‌, một giải pháp thay thế không yêu cầu bất kỳ thay đổi đồng thuận nào, đã đạt được tiến bộ lớn.

ERC-4337 cố gắng đạt được điều tương tự như EIP-2938 thông qua các phương tiện giao thức bổ sung. Người dùng cần gửi các tin nhắn ngoài chuỗi được gọi là hoạt động của người dùng, được thu thập theo đợt và đóng gói thành một giao dịch duy nhất bởi người đề xuất khối hoặc người xây dựng tạo ra các gói cho giao dịch của người đề xuất khối. Người đề xuất hoặc người xây dựng chịu trách nhiệm sàng lọc các hoạt động để đảm bảo rằng họ chỉ chấp nhận các hoạt động được trả phí. Có một nhóm lưu trữ mempool riêng cho các hoạt động của người dùng và các nút được kết nối với nhóm lưu trữ này thực hiện xác minh cụ thể ERC-4337 để đảm bảo rằng các hoạt động của người dùng có thể trả phí trước khi chuyển tiếp.

ERC -4337 Trở thành một ERC hoàn toàn tự nguyện có thể làm được rất nhiều điều. Tuy nhiên, nó yếu hơn một giải pháp trong giao thức thực sự ở một số lĩnh vực chính:

- Hiện tại người dùng không thể nâng cấp nếu không di chuyển tất cả nội dung và hoạt động của họ sang tài khoản mới;

- Chi phí gas bổ sung (cơ bản UserOperation Hoạt động của người dùng ~42k, so với ~21k đối với các giao dịch cơ bản);

- được hưởng lợi ít hơn từ các kỹ thuật chống kiểm duyệt trong giao thức (ví dụ: crLists), nhắm mục tiêu vào các giao dịch và sẽ bỏ lỡ các hoạt động của người dùng

Một cách thực tế để đạt được kết quả tốt nhất là bắt đầu hỗ trợ mạnh mẽ ERC-4337 trong thời gian ngắn và sau đó là EIP được thêm vào theo thời gian để bù đắp cho những điểm yếu của chúng. Điều này không nhất thiết yêu cầu cam kết cụ thể về việc tuân thủ ERC-4337. Thay vào đó, hỗ trợ trong giao thức có thể được thiết kế tổng quát hơn và hỗ trợ ERC-4337 cũng như các lựa chọn thay thế và cải tiến của nó.

Ở đây tôi sẽ liệt kê một số EIP này và giải thích thứ tự chúng có thể được triển khai.

Chuyển đổi ví EOA thành ví hợp đồng thông minh

Để nâng cấp ví EOA hiện có lên ví ERC-4337, chúng tôi có thể tạo EIP để cho phép thực thi EOA. hoạt động của mã hợp đồng của nó. Một khi EOA thực hiện điều này, sự thay đổi là không thể đảo ngược. Kể từ thời điểm đó, tài khoản sẽ chỉ được sử dụng làm ví hợp đồng thông minh. May mắn thay, vì tài khoản ERC-4337 là proxy DELEGATECALL nên sau này, ví có thể được chuyển đổi thành hợp đồng thông minh tương thích với các ERC khác nếu muốn.

Có một số đề xuất về cách thực hiện quá trình nâng cấp này:

1. Loại giao dịch "thay thế mã"

Điều này vẫn chưa được giới thiệu là EIP chính thức, nhưng phương pháp này rất đơn giản: thêm loại giao dịch EIP-2718‌ mới, chỉ cần thêm Mã tài khoản được thay thế bằng calldata.

2. AUTH_USURP (EIP-5003)

EIP-5003‌ là một đề xuất mở rộng của EIP-3074‌ (AUTH và AUTHCALL) , giới thiệu AUTHUSURP opcode mới. Nếu địa chỉ EOA A đã ủy quyền cho một địa chỉ B khác hành động thay mặt nó bằng cơ chế EIP-3074 thì AUTHUSURP cho phép B đặt mã của A.

Phương pháp này phức tạp hơn lộ trình "thay thế mã" và chỉ có ý nghĩa nếu chúng tôi có ý định áp dụng EIP-3074.

Bắt buộc chuyển đổi

Về lâu dài, chúng tôi có thể muốn thực hiện một thử nghiệm để đơn giản hóa giao thức và biến hợp đồng thành loại tài khoản duy nhất, loại bỏ ECDSA khỏi giao thức. Một cách tiếp cận khả thi là thêm quy tắc ghi đè để bắt đầu từ một khối nhất định, các tài khoản không có mã sẽ được coi là tài khoản có mã "ví EOA ERC-4337" được tiêu chuẩn hóa cụ thể.

Điều này có thể được thực hiện thông qua quy trình "poking", trong đó bất kỳ giao dịch nào bắt nguồn từ EOA đều chuyển đổi nó và bất kỳ giao dịch nào chạm vào EOA có giá trị khác 0 chuyển đổi nó Chuyển đổi nó. Nó cũng có thể được thực hiện bằng cách đi qua toàn bộ tiểu bang trong một lần.

Câu hỏi

Xác minh ECRECOVER trong hợp đồng: Một số hợp đồng thông minh dựa trên giả định rằng nếu bạn cung cấp chữ ký của ECRECOVER cho một tài khoản cụ thể thì bạn sở hữu tài khoản đó. Nếu EOA được chuyển đổi thành hợp đồng và sau đó các khóa xác minh của nó được thay đổi, các khóa ban đầu vẫn có thể "đại diện" cho tài khoản trong các ngữ cảnh cụ thể đó. Điều này có thể được thực hiện bằng cách bắt đầu khuyến khích tất cả các dự án như vậy chuyển sang sử dụng xác minh EIP-1271 thay vì sử dụng ECRECOVER nếu tài khoản có mã.

Các tài khoản chưa được phát hiện: Một thách thức đối với chuyển đổi bắt buộc là các tài khoản sở hữu nội dung (như ERC20, ERC721, nhưng không phải ETH) nhưng chưa gửi hoặc đã nhận được bất kỳ tài khoản nào cho các giao dịch, vì vậy giao thức không thể phát hiện các tài khoản này một cách đáng tin cậy. Giao thức phải duy trì khả năng chuyển đổi vĩnh viễn các tài khoản đó sang ví mặc định hoặc cần phải có thời hạn hết hạn (ví dụ: 4 năm sau khi triển khai), sau đó các tài khoản chưa được chuyển đổi sẽ bị đốt cháy.

EOA chỉ kiểm tra tính không thể chuyển nhượng: Một số ứng dụng triển khai kiểm tra trong hợp đồng để chỉ cho phép EOA tương tác với chúng. Điều này thường được thực hiện để thực thi quyền không chuyển nhượng. Về cơ bản, đây là một ý tưởng tồi và không phù hợp với mục tiêu chuyển sang hợp đồng thông minh để cải thiện tính bảo mật. Do đó, cách làm này không nên được khuyến khích mà thay vào đó, nên khuyến khích các ứng dụng dựa vào quy trình khôi phục của chủ sở hữu ban đầu để khiến việc chuyển giao không thể thực hiện được.

Giảm chi phí gas

Ví ERC-4337 phải đối mặt với chi phí gas cao hơn (các hoạt động cơ bản của ERC-4337 tốn khoảng 42.000 gas, trong khi các giao dịch cơ bản thông thường cần 21.000 gas) vì những lý do sau:

1. Cần phải thanh toán một lượng lớn chi phí đọc/ghi bộ nhớ riêng lẻ. những chi phí này sẽ được gộp vào khoản thanh toán 21000 gas:

(1) Chỉnh sửa để bao gồm pubkey +khe lưu trữ không một lần (~ 5000);

(2) Chi phí dữ liệu cuộc gọi thao tác của người dùng (khoảng 4500, có thể giảm xuống khoảng 2500 thông qua nén);

(3) ECRECOVER (~3000);

(4) Truy cập lần đầu vào chính ví (~2600)

(5) Truy cập lần đầu vào tài khoản người nhận thanh toán (~2600)

(6) Chuyển ETH Chuyển sang tài khoản người nhận thanh toán (~9000)

(7) Chỉnh sửa bộ nhớ để trả phí (~5000)

(8) Truy cập bộ nhớ khe chứa tác nhân (~2100), Sau đó truy cập vào chính proxy (~2600); 2. Ngoài chi phí đọc/ghi lưu trữ nêu trên, hợp đồng còn cần thực thi "logic nghiệp vụ" (giải nén UserOperation, băm nó, xáo trộn các biến, v.v.)

3. Gas cần được tiêu thụ để trả tiền mua nhật ký (EOA không xuất bản nhật ký); p>

4. Chi phí tạo hợp đồng một lần (khoảng 32.000 gas, cộng thêm 200 gas cho mỗi byte mã trong proxy, cộng thêm 20.000 gas để thiết lập proxy address)

Nhiều vấn đề trong số này sẽ được giải quyết tự động trong cây Verkle nhân chứng chi phí gas EIP‌ và viết cải cách chi phí khí đốt EIP‌, thay thế một số lượng lớn trong số chúng bằng một hệ thống hợp lý hơn Chi phí lưu trữ. Ví dụ: pubkey và nonces có thể được lưu trữ trong các khe 0…63, giúp giảm chi phí truy cập chúng xuống dưới 1000. Người dùng sẽ trả ít hơn khi chuyển ETH và trả phí vì tài khoản đích và tài khoản nhận chỉ cần được truy cập một lần lần đầu tiên.

Có nhiều EIP khác có thể giúp chúng tôi đơn giản hóa. Ví dụ:

Việc cấm logic hợp đồng thông minh sử dụng ERC tự nguyện của vị trí 0 sẽ cho phép nó được sử dụng cho proxy lưu trữ, do đó cho phép nó được hưởng lợi từ chi phí gas rẻ hơn.

Trường "địa chỉ mã" có thể giúp việc ủy quyền trở nên dễ dàng hơn và tiêu tốn ít xăng hơn.

Tính năng biên dịch trước "nén nhanh" giúp sử dụng các đối tượng ABI dễ dàng hơn mà không phải trả chi phí gas calldata cho tất cả byte 0.

Đây là một lĩnh vực cần được nghiên cứu nhiều hơn.

crLists

Đây là một vấn đề lâu dài, vì crLists chỉ thực sự hoạt động nếu tính năng phân tách trình xây dựng/đề xuất giao thức đầy đủ được kích hoạt. Thách thức là chúng tôi muốn những người đề xuất có thể xác định các hành động của người dùng "xứng đáng" được đưa vào (tức là họ trả đủ tiền) để giao thức có thể buộc họ được đưa vào khối tiếp theo nếu còn chỗ.

Điều này đòi hỏi phải làm rõ các khái niệm "xác minh" và "thực thi" trong giao thức. Đối với hành động của người dùng, phải có cách xác định để xác thực hành động và cách xác định để thực hiện hành động, sao cho nếu một hành động được xác thực, nỗ lực thực hiện hành động đó sẽ được đảm bảo trả tiền trừ khi trạng thái đang đọc được sửa đổi trong quá trình xác nhận. Các hoạt động này có thể được triển khai bằng cách nhúng các phương thức ABI hoặc bằng cách thêm phần EOF chuyên dụng nếu EOF EIP được triển khai.

May mắn thay, điều này không đòi hỏi chúng tôi phải coi ERC-4337 là tiêu chuẩn cuối cùng; khái niệm yếu hơn được hỗ trợ bởi ERC-4337 và có thể dễ dàng được hỗ trợ bởi các ERC khác nhau.

Lý do là vì độ phức tạp của ERC-4337 và EIP-2938 phần lớn liên quan đến việc giải quyết Vấn đề với khả năng chống DoS lớn hơn là không thể thực hiện một thao tác hủy hàng trăm thao tác khác, vì điều này sẽ cho phép các cuộc tấn công spam giao dịch rẻ tiền trên mempool. Điều này yêu cầu áp đặt các hạn chế đối với những gì có thể truy cập được bằng xác minh tài khoản. Ở đây, chúng ta có thể làm điều gì đó đơn giản hơn: chỉ cần ghi lại những đối tượng trạng thái nào đã được chạm vào trong quá trình xác thực và không cần đưa vào nếu bất kỳ đối tượng trạng thái nào trong số này đã được chỉnh sửa.

Điều này cho phép các tài khoản cá nhân tự lựa chọn sự cân bằng giữa khả năng chống kiểm duyệt và tính linh hoạt. Trong những trường hợp cực đoan, tài khoản có thể trả phí thông qua Uniswap trong quá trình xác minh nếu họ muốn, nhưng vì bất kỳ ai cũng có thể gửi các giao dịch ảnh hưởng đến trạng thái của Uniswap nên thực tế không có đảm bảo chống kiểm duyệt nào cho những tài khoản đó.

Bản phác thảo sơ bộ của thiết kế crList như sau:

Các đề xuất có thể chứa một crList chỉ định danh sách các thao tác cần đưa vào và danh sách các cặp đối tượng trạng thái (khóa, giá trị) sẽ được đọc bởi mỗi thao tác. Người xây dựng (hoặc bất kỳ ai khác) chấp nhận crList phải kiểm tra xem tất cả các hoạt động có vượt qua kiểm tra xác thực hay không.

Khối này bắt buộc phải thực thi mọi thao tác trong crList, trừ khi khối không còn đủ gas hoặc trạng thái hiện tại tại thời điểm thực thi có Một trong số các đối tượng trạng thái được thao tác này đọc đã được chỉnh sửa.

Sự phức tạp còn lại của ERC-4337 sẽ chỉ được sử dụng để bảo mật mempool. Về nguyên tắc, có thể có nhiều ERC cạnh tranh đạt được mục tiêu này theo những cách khác nhau, miễn là tất cả chúng đều tuân thủ cùng các tiêu chuẩn xác minh và thực thi.

Một nhược điểm của phương pháp này là nó không hoàn toàn tương thích với việc tổng hợp chữ ký (như ERC- 4337 đang cố gắng thực hiện điều đó): Vì giao thức không "hiểu" sơ đồ tổng hợp nên nó không thể ép buộc tổng hợp và trình tạo độc hại có thể bao gồm các hoạt động không được tổng hợp và buộc người gửi phải trả toàn bộ gas cho chúng. Nhưng sự bất tiện này được cho là vừa phải.

Lộ trình khả thi

Ngắn hạn

Đưa ERC-4337 vào sản xuất hoàn chỉnh. Lý tưởng nhất là điều này có thể được mở rộng bằng cách sử dụng khả năng tổng hợp chữ ký để đạt được tính thân thiện với việc tổng hợp.

Cần có ví trình duyệt dễ sử dụng có giao diện với ERC-4337.

Cân nhắc triển khai tính năng tổng hợp và nén chữ ký để làm cho ERC-4337 thân thiện hơn với L2;

Hướng dẫn hệ sinh thái ERC-4337 trong giao thức L2, nơi vấn đề về chi phí gas sẽ ít hơn;

Trung hạn

Triển khai cây Verkle và thêm EIP để giảm chi phí gas;

Thêm chuyển đổi EOA-to-ERC-4337 tùy chọn;

Thêm logic crList cùng lúc hoặc ngay sau khi ra mắt PBS;

Dài hạn

Cân nhắc việc tuyển chọn;

Các lựa chọn thay thế có thể có

1. Hãy cân nhắc viết EIP chứa các tài khoản và giao dịch tương đương ERC-4337 ở lớp giao thức, đồng thời thúc đẩy việc áp dụng nó trong L2;

2. Sử dụng giải pháp chống kiểm duyệt hoạt động thông qua các khối phụ để loại bỏ nhu cầu giao thức Ethereum có thể đọc được các hoạt động của người dùng;