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:

Đề xuất EIP-2938 của Vitalik là gì?

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

Tìm hiểu mức độ tài khoản trừu tượng do EIP-2938 đề xuất có thể giúp giảm bớt khó khăn và cải thiện trải nghiệm người dùng.

Tiêu đề gốc: "Chuyên sâu丨EIP-2938 do Vitalik đề xuất sẽ mang lại những thay đổi gì cho Ethereum? 》

Nguồn gốc: Thung lũng tiền điện tử

Ethereum có hai loại tài khoản. Tài khoản thuộc sở hữu bên ngoài (EOA) và Tài khoản hợp đồng (CA). EOA được kiểm soát bằng khóa riêng, trong khi CA được kiểm soát bởi mã hợp đồng thông minh có trong chúng. EOA luôn có nhiều đặc quyền hơn CA vì chỉ EOA mới có thể bắt đầu thực hiện giao dịch bằng cách trả phí gas. Trừu tượng hóa tài khoản (AA) là một đề xuất cho phép hợp đồng trở thành tài khoản "cấp cao nhất" như EOA, có thể trả phí và bắt đầu thực hiện giao dịch.

Động lực của việc trừu tượng hóa tài khoản là để cải thiện đáng kể trải nghiệm người dùng trong ví, Trải nghiệm người dùng khi tương tác với Ethereum trong nhiều tình huống khác nhau như DApps và DeFi. Tính năng trừu tượng hóa tài khoản cung cấp một lớp chức năng cơ bản trong Ethereum để quyết định khi nào có thể thanh toán gas và ai sẽ được thanh toán gas.

Ứng dụng Status Messenger tích hợp hệ thống nhắn tin tập trung vào quyền riêng tư cũng như ví Ethereum và thiết bị trình duyệt Web3 DApp. Ví trạng thái hiện là ví EOA, điều này hạn chế chúng tôi cung cấp trải nghiệm người dùng phong phú mà chỉ ví hợp đồng thông minh mới có thể cung cấp, chẳng hạn như bảo mật đa chữ ký, phục hồi xã hội, giới hạn lãi suất, danh sách địa chỉ được phép/từ chối và meta không cần gas giao dịch. Hiện tại, người dùng ví hợp đồng thông minh gặp phải tác động của biến động phí gas và các nhà chuyển tiếp bên thứ ba không thể giải quyết vấn đề này một cách hiệu quả. Việc trừu tượng hóa tài khoản nhằm giải quyết vấn đề này.

Trong bài viết này, chúng tôi trình bày nhu cầu trừu tượng hóa tài khoản trong bối cảnh ví hợp đồng thông minh. Sau đó, chúng tôi đi sâu vào các khía cạnh chính của việc trừu tượng hóa tài khoản bằng cách mô tả các thay đổi và tác động của giao thức lên các nút. Cuối cùng, chúng tôi thảo luận về một số đề xuất mở rộng và kết luận bằng cách hợp lý hóa lộ trình đã lên kế hoạch cho các dự án Trạng thái giao tiếp với Ethereum mà tất cả đều có thể bị ảnh hưởng bởi việc trừu tượng hóa tài khoản.

Lịch sử và động lực

Việc trừu tượng hóa tài khoản ban đầu được đề xuất vào năm 2017 dưới dạng EIP-86 để đạt được "bản tóm tắt về nguồn gốc và chữ ký giao dịch", nhưng nguồn gốc của ý tưởng này có thể bắt nguồn từ năm 2016. Khi đó, có người đề xuất: “Thay vì có cơ chế trong giao thức sử dụng ECDSA và sơ đồ nonce mặc định là cách “chuẩn” duy nhất để đảm bảo an toàn cho tài khoản, tốt hơn hết bạn nên thực hiện các biện pháp sơ bộ và thiết lập một mô hình. Về lâu dài, tất cả các tài khoản đều là hợp đồng và hợp đồng có thể trả phí gas và người dùng có thể tự do xác định mô hình bảo mật của riêng mình. "

Đề xuất ban đầu được coi là thách thức vì nhiều giao thức cần phải thay đổi và cần phải đảm bảo an ninh. Gần đây , Vitalik và cộng sự đã đề xuất bản dự thảo EIP-2938, trong đó nêu ra một cách tiếp cận dễ thực hiện hơn: bằng cách giảm thiểu các thay đổi đối với giao thức/sự đồng thuận và thực thi các đảm bảo bảo mật cần thiết thông qua các quy tắc bộ nhớ nút. và Bài trình bày trực tuyến ETH (và các bài viết liên quan 1 và 2) của Ansgar Dietrichs (hai tác giả EIP khác) giới thiệu chi tiết hơn về chủ đề này. Bài viết này nêu bật những điểm chính từ tất cả các nguồn Nội dung này.

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

Vậy tại sao điều này lại hữu ích? Hãy lấy ví Ethereum làm ví dụ để nêu bật những lợi ích của việc trừu tượng hóa tài khoản.

;

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

Ví hợp đồng thông minh được triển khai trên chuỗi thông qua hợp đồng thông minh. Ví này cung cấp khả năng giảm thiểu rủi ro chức năng 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ý, phục hồi xã hội hoặc dựa trên thời gian, giới hạn tốc độ giao dịch hoặc số tiền, danh sách địa chỉ được phép/từ chối, giao dịch không cần gas và giao dịch hàng loạt.

Mặc dù ví hợp đồng thông minh dễ bị tổn thương nhưng vẫn có rủi ro bảo mật đối với hợp đồng, nhưng rủi ro này có thể được giảm thiểu bằng cách kiểm tra và đánh giá bảo mật do nhà cung cấp ví thực hiện. Rủi ro của ví EOA hoàn toàn nằm ở người dùng ví, người được ủy thác bảo mật cụm từ hạt giống mà không có bất kỳ thủ tục nào trong hợp đồng thông minh để đảm bảo an ninh.

Ví dụ về ví hợp đồng thông minh là Argent, Authereum, Dapper, Dharma, Gnosis Safe, Monolith và MYKEY. Như được hiển thị trong biểu đồ bên dưới, tỷ lệ chấp nhận loại ví này dường như đang tăng lên.

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

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

Tất cả các tính năng ví nâng cao này đều yêu cầu sử dụng các hợp đồng thông minh phức tạp. Người dùng ví cần phải tương tác với EOA hoặc dựa vào nhà cung cấp ví để hỗ trợ các giao dịch meta thông qua bộ chuyển tiếp của nhà cung cấp hoặc mạng chuyển tiếp của bên thứ ba như Mạng trạm xăng. Cái trước phụ thuộc vào việc mua ETH trên một sàn giao dịch tập trung sau KYC, trong khi cái sau nhằm mục đích giảm bớt trở ngại về trải nghiệm người dùng trên chuỗi này bằng cách chuyển gánh nặng của người dùng sang những người chuyển tiếp, chi phí do người dùng chịu trên chuỗi/trên chuỗi nhà cung cấp ví Tiền thưởng ngoài chuỗi và/hoặc ngoài chuỗi cho người dùng.

Tuy nhiên, kiến trúc dựa trên chuyển tiếp có ba nhược điểm chính: (1) chúng có thể được coi là trung gian tập trung; Có khả năng là giao dịch sẽ được xem xét (2) Vì giao dịch của người chuyển tiếp yêu cầu thêm phí gas cơ bản 21000 và hoạt động kinh doanh của họ yêu cầu lợi nhuận ngoài phí gas, nên giao dịch này không hiệu quả về mặt kỹ thuật/kinh tế (3) Khi sử dụng các giao thức dành riêng cho người kế nhiệm buộc các ứng dụng phải dựa vào trên cơ sở hạ tầng Ethereum không phải lớp cơ sở, có cơ sở người dùng nhỏ hơn và đảm bảo tính khả dụng không chắc chắn.

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 không cần gas từ người dùng và thực hiện các giao dịch mà không cần dựa vào lớp chuyển tiếp mạng. Trả phí gas cho nó. Do đó, khả năng cấp cơ sở này sẽ cải thiện đáng kể trải nghiệm của người dùng khi sử dụng các ví như vậy mà không phải hy sinh các đảm bảo phân cấp của Ethereum.

Tornado Cash: Một ứng dụng tạo động lực có liên quan là một công cụ trộn tiền xu, chẳng hạn như Tornado.cash, trong đó Tornado sử dụng các hợp đồng thông minh Breaking liên kết trực tuyến giữa các địa chỉ để cải thiện quyền riêng tư của giao dịch, hợp đồng chấp nhận tiền gửi ETH mà sau đó có thể được rút bằng các địa chỉ khác nhau. Người dùng được yêu cầu cung cấp hàm băm của bí mật khi gửi tiền và sau đó là bằng chứng zkSnark khi rút tiền để thể hiện kiến thức về bí mật mà không tiết lộ bí mật hoặc chính khoản tiền gửi trước đó. Điều này tách riêng việc rút tiền khỏi tiền gửi.

Nhưng đã xảy ra sự cố khi rút tiền. Để thực hiện giao dịch rút tiền từ địa chỉ mới được tạo, người dùng cần phải có một số ETH trong đó Trả tiền xăng. Nguồn ETH này (thường là trao đổi) sẽ làm suy yếu quyền riêng tư của Tornado. Giải pháp thay thế ưu tiên là sử dụng lại mạng lặp lại, nhưng cách này có những nhược điểm đã nêu trước đó.

Việc trừu tượng hóa tài khoản sẽ giải quyết vấn đề này, cho phép hợp đồng Tornado chấp nhận giao dịch trừu tượng tài khoản rút tiền của người dùng, sau đó xác minh zkSnark và trừ một số phí gas (trừ vào số tiền gửi trước đó) và sau đó chuyển số tiền gửi còn lại về địa chỉ rút tiền.

Tóm tắt tài khoản

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

Ứng dụng trừu tượng hóa tài khoản được chia thành hai khía cạnh: 1) Các ứng dụng dành cho một bên thuê, chẳng hạn như ví hợp đồng thông minh, tạo một ứng dụng cho mỗi bên người dùng Hợp đồng mới 2) Các ứng dụng nhiều người thuê, chẳng hạn 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.

Việc hỗ trợ trừu tượng hóa tài khoản cho các ứng dụng nhiều người thuê cần phải nghiên cứu nhiều hơn và được đề xuất là công việc trong tương lai. Vì vậy, chúng tôi sẽ tập trung vào việc hỗ trợ việc trừu tượng hóa tài khoản một bên thuê trong bài viết này.

Thay đổi giao thức

Giới thiệu Một loại giao dịch mới được giới thiệu cũng như hai mã hoạt động hỗ trợ NONCE và PAYGAS. Đây là những thay đổi giao thức duy nhất.

Giao dịch trừu tượng tài khoản: Loại giao dịch trừu tượng tài khoản mới AA_TX_TYPE được giới thiệu. Loại hợp lệ của nó được hiểu là RLP([nonce, target, data]), không phải loại giao dịch hiện có. Các loại hợp lệ cho loại sau 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 trừu tượng tài khoản được chỉ định bởi hợp đồng trừu tượng tài khoản mục tiêu trong quá trình thực hiện. Các chữ ký ECDSA v,r,s bị bỏ qua trong giao dịch trừu tượng hóa tài khoản được thay thế bằng việc kiểm tra xác minh dữ liệu theo một hợp đồng cụ thể. Địa chỉ tới được thay thế bằng địa chỉ hợp đồng đích. Giá trị này bị bỏ qua vì địa chỉ gốc cho tất cả các giao dịch trừu tượng của tài khoản là địa chỉ ENTRY_POINT đặc biệt (0xFFFF...FFF) chứ không phải giá trị EOA được liên kết với nó.

Nếu kiểm tra không thành công, giao dịch được coi là không hợp lệ, nếu không, tx.target.nonce sẽ tăng lên và giao dịch sẽ tăng lên tiếp tục đi.

Chi phí gas cơ bản cho các giao dịch trừu tượng tài khoản được khuyến nghị là 15.000 thay vì 21.000 hiện tại (để phản ánh việc thiếu chữ ký ECDSA vốn có) tiết kiệm chi phí). Ngoài ra, các giao dịch trừu tượng tài khoản không có giới hạn gas nội tại. Khi bắt đầu thực hiện, giới hạn gas chỉ được đặt thành lượng gas còn lại cho nhóm.

Mã opcode NONCE: Opcode NONCE (0x48) đẩy NONCE của người được gọi (hợp đồng mục tiêu trừu tượng của tài khoản) vào ngăn xếp EVM. Do đó, Nonce được tiếp xúc với EVM để cho phép xác minh chữ ký của tất cả các trường giao dịch (bao gồm cả nonce) như một phần của xác minh trong hợp đồng tóm tắt tài khoản.

Mã hoạt động PAYGAS: Mã hoạt động PAYGAS (0x49) Lấy hai tham số từ ngăn xếp: (trên cùng) version_number, ( Tham số thứ hai từ trên cùng) Memory_start.version_number cho phép các triển khai trong tương lai thay đổi ngữ nghĩa của opcode. Hiện tại, ngữ nghĩa của opcode này như sau.

Kiểm tra version_number == 0 (nếu không thì ném ngoại lệ)

Trích xuất gas_price = bytes_to_int(vm.memory[memory_start: Memory_start + 32])

Trích xuất gas_limit = bytes_to_int(vm.memory[memory_start + 32: Memory_start + 64])

Kiểm tra hợp đồng.balance >= gas_price * gas_limit (nếu không sẽ đưa ra ngoại lệ)

Kiểm tra Globals.transaction_fee_pay = = Sai (nếu không sẽ ném ra một ngoại lệ)

Kiểm tra khung thực thi AA == khung cấp cao nhất, nghĩa là, nếu việc thực thi EVM hiện tại thoát hoặc được khôi phục thì việc thực thi EVM của toàn bộ giao dịch sẽ bị chấm dứt (nếu không sẽ đưa ra một ngoại lệ)

Đặt hợp đồng.số dư -= gas_price * gas_limit(limit)

Đặt Globals.transaction_fee_pay = True

Đặt Globals.gas_price = gas_price và Globals.gas_limit = gas_limit

Đặt bối cảnh thực thi hiện tại Lượng gas còn lại = gas_limit - lượng gas đã tiêu thụ

Khi kết thúc quá trình thực hiện giao dịch trừu tượng của tài khoản, (globals.gas_limit - còn lại_gas ) *globals.gas_price được chuyển cho người khai thác và hợp đồng trừu tượng của tài khoản trả về còn lại_gas *globals.gas_price.

PAYGAS làm điểm kiểm tra thực thi EVM. Mọi hoạt động hoàn nguyên sau thời điểm này sẽ chỉ hoàn nguyên về thời điểm này, khi đó hợp đồng sẽ không chấp nhận hoàn tiền và Globals.gas_limit * Globals.gas_price sẽ được chuyển cho người khai thác.

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

Quy tắc của Mempool

" Mempool "đề cập đến một tập hợp các cấu trúc dữ liệu trong bộ nhớ bên trong nút Ethereum để lưu trữ các giao dịch ứng viên trước khi khai thác." Geth gọi nó là "nhóm giao dịch"; Parity gọi nó là "hàng đợi giao dịch". Bất kể tên là gì, nó là một tập hợp các giao dịch nằm trong bộ nhớ đang chờ được đưa vào một khối. Hãy coi nó như một "khu vực chờ" chờ các giao dịch được chấp nhận vào một khối. "

Hiện tại, với quy tắc hợp lệ giao dịch cố định, thợ mỏ và các nút khác có thể xác minh nó mà không tốn nhiều công sức. , do đó tránh được các cuộc tấn công DoS. Ví dụ: nếu người khai thác có chữ ký ECDSA hợp lệ, số không hợp lệ và số dư tài khoản đủ, thì có thể chắc chắn rằng một giao dịch nhất định sẽ thực sự trả phí. chỉ làm mất hiệu lực một giao dịch đang chờ xử lý nếu nó đến từ cùng một địa chỉ và làm tăng số lần sử dụng hoặc giảm đủ số dư tài khoản. /p>

Các giao dịch trừu tượng về tài khoản gây ra sự phức tạp hơn do hiệu quả có thể lập trình của chúng. Các giao dịch trích xuất tài khoản không trả trước bất kỳ khoản gas nào và dựa vào hợp đồng trích xuất tài khoản mục tiêu của họ để thanh toán gas (thông qua PAYGAS). Về mặt khái niệm, quá trình xử lý giao dịch trừu tượng hóa tài khoản đượ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 hiện dài hơn (sau PAYGAS). Nếu giai đoạn xác minh không thành công (hoặc ngoại lệ được đưa ra), giao dịch không hợp lệ (giống như các giao dịch trừu tượng không có tài khoản có chữ ký không hợp lệ ngày nay), sẽ không được đưa vào một khối và người khai thác sẽ không nhận được bất kỳ khoản phí nào.

Do đó, các công cụ khai thác và nút cần có một cơ chế có thể dự đoán được để tránh tính hợp lệ của giao dịch trừu tượng hóa tài khoản đang chờ xử lý bị xâm phạm. các giao dịch đang chờ xử lý khác trong mempool. Mặt khác, việc thực hiện một giao dịch có thể làm mất hiệu lực nhiều/tất cả các giao dịch trừu tượng của tài khoản trong mempool, dẫn đến một cuộc tấn công DoS. Để tránh điều này, có hai quy tắc được đề xuất sẽ được thực thi trên các giao dịch trừu tượng của tài khoản trong mempool (được thực thi bởi các công cụ khai thác và nút, nhưng không phải trong chính giao thức).

Hạn chế mã hoạt động

Dành cho Để ngăn tính hiệu quả của các giao dịch trừu tượng hóa tài khoản phụ thuộc vào bất kỳ yếu tố nào ngoài chính hợp đồng trừu tượng hóa tài khoả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): Opcode môi trường (BLOCKHASH, COINBASE, TIMESTAMP, NUMBER), KHÓ KHÓ , GASLIMIT), BALANCE (bất kỳ tài khoản nào, bao gồm cả chính mục tiêu), lệnh gọi/tạo hoặc biên dịch trước bên ngoài cho bất kỳ thứ gì bên ngoài mục tiêu (CALL, CALLCODE, STATICCALL, CREATE, CREATE2) và truy cập trạng thái bên ngoài từ mã đọc ( EXTCODESIZE, EXTCODEHASH, EXTCODECOPY , DELEGATECALL) trừ khi địa chỉ đó là mục tiêu.

Nút phải từ bỏ giao dịch tóm tắt tài khoản nhắm mục tiêu hợp đồng tóm tắt tài khoản trong mempool để phá vỡ quy tắc hạn chế opcode này. Điều này đảm bảo rằng các giao dịch trừu tượng hóa tài khoản hợp lệ trong mempool sẽ vẫn hợp lệ miễn là trạng thái hợp đồng trừu tượng hóa tài khoản không thay đổi.

Hạn chế tiền tố bytecode

Nếu các giao dịch trừu tượng không phải tài khoản có thể ảnh hưởng đến trạng thái của hợp đồng trừu tượng tài khoản thì điều đó sẽ Ảnh hưởng đến tính hợp lệ của các giao dịch trừu tượng tài khoản trong mempool. Để ngăn điều này xảy ra, chỉ nên cho phép các giao dịch trừu tượng tài khoản đối với những hợp đồng có AA_PREFIX ở đầu mã byte của chúng, trong đó AA_PREFIX thực hiện kiểm tra xem msg.sender có phải là địa chỉ ENTRY_POINT đặc biệt của giao dịch trừu tượng tài khoản hay không. Điều này ngăn chặn một cách hiệu quả các giao dịch trừu tượng không có tài khoản tương tác với các hợp đồng trừu tượng tài khoản.

Nút sẽ chuyển giao dịch trừu tượng tài khoản sang hợp đồng trừu tượng tài khoản không có AA_PREFIX này trong điểm nhập mã byte của nó .

Hai hạn chế này được áp dụng đối với hợp đồng trừu tượng tài khoản cùng đảm bảo: (1) Logic hợp lệ của giao dịch trừu tượng tài khoản. trạng thái duy nhất có thể được truy cập là trạng thái bên trong hợp đồng trừu tượng tài khoản, (2) trạng thái này chỉ có thể được sửa đổi bởi các giao dịch trừu tượng tài khoản khác nhắm mục tiêu hợp đồng trừu tượng tài khoản cụ thể này.

Do đó, chỉ trong một giao dịch đang chờ xử lý khác cho cùng một hợp đồng tóm tắt tài khoản, giao dịch tóm tắt tài khoản chưa hoàn thành sẽ không thành công. Tuy nhiên, do đây không phải là những thay đổi về giao thức/sự đồng thuận, nên người khai thác có thể tự do đưa các giao dịch vào các khối vi phạm các quy tắc này.

Tiện ích mở rộng

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

opcode SET_INDESTRUCTIBLE, vô hiệu hóa SELFESTRUCT, cho phép hợp đồng tóm tắt tài khoản gọi thư viện của DELEGATECALL một cách an toàn trong giai đoạn xác minh.

Mã opcode IS_STATIC, nếu ngữ cảnh hiện tại là tĩnh, trả về true, cho phép người gọi giao dịch trừu tượng không có tài khoản ghi đè Bytecode trước đó hạn chế tiền tố để đọc các giá trị một cách an toàn từ các hợp đồng trừu tượng của tài khoản.

Mã opcode RESERVE_GAS, khi được gọi từ một giao dịch trừu tượng không phải tài khoản, sẽ thiết lập giới hạn thấp hơn về lượng gas tiêu thụ bởi hợp đồng trừu tượng tài khoản. giới hạn dưới là Tìm cách viết trạng thái hợp đồng. Tác dụng của việc này là buộc kẻ tấn công không tiêu thụ một lượng gas tối thiểu để ngăn chặn các nỗ lực vô hiệu hóa bất kỳ giao dịch trừu tượng hóa tài khoản nào trong mempool.

Có nhiều giao dịch khác như nhiều giao dịch đang chờ xử lý, kết quả được lưu trong bộ nhớ đệm để xác thực, giới hạn gas động để xác thực và các giao dịch tài trợ, những thứ này là cần thiết để hỗ trợ các ứng dụng nhiều người thuê và bằng chứng zk, chẳng hạn như Tornado Cash. Thông tin chi tiết về chúng nằm ngoài phạm vi của bài viết này.

Bước tiếp theo

Tài khoản Bản tóm tắt EIP-2938 hiện đang ở chế độ phác thảo và đang được thảo luận trong Diễn đàn nghiên cứu Ethereum. Bước tiếp theo đối với EIP là được xem xét đưa vào một trong những đợt hard fork sắp tới. Các tác giả EIP rõ ràng đang nhắm mục tiêu đến một hard fork hậu Berlin (Berlin dự kiến vào khoảng đầu năm 2021), mốc thời gian của việc này vẫn chưa rõ ràng. Vì vậy vẫn còn quá sớm cho EIP-2938.

Ngoài ra, không rõ liệu có cần thiết thêm EIP-2938 vào lớp cơ sở Ethereum 1 (L1) hay không . Do tính linh hoạt tương đối của các giải pháp Lớp 2 (L2) (như đã thảo luận trong bài viết trước của chúng tôi), việc trừu tượng hóa tài khoản có thể được triển khai trên một L2 cụ thể mà không cần nâng cấp toàn bộ L1. Tuy nhiên, ngay cả khi một số L2 triển khai phiên bản trừu tượng hóa tài khoản của riêng họ thì việc hỗ trợ thống nhất việc trừu tượng hóa tài khoản trên L1 vẫn mang lại lợi ích. Do đó, vẫn còn phải xem việc trừu tượng hóa tài khoản được triển khai ở đâu và như thế nào.

"Việc trừu tượng hóa tài khoản không quan trọng vì nó có thể được triển khai trên L2 bất kể L1 có hỗ trợ hay không." - -- Vitalik nói về những thứ sẽ tiếp tục hoạt động ở lớp cơ sở trong bài viết của anh ấy về lộ trình Ethereum tập trung vào tổng hợp).

Trạng thái: Ví trạng thái hiện là ví EOA, điểm khác biệt của nó là nó được tích hợp hệ thống SMS tập trung vào quyền riêng tư và cho phép tích hợp như thanh toán trong trò chuyện hoặc tăng cường bảo mật của Keycard. Các tính năng của ví hợp đồng thông minh như đa chữ ký và phục hồi xã hội đang được xem xét và hỗ trợ trừu tượng hóa tài khoản EIP-2938 sẽ giúp loại bỏ sự phụ thuộc vào kiến trúc dựa trên bộ chuyển tiếp tập trung và không hiệu quả, như đã đề cập trước đó.

Status cũng đang đánh giá các giải pháp L2, để hỗ trợ nhiều chuỗi trong ví của mình và cung cấp các Tiện ích mở rộng cần thiết, như chúng tôi đã đề cập trong các bài viết trước . Ví dụ: Keycard đang khám phá một mạng thanh toán với các yêu cầu thiết kế về khả năng mở rộng ở cấp độ thẻ tín dụng và tính hữu hạn gần như ngay lập tức mà mạng Ethereum hiện tại không thể đáp ứng. Ngoài ra, còn có nhiều chương trình khác như Chương trình giới thiệu, Tribute-to-Talk và 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à mang lại trải nghiệm tốt cho người dùng. Nếu một giải pháp L2 khả thi triển khai tính năng trừu tượng hóa tài khoản thì các dự án được xây dựng trên L2 đó sẽ có thể tận dụng tính năng trừu tượng hóa tài khoản mà không cần phải dựa vào L1.

Tóm tắt

Ethereum A Khía cạnh cơ bản của giao thức là chỉ Tài khoản thuộc sở hữu bên ngoài (EOA) mới có thể trả phí gas và bắt đầu thực hiện giao dịch. Tài khoản hợp đồng (CA) không thể thực hiện việc này. Trừu tượng tài khoản (AA) là một đề xuất nhằm thay đổi sự khác biệt này, cho phép các CA được xây dựng có mục đích kiểm tra theo chương trình tính hợp lệ của một loại giao dịch Trừu tượng tài khoản mới, quyết định thay mặt họ thanh toán phí gas và do đó bắt đầu thực hiện giao dịch đó một cách hiệu quả mà không cần EOA.

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

Trong bài viết này, chúng tôi đã đề cập đến nhu cầu trừu tượng hóa tài khoản trong bối cảnh 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 việc trừu tượng hóa tài khoản bằng cách mô tả các thay đổi và tác động của giao thức lên các nút. Chúng tôi đã đề cập đến một số tiện ích mở rộng được đề xuất cho các mục đích sử dụng nâng cao và cuối cùng, chúng tôi định vị việc trừu tượng hóa tài khoản trong lộ trình hiện tại của Ethereum và các ưu tiên của Trạng thái.

Giảm xung độ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. Việc trừu tượng hóa tài khoản, dưới một hình thức nào đó, chắc chắn sẽ đóng một vai trò quan trọng trong những nỗ lực trong tương lai.