Trừu tượng hóa tài khoản nhằm cải thiện trải nghiệm người dùng và nhà phát triển trên toàn bộ hệ sinh thái Ethereum. Bên cạnh việc làm cho trải nghiệm trên chuỗi truyền thông trở nên dễ tiếp cận và thú vị hơn đối với người dùng, nó cũng giúp nhà phát triển có thể thực hiện những việc mạnh mẽ hơn trên Ethereum và phục vụ người dùng một cách ý nghĩa hơn.

Phân loại của chúng tôi về các phương pháp trừu tượng hóa tài khoản như sau:

1. Nâng cao/tính lập trình EOA: Điều này bao gồm các thay đổi cấp độ giao thức cho phép EOA (Externally Owned Accounts) định nghĩa lại phần logic thực thi của các quy tắc hợp lệ của họ. Như đã biết trong cộng đồng phát triển, EOA là các tài khoản thường liên kết với người dùng cuối. Do đó, các giải pháp thuộc phạm vi này sẽ trao quyền cho các tài khoản người dùng cuối để kiểm soát hơn về loại hành động mà họ có thể ủy quyền, so với cách mà điều này có thể được quản lý ngày nay.
2. Chuyển đổi/migra EOA: Phương pháp này bao gồm các đề xuất tìm kiếm việc chuyển đổi hoàn chỉnh từ EOA sang CA (tài khoản hợp đồng). Ý tưởng chính của phương pháp này là tài khoản hợp đồng đã cung cấp hầu hết các lợi ích được cung cấp bởi tài khoản thông minh, vì vậy không cần phức tạp hóa thêm; mọi người chỉ cần sử dụng tài khoản hợp đồng làm tài khoản chính của họ (qua ví hợp đồng thông minh).

Phương pháp này có cơ chế cho phép một EOA chuyển đổi thành một CA, mà không cần di chuyển tài sản của nó, như EIP 7377 và EIP 5003(khi xem xét cùng với EIP 3074).

1. Tài Khoản Thông Minh: Nhóm các đề xuất này bao gồm các thiết kế cho phép cả EOAs và CAs hoạt động như 'tài khoản thông minh' bằng cách cho phép họ hoàn toàn xác định lại quy tắc hiệu lực của mình.

Trước đây đã có nhiều đề xuất được đưa ra để tạo ra các tài khoản thông minh và trừu tượng hóa tài khoản được ghi nhận ở mức giao thức; EIP-86 và EIP-2938Những điều này là một số trong số những điều được trích dẫn nhiều nhất. Tuy nhiên, đã có rất nhiều phản đối do sự phức tạp được cho là đã được giới thiệu bởi thiết kế này và ý kiến ​​phần lớn rằng Ethereum chưa sẵn sàng cho sự phức tạp như vậy.

Sau khi Vitalik hồi sinh chủ đề sau khi The Merge,ERC-4337được đề xuất như một phiên bản tùy chọn của tiêu chuẩn tài khoản thông minh, tương tự như cơ sở hạ tầng PBS (Tách Biệt Người Đề Xuất-Xây Dựng) cho MEV (Giá Trị Có Thể Trích Xuất Tối Đa). Do đó, người dùng muốn truy cập các lợi ích của tài khoản thông minh có thể đơn giản sử dụng đường ống ERC-4337 để định lại logic tài khoản và quy tắc hợp lệ của giao dịch trong các cấu trúc được gọi là Một Phép Vận Hành Người Dùng (hoặc UserOps tóm gọn).

ERC 4337 mang lại những lợi ích của tài khoản thông minh cho Ethereum hiện tại mà không khắc phục bất kỳ sự phức tạp nào, bằng cách hoạt động như một lựa chọn ngoài giao thức cho các tài khoản thông minh đã được khắc phục. Tuy nhiên, điều này không có nghĩa là cơ sở hạ tầng hiện tại là tối ưu vì sự phức tạp của nó vẫn là một điểm yếu đáng kể.

Để giải quyết sự phức tạp này, RIP 7560được soạn thảo như một phiên bản được khắc sâu của cơ sở hạ tầng ERC 4337 trên Ethereum và L2 của nó, để nó kế thừa các chương trình chống sybil của mạng thay vì phải định nghĩa một tập hợp quy tắc mới (như ERC 4337 với ERC 7562.

Trong báo cáo này, chúng tôi sẽ tập trung khám phá tính khả chương trình của EOA, đánh giá các EIP khác nhau mô tả các giải pháp theo hướng này và thảo luận những ưu điểm và nhược điểm của chúng. Trong phần 2 và 3 của loạt bài viết này, chúng tôi sẽ bao gồm hai lớp tiếp cận còn lại của trừu tượng hóa tài khoản được khai thác trong Ethereum.

Một Bài Giảng Về Tài Khoản và Giao Dịch Ethereum

Để tìm hiểu những gì có thể được trừu tượng hóa, chúng ta cần có một bức tranh (khoảng) đầy đủ về thiết kế tài khoản hiện tại. Phần này chủ yếu sẽ phục vụ như một bài ôn tập về tài khoản trên Ethereum thực sự là gì, và cách giao dịch của họ được xác minh và thực thi.

Tài khoản Ethereum là các thực thể có số dư ether (ETH) và có khả năng gửi giao dịch trên blockchain Ethereum. Chúng được đại diện bằng một địa chỉ hexa 42 ký tự, đóng vai trò như một con trỏ duy nhất đến số dư và giao dịch của tài khoản.

Một địa chỉ hoạt động như một chìa khóa vào bộ ba trạng thái của blockchain. Các nút lá của trie này là cấu trúc dữ liệu tài khoản có thể được phân tách thành bốn trường:

1. nonce: Một bộ đếm tuyến tính được sử dụng để chỉ số lượng giao dịch đi ra được khởi xướng bởi một tài khoản. Điều này cũng rất quan trọng trong việc ngăn chặn các cuộc tấn công phát lại.
2. balance: Số lượng ether (ETH) được định giá bằng wei mà tài khoản sở hữu.
3. codeHash: Một hash của mã nguồn có thể thực thi trên EVM (Ethereum Virtual Machine) nằm trong một tài khoản. EVM là môi trường thực thi đặc biệt dành riêng cho Ethereum, có trách nhiệm xử lý các chuyển đổi trạng thái phức tạp hơn các giao dịch đơn giản "send". Nội dung mã nguồn của một tài khoản được lập trình không thể thay đổi để thực hiện các hình thái chuyển đổi trạng thái cụ thể trên blockchain Ethereum, thông qua EVM.
4. storageHash: Một hash của gốc lưu trữ của một tài khoản, được sử dụng để đại diện cho nội dung lưu trữ của một tài khoản dưới dạng một hash 256-bit của nút gốc của cây merkle patricia trie. Đơn giản, đó là một hash của dữ liệu biến trạng thái liên quan đến nội dung mã của một tài khoản.

Nội dung của bốn trường này được sử dụng để xác định loại tài khoản và cuối cùng là để xác định phạm vi của chức năng của nó. Do đó, hai loại tài khoản Ethereum là:

1. Tài Khoản Sở Hữu Bên Ngoài (EOAs) - được khởi tạo như một cặp khóa mật mã:

• Một khóa riêng tư có thể được mã hóa và chứng minh ngẫu nhiên 64 ký tự hex, và bản đối tác bổ sung của nó;
• Một khóa công khai được suy ra từ khóa riêng sử dụng ECDSA (Thuật toán Chữ ký Số học Đường cong Elliptic).

EOAs có các trường codeHash và storageHash trống và chỉ có thể được kiểm soát bởi bất kỳ ai nắm giữ các khóa riêng. Địa chỉ của họ có thể được lấy từ khóa công khai tương ứng bằng cách thêm tiền tố “0x” vào hai mươi ký tự cuối cùng của mã băm keccak-256 của khóa công khai của tài khoản.

1. Tài Khoản Hợp Đồng (CAs) - chỉ có thể được tạo ra bởi một EOA hiện có. Chúng được khởi tạo do một EOA triển khai nội dung mã thực thi trên EVM. Nội dung mã này (được lưu trữ dưới dạng codeHash) được thể hiện trong EVM và chịu trách nhiệm điều khiển tài khoản bằng cách xác định logic và tương tác của nó.

Các giao dịch của họ hoàn toàn dựa vào việc rút ra và dựa trên logic mã đã triển khai của họ.

Vì những tài khoản này chỉ có thể được kiểm soát bởi nội dung mã của họ, họ không cần một khóa riêng tư và chỉ có một khóa công khai. Do đó, bất kỳ đại lý nào có khả năng cập nhật/thay đổi nội dung mã của tài khoản hợp đồng đều có thể truy cập vào số dư của nó.

Địa chỉ của một CA được suy ra từ địa chỉ người tạo và nonce của nó cho đến thời điểm triển khai hợp đồng.

Giao dịch

Gần đây, chúng tôi đã mô tả các tài khoản như các thực thể có khả năng gửi giao dịch trên Ethereum. Chúng ta có thể hiểu rằng một mục đích chính của một tài khoản là gửi và nhận giao dịch, trong khi blockchain hoạt động như một sổ cái ghi lại lịch sử giao dịch cũng như mô tả cách giao dịch thay đổi các trường tài khoản dựa trên các quy tắc được mô tả trong quy định của giao thức blockchain.

Vậy những 'giao dịch' này là gì?

Giao dịch là các hoạt động được gửi từ một tài khoản, gây ra sự thay đổi trong 'trạng thái' của mạng. Chúng là các hướng dẫn được ký số mật mã từ các tài khoản, gây ra cập nhật trạng thái trên toàn mạng khi được thực thi.

Không được phép đi kèm với những động cơ sai lệch, để giải quyết vấn đề này, cần phải định nghĩa quy định nghiêm ngặt (hoặc quy tắc hợp lệ) cho sự tương tác trong môi trường như vậy.

Trong ngữ cảnh này, các giao dịch phải tuân theo những quy tắc hợp lệ cụ thể để được xem xét là hợp lệ và được thực hiện. Hầu hết những quy tắc hợp lệ này được thực hiện thông qua các ràng buộc đặt ra trên tài khoản gửi giao dịch, và thay đổi dựa trên loại tài khoản đó là gì.

Tài Khoản và Tính Hợp Lệ của Giao Dịch

Trên Ethereum, EOAs được tối ưu hóa cho tính sử dụng vì chúng đối mặt trực tiếp với người dùng cuối. Chúng có khả năng gửi giao dịch theo một cách cụ thể và hoạt động hoàn toàn tự động. Chúng cũng có thể được tạo ra cục bộ, phương pháp phổ biến hơn là sử dụng các nhà cung cấp ví như MetaMask, Rainbow, Rabby, v.v.

Trong khi đó, tài khoản hợp đồng chỉ có thể gửi giao dịch được cho phép bởi logic của chúng, đáp ứng khi được “gọi”. Ngoài ra, chúng chỉ có thể được tạo bởi một EOA có số dư đủ để trả tiền cho việc lưu trữ trạng thái của nó.

Một mô tả cao cấp hơn sẽ là EOAs chỉ có thể giữ số dư, trong khi CAs có thể giữ cả số dư và logic quy định cách mà số dư này có thể được chi tiêu.

Những thuộc tính này do các thông số logic sau định nghĩa các quy tắc mà các giao dịch của một tài khoản phải tuân thủ:

1. Authentication logic - Được sử dụng để xác định cách một tài khoản chứng minh danh tính của mình cho mạng khi thay đổi số dư và/hoặc logic.
2. Logic quyền hạn - Được sử dụng để định nghĩa chính sách truy cập của tài khoản, từ nào có thể truy cập và thay đổi số dư và/hoặc logic của tài khoản.
3. Logic Nonce - xác định thứ tự thực hiện giao dịch từ một tài khoản.
4. Logic thanh toán Gas - Được sử dụng để định nghĩa bên chị đủ vào việc thanh toán phí gas của giao dịch.
5. Logic thực thi - Được sử dụng để xác định những hình thức giao dịch mà một tài khoản có thể gửi, hoặc cách thức thực hiện giao dịch.

Các tham số này được thiết kế để cứng nhắc cho các tài khoản EOA như sau:

• Xác thực và ủy quyền được cung cấp bởi một khóa riêng dựa trên ECDSA, tức là, người dùng muốn gửi giao dịch từ EOA của họ phải sử dụng khóa riêng của họ để truy cập vào tài khoản và chứng minh họ có quyền thực hiện bất kỳ thay đổi nào đối với số dư của nó.
• Logic nonce thực hiện một kế hoạch đếm tuần tự, cho phép chỉ có một giao dịch cho mỗi nonce duy nhất được thực hiện tuần tự mỗi tài khoản.
• Logic thanh toán gas quy định rằng phí gas cho giao dịch phải được giải quyết bởi tài khoản gửi/nguồn gốc.
• Logic thực thi chỉ định rằng các EOA chỉ có thể gửi các biểu mẫu giao dịch sau đây:

1. Chuyển khoản thường xuyên giữa hai tài khoản ngoại vi.
2. Triển khai hợp đồng.
3. các cuộc gọi hợp đồng nhằm vào logic của một tài khoản hợp đồng đã triển khai.

Nói chung, logic thực thi của EOA hạn chế chúng chỉ thực hiện một giao dịch cho mỗi chữ ký hợp lệ.

Tuy nhiên, CAs có nhiều linh hoạt hơn với các tham số này:

• Xác thực không cần thiết, vì giao dịch của họ có tính chất kết quả/rút ra.
• Ủy quyền cho CAs có thể có hai hình thức:

1. Khả năng "gọi" mã nội dung của các CAs (hoặc thực thi hợp đồng thông minh của nó), phụ thuộc vào logic của hợp đồng thông minh của tài khoản và các điều kiện không đổi của nó.
2. Khả năng thay đổi mã nội dung của CAs, phụ thuộc chủ yếu vào việc mã nội dung có thể nâng cấp hay không.

Trong hầu hết các trường hợp thực tế, logic được sử dụng trong trường hợp này là một hệ thống chữ ký đa chữ ký mà quy định rằng cần có M chữ ký hợp lệ trong tổng số N chữ ký (trong đó M < N) từ các tài khoản cụ thể (thường là EOAs) để việc thay đổi logic của CA được coi là hợp lệ.

• Thứ tự giao dịch của họ dựa vào nonce một cách lỏng lẻo. Chính CA có thể gửi ra nhiều giao dịch tới nhiều người gọi đa dạng nhưng mỗi người gọi bị giới hạn dựa trên khả năng của họ.
• Thanh toán gas thường được xử lý bởi người gọi logic của CA.
• Logic thực thi của CA đa dạng hơn để cho phép cải tiến UX như giao dịch đa cuộc gọi và giao dịch nguyên tử.

Đánh giá những tính năng này, chúng tôi quan sát thấy rằng mỗi loại tài khoản được thiết kế để có một sự đánh đổi giữa sự tự chủ và khả năng lập trình.

EOA có độc lập hoàn toàn nhưng có khả năng lập trình hạn chế; họ có thể ủy quyền và gửi giao dịch bất cứ khi nào họ muốn, nhưng những giao dịch này phải tuân theo định dạng chặt chẽ để được coi là hợp lệ. CA có khả năng lập trình đầy đủ (chỉ bị hạn chế bởi thiết kế của EVM) nhưng độc lập hạn chế; giao dịch của họ không cần tuân theo bất kỳ định dạng chặt chẽ nào, nhưng chỉ có thể được gửi ra do logic của họ được gọi trước.

Trong phần tiếp theo, chúng tôi sẽ nghiên cứu các hàm ý của những lựa chọn thiết kế này, để hiểu rõ đề xuất của mỗi EIP được thảo luận trong loạt bài này.

Vấn đề tài khoản của Ethereum

Bây giờ chúng ta đã hiểu một cách khái quát về các chức năng khác nhau của các tài khoản, chúng ta có thể dễ dàng xác định điểm mạnh của họ cũng như các vấn đề mà họ đem đến cho cả trải nghiệm người dùng và nhà phát triển trên Ethereum.

Như chúng tôi đã đề cập trước đây, EOA được thiết kế như các tài khoản hạng nhất nhắm mục tiêu đến người dùng cuối. Các ứng dụng được thiết kế để dễ dàng tương tác với chúng, hầu như không có sự phức tạp nào đối với chúng và tất nhiên không có chi phí để tạo ra chúng. Tuy nhiên, sự đơn giản của nó đi kèm với sự mất mát đáng kể về tính mới vì chúng được thiết kế để xác định nghiêm ngặt.

Một số mối quan ngại xoay quanh chúng là:

1. Tính dễ bị tấn công bởi lượng tử - Hệ thống chữ ký ECDSA được sử dụng bởi cặp khóa của họ không chống lại tấn công lượng tử, và với một kế hoạch thời gian lạc quan trong khoảng từ 5 đến 10 năm để đạt được các hệ thống lượng tử trong công nghiệp, điều này đe dọa đáng kể Ethereum và các ứng dụng của nó mà phụ thuộc mạnh mẽ vào hệ thống ECDSA để chứng minh và bảo mật mật mã.
2. Thiếu sự biểu đạt - Định dạng cứng của quy tắc hợp lệ của EOAs loại bỏ khả năng cho người dùng biểu đạt giao dịch của họ một cách ngắn gọn hơn thông qua các tính năng như nguyên tắc nguyên tử và gom giao dịch, và ủy quyền giao dịch.
3. Tự cung cấp - Mọi người đều có những khoảnh khắc "tôi hết xăng" trong quá trình giao dịch. Điều này là do yêu cầu rằng EOAs phải tự giải quyết chi phí gas cho giao dịch của họ, điều này sẽ không phải là một yêu cầu quá lớn nếu ether (ETH) không phải là loại tiền gas duy nhất được chấp nhận. Mặc dù đây là một vấn đề chung của các máy trạng thái dựa trên tài khoản (và thậm chí cả dựa trên UTXO), Ethereum luôn có ý định trở nên khác biệt.

Không phải ai cũng muốn (hoặc có khả năng) luôn giữ ETH (nghĩa là nhìn vào hành động giá cả), vì vậy các giải pháp khả thi sẽ là cho phép nhiều loại tiền gas (quá khó, làm hỏng quá nhiều invariants như mô tả trong phần 'Tiền tệ')ở đây) hoặc cho phép thanh toán gas được giải quyết bởi một tài khoản khác không phải là nguồn gốc giao dịch.

Ở phía đầu bên kia của phổ tài khoản, CAs nhắm đến các nhà phát triển và một đối tượng người dùng kỹ thuật hơn. Chúng hoạt động như phương tiện cho các hợp đồng thông minh (tức là chúng tôi coi hợp đồng thông minh là nội dung logic hoặc mã code được chứa trong chúng) và do đó có thể triển khai định dạng giao dịch mới lạ như được cho phép bởi EVM.

Tuy nhiên, đối với tất cả những tính năng này, họ chỉ là những tài khoản cấp hai được tuyên dương vì họ không có tính tự chủ. Một số điểm hạn chế của họ như sau:

1. Hoàn toàn thiếu tính tự chủ - CAs không thể bắt đầu một giao dịch, họ chỉ có thể gửi giao dịch ra phản ứng khi được kích hoạt theo một cách cụ thể rất nhất định.
2. Dễ bị lỗi do sai sót của con người trong logic - Sự thiếu cứng nhắc thường dẫn đến việc xác định sai các hằng số và logic khác, điều này đã dẫn đến hàng tỉ đô la mất mát do lỗ hổng và hack trong hợp đồng thông minh. Tuy nhiên, đây là một chủ đề hoàn toàn khác nằm ngoài phạm vi của chúng ta ở đây.

Sau khi xem xét các lựa chọn thiết kế dẫn đến các vấn đề được xác định trong phần này, chúng ta có thể tiếp tục đánh giá các giải pháp đề xuất.

Một dòng thời gian về trừu tượng hóa tài khoản

Khái niệm trừu tượng hóa tài khoản (thông qua tài khoản thông minh ít nhất) luôn là một phần không thể thiếu của lộ trình Ethereum. Truyền thuyết là sự phức tạp liên quan đến việc triển khai của nó đe dọa làm chậm thêm việc ra mắt Ethereum, vì vậy nó đã bị loại bỏ cho thiết kế hiện tại với các tài khoản khác nhau cung cấp các chức năng khác nhau. Nó đã bị trì hoãn lại bởi sự tập trung của Ethereum vào The Merge, và bây giờ nó lại xuất hiện như một phần chính của nâng cấp lớn tiếp theo của mạng - Pectra. Tuy nhiên, sự phức tạp của nó vẫn được coi là một nhược điểm đáng kể ngăn cản sự thống trị của nó, đặc biệt là khi Ethereum đã chuyển hướng sang lộ trình tập trung vào Rollup.

Yêu cầu hiện nay là hai lớp:

1. Tiêu chuẩn tài khoản phải trở nên rõ ràng hơn, nhưng không mất tính tự chủ. Một tiêu chuẩn mới nhằm kết hợp giữa tiêu chuẩn EOA và CA.
2. Tiêu chuẩn mới phải vượt qua khoảng cách giữa các EOA và CA, đồng thời vẫn hoàn toàn tương thích trên Ethereum và hệ sinh thái L2 của nó.

Về mặt trực giác, khái niệm này đóng vai trò quan trọng hơn trong ngữ cảnh trừu tượng hóa chuỗi và khả năng tương tác, tuy nhiên phạm vi của chúng tôi trong báo cáo này giới hạn chỉ đến các sáng kiến kỹ thuật được thực hiện để đạt được trừu tượng hóa tài khoản chính nó.

Trừu tượng hóa tài khoản nhằm kết hợp những tính năng tốt nhất của EOAs và CAs thành một tiêu chuẩn tài khoản mới - tài khoản thông minh, cho phép tách biệt hoàn toàn hoặc một phần các quy tắc hợp lệ của bất kỳ tài khoản thành một logic xác thực và một logic thực thi; để các tài khoản có thể xác định các quy tắc hợp lệ riêng của mình - như được phép bởi EVM - giống như tài khoản hợp đồng, trong khi vẫn hoàn toàn tự động như tài khoản sở hữu bên ngoài.

Thường có sự nhầm lẫn về sự khác biệt giữa tài khoản thông minh và ví hợp đồng thông minh, vì vậy hãy mô tả rõ ràng những sự khác biệt này dưới đây:

• Tài khoản thông minh là tài khoản Ethereum được trừu tượng hóa để cung cấp phần bằng nhau về khả năng lập trình và tự trị. Ý tưởng là cả EOAs và CAs có thể trở thành tài khoản thông minh chỉ bằng cách sử dụng một cơ chế nào đó (ví dụ: ERC 4337) cho phép thay thế các quy tắc hiệu lực do mạng áp đặt bằng quy tắc hiệu lực tùy chỉnh theo ý muốn của họ.
• Ví hợp đồng thông minh, được cung cấp bởi các nhà cung cấp ví, đóng vai trò giao diện cho các tài khoản hợp đồng (đúng vậy, một ví không phải là một tài khoản).

Việc thương mại hóa ví hợp đồng thông minh đã giúp việc áp dụng CAs (chứng chỉ) dễ dàng hơn đối với một thị trường rộng hơn, cho phép người dùng ít kỹ thuật hơn tận dụng các tính năng mà chúng cung cấp. Tuy nhiên, họ vẫn đối mặt với những khó khăn liên quan đến CAs.

Quay trở lại cuộc trò chuyện; chúng ta đã thảo luận trước đó về các tham số được sử dụng để xác định các quy tắc hợp lệ của giao dịch tài khoản:

• Xác thực
• Ủy quyền
• Logic Nonce
• Logic thanh toán Gas
• logic thực thi

Giá trị của bốn tham số đầu tiên có thể được gọi chung là logic xác thực của một tài khoản, đó là các kiểm tra xảy ra trước khi một giao dịch bắt đầu thực thi.

Tham số cuối cùng xác định cách thực hiện giao dịch sẽ tiến hành.

Trong phần giới thiệu, chúng tôi cung cấp một cái nhìn tổng quan về cảnh quan AA hiện tại dưới dạng một phân loại cho các thiết kế đề xuất khác nhau. Bây giờ chúng tôi sẽ tập trung vào lớp giải pháp đầu tiên cho vấn đề tài khoản Ethereum- EOA có thể lập trình.

EOA có thể lập trình

Sức hấp dẫn lớn nhất của Ethereum là hệ sinh thái DeFi trẻ nhưng sôi động, có nhiều ứng dụng phi tập trung là điểm nhấn thanh khoản chính của nó. Hầu hết các DApp này được tối ưu hóa để phục vụ EOA, do đó chúng khó giao tiếp với CA và cuối cùng là tài khoản thông minh. Mặc dù ví hợp đồng thông minh giúp CA trong trường hợp này, nhưng chúng đi kèm với những hạn chế riêng và một UX hoàn toàn khác.

Một giải pháp tạm thời đang được khám phá trong khi cả DApps và nhà cung cấp ví tiền điện tử quen dần với tiêu chuẩn tài khoản thông minh, là cung cấp các cải tiến tạm thời cho EOAs để giúp họ vượt qua hầu hết các hạn chế được áp đặt, cho dù là việc xác thực hay logic thực thi của họ.

Dưới đây, chúng tôi sẽ đi qua các thông số kỹ thuật của ba EIPs chính cung cấp các tuyến đường hành động cho tính khả thi của EOA; từ cái ít người biết đếnEIP 5806đến những người tham vọngEIP 3074và sau cùng là chiến thắngEIP 7702.

Khả năng lập trình qua EIP-5806

Đề xuất này nhằm mục đích mang đến nhiều chức năng hơn cho tiêu chuẩn EOA bằng cách cho phép nó thực hiện cuộc gọi ủy quyền đến logic của tài khoản hợp đồng (hợp đồng thông minh của nó). Điều này hiệu quả khiến cho hợp đồng thông minh được thực thi trong ngữ cảnh của EOA gọi, tức là EOA vẫn nắm quyền kiểm tra logic của nó, trong khi logic thực thi được xử lý bởi logic tương ứng của CA.

Trước khi chúng ta tiếp tục điều gì đó, hãy cùng nhau đi một chuyến đi về quá khứ tiến hóa của EthereumEIP-7.

EIP-7 đề xuất việc tạo mã opcode 0xf4/DELEgateCALL, được sử dụng để gửi cuộc gọi tin nhắn vào một tài khoản chính với logic của một tài khoản phụ, đồng thời duy trì các giá trị của các trường [người gửi] và [giá trị] của tài khoản chính.

Nói cách khác, tài khoản chính 'kế thừa' (hoặc mượn nếu bạn muốn) logic của tài khoản phụ trong một khoảng thời gian được chỉ định trong cuộc gọi tin nhắn, để logic của tài khoản sau được thực thi trong ngữ cảnh của tài khoản trước.

Mã này cho phép nhà phát triển dApp chia logic ứng dụng của họ thành nhiều hợp đồng thông minh khác nhau trong khi duy trì sự phụ thuộc lẫn nhau, để họ có thể dễ dàng vượt qua các rào cản về kích thước mã và gas.

EIP-5806 tóm tắt

Okay, vậy cuộc gọi đại diện nào cho phép CAs phụ thuộc lẫn nhau? EIP-5806 sử dụng EIP-7 làm nguồn cảm hứng để đề xuất mở rộng chức năng cuộc gọi đại diện đến EOAs; tức là, hãy cho phép EOAs cũng phụ thuộc lẫn nhau với CAs, vì sao không.

Thông số kỹ thuật

EIP 5806 giới thiệu một tuân thủ EIP-2718loại giao dịch được đóng gói như sau:

rlp([chainID, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list, signature_y_parity, signature_r, signature_s]).

Các giao dịch này được thiết kế sao cho trường [to] - đại diện cho địa chỉ người nhận - chỉ có thể chấp nhận địa chỉ làm đầu vào 20 byte, vô hiệu hóa người gửi sử dụng opcode CREATE.

Động lực đằng sau mỗi thành phần của hệ thống RLP như sau:

• chainID: Mã định danh tuân thủ EIP-115 của chuỗi hiện tại được lót thêm để có 32 byte. Giá trị này cung cấp bảo vệ chống lại cuộc tấn công phát lại, để các giao dịch trên chuỗi gốc không được sao chép dễ dàng trên các chuỗi EVM thay thế khác với lịch sử tương tự và ít bảo mật kinh tế hơn.
• nonce: Một định danh duy nhất cho mỗi giao dịch cung cấp bảo vệ chống lại cuộc tấn công phát lại.
• max_priority_fee_per_gas và max_fee_per_gas: Các giá trị của phí gas mà một giao dịch EIP-5806 phải thanh toán để đặt hàng và bao gồm tương ứng.
• gas_limit: Số lượng gas tối đa mà một giao dịch loại 5806 có thể tiêu thụ.
• điểm đến: Người nhận giao dịch
• dữ liệu: Nội dung mã thực thi
• access_list: Những người đại diện được điều kiện cho phép thực hiện giao dịch EIP-5806.
• signature_y_parity, signature_r, và signature_s: ba giá trị cùng nhau đại diện cho chữ ký secp256k1 trên thông điệp — keccak256 (TX_TYPE || rlp ([chainID, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list])).

Trong khi việc đóng gói giao dịch EIP-5806 trong phong bì EIP-2718 cho phép chúng tương thích ngược tốt, Tài khoản địa chỉ không tương đương với Tài khoản thông thường. Vì vậy, một số hạn chế nhất định phải được định nghĩa trong cách mà một Tài khoản địa chỉ sử dụng cuộc gọi ủy quyền để ngăn chặn việc phá vỡ không biến đổi.

Những hạn chế này nhắm vào các opcode sau đây:

• SSTORE/0x55: Mã opcode này cho phép một tài khoản lưu trữ một giá trị vào bộ nhớ lưu trữ. Nó bị hạn chế trong các giao dịch EIP-5806 để ngăn EOAs từ việc thiết lập/truy cập bộ nhớ lưu trữ bằng cách gọi đại diện, do đó ngăn ngừa các vấn đề tiềm ẩn có thể phát sinh trong tương lai do di cư tài khoản.
• CREATE/0xF0, CREATE2/0xF5 và SELFDESTRUCT/0xFF: Các mã opcode này cho phép người gọi tạo một tài khoản mới một cách rộng rãi. Việc truy cập vào chúng bị hạn chế để ngăn chặn sự thay đổi của nonce của một EOA trong một khung thực thi khác nhau (tạo/hoàn tác hợp đồng trong trường hợp này) trong khi nó đang thực hiện một giao dịch EIP-5806, nhằm ngăn chặn việc vô hiệu hóa kỳ vọng rằng giao dịch mang theo các nonce liên tiếp.

Khả năng áp dụng/trường hợp sử dụng tiềm năng

Ứng dụng chính của EIP 5806 là trừu tượng hóa thực thi cho các tài khoản ngoại vi. Cho phép các tài khoản ngoại vi tương tác một cách không cần tin cậy với hợp đồng thông minh vượt ra ngoài các cuộc gọi đơn giản tới logic của chúng, cấp họ các tính năng như:

• Thực thi điều kiện của các giao dịch
• Gộp giao dịch
• Giao dịch đa cuộc gọi (ví dụ: phê duyệt và gọi)

Criticisms

Các thay đổi được đề xuất bởi EIP-5806, trong khi cho phép các tính năng cần thiết, không đặc biệt mới mẻ; sự tồn tại của nó chủ yếu dựa trên EIP-7 đã hoạt động. Điều này cho phép nó vượt qua nhiều rào cản tiềm năng để được chấp nhận.

Một trong những mối quan tâm chính được đề cập trong những ngày đầu của nó là nguy cơ tiềm ẩn khi cho phép EOAs truy cập và thay đổi lưu trữ, tương tự như CAs hiện tại làm. Điều này vi phạm nhiều điều kiện không thể thay đổi của mạng về cách EOAs thực hiện giao dịch, và vì vậy đã được giải quyết bằng cách đưa ra các hạn chế được đề cập trong phần tiếp theo.

Một lời chỉ trích thứ hai (hơi giống con dao hai lưỡi) là sự đơn giản của EIP-5806; có một số ý kiến cho rằng phần thưởng do chấp nhận EIP-5806 có thể không đáng giá, vì nó chỉ cho phép trừu tượng hóa thực hiện và không có nhiều thứ khác. Mọi hạn chế về hiệu lực khác vẫn được xác định theo mạng cho các EOA chọn tham gia EIP-5806, trái ngược với các EIP tương tự khác mà chúng ta thảo luận trong các tiểu mục sau.

Khả năng lập trình qua EIP-3074

EIP-3074 đề xuất cho phép các EOA ủy quyền hầu hết logic xác thực của họ cho các tài khoản hợp đồng chuyên biệt, được gọi là người gọi, bằng cách chồng logic ủy quyền của người sau lên logic của họ đối với các hình thức giao dịch cụ thể.

Điều này được đạt được bằng cách ký quyền truy cập của họ cho một hợp đồng triệu tập, sau đó hợp đồng này trở thành người chịu trách nhiệm xác định chính sách truy cập của EOA.

EIP này đề xuất việc thêm hai mã opcode mới vào EVM:

• [AUTH] đặt tài khoản biến ngữ cảnh [được ủy quyền] để hành động thay mặt cho tài khoản [cơ quan] thứ hai, dựa trên chữ ký ECDSA của tài khoản sau.
• [AUTHCALL] gửi / thực thi cuộc gọi cho tài khoản [authority] từ / như tài khoản [authorized].

Hai mã opcode này cho phép EOA ủy quyền kiểm soát cho một CA đã thiết lập trước đó và do đó hoạt động như một thông qua nó, mà không cần triển khai hợp đồng và chịu các chi phí và yếu tố bên ngoài liên quan đến điều đó.

Thông số kỹ thuật

EIP-3074 cho phép các giao dịch sử dụng định dạng ký [MAGIC] để tránh xung đột với các định dạng ký giao dịch khác. Tài khoản hiện hoạt mà lệnh [AUTHCALL] được chuyển đến được định nghĩa là trường biến ngữ cảnh có tên [được ủy quyền], chỉ tồn tại thông qua một giao dịch duy nhất và phải được xác định lại cho mỗi [AUTHCALL] mới.

Trước khi xử lý các phức tạp của mỗi opcode, đây là các thực thể liên quan đến giao dịch EIP-3074:

• [quyền lực]: Tài khoản ký chính (một EOA) ủy quyền truy cập/kiểm soát cho một tài khoản thứ hai, thường là một tài khoản hợp đồng.
• [được ủy quyền]: Tài khoản mà các lệnh [AUTHCALL] sẽ được chuyển đến để thực thi. Nói cách khác, nó là tài khoản trong đó logic của [AUTHCALL] được thực thi, thay mặt cho [cơ quan], sử dụng các ràng buộc được xác định bởi [người gọi].
• [invoker]: Một hợp đồng con được thiết kế để quản lý tương tác giữa tài khoản được ủy quyền và logic của [AUTHCALL], đặc biệt là trong những trường hợp mã hợp đồng chính của nó là tài trợ gas.

Hợp đồng invoker nhận tin nhắn [AUTH] với giá trị [COMMIT] từ [authority]; giá trị này xác định các hạn chế mà tài khoản muốn đặt ra đối với việc thực hiện các lệnh [AUTHCALL] của [được ủy quyền].

Do đó, những người triệu tập chịu trách nhiệm đảm bảo rằng [contract_code] được xác định trong một tài khoản [authorized] không phải là độc hại và có khả năng đáp ứng các điều kiện được đặt ra bởi tài khoản ký chính trong một giá trị [COMMIT].

Mã [AUTH] có ba ngăn xếp đầu vào; hoặc đơn giản hơn — nó được định nghĩa bởi ba đầu vào tính toán một đầu ra duy nhất. Các đầu vào này là:

1. authority: đây là địa chỉ của EOA tạo chữ ký
2. khoảng cách
3. độ dài

Hai đầu vào cuối cùng được sử dụng để mô tả một phạm vi bộ nhớ có thể sửa đổi từ 0 đến 97, trong đó:

1. [memory(offset : offset+1)] - [yParity]
2. [memory(offset+1 : offset+33] – [r]
3. [bộ nhớ (offset+33 : offset+65)] - [s]
4. [memory(offset + 65: offset + 97)] - [COMMIT]

Các biến [yParity], [r] và [s] được hiểu chung là chữ ký ECDSA, [magic], trên đường cong secp256k1 trên thông điệp:

[keccak256 (MAGIC || chainID || nonce || invoker address || COMMIT)]

nơi:

• [MAGIC] là một chữ ký ECDSA được tạo ra từ sự kết hợp của các biến:
  • [chainID] là bộ nhận dạng tuân thủ EIP 115 của chuỗi hiện tại được sử dụng để cung cấp bảo vệ chống lại cuộc tấn công lặp lại trên các chuỗi EVM thay thế với lịch sử tương tự và ít bảo mật kinh tế.
  • [nonce] là số nonce hiện tại của địa chỉ người ký giao dịch, được đệm phía trái bằng 32 byte.
  • [invokerAddress] là địa chỉ của hợp đồng chứa logic cho việc thực thi của [AUTH].
• [COMMIT] là giá trị 32 byte được sử dụng để chỉ định các điều kiện hợp lệ giao dịch bổ sung trong logic tiền xử lý của trình gọi.

Nếu chữ ký tính toán được xác thực và địa chỉ người ký bằng với [authority], trường [authorized] được cập nhật thành giá trị được cung cấp bởi [authority]. Nếu bất kỳ yêu cầu nào không được đáp ứng, trường [authorized] vẫn giữ nguyên trạng thái trước đó hoặc là một giá trị chưa được thiết lập.

Chi phí gas cho opcode này được tính bằng tổng của:

1. Một khoản phí cố định cho việc tiền xử lý [ecrecover] và một khoản phí bổ sung cho băm keccak256 và một số logic bổ sung, được định giá ở 3100 đơn vị
2. Một khoản phí mở rộng bộ nhớ được tính tương tự như mã [RETURN], và áp dụng khi bộ nhớ được mở rộng vượt qua phạm vi được chỉ định của phân bổ hiện tại (97 đơn vị)
3. Một chi phí cố định là 100 đơn vị phát sinh cho một [authority] nóng và 2600 đơn vị cho một [authority] lạnh để ngăn chặn các cuộc tấn công do lỗi định giá các opcodes truy cập trạng thái.

[AUTH] được thực hiện để không sửa đổi bộ nhớ và lấy giá trị của [authority] làm đối số để xác minh giá trị của nó từ chữ ký được cung cấp là tầm thường.

Mã [AUTHCALL] có bảy phần tử đầu vào của ngăn xếp được sử dụng để tính toán một phần tử đầu ra của ngăn xếp duy nhất.

Nó có cùng logic như mã [CALL], tức là; nó được sử dụng để gửi cuộc gọi tin nhắn vào một tài khoản và kích hoạt logic cụ thể trong hợp đồng của nó. Sự khác biệt duy nhất trong logic của chúng là [AUTHCALL] được thiết kế để đặt giá trị [CALLER] trước khi tiến hành thực thi.

Do đó, [AUTHCALL] được sử dụng bởi [authority] để kích hoạt hành vi cụ thể trong [authorized] với kiểm tra logic được thực hiện như sau:

1. Kiểm tra giá trị của [được ủy quyền]. Nếu chưa đặt, việc thực thi được coi là không hợp lệ và khung được thoát ngay lập tức. Điều này giúp ngăn chặn các khoản phí không công bằng do những thất bại chưa từng có.
2. Kiểm tra chi phí gas của hành vi dự định của [authorized].
3. Kiểm tra giá trị tuân thủ EIP-150 của [gas].
4. Kiểm tra tính khả dụng của tổng chi phí khí đốt –[giá trị]—trong số dư của [cơ quan].
5. Thực thi xảy ra sau khi khấu trừ [value] từ số dư trong tài khoản của [authority]. Nếu [value] lớn hơn số dư của họ, thực thi sẽ bị vô hiệu.

Chi phí gas cho [AUTHCALL] được tính như tổng của:

• Chi phí cố định để gọi [warm_storage_read]
• Chi phí mở rộng bộ nhớ [memory_expansion_fee]; được tính tương tự như chi phí gas cho opcode [CALL]
• Một chi phí động [dynamic_gas]
• Chi phí thực thi của cuộc gọi con [subcall_gas]

Dữ liệu được trả về từ một [AUTHCALL] được truy cập thông qua:

• [RETURNDATASIZE] - đẩy kích thước của bộ đệm dữ liệu trả về vào ngăn xếp đầu ra
• [RETURNDATACOPY] - sao chép dữ liệu từ bộ đệm dữ liệu trả về vào bộ nhớ.

Để kết hợp tất cả với ít hơn sự nói chuyện kỹ thuật; Giao dịch Ethereum thường chỉ định hai giá trị:

1. tx.origin - cung cấp quyền cho giao dịch.
2. msg.sender - trong đó giao dịch thực sự xảy ra.

Trong các EOA, như đã đề cập trước đây, ủy quyền được kết hợp chặt chẽ với việc thực thi, tức là; (tx.origin == msg.sender). Bất biến đơn giản này làm phát sinh hầu hết các vấn đề mà chúng tôi đã giải thích trong tiểu mục "Tài khoản và tính hợp lệ của giao dịch" của báo cáo này.

[AUTH] tin nhắn từ [authority] cho phép nó bù đắp chức năng tx.origin thành [authorized], trong khi vẫn là msg.sender. Nó cũng cho phép nó định nghĩa các hạn chế cho đặc quyền này bằng giá trị [COMMIT].

[AUTHCALL] sau đó cho phép [authorized] truy cập vào logic của hợp đồng, sử dụng một [invoker] làm trung gian để đảm bảo hợp đồng mà nó muốn truy cập là không gây hại. Đó là, đối với mỗi [AUTHCALL], [authorized] phải chỉ định một [invoker] cụ thể cho [COMMIT] của họ.

Ứng dụng/Potential Applicability

EIP 3074 chịu trách nhiệm chủ yếu cho việc cho phép các EOAs ủy quyền logic ủy quyền của họ cho một tài khoản khác, tuy nhiên thiết kế mở của nó còn cho phép nhiều hơn trong các ngữ cảnh khác nhau.

Toàn bộ logic xác nhận của EOA có thể được trừu tượng hóa bằng cách áp dụng các hạn chế / đổi mới khác nhau cho trình gọi khi cần thiết, một số thiết kế có thể dựa trên logic đích của chúng bao gồm:

• Logic của Nonce: EIP-3074 cho phép Nonce của EOAs không thay đổi sau khi gửi một thông điệp [AUTH], trong khi Nonce của nó cho mỗi [AUTHCALL] phụ thuộc vào người gọi mà nó tương tác. Điều này cho phép đồng thời hóa Nonce cho EOAs, để họ có thể gửi ra nhiều [AUTHCALL] không chồng chéo nhau theo ý muốn.
• Logic thanh toán Gas:Theo yêu cầuTrong EIP, các bộ gọi có thể được thiết kế để cho phép tài khoản trừu tượng hóa. Do đó, phí gas cho [COMMIT] của người dùng có thể được khấu trừ từ nguồn gốc giao dịch hoặc từ bất kỳ tài khoản hỗ trợ nào, bất kể là tài khoản cá nhân hay là một trạm chuyển tiếp dựa trên dịch vụ (dịch vụ tài trợ gas).

Ngoài ra, logic thực thi được trừu tượng hóa một cách trực quan; xét cho cùng, người gọi (là CA) hiện chịu trách nhiệm thực hiện các yêu cầu giao dịch thay mặt cho EOA.

Criticisms

• Tập trung Trung tâm Invoker

Trích dẫnmột trong các tác giả của nó: “Tôi không mong đợi các ví tiền điện tử tiết lộ chức năng để ký giao dịch cho các bên gọi hàm tùy ý …”. Có lẽ vấn đề lớn nhất mà sáng kiến 3074 mang lại là sự dễ dàng của việc phát triển độc quyền và luồng giao dịch sở hữu; giống như các phiên bản hiện tại của thị trường MEV và PBS của Ethereum.

Mặc định, hợp đồng gọi phải được kiểm tra kỹ để ngăn chặn các cuộc tấn công tồi tệ hơn những gì hiện tại đang có thể. Điều này sẽ dẫn đến một hệ sinh thái chỉ có một vài hợp đồng gọi được phát triển bởi các nhân vật ảnh hưởng được chấp nhận như mặc định cho các nhà phát triển ví. Do đó, đó là một sự đánh đổi giữa việc theo con đường phi tập trung khó khăn của việc kiểm tra và hỗ trợ hợp đồng gọi với nguy cơ an ninh của người dùng; hoặc đơn giản là áp dụng hợp đồng gọi từ các nguồn đáng tin cậy đã được thiết lập với các bảo đảm tốt hơn cho an ninh người dùng và ít giám sát hơn về an toàn của hợp đồng.

Một khía cạnh khác của vấn đề này là hàm chi phí liên quan đến việc thiết kế, kiểm toán và tiếp thị một người gọi chức năng và an toàn. Những nhóm nhỏ hầu như luôn bị các tổ chức lớn vượt mặt – đặc biệt là ở mặt tiếp thị – mà đã có một số danh tiếng đã được lập, ngay cả khi sản phẩm của họ tốt hơn.

• Vấn đề tương thích tiến

EIP-3074 củng cố chủ đề chữ ký ECDSA, vì nó vẫn được coi là hợp lệ hơn phương thức ủy quyền được giới thiệu thông qua bộ kích hoạt. Trong khi có những lập luận cho rằng khả năng chống lại lượng tử không phải là một vấn đề xác định trong thời điểm hiện tại, và rằng có nhiều vấn đề tồi tệ hơn trong một tương lai khi ECDSA có thể bị hỏng; Mục tiêu không được công bố rõ ràng của Ethereum là luôn luôn tiên phong trong việc giải quyết những vấn đề như vậy. Việc hy sinh khả năng chống lại lượng tử và kiểm duyệt để cải thiện chút ít trải nghiệm người dùng có thể không phải là lựa chọn tốt nhất trong tương lai gần.

Một điểm khác trong lập luận về sự tương thích về phía trước là trong khi những lợi ích của 3074 vẫn đang được đánh giá, ERC-4337 (không yêu cầu bất kỳ thay đổi nào trong giao thức) hiện nay đã có một thị trường tốt, vì vậy bạn cũng phải tương thích với nó để tránh sự phân tách của các hệ sinh thái.

Ngay cả với lộ trình trừu tượng hóa tài khoản, các opcode [AUTH] và [AUTHCALL] sẽ cuối cùng trở nên lỗi thời trên EVM, gây ra một khoản nợ kỹ thuật lớn cho Ethereum để mang lại một lượng cải thiện UX không đáng kể.

• ECDSA Scheme Irrevocability

Sau khi gửi một tin nhắn [AUTH] và ủy quyền kiểm soát, EOA được mong đợi sẽ tránh sử dụng hệ thống xác thực khóa riêng thông thường, vì việc gửi một giao dịch “bình thường” sẽ làm cho quyền ủy quyền mà nó đã giao cho mọi người gọi bị thu hồi.

Do đó, hệ thống ECDSA vẫn hoàn toàn vượt trội so với bất kỳ hệ thống ủy quyền nào mà các hợp đồng liên quan có thể cho phép, có nghĩa là mất chìa khóa riêng tư sẽ dẫn đến mất hết tài sản của tài khoản.

Khả năng lập trình thông qua EIP-7702

Đề xuất này ban đầu được thiết lập như một biến thể tương đối tối giản của EIP 3074 và đã ...đã có ý địnhđể là một bản cập nhật cho nó. Nó được sinh ra để giải quyết những không hiệu quả được cho là của EIP 3074, đặc biệt là những lo ngại về tính không tương thích của nó với hệ sinh thái 4337 đang phát triển và đề xuất trừu tượng hóa tài khoản cục bộ - RIP 7560.

Cách tiếp cận của nó là thêm một loại giao dịch tuân thủ EIP 2718 mới - [SET_CODE_TX_TYPE] - cho phép một EOA hoạt động như một tài khoản thông minh cho các giao dịch cụ thể.

Thiết kế này cho phép các tính năng giống như EIP 5806 và một số tính năng khác, đồng thời vẫn tương thích với lộ trình trừu tượng hóa tài khoản cố định và các sáng kiến hiện tại.

Thông số kỹ thuật

EIP-7702 cho phép một EOA "nhập" nội dung mã của một hợp đồng thông qua một giao dịch tuân thủ [SET_CODE_TX_TYPE] 2718 có định dạng:

rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, value, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s])

Gói tin này hoàn toàn giống với EIP 5806, ngoại trừ nó giới thiệu một 'danh sách ủy quyền'. Danh sách này là một chuỗi các giá trị có định dạng được sắp xếp theo thứ tự:

[[chain_id, địa chỉ, nonce, y_parity, r, s], …]

nơi mỗi bộ ba xác định giá trị của [địa chỉ].

Trước khi tiếp tục, các bên liên quan trong một SET_CODE_TX_TYPE là:

• [authority]: đây là tài khoản EOA/tài khoản chính để ký
• [địa chỉ]: địa chỉ của một tài khoản chứa mã có thể ủy quyền.

Khi [authority] ký một SET_CODE_TX_TYPE chỉ định [address], một người chỉ định ủy quyền được tạo ra. Đây là một “chương trình con trỏ” khiến tất cả các yêu cầu truy xuất mã do hành động của [authority] tại bất kỳ thời điểm nào đều được chuyển đến mã quan sát của [address].

Đối với mỗi bộ tứ [chain_id, địa chỉ, nonce, y_parity, r, s], luồng logic của giao dịch loại 7702 được thực hiện như sau:

1. Xác minh chữ ký của [authority] từ hash đã cung cấp bằng cách sử dụng: authority = ecrecover(keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s]
2. Ngăn chặn các cuộc tấn công phát lại chuỗi chéo và các vector tấn công khácbằng cách xác minh ID của chuỗi.
3. Kiểm tra xem [authority] đã có nội dung mã code chưa.
4. Kiểm tra Nonce để đảm bảo Nonce của [authority] bằng với Nonce được bao gồm trong bộ lưu trữ.
5. Nếu giao dịch là giao dịch LOẠI_TRANSACTION_SET_CODE_TX_TYPE đầu tiên của [authority], nó sẽ bị tính phí CHI_PHÍ_TÀI_KHOẢN_TRỐNG. Trong trường hợp số dư của nó nhỏ hơn giá trị của khoản phí này, hoạt động sẽ bị hủy bỏ.
6. Được chỉ định ủy quyền, trong đó mã [authority] được đặt thành con trỏ của [address].
7. Giá trị nonce của người ký –[authority]– được tăng lên một đơn vị.
8. [authority] được thêm vào một danh sách địa chỉ được truy cập, (đơn giản hóa) là một tập hợp các địa chỉ được tạo sao cho việc quay lại phạm vi của giao dịch từ chúng khiến chúng (địa chỉ) trở về trạng thái trước đó, trước khi phạm vi quay trở lại được nhập. Điều này được định nghĩa trongEIP-2929để cho phép lưu trữ tạm thời các giá trị có thể sử dụng lại và ngăn ngừa các khoản phí không cần thiết.

Phew! Để kết nối lại tất cả; EIP này cho phép EOAs gửi giao dịch để thiết lập một con trỏ đến mã của hợp đồng, cho phép họ thực hiện logic này như là của riêng họ trong các giao dịch tiếp theo. Theo cách này, nó mạnh hơn EIP 5806, vì nó cho phép EOAs thực sự có nội dung mã trong suốt thời gian họ muốn (không giống như EIP 5806 chỉ cho phép EOAs gửi các cuộc gọi ủy quyền).

Các trường hợp sử dụng tiềm năng

• Trừu tượng thực hiện

Trong khi có thể đưa ra lập luận rằng đó không còn là một trừu tượng nữa khi EOA chủ động tiếp nhận logic mà nó muốn thực thi, nhưng nó vẫn không phải là 'chủ sở hữu chính' của logic đó. Ngoài ra, nó không trực tiếp chứa logic, chỉ đơn giản là chỉ định một con trỏ đến logic (nhằm giảm độ phức tạp tính toán). Vì vậy, chúng tôi chọn trừu tượng hóa thực thi!

• Tài trợ Gas

Trong khi invariante require (msg.sender == tx.origin) bị phá vỡ để cho phép tự tài trợ, EIP vẫn cho phép tích hợp các trình kết nối giao dịch được tài trợ. Tuy nhiên, điều cần lưu ý là các trình kết nối như vậy cần có hệ thống dựa trên danh tiếng hoặc cổ phần để ngăn chặn cuộc tấn công griefing.

• Chính sách truy cập có điều kiện

EOA chỉ có thể trỏ đến một phần cụ thể của mã tài khoản, sao cho chỉ có logic của phần đó được thực thi trong ngữ cảnh của chúng.

Điều này cũng cho phép sự tồn tại của các khóa phụ, từ đó cho phép “giảm đặc quyền”, để các dAPP cụ thể chỉ có quyền truy cập vào số dư tài khoản trong các điều kiện cụ thể. Ví dụ, bạn có thể tưởng tượng một quyền để tiêu ERC-20 nhưng không phải ETH, hoặc tiêu không quá 1% số dư tổng cộng mỗi ngày, hoặc tương tác chỉ với một ứng dụng cụ thể.

• Triển khai Hợp đồng Thông minh Chéo chuỗi

Do tính không hạn chế của nó, giao dịch EIP-7702 có thể cho phép người dùng truy cập vào mã opcode CREATE2 và sử dụng nó để triển khai mã bytecode tới địa chỉ mà không có bất kỳ thông số hạn chế nào khác như logic thị trường phí (ví dụ như EIP-1559 và EIP-4844). Điều này cho phép địa chỉ được khôi phục và sử dụng trên nhiều máy trạng thái, với cùng mã bytecode, trong đó tài khoản của nó trên mỗi chuỗi sau đó phụ trách xác định các thông số ngữ cảnh khác.

Nhận xét

• Thiếu tính tương thích ngược

Trong khi EIP-7702 vẫn rất mới, đã có rất nhiều việc thử nghiệm và kiểm tra cho các phụ thuộc và nhược điểm tiềm năng của nó, nhưng mô hình tối giản của nó đảm bảo cho nó nhiều tính linh hoạt và do đó giá trị trong các ngữ cảnh khác nhau. Tuy nhiên, nó phá vỡ quá nhiều nguyên tắc và không tương thích ngược ngay lập tức.

Một số phần của nó bao gồm:

1. Sửa đổi số nonce của EOA trong quá trình giao dịch: EIP-7702 không giới hạn bất kỳ opcode nào nhằm đảm bảo tính nhất quán. Điều này có nghĩa là một EOA có thể thực hiện các opcode như CREATE, CREATE2 và SSTORE trong khi thực hiện một giao dịch EIP-7702, cho phép số nonce của nó tăng trong ngữ cảnh khác nhau.
2. Cho phép tài khoản có giá trị codeHash không bằng không để trở thành nguồn gốc giao dịch: EIP-3607 được thực hiện để giảm thiểu tiềm năng của một “va chạm địa chỉ” giữa các EOA và CA. Một va chạm địa chỉ xảy ra khi giá trị 160-bit của địa chỉ EOA hoàn toàn tương đương với địa chỉ của CA.

Hầu hết người dùng không hiểu rõ nội dung thực tế của một tài khoản (hoặc thậm chí là sự khác biệt giữa một tài khoản và một địa chỉ!), vì vậy cho phép va chạm địa chỉ có nghĩa là một EOA có thể giả mạo thành một CA và thu hút quỹ của người dùng một cách dài dòng để cuối cùng đánh cắp tất cả. EIP-3607 đã giải quyết vấn đề này bằng cách quy định rằng các tài khoản chứa mã không được phép chi tiêu số dư của mình bằng cách sử dụng logic ủy quyền riêng của chúng. Tuy nhiên, EIP 7702 phá vỡ tính không biến này để cho phép EOAs tự trị ngay cả sau khi có một số khả năng lập trình.

• Giống với EIP-3074

Việc ký quyền địa chỉ tài khoản thay vì nội dung mã của nó về cơ bản giống như sơ đồ 3074 với người gọi. Điều này không đảm bảo nghiêm ngặt về tính nhất quán của nội dung mã chéo chuỗi, vì một địa chỉ có thể chứa nội dung mã khác nhau trên các chuỗi khác nhau. Điều này có nghĩa là một địa chỉ mà nội dung mã chứa cùng logic trên một chuỗi có thể là ác quỷ hoặc trực tiếp độc hại trên một chuỗi khác, và điều này có thể dẫn đến mất mát quỹ người dùng.

Kết luận

EOA ở dạng hiện tại hôm nay bị hạn chế rất nhiều vì họ không cho phép người dùng tận dụng các tính năng lập trình được cung cấp bởi EVM. Trong khi có nhiều con đường để nâng cấp tài khoản, như chúng tôi đã đề cập ở đầu báo cáo này, giải pháp được chọn phải duy trì các nguyên tắc tự lưu trữ an toàn và bảo mật. Hơn nữa, việc nâng cấp EOA có thể ảnh hưởng đáng kể đến cả trải nghiệm người dùng và các nhà phát triển ứng dụng nên tất cả các ý kiến của các bên liên quan phải được xem xét.

Cho phép EOAs thực thi mã theo bất kỳ cách nào mở rộng đáng kể chức năng của tài khoản, nhưng tính linh hoạt mới này đi kèm với những rủi ro ý nghĩa và những điểm mù có thể xảy ra. Giải quyết những sự đánh đổi này là rất quan trọng để mang lại lợi ích UX không thể tranh cãi cho người dùng Ethereum.

Văn hóa thảo luận mở của Ethereum khiến nó trở thành một môi trường thử nghiệm tuyệt vời cho những đổi mới như vậy, vì hầu hết mọi khía cạnh của mọi thiết kế đều được phân tích kỹ lưỡng bởi các chuyên gia. Sự xem xét toàn diện này sẽ giúp giảm thiểu rủi ro phạm pháp từ những đối thủ.

EIP-7702 hiện đang là điển hình cho các cơ chế nhằm đưa tính khả thi lập trình EVM đến các EOA, đã được đánh dấu là sự thay thế cho khe EIP 3074 trong nâng cấp Pectra. Nó thừa hưởng thiết kế mở của cơ chế 3074 trong khi giảm thiểu đáng kể diện tích tấn công / rủi ro. Nó cũng cho phép nhiều hơn bằng cách tránh các hạn chế của 3074 đối với một số lớp opcode nhất định.

Trong khi vẫn còn một số điều chỉnh được thực hiện trên thiết kế của đề xuất, nó đã nhận được rất nhiều thiện ý và sự ủng hộ từ các nhà phát triển, đặc biệt là khi nó có sự hỗ trợ trực tiếp từ Vitalik.

Trong cộng đồng có những tuyên bố rằng cách tiếp cận trừu tượng hóa tài khoản này thậm chí có thể tốt hơn tài khoản thông minh. Bài bình luận này nhấn mạnh rằng con đường này đòi hỏi ít thay đổi hơn và không phức tạp và các EOA đã được lưu giữ. Tuy nhiên, chúng ta phải nhớ cột mốc bảo mật trong tương lai của kháng lượng tử ở mọi cấp độ của mạng Ethereum. Sự an toàn lượng tử này là không khả thi với lõi mô hình tài khoản hiện tại do việc sử dụng các sơ đồ chữ ký dựa trên ECDSA để ủy quyền EOA.

Do đó, tính khả năng lập trình của EOA được xem như là một bước tiến trên con đường đến tài khoản thông minh và không phải là điểm đến cuối cùng. Nó tăng tốc độ cho EOAs và cải thiện trải nghiệm người dùng và nhà phát triển, đồng thời vẫn tương thích với mục tiêu trừu tượng hóa tài khoản tối đa của tài khoản thông minh.

Trong báo cáo tiếp theo của chúng tôi, chúng tôi sẽ đi sâu vào các kế hoạch di cư EOA để xem chúng có phù hợp với lộ trình trừu tượng hóa tài khoản hay không, hãy đồng hành!

Disclaimer：

1. Bài viết này được in lại từ [2077.xyz], Tất cả quyền tác giả thuộc về tác giả gốc [zhev]. Nếu có ý kiến ​​phản đối về việc tái bản này, vui lòng liên hệ với Gate Learnđội, và họ sẽ xử lý nó ngay lập tức.
2. Miễn trách nhiệm về trách nhiệm: Các quan điểm và ý kiến được thể hiện trong bài viết này chỉ thuộc về tác giả và không đại diện cho bất kỳ lời khuyên đầu tư nào.
3. Bản dịch của bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Learn của cổng. Trừ khi được đề cập, việc sao chép, phân phối hoặc đạo văn bản dịch là không được phép.