Tổng hợp văn bản gốc: The Way of DeFi

Tổng hợp văn bản gốc: The Way of DeFi

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 các giao dịch, cũng như thanh toán phí và logic xác thực. Đ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í khôi phục 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 cách tiếp cận để 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 đã bị đình trệ do các nhà phát triển muốn tập trung vào việc hợp nhất và phân mảnh, 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 bởi những người đề xuất khối hoặc nhà xây dựng, những người tạo ra các gói cho những người đề xuất khối và đóng gói thành một giao dịch. Người đề xuất hoặc người xây dựng chịu trách nhiệm lọc các hoạt động để đảm bảo họ chỉ chấp nhận các hoạt động trả phí. Có một nhóm ghi nhớ riêng cho các hành động của người dùng và các nút kết nối với nhóm này sẽ thực hiện xác thực dành riêng cho ERC-4337 để đảm bảo các hành động của người dùng được thanh toán trước khi chúng được chuyển tiếp.

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

1. Người dùng hiện tại không thể nâng cấp mà không chuyển tất cả tài sản và hoạt động của họ sang tài khoản mới;

2. Chi phí gas bổ sung(Một thao tác người dùng UserOperation cơ bản là khoảng 42k, trong khi một giao dịch cơ bản là khoảng 21k);

3. Ít lợi ích 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 các giao dịch và bỏ lỡ các hoạt động của người dùng

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

tiêu đề phụ

Chuyển đổi ví EOA sang 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 một EIP cho phép EOA thực hiện các hoạt động đặt mã hợp đồng. Khi EOA đã đạt được điều này, quá trình chuyển đổi là không thể đảo ngược. Kể từ đó, tài khoản sẽ chỉ được sử dụng làm ví hợp đồng thông minh. May mắn thay, vì các tài khoản ERC-4337 là proxy của DELEGATECALL, ví sau này có thể được chuyển đổi sang các hợp đồng thông minh tương thích với ERC khác nếu muốn.

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

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

Điều này chưa được giới thiệu dưới dạng 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 thay thế account_code bằng calldata.

2、AUTH_USURP (EIP-5003)

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

tiêu đề phụ

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

Về lâu dài, chúng tôi có thể muốn thực hiện chuyển đổi bắt buộc để đơ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 đè, theo đó bắt đầu từ một khối nhất định, các tài khoản không có mã được coi là tài khoản có mã "ví ERC-4337 EOA" được tiêu chuẩn hóa cụ thể.

câu hỏi

câu hỏi

1. 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ý 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 đó khóa xác minh của nó bị thay đổi, thì khóa ban đầu vẫn có thể "đại diện" cho tài khoản trong các ngữ cảnh cụ thể này. Đ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ì ECRECOVER nếu tài khoản có mã.

2. Tài khoản chưa được phát hiện:Một thách thức với chuyển đổi bắt buộc là các tài khoản sở hữu nội dung (chẳng hạn như ERC20, ERC721, nhưng không phải ETH) nhưng chưa gửi hoặc nhận bất kỳ giao dịch nào, 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 (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.

3. EOA chỉ kiểm tra khả năng không thể chuyển nhượng:tiêu đề phụ

Giảm chi phí xăng

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

1. Bạn cần phải trả nhiều chi phí đọc/ghi bộ nhớ riêng lẻ. Trong trường hợp EOA, những chi phí này sẽ được gộp thành một khoản thanh toán duy nhất là 21000 gas:

(1) Chỉnh sửa khe lưu trữ chứa pubkey+nonce (~5000);

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

（3）ECRECOVER (~3000)；

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

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

(6) Chuyển ETH vào tài khoản của người thụ hưởng (~9000)

(7) Chỉnh sửa dung lượng để trả phí (~5000)

(8) Truy cập khe lưu trữ chứa tác nhân (~2100), sau đó truy cập vào chính tác nhân đó (~2600);

2. Ngoài chi phí đọc/ghi bộ nhớ ở trên, hợp đồng cũng 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. Cần tiêu thụ gas để trả phí nhật ký (EOA không công bố nhật ký);

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 để đặt địa chỉ proxy)

Nhiều vấn đề trong số này sẽ tự động được giải quyết trong EIP chi phí gas chứng kiến ​​cây Verkle và viết EIP cải cách chi phí gas, thay thế chi phí lưu trữ lớn bằng một hệ thống gọn gàng hơn. Ví dụ: pubkey và nonce có thể được lưu trữ trong các vị trí 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 tiền 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 truy cập một lần lần đầu tiên.

Có thêm EIP giúp chúng ta đơn giản hóa. Ví dụ:

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

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

3. quá trình biên dịch trước "nén linh hoạt" giúp sử dụng các đối tượng ABI dễ dàng hơn mà không phải trả chi phí khí cuộc gọi cho tất cả các byte bằng không.

tiêu đề phụ

crLists

Đây là một vấn đề lâu dài, bởi vì crLists chỉ thực sự được áp dụng khi một lược đồ phân tách người đề xuất/người xây dựng 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ả đủ phí) để giao thức có thể buộc họ được đưa vào khối tiếp theo có chỗ.

Điều này đòi hỏi các khái niệm về "xác thực" và "thực thi" phải được làm rõ trong giao thức. Đối với các hành động của người dùng, phải có một cách xác định để xác thực hành động và một 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, các nỗ lực thực hiện hành động đó sẽ được đảm bảo thanh toán trừ khi Trạng thái đọc được sửa đổi trong quá trình xác thực . Các hoạt động này có thể được triển khai bằng cách nhúng các phương pháp 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 yêu cầu chúng tôi phải coi ERC-4337 là tiêu chuẩn cuối cùng mà thay vào đó kết hợp một khái niệm yếu hơn được hỗ trợ bởi ERC-4337 mà có thể dễ dàng được hỗ trợ bởi các ERC phần lớn khác.

Lý do là sự 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 đề kháng DoS mạnh hơn: không thể thực hiện một thao tác hủy bỏ hàng trăm thao tác khác, vì điều này sẽ tạo ra rác giá rẻ của giao dịch mempool tấn công. Điều này yêu cầu áp đặt các hạn chế đối với những gì xác minh tài khoản có thể truy cập. Ở đâ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 xem có bất kỳ đối tượng trạng thái nào đã được chỉnh sửa hay không.

Điều này cho phép các tài khoản cá nhân lựa chọn sự đánh đổi của riêng họ 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í trong quá trình xác minh qua Uniswap 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 những tài khoản đó thực sự không có bảo đảm chống kiểm duyệt.

Các phác thảo chung của thiết kế crList như sau:

1. Một đề xuất có thể chứa một crList chỉ định danh sách các thao tác cần bao gồm và danh sách các cặp đối tượng trạng thái (khóa, giá trị) mà mỗi thao tác đọc. Trình tạo (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.

2. Khối được yêu cầu thực hiện mọi hoạt động 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 hiện đã chỉnh sửa một trong các đối tượng trạng thái được đọc bởi hoạt động.

Độ phức tạp còn lại của ERC-4337 sẽ chỉ được sử dụng cho 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 một tiêu chuẩn xác minh và thực thi.

tiêu đề phụ

lộ trình có thể

thời gian ngắn

1. Đưa ERC-4337 vào sản xuất đầy đủ. Lý tưởng nhất là điều này có thể được mở rộng với chức năng tổng hợp chữ ký để tạo sự thân thiện với bản tổng hợp.

2. Nên có một ví trình duyệt dễ sử dụng có giao diện với ERC-4337.

3. Xem xét triển khai tổng hợp và nén chữ ký để làm cho ERC-4337 thân thiện hơn với L2;

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

trung hạn

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

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

3. Thêm logic crList cùng lúc hoặc ngay sau khi khởi chạy PBS;

dài

1. tiêu đề phụ

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

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

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