Ethereum có hai loại tài khoản: Tài khoản Sở Hữu Bên Ngoài (EOA) và Tài khoản Hợp Đồng (CA). EOA được kiểm soát bởi một khóa riêng trong khi CA được kiểm soát bởi mã hợp đồng thông minh chứa trong đó. EOA luôn được ưu ái hơn CAs vì chỉ có EOA mới có thể bắt đầu thực thi giao dịch bằng cách thanh toán gas. Account Abstraction (AA) là một đề xuất cho phép một hợp đồng trở thành một tài khoản “cấp cao”, giống như một EOA, có thể thanh toán phí và bắt đầu thực thi giao dịch.

Động lực của AA là cải thiện đáng kể trải nghiệm người dùng trong cách họ tương tác với blockchain Ethereum hiện nay trong các kịch bản khác nhau như ví, máy trộn, ÐApps và DeFi. AA cung cấp một chức năng cơ bản trong Ethereum để quyết định khi nào người dùng có thể thanh toán cho gas, điều này cũng ảnh hưởng đến việc ai trả tiền gas và cách họ thanh toán cho nó.

Ứng dụng Messenger của Status bao gồm một ứng dụng nhắn tin tập trung vào quyền riêng tư cùng với một ví Ethereum và trình duyệt ÐApp Web3. Ví Status hiện tại là một ví EOA giới hạn chúng tôi khỏi việc cung cấp một UX phong phú mà chỉ một ví hợp đồng thông minh mới có thể cung cấp như bảo mật đa chữ ký, khôi phục xã hội, giới hạn tốc độ, cho phép/từ chối danh sách địa chỉ và giao dịch meta không khí. Tuy nhiên, UX của các ví hợp đồng thông minh hiện nay đang bị ảnh hưởng nghiêm trọng bởi giá gas biến động mà không được giải quyết một cách hiệu quả bởi các bên trung gian truyền tin. AA nhắm mục tiêu giải quyết vấn đề này.

Trong bài viết này, chúng tôi thúc đẩy nhu cầu về Sự trừu tượng hóa tài khoản trong ngữ cảnh của ví hợp đồng thông minh. Sau đó, chúng tôi sẽ đi sâu vào các khía cạnh quan trọng của AA bằng cách mô tả các thay đổi giao thức và tác động đối với các node. Cuối cùng, chúng tôi sẽ thảo luận về một số phần mở rộng được đề xuất và kết luận bằng cách hợp lý hóa lộ trình dự kiến cho các dự án Status tương tác với Ethereum và do đó có thể bị ảnh hưởng bởi AA.

Lịch sử & Động lực

Trừu tượng tài khoản ban đầu được đề xuất như là EIP-86 vào năm 2017 để thực hiện "Trừu tượng hóa nguồn gốc giao dịch và chữ ký" nhưng nguồn gốc của ý tưởng thúc đẩy đã quay trở lại thậm chí xa hơn nữa đến đầu năm 2016, nơi đã được đề xuất rằng: “Thay vì có một cơ chế trong giao thức mà ECDSA và mô hình nonce mặc định được tôn thờ như cách duy nhất “tiêu chuẩn” để bảo mật một tài khoản, chúng ta tiến hành những bước đầu tiên để định hình một mô hình trong tương lai mà tất cả các tài khoản đều là hợp đồng, hợp đồng có thể thanh toán gas, và người dùng có thể tự do định nghĩa mô hình bảo mật của riêng họ.”

Các đề xuất ban đầu được coi là thách thức trong việc triển khai do nhiều thay đổi giao thức cần thiết và các cam kết bảo mật phải được đáp ứng. Gần đây hơn, Vitalik và cộng sự đã đề xuất một bản thảo cho EIP-2938mô tả một cách triển khai đơn giản hơn bằng cách giữ thay đổi giao thức/konsensus tối thiểu và áp đặt các bảo đảm an ninh cần thiết thông qua các quy tắc mempool của nút. Vitalik’sBài thuyết trình Hội thảo nhóm Kỹ thuật EthereumvàBài thuyết trình ETHOnline(cùng với các bài viết đi kèm@SamWilsn/ryhxoGp4D">1 & @SamWilsn/S1UQDOzBv">2) bởi Sam Wilson & Ansgar Dietrichs (hai trong số các tác giả EIP khác) cung cấp sự giới thiệu tuyệt vời về chủ đề. Bài viết này tập trung vào các khía cạnh quan trọng từ tất cả các nguồn này.

Động lực: Lý do thúc đẩy đằng sau AA rất đơn giản nhưng cơ bản: Giao dịch Ethereum hiện nay có hiệu ứng có thể lập trình (đạt được thông qua cuộc gọi đến hợp đồng thông minh) nhưng chúng có tính hợp lệ cố định trong việc giao dịch chỉ hợp lệ nếu chúng có chữ ký ECDSA hợp lệ với nonce hợp lệ và có đủ số dư tài khoản. AA nâng cấp giao dịch từ tính hợp lệ cố định thành tính hợp lệ có thể lập trình bằng cách giới thiệu một loại giao dịch AA mới luôn bắt nguồn từ một địa chỉ đặc biệt mà trong đó giao thức không yêu cầu chữ ký, nonce hoặc kiểm tra số dư. Tính hợp lệ của các giao dịch AA như vậy được xác định bởi một hợp đồng thông minh mục tiêu mà có thể áp dụng các quy tắc hợp lệ của riêng mình sau đó có thể quyết định trả tiền cho các giao dịch đó.

Vì vậy, điều này có ích như thế nào? Hãy xem ví dụ về các ví Ethereum để nhấn mạnh lợi ích của AA.

Ví Hợp Đồng Thông Minh: Hầu hết các ví Ethereum hiện nay đều là ví EOA được bảo vệ bằng một khóa riêng được tạo ra từ cụm từ hạt giống. (A BIP-39Cụm từ khóa hoặc cụm từ ghi nhớ là một danh sách được sắp xếp từ 12-24 từ được chọn ngẫu nhiên từ một danh sách gồm 2048 từ. Điều này cung cấp đủ entropy cần thiết để có được một seed nhị phân được tạo ra bằng cách sử dụng hàm PBKDF2. Seed nhị phân sau đó được sử dụng để tạo ra các cặp khóa bất đối xứng cho BIP-32 ví.) Người dùng được mong đợi phải ghi lại cụm từ khóa ở một nơi an toàn vì nó có thể được yêu cầu sau này để khôi phục các khóa trên một ví khác. Tuy nhiên, các ví như vậy dễ bị đánh cắp khóa riêng tư hoặc mất cụm từ khóa dẫn đến mất tiền của người dùng.

Ví hợp đồng thông minh được triển khai trên chuỗi thông qua các hợp đồng thông minh (như tên gọi của nó). Các loại ví này cung cấp khả năng giảm thiểu rủi ro có thể lập trình và trải nghiệm thân thiện với người dùng bằng cách triển khai các tính năng như bảo mật đa chữ ký, khôi phục dựa trên xã hội hoặc thời gian, giới hạn tốc độ giao dịch hoặc số tiền, cho phép / từ chối danh sách địa chỉ, giao dịch meta không cần gas và giao dịch được gom nhóm.

Trong khi ví hợp đồng thông minh bị nguy cơ an ninh từ các hợp đồng thông minh có lỗ hổng, nguy cơ này có thể được giảm bớt thông qua kiểm thử an ninh và đánh giá thực hiện bởi nhà cung cấp ví. Nguy cơ trong ví EOA hoàn toàn nằm ở người dùng ví, người được giao phó với an ninh của cụm từ khóa mà không có bất kỳ biện pháp an ninh có thể có được với các hợp đồng thông minh.

Các ví hợp đồng thông minh điển hình là Argent, Authereum, Dapper, Dharma, Gnosis Safe, MonolithvàMYKEY. Việc áp dụng các ví như vậy dường như đang tăng lên như đã được chỉ ra bên dưới đồ thị.

Argent triển khai khôi phục xã hội không cần hạt giống với khái niệm Guardians của họ, người hoặc thiết bị mà người dùng tin tưởng có thể giúp khôi phục ví của người dùng. Argent cũng nhắm mục tiêu cung cấp bảo mật giống như ngân hàng (qua các tính năng như giới hạn giao dịch hàng ngày, khóa tài khoản và liên hệ được tin cậy) kết hợp với tính khả dụng giống như Venmo (qua việc sử dụng tên ENS thay vì địa chỉ và hỗ trợ cho các giao dịch siêu dữ liệu).

Gnosis Safe là một ví hợp đồng thông minh multi-sig tập trung vào quản lý đội ngũ quỹ yêu cầu một số tối thiểu (m-of-n) thành viên đội phải phê duyệt giao dịch trước khi có thể xảy ra. Nó cũng cho phép chữ ký không cần gas thông qua các giao dịch meta.

Tất cả các khả năng ví tiên tiến như vậy đều đòi hỏi việc sử dụng các hợp đồng thông minh không đơn giản. Người dùng ví cần một EOA với gas để tương tác với chúng hoặc phụ thuộc vào nhà cung cấp ví để hỗ trợ các giao dịch siêu thông qua các bộ truyền của nhà cung cấp hoặc các mạng bộ truyền của bên thứ ba như Mạng Trạm XăngTrong khi người đầu tiên dựa vào ETH thường được mua trên các sàn giao dịch tập trung sau KYC, người thứ hai nhắm đến việc giảm ma sát UX khi đăng ký này bằng cách chuyển gánh nặng của người dùng sang các bộ truyền thông với chi phí được bồi thường bởi nhà cung cấp ví trên chuỗi / ngoại tuyến và / hoặc bởi người dùng ngoại tuyến.

Tuy nhiên, các kiến trúc dựa trên relayer có ba điểm chính không mong muốn: (1) Chúng có thể được coi là trung gian tập trung với khả năng kiểm duyệt giao dịch (2) Chúng kỹ thuật/kinh tế không hiệu quả do phí gas cơ sở thêm 21000 cần thiết cho giao dịch của relayer và nhu cầu kinh doanh của họ để tạo lợi nhuận trên phí gas (3) Việc sử dụng các giao thức cụ thể của relayer buộc ứng dụng phải phụ thuộc vào cơ sở hạ tầng Ethereum không căn cứ với cơ sở người dùng nhỏ và không đảm bảo sẵn có.

Việc trừu tượng hóa tài khoản sẽ cho phép ví hợp đồng thông minh chấp nhận các giao dịch siêu chuyển tiền không cần gas của người dùng và thanh toán cho gas của họ mà không phụ thuộc vào mạng relayer. Khả năng ở tầng cơ bản này sẽ cải thiện đáng kể trải nghiệm người dùng mới của các ví như vậy mà không phải hy sinh các cam kết phân quyền của Ethereum.

Tornado Cash: Một ứng dụng liên quan đầy động lực là một trình kết hợp như tornado.cashnơi@tornadoTornado cải thiện tính riêng tư giao dịch bằng cách phá vỡ liên kết trên chuỗi giữa các địa chỉ bằng cách sử dụng một hợp đồng thông minh chấp nhận tiền ETH được gửi rồi có thể được rút bởi một địa chỉ khác. Người dùng được mong đợi cung cấp băm của một bí mật trong lúc gửi và sau đó cung cấp bằng chứng zkSnark trong lúc rút để chứng minh việc biết về bí mật mà không tiết lộ bí mật hoặc việc gửi trước đó. Điều này tách rời việc rút tiền từ việc gửi tiền.

Nhưng có một vấn đề rắc rối là việc rút tiền. Để thực hiện giao dịch rút tiền từ một địa chỉ mới được tạo ra, người dùng cần phải có một số ETH trong đó để thanh toán cho gas. Nguồn ETH này (thường là một sàn giao dịch) có thể làm hỏng tính riêng tư của Tornado. Lựa chọn thay thế ưu tiên là sử dụng một mạng relayer một lần nữa, có nhược điểm đã được đề cập trước đó.

Trừ tối đa một số phí gas (từ số tiền gửi ban đầu) và sau đó chuyển số tiền gửi còn lại đến địa chỉ rút tiền.

Trừu tượng tài khoản

Trừu tượng Hóa Tài khoản, như đã được đề xuất trong EIP-2938, cho phép hợp đồng là tài khoản cấp cao nhất trả phí và bắt đầu thực thi giao dịch. Điều này được thực hiện bằng cách giới thiệu các thay đổi của giao thức với một loại giao dịch AA mới yêu cầu hai lệnh mới: NONCE và PAYGAS, thay đổi các quy tắc mempool và mở rộng để hỗ trợ các cách sử dụng tiên tiến. Các loại tài khoản vẫn tiếp tục là hai (EOA và Hợp đồng Tài khoản) và tất cả các thay đổi đề xuất đều tương thích ngược với các giao dịch hiện tại, hợp đồng thông minh và giao thức.

Các ứng dụng của AA được xem xét trong hai danh mục: 1) Các ứng dụng đơn người dùng như ví hợp đồng thông minh, tạo một hợp đồng mới cho mỗi người dùng 2) Các ứng dụng đa người dùng như tornado.cash hoặc Uniswap, nơi nhiều người dùng tương tác với cùng một bộ hợp đồng thông minh.

Hỗ trợ AA cho các ứng dụng đa người dùng đòi hỏi nhiều nghiên cứu hơn và được đề xuất làm việc trong tương lai. Vì vậy, chúng tôi sẽ tập trung vào việc hỗ trợ AA cho một người dùng duy nhất trong bài viết này.

Thay đổi giao thức

Có một loại giao dịch mới được giới thiệu kèm theo hai opcode hỗ trợ là NONCE và PAYGAS. Đây là những thay đổi duy nhất trong giao thức.

Giao dịch AA: Một loại giao dịch AA mới AA_TX_TYPE được giới thiệu. Dữ liệu của nó được hiểu là RLP([nonce, target, data]) thay vì loại giao dịch hiện tại mà dữ liệu của nó là RLP([nonce, gas_price, gas_limit, to, value, data, v, r, s]).

Gas_price và gas_limit bị bỏ qua trong giao dịch AA được chỉ định bởi hợp đồng AA mục tiêu trong quá trình thực thi. Chữ ký ECDSA v, r, s bị bỏ qua trong giao dịch AA được thay thế bằng các kiểm tra xác thực cụ thể của hợp đồng trên dữ liệu. Địa chỉ đến được thay thế bằng địa chỉ hợp đồng mục tiêu. Giá trị bị bỏ qua vì địa chỉ gốc cho tất cả các giao dịch AA là địa chỉ ĐIỂM NHẬP (0xFFFF…FFFF) đặc biệt và không phải là EOA có giá trị đi kèm.

Các số nonce được xử lý tương tự như các giao dịch hiện có bằng cách kiểm tra xem tx.nonce == tx.target.nonce. nếu kiểm tra này thất bại thì giao dịch được coi là không hợp lệ nhưng nếu không, tx.target.nonce được tăng lên và giao dịch tiếp tục thực hiện.

Chi phí khí cơ bản của giao dịch AA được đề xuất là 15000 thay vì 21000 hiện tại (để phản ánh sự tiết kiệm chi phí từ việc thiếu chữ ký ECDSA nội tại). Hơn nữa, giao dịch AA không có giới hạn khí cơ bản. Khi bắt đầu thực hiện, giới hạn khí đơn giản được đặt là khí còn lại trong khối.

Mã lệnh NONCE: Mã lệnh NONCE (0x48) đẩy ra nonce của người được gọi, tức là hợp đồng mục tiêu AA, lên ngăn xếp EVM. Do đó, các nonce được tiết lộ cho EVM để cho phép xác minh chữ ký được thực hiện trên tất cả các trường giao dịch (bao gồm cả nonce) như một phần của quá trình xác minh trong hợp đồng AA.

Mã lệnh PAYGAS: Mã lệnh PAYGAS (0x49) lấy hai đối số từ ngăn xếp: (đỉnh) version_number, (thứ hai từ đỉnh) memory_start. version_number cho phép các triển khai trong tương lai thay đổi ngữ nghĩa của mã lệnh. Hiện tại, mã lệnh có các ngữ nghĩa sau:

1. Kiểm tra version_number == 0 (nếu không thì ném ngoại lệ)
2. Đọc gas_price = bytes_to_int(vm.memory[memory_start: memory_start + 32])
3. Đọc gas_limit = bytes_to_int(vm.memory[memory_start + 32: memory_start + 64])
4. Kiểm tra contract.balance >= gas_price * gas_limit (nếu không thì ném ngoại lệ)
5. Kiểm tra globals.transaction_fee_paid == False (nếu không thì ném ra ngoại lệ)
6. Kiểm tra khung thực thi AA == khung cấp cao nhất, tức là nếu việc thực thi EVM hiện tại thoát ra hoặc quay lại, việc thực thi EVM của toàn bộ giao dịch sẽ bị chấm dứt (nếu không thì ném ngoại lệ)
7. Thiết lập contract.balance -= gas_price * gas_limit
8. Đặt globals.transaction_fee_paid = True
9. Set globals.gas_price = gas_price and globals.gas_limit = gas_limit
10. Đặt ngữ cảnh thực thi hiện tại của remaining_gas = gas_limit - gas đã tiêu thụ

Khi giao dịch AA kết thúc, (globals.gas_limit - remaining_gas) globals.gas_price được chuyển đến người đào và hợp đồng AA được hoàn lại remaining_gasglobals.gas_price.

PAYGAS hoạt động như một điểm kiểm tra thực thi EVM. Bất kỳ sự quay lại nào sau điểm này chỉ sẽ quay lại cho đến đây và sau đó hợp đồng sẽ không nhận hoàn tiền và globals.gas_limit * globals.gas_price sẽ được chuyển đến người đào.

Loại giao dịch mới và hai mã opcode mới tạo thành các thay đổi cấp độ giao thức/đồng thuận và ý nghĩa của chúng tương đối dễ hiểu.

Quy tắc Mempool

“mempoolđề cập đến bộ cấu trúc dữ liệu trong bộ nhớ bên trong một nút Ethereum lưu trữ các giao dịch ứng cử trước khi được đào. Geth gọi đó là “hồ bơi giao dịch”; Parity gọi đó là “hàng đợi giao dịch.” Bất kể tên gọi, đó đều là một hồ bơi giao dịch đang đợi trong bộ nhớ để được bao gồm trong một khối. Hãy nghĩ về nó như là một “khu vực chờ” cho các giao dịch được chấp nhận vào một khối.

Hiện nay, với các quy tắc xác thực giao dịch cố định, các máy đào và các nút khác cần ít nỗ lực nhất để xác minh giao dịch trong bộ nhớ tạm của họ và tránh tấn công DoS. Ví dụ, một máy đào có thể chắc chắn rằng một giao dịch sẽ thực sự trả phí nếu nó có chữ ký ECDSA hợp lệ, nonce hợp lệ và có số dư tài khoản đủ. Các giao dịch khác trong bộ nhớ tạm của máy đào này chỉ có thể vô hiệu hóa giao dịch đang chờ xử lý này nếu chúng từ cùng địa chỉ và, hoặc tăng nonce hoặc giảm đáng kể số dư tài khoản. Những điều kiện này tối thiểu về mặt tính toán để cung cấp đủ niềm tin cho máy đào và các nút trong bộ nhớ tạm của họ để xem xét khối hoặc phát lại giao dịch tương ứng.

Các giao dịch AA mang đến sự phức tạp hơn với tính hợp lệ có thể lập trình của chúng. Các giao dịch AA không trả trước gas và phụ thuộc vào hợp đồng AA mục tiêu của chúng để trả gas (thông qua PAYGAS). Về mặt khái niệm, xử lý giao dịch AA được chia thành hai giai đoạn: giai đoạn xác minh ngắn hơn (trước PAYGAS) và giai đoạn thực thi dài hơn (sau PAYGAS). Nếu giai đoạn xác minh thất bại (hoặc ném ra một ngoại lệ), giao dịch sẽ không hợp lệ (giống như một giao dịch không phải AA với chữ ký không hợp lệ ngày nay), không được bao gồm trong một khối và người đào không nhận phí nào.

Người đào và nút do đó cần một cơ chế dự đoán để tránh sự phụ thuộc của tính hợp lệ của giao dịch AA đang chờ xử lý vào các giao dịch khác đang chờ trong mempool. Nếu không, việc thực thi của một giao dịch có thể làm mất tính hợp lệ của nhiều/tất cả giao dịch AA trong mempool dẫn đến cuộc tấn công DoS. Để tránh tình huống này, có hai quy tắc được đề xuất để thực thi (bởi người đào và nút nhưng không nằm trong giao thức chính) đối với các giao dịch AA trong mempool:

Hạn chế Opcode

Để ngăn chặn tính hợp lệ của giao dịch AA phụ thuộc vào bất kỳ trạng thái ngoại vi nào khác ngoài hợp đồng AA chính nó, các opcode sau được coi là không hợp lệ trong giai đoạn xác minh (tức là trước PAYGAS): các opcode môi trường (BLOCKHASH, COINBASE, TIMESTAMP, NUMBER, DIFFICULTY, GASLIMIT), BALANCE (của bất kỳ tài khoản nào, bao gồm cả mục tiêu chính nó), một cuộc gọi/tạo bên ngoài đến bất cứ thứ gì ngoại trừ mục tiêu hoặc một precompile (CALL, CALLCODE, STATICCALL, CREATE, CREATE2) và truy cập trạng thái bên ngoài mà đọc mã (EXTCODESIZE, EXTCODEHASH, EXTCODECOPY, DELEGATECALL) trừ khi địa chỉ là mục tiêu.

Dự kiến các nút sẽ loại bỏ các giao dịch AA khỏi bộ nhớ tạm mục tiêu vào các hợp đồng AA vi phạm quy tắc hạn chế mã này. Điều này đảm bảo rằng các giao dịch AA hợp lệ trong bộ nhớ tạm sẽ vẫn hợp lệ miễn là trạng thái hợp đồng AA không thay đổi.

Hạn chế tiền tố bytecode

Nếu các giao dịch không phải AA có thể ảnh hưởng đến trạng thái của các hợp đồng AA, thì điều này sẽ ảnh hưởng đến sự hợp lệ của các giao dịch AA trong mempool. Để ngăn chặn điều này, các giao dịch AA chỉ nên được phép nhắm mục tiêu vào các hợp đồng có một AA_PREFIX ở đầu bytecode của chúng, nơi AA_PREFIX thực hiện một kiểm tra rằng msg.sender là địa chỉ ENTRY_POINT đặc biệt của các giao dịch AA. Điều này hiệu quả ngăn chặn các giao dịch không phải AA tương tác với các hợp đồng AA.

Các nút được dự kiến sẽ loại bỏ các giao dịch AA đến các hợp đồng AA không có AA_PREFIX tại các điểm nhập bytecode của chúng.

Hai ràng buộc này được áp dụng trên các hợp đồng AA cùng nhau đảm bảo rằng: (1) trạng thái duy nhất mà logic hợp lệ của giao dịch AA có thể truy cập là trạng thái nội bộ của hợp đồng AA và (2) trạng thái này chỉ có thể được sửa đổi bởi các giao dịch AA khác nhắm mục tiêu vào hợp đồng AA cụ thể này.

Một giao dịch AA đang chờ xử lý đến một hợp đồng AA chỉ có thể bị vô hiệu hóa bởi một khối chứa một giao dịch AA khác nhắm đến cùng một hợp đồng AA. Tuy nhiên, vì đây không phải là những thay đổi giao thức/đồng thuận, các thợ đào có quyền bao gồm các giao dịch trong một khối mà vi phạm những quy tắc này.

Phần mở rộng

Các thay đổi giao thức và quy tắc mempool ở trên cho phép hợp đồng AA cơ bản triển khai các ứng dụng đơn người dùng như ví hợp đồng thông minh một cách đủ và an toàn. Các ứng dụng tiên tiến khác cần sự nới lỏng của các quy tắc trên hoặc cần triển khai các ứng dụng đa người dùng yêu cầu sự hỗ trợ hơn từ AA dưới dạng các tiện ích mở rộng như:

1. Mã lệnh SET_INDESTRUCTIBLE, vô hiệu hóa SELFDESTRUCT và cho phép các hợp đồng AA gọi thư viện bằng DELEGATECALL an toàn trong giai đoạn xác minh.
2. Mã lệnh IS_STATIC, trả về true nếu ngữ cảnh hiện tại là tĩnh và cho phép các bên gọi giao dịch không phải AA ghi đè vào hạn chế tiền tố bytecode trước đó và đọc giá trị từ hợp đồng AA một cách an toàn.
3. Mã lệnh RESERVE_GAS, thiết lập một ngưỡng dưới về gas tiêu thụ bởi hợp đồng AA khi được gọi từ một giao dịch không phải AA mà cố gắng ghi trạng thái hợp đồng. Điều này giúp buộc kẻ tấn công phải tiêu tốn một lượng gas tối thiểu để làm mất hứng thú với việc cố gắng vô hiệu hóa bất kỳ giao dịch AA nào trong mempool.

Có những yếu tố khác như nhiều giao dịch đang chờ xử lý, lưu kết quả của việc xác thực, giới hạn gas động cho việc xác thực và các giao dịch được tài trợ cần thiết để hỗ trợ các ứng dụng đa người dùng và chứng minh zk ví dụ như Tornado Cash. Cuộc thảo luận về chúng không nằm trong phạm vi của bài viết này.

Bước tiếp theo

EIP-2938 về Account Abstraction hiện đang ở chế độ nháp và đang được thảo luận trong diễn đàn nghiên cứu Ethereum. Bước tiếp theo cho EIP là được xem xét để bao gồm trong một trong những hard fork sắp tới. Các tác giả của EIP có vẻ đang nhắm đến hard fork sau Berlin (Berlin dự kiến sẽ diễn ra vào một thời điểm nào đó vàođầu năm 2021) mà thời gian của nó hiện tại vẫn chưa rõ ràng. Vì vậy, quá trình cho EIP-2938 vẫn còn sớm.

Ngoài ra, cũng không rõ liệu có cần phải bao gồm EIP-2938 ở Layer 1 (L1) của Ethereum không. Với sự linh hoạt tương đối của các giải pháp Layer 2 (L2) (như đã mô tả trong bài viết trước đây của chúng tôi bài báo) Ví dụ, Abstraction Tài khoản có thể được triển khai trên các L2 cụ thể mà không yêu cầu toàn bộ L1 phải nâng cấp. Tuy nhiên, vẫn có lợi ích khi hỗ trợ AA đồng nhất trên L1 ngay cả khi một số L2 triển khai phiên bản AA riêng của họ. Do đó, vẫn cần xem xét nơi và cách mà AA được triển khai.

"Abstraction tài khoản không quan trọng một cách tương đối, vì nó có thể được triển khai trên L2 mà không cần L1 hỗ trợ." — Vitalik về những điều vẫn quan trọng ở tầng cơ bản (trong suy nghĩ của ông)bài đăngtrên lộ trình Ethereum tập trung vào rollup).

Trạng thái: Ví Trạng thái hiện tại là một loại ví EOA khác biệt với việc gói gọn một tin nhắn riêng tư trung tâm và cho phép tích hợp như thanh toán trong cuộc trò chuyện hoặc bảo mật nâng cao với KeycardCác tính năng ví hợp đồng thông minh như multisig và khôi phục xã hội đang được xem xét cho việc hỗ trợ AA EIP-2938 sẽ giúp bằng cách loại bỏ sự phụ thuộc vào cấu trúc trung tâm và không hiệu quả dựa trên relayer, như đã mô tả trước đó.

Status cũng đang đánh giá các giải pháp L2 cả về việc hỗ trợ nhiều chuỗi trong ví của mình và cung cấp sự mở rộng cần thiết cho các trường hợp sử dụng khác nhau như đã mô tả trong bài viết trước đó của chúng tôi bài báo. Ví dụ, Keycard đang khám phá một mạng thanh toánnhững yêu cầu thiết kế của sự mở rộng theo mẫu thẻ tín dụng và khả năng hoàn thiện gần như ngay lập tức hiện tại không được Ethereum đáp ứng. Nữa, còn có nhiều sự kiện khác như Chương trình giới thiệu, Phản ứng SNT, Tribute-to-Talkvàtên ENS, tất cả đều sẽ được hưởng lợi từ khả năng mở rộng L2 để triển khai khả thi và trải nghiệm người dùng hợp lý. Nếu một giải pháp L2 khả thi thực hiện AA thì các dự án xây dựng trên nền tảng L2 đó sẽ có thể tận dụng các lợi ích của AA mà không cần phải phụ thuộc vào L1.

Tóm tắt

Một khía cạnh cơ bản của giao thức Ethereum là chỉ có Tài Khoản Sở Hữu Bên Ngoài (EOAs) mới có thể trả phí gas và bắt đầu thực thi giao dịch. Các Tài Khoản Hợp Đồng (CAs) không thể làm điều đó. Account Abstraction (AA) là một đề xuất nhằm thay đổi sự phân biệt này và cho phép CAs được xây dựng đặc biệt kiểm tra tính hợp lệ của một loại giao dịch AA mới theo cách lập trình, quyết định trả phí gas thay mặt và do đó hiệu quả bắt đầu thực thi mà không cần EOA.

AA có ý nghĩa quan trọng trong việc cải thiện trải nghiệm người dùng đáng kể trên nhiều tình huống khác nhau như ví tiền, máy trộn, ÐApps và DeFi mà không phụ thuộc vào kiến trúc dựa trên trung tâm và không hiệu quả của người chuyển tiếp. Các tình huống cơ bản với một người thuê, như ví hợp đồng thông minh, có thể được hỗ trợ an toàn bởi AA với sự giới thiệu của một loại giao dịch mới, hai mã opcode mới và hai quy tắc mempool mới. Các ứng dụng nhiều người thuê tiên tiến, như Tornado Cash, yêu cầu mở rộng để thay đổi giao thức này và quy tắc nút.

Trong bài viết này, chúng tôi đã khuyến khích sự cần thiết của AA trong ngữ cảnh của ví hợp đồng thông minh. Chúng tôi đã nêu bật các khía cạnh chính của AA bằng cách mô tả các thay đổi giao thức và tác động đối với các nút. Chúng tôi đã đề cập đến một số phần mở rộng được đề xuất cho các cách sử dụng tiên tiến và kết luận cuối cùng bằng cách đặt AA vào ngữ cảnh của lộ trình hiện tại của Ethereum và các ưu tiên tại Status.

Việc giảm ma sát và cải thiện trải nghiệm người dùng trong Web3 là ưu tiên hàng đầu của tất cả các dự án trong hệ sinh thái này. Trừ tài khoản, theo một cách nào đó, chắc chắn sẽ đóng một vai trò quan trọng trong nỗ lực này trong tương lai.

Tuyên bố:

1. Bài viết này được sao chép từ [ trạng thái], Chuyển tiếp tiêu đề gốc'Trừu tượng tài khoản (EIP-2938): Tại sao & Cái gì', Tất cả bản quyền thuộc về tác giả gốc [Rajeev Gopalakrishna]. Nếu có ý kiến phản đối về việc tái in này, vui lòng liên hệ Học cửađội, và họ sẽ xử lý nó ngay lập tức.

2. Miễn Trừ 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 cấu thành bất kỳ lời khuyên đầu tư nào.

3. Các 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 Gate Learn. Trừ khi có thông báo, việc sao chép, phân phối hoặc đạo văn các bài viết dịch là cấm.