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:

Độ sâu丨EIP-2938 do Buterin đề xuất sẽ mang lại những thay đổi gì cho Ethereum?

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

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.

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 khi tương tác với Ethereum trong nhiều tình huống khác nhau như ví, DApp và DeFi. Việc 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ư với ví Ethereum và 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ử & Động lực

Tính năng trừu tượng hóa tài khoản ban đầu được giới thiệu vào năm 2017 với tên gọi EIP-86 It đã được đề xuất dưới dạng "bản tóm tắt các nguồn giao dịch và chữ ký", 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 sẽ là một 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 sẽ cần phải thay đổi và cần phải đảm bảo an ninh. Gần đây, Vitalik Buterin 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. Bài thuyết trình Gặp gỡ nhóm kỹ thuật Ethereum của Vitalik và bài thuyết trình ETH trực tuyến (và các bài viết liên quan 1 và 2) được viết bởi Sam Wilson và Ansgar Dietrichs (hai tác giả EIP khác) cung cấp phần 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 rút ra từ tất cả các nguồn 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 mang tính cơ bản: Ethereum ngày nay Giao dịch Square có tác dụ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, tức là các giao dịch chỉ có hiệu lực khi có chữ ký ECDSA hợp lệ và nonce hợp lệ, đồng thời có đủ số dư tài khoản. Trừu tượng hó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 loại giao dịch trừu tượng hóa tài khoản mới. Loại giao dịch trừu tượng tài khoản này luôn đến từ một địa chỉ đặc biệt và giao thức không yêu cầu chữ ký, số không hoặc kiểm tra số dư trên đó. Tính hợp lệ 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, hợp đồng này 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 đó.

Vậy tại sao điều này lại hữu ích? Chúng tôi sử dụng ví Ethereum làm ví dụ để nêu bật 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ằng khóa riêng được tạo 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ự gồm 12-24 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 hàm PBKDF2. Hạt giống nhị phân sau đó được sử dụng để tạo một 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. Tuy nhiên, những ví như vậy dễ bị đánh cắp khóa riêng hoặc mất cụm từ hạt giống, 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 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 phải đối mặt với rủi ro bảo mật của các hợp đồng thông minh dễ bị tấn cô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 sử 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 cho phép khôi phục xã hội không cần chìa khóa thông qua khái niệm Người giám hộ của họ, trong đó Người giám hộ là những người hoặc thiết bị mà người dùng tin tưởng để giúp Lấy ví của người dùng .

Argent cũng đặt mục tiêu đạt được mức độ 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 ( Bằng cách sử dụng tên ENS thay vì địa chỉ và hỗ trợ giao dịch meta).

Gnosis Safe là ví hợp đồng thông minh đa chữ ký, tập trung vào việc quản lý quỹ của nhóm và yêu cầu số lượng thành viên nhóm tối thiểu (m-of-n) để phê duyệt giao dịch. 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í tiên tiến 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 dựa 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 nhà cung cấp ví trên chuỗi/trên chịu. -Bồi 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ó thể có tác động tiêu cực đến giao dịch. 2) Vì các giao dịch của người chuyển tiếp yêu cầu thêm 21.000 phí gas cơ bản và hoạt động kinh doanh của họ yêu cầu lợi nhuận ngoài phí gas, nên điều này không hiệu quả về mặt kỹ thuật/kinh tế (3) Việc sử dụng giao thức dành riêng cho rơle buộc các ứng dụng phải dựa vào lớp không cơ sở Cơ sở hạ tầng Ethereum, có cơ sở người dùng nhỏ 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à trả phí gas cho họ mà không cần dựa vào mạng lớp chuyển tiếp. 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 liên quan là máy trộn tiền xu, chẳng hạn như Tornado.cash, trong đó Tornado hoạt động bằng cách sử dụng hợp đồng thông minh để phá vỡ các liên kết trên chuỗi 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 có một vấn đề với việc 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 có một số ETH trong đó để trả tiền gas. 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à khấu trừ một số phí gas (từ khoản tiền gửi trước đó khấu trừ số tiền) và sau đó chuyển số tiền gửi còn lại đến địa chỉ rút tiền.

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

EIP-2938 The Việc trừu tượng hóa tài khoản được đề xuất trong tài liệu 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 hóa tài khoản mới yêu cầu hai mã hoạt động mới: NONCE và PAYGAS, các thay đổi đối vớ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 người thuê, chẳng hạn như ví hợp đồng thông minh, tạo hợp đồng mới cho mỗi người dùng 2) Các ứng dụng nhiều người thuê, chẳng hạn như Tornado.cash hoặc Uniswap, có 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 có 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 giao dịch mới loại và hai mã opcode 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 tiếp tục.

Chi phí gas cơ bản cho các giao dịch trừu tượng tài khoản được đề xuất là 15.000 thay vì 21.000 hiện tại (để phản ánh mức tiết kiệm chi phí do thiếu chữ ký ECDSA nội tại). 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 (nghĩa là 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ã opcode PAYGAS: Mã op PAYGAS (0x49) Lấy hai tham số từ ngăn xếp: (trên cùng) version_number, (thứ hai từ trên cùng) Memory_start.version_number được phép Việc triển khai trong tương lai có thể 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 sẽ đưa ra 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 thì ném ngoại lệ)

Kiểm tra Globals.transaction_fee_pay == Sai (nếu không sẽ đưa 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 quá trình thực thi EVM hiện tại thoát ra hoặc khôi phục, thì Thực hiện EVM của toàn bộ giao dịch Chấm dứt (nếu không sẽ ném một ngoại lệ).

Đặt hợp đồng.balance -= gas_price * gas_limit (giới hạn).

Đặt Globals.transaction_fee_pay = True

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

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

Khi kết thúc quá trình thực hiện giao dịch trừu tượng 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 tài khoản trả về còn lại_gas * Globals.gas_price.

PAYGAS thực hiện các điểm kiểm tra dưới dạng 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ễ hiểu.

Quy tắc Mempool

"Mempool" đề cập đến to là 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 các quy tắc hợp lệ giao dịch cố định, các công cụ khai thác và các nút khác yêu cầu nỗ lực tối thiểu để xác minh các giao dịch trong mempool của họ, 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 giao dịch sẽ thực sự trả phí. Các giao dịch khác trong mempool của người khai thác chỉ có thể vô hiệu hóa giao dịch đang chờ xử lý này nếu chúng đến từ cùng một địa chỉ và làm tăng nonce hoặc giảm đủ số dư tài khoản. Các điều kiện này được tính toán ở mức tối thiểu để các thợ mỏ và nút có đủ tin cậy vào mempool của họ để chờ hoặc phát lại các khối tương ứng.

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 tính hiệu quả có thể lập trình được 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 với 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 sự phụ thuộc trừu tượng của tài khoản đang chờ xử lý vào tính hợp lệ của giao dịch đối với 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ế Opcode

Để ngăn chặn trừu tượng hóa tài khoản Hiệu lực của giao dịch phụ thuộc vào bất kỳ yếu tố nào ngoài chính hợp đồng trừu tượng 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, DIFFICULTY, 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 bên ngoài tới bất kỳ thứ gì bên ngoài mục tiêu/tạo hoặc biên dịch trước (CALL, CALLCODE, STATICCALL, CREATE, CREATE2) và quyền truy cập trạng thái bên ngoài để đọc mã (EXTCODESIZE, EXTCODEHASH , EXTCODECOPY, DELEGATECALL ), trừ khi địa chỉ đó là mục tiêu.

Nút phải từ bỏ giao dịch trừu tượng hóa tài khoản nhắm mục tiêu hợp đồng trừu tượng hóa 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 không- Các giao dịch trừu tượng 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, điều này 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 hóa tài khoản sang hợp đồng trừu tượng hóa 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 cho hợp đồng trừu tượng tài khoản cùng đảm bảo rằng: (1) trạng thái duy nhất có thể truy cập được đối với logic hiệu lực của giao dịch trừu tượng tài khoản là trạng thái bên trong hợp đồng trừu tượng tài khoản, (2) chỉ có thể truy cập trạng thái này bởi các sửa đổi giao dịch trừu tượng Tài khoản khác cho hợp đồng tóm tắt tài khoản cụ thể này.

Do đó, giao dịch tóm tắt tài khoản chưa hoàn thành sẽ chỉ trở nên không hợp lệ trong một giao dịch đang chờ khác cho cùng một hợp đồng tóm tắt tài khoản. 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

Giao thức trên thay đổi và mempool Các quy tắc 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ê, chẳng hạn 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.

Mã opcode SET_INDESTRUCTIBLE vô hiệu hóa SELFESTRUCT, cho phép các hợp đồng trừu tượng của 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, trả về true nếu bối cảnh hiện tại là tĩnh, cho phép người gọi giao dịch trừu tượng không có tài khoản ghi đè các hạn chế tiền tố bytecode trước đó và trả về một cách an toàn từ Đọc giá trị từ hợp đồng tóm tắt tài khoản.

Mã opcode RESERVE_GAS, khi được gọi từ một giao dịch trừu tượng không có 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 một hợp đồng trừu tượng hóa tài khoản đang 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 đã được xác thực, giới hạn gas động được xác thực và các giao dịch được tài trợ, hỗ trợ các ứng dụng nhiều người thuê. 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

EIP tóm tắt tài khoản - 2938 hiện đang ở chế độ dự 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, vẫn chưa 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 ít quan trọng hơn vì nó có thể được triển khai trên L2 bất kể L1 có hỗ trợ hay không." --- Vitalik trong bài viết về tổng hợp- centric Bài viết Lộ trình Ethereum nói về những thứ sẽ tiếp tục hoạt động ở lớp cơ sở).

Trạng thái: Ví Trạng thái hiện là ví EOA, khác ở chỗ nó tích hợp hệ thống SMS tập trung vào quyền riêng tư và cho phép thanh toán trong trò chuyện hoặc Tích hợp như nâng cao bảo mật cho 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, vừa để hỗ trợ nhiều chuỗi trong ví của mình vừa để cung cấp các tiện ích mở rộng cần thiết cho các trường hợp sử dụng khác nhau, như chúng ta đã thảo luận trong phần Mô tả ở phần trước. bài báo. 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

Một trong những giao thức Ethereum Khía cạnh cơ bản 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 có ý nghĩa quan trọng 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í, bộ trộn, DApp và DeFi mà không cần dựa vào kiến trúc dựa trên bộ chuyển tiếp tập trung và kém 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 ma sát và cải thiện trải nghiệm người dùng là ưu tiên hàng đầu cho mọi dự án trong hệ sinh thái này. Ở một mức độ nào đó, việc trừu tượng hóa tài khoản chắc chắn sẽ đóng một vai trò quan trọng trong những nỗ lực trong tương lai.