EIP-2938 do Vitalik đề xuất sẽ mang lại những thay đổi gì cho Ethereum?

Lưu ý của biên tập viên: Bài viết này đến từThung lũng tiền điện tử trực tiếp (ID: cryptovalley)Lưu ý của biên tập viên: Bài viết này đến từ

Thung lũng tiền điện tử trực tiếp (ID: cryptovalley)"Thung lũng tiền điện tử trực tiếp (ID: cryptovalley)", Tác giả: Rajeev Gopalakrishna, Người dịch: Olivia, Odaily sao chép với sự cho phép.

Có hai loại tài khoản trong Ethereum. Tài khoản riêng bên ngoài (EOA) và Tài khoản hợp đồng (CA). EOA được kiểm soát bởi các 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 thanh toán gas. Trừu tượng hóa tài khoản (AA) là một đề xuất cho phép một hợp đồng trở thành một

tầng trên cùng

Động lực đằng sau 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 các tình huống khác nhau như ví, DApp và DeFi. Tính năng trừu tượng hóa tài khoản cung cấp chức năng lớp cơ sở trong Ethereum để quyết định khi nào có thể thanh toán gas và trả gas cho ai.

Ứ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 với ví Ethereum và trình duyệt Web3 DApp. Ví trạng thái hiện là ví EOA, 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ể, chẳng hạn như bảo mật đa chữ ký, khôi phục xã hội, giới hạn lãi suất, danh sách địa chỉ cho phép/từ chối và giao dịch meta không tốn xăng . 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 bộ lặp của bên thứ ba không thể giải quyết vấn đề này một cách hiệu quả. Sự trừu tượng hóa tài khoản nhằm giải quyết vấn đề này.

Trong bài báo này, chúng tôi giải quyết 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ề giao thức và tác động đối với 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 quy mô và kết luận bằng cách hợp lý hóa lộ trình đã lên kế hoạch cho dự án Status giao tiếp với Ethereum, tất cả đều có thể bị ảnh hưởng bởi việc trừu tượng hóa tài khoản."tiêu đề phụ"Lịch sử & Động lực"Tóm tắt tài khoản ban đầu được đề xuất vào năm 2017 dưới dạng EIP-86 để cho phép"

Tóm tắt nguồn gốc 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. Vào thời điểm đó, người ta đã đề xuất rằng:

Thay vì có một cơ chế trong giao thức sử dụng ECDSA và lược đồ nonce mặc định làm cách "tiêu chuẩn" duy nhất để giữ an toàn cho tài khoản, tốt hơn là nên thực hiện các bước ban đầu và xây dựng một mô hình trong đó về lâu dài, tất cả các tài khoản đều là hợp đồng và hợp đồng Gas có thể được thanh toán và người dùng có thể tự do xác định mô hình bảo mật của riêng họ.

Đề xuất ban đầu được coi là thách thức vì cần có nhiều thay đổi về giao thức và nhu cầu đảm bảo an ninh. Gần đây hơn, Vitalik và cộng sự đã đề xuất một bản dự thảo của EIP-2938, phác thảo một cách tiếp cận khả thi hơn: bằng cách giảm thiểu các thay đổi về giao thức/sự đồng thuận và thực thi các đảm bảo an toàn cần thiết thông qua các quy tắc mempool của 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 Online (và các bài viết liên quan 1 và 2) của 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 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 cơ bản: Các giao dịch Ethereum ngày nay có các hiệu ứng có thể lập trình được (được thực hiện bằng cách gọi các hợp đồng thông minh), nhưng chúng chỉ có giá trị cố định, tức là chỉ khi chúng có chữ ký ECDSA hợp lệ, nonce hợp lệ, và đủ số dư tài khoản hợp lệ cho giao dịch. Tóm tắt 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 hóa tài khoản mới. Loại giao dịch trừu tượng hóa 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ý, chữ ký 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 như vậy đượ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ì vậy, tại sao điều này là hữu ích? Chúng tôi sử dụng 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 ví Ethereum ngày nay là ví EOA, được bảo mật bằng khóa riêng được tạo từ cụm từ gốc. (Cụm từ gốc BIP-39 là một danh sách được sắp xếp 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 để thu được gốc nhị phân, được tạo bằng cách sử dụng hàm PBKDF2. Sau đó, gốc nhị phân đượ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 giữ cụm từ gốc ở 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 chiếc ví như vậy dễ bị đánh cắp khóa riêng hoặc mất cụm từ gốc, 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 trải nghiệm giảm thiểu rủi ro có thể lập trình và 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ỷ lệ đối với giao dịch hoặc số lượng, cho phép/từ chối danh sách địa chỉ, giao dịch không tốn gas và giao dịch theo lô.

Mặc dù các ví hợp đồng thông minh có thể gặp rủi ro bảo mật do các hợp đồng thông minh dễ bị tổn thương, nhưng rủi ro này có thể được giảm thiểu bằng cách kiểm tra và kiểm tra bảo mật do các nhà cung cấp ví thực hiện. Rủi ro của ví EOA hoàn toàn thuộc về người dùng ví, những 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ư biểu đồ bên dưới cho thấy, việc sử dụng các ví như vậy dường như đang tăng lên.

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

Gnosis Safe là một 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, yêu cầu số lượng thành viên nhóm tối thiểu (m-of-n) để phê duyệt các giao dịch xảy ra. Nó cũng cho phép chữ ký không tố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 được thiết lập tốt. Người dùng ví sẽ 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, chẳng hạn như Mạng trạm xăng. Cái trước dựa vào việc mua ETH trên các 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 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 người chuyển tiếp, chi phí do nhà cung cấp ví trên chuỗi/trên chuỗi chịu -bồi thường ngoài chuỗi và/hoặc người dùng ngoài chuỗi.

Tuy nhiên, kiến ​​trúc dựa trên bộ 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 kiểm duyệt giao dịch (2) giao dịch do bộ 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ọ cần kiếm lợi nhuận ngoài phí gas , do đó, nó không hiệu quả về mặt kỹ thuật/kinh tế (3) khi sử dụng giao thức chỉ chuyển tiếp buộc các ứng dụng phải dựa vào cơ sở hạ tầng Ethereum lớp không cơ sở, có cơ sở người dùng nhỏ hơn, không đảm bảo tính khả dụng.

Tornado Cash: Một ứng dụng tạo động lực có liên quan là máy trộn tiền xu như Tornado.cash, nơi Tornado cải thiện quyền riêng tư của giao dịch bằng cách phá vỡ mối quan hệ trên chuỗi giữa các địa chỉ bằng cách sử dụng hợp đồng thông minh chấp nhận tiền gửi ETH mà sau đó có thể được rút bởi 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 đó cung cấp 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 từ 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ả phí gas. Nguồn của ETH này (thường là trao đổi) sẽ xâm phạm quyền riêng tư của Tornado. Một lần nữa, giải pháp thay thế ưa thích là sử dụng mạng lưới các bộ lặp, nhưng nó 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 hóa 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 (khấu trừ từ số tiền ký quỹ trước đó), sau đó chuyển số tiền ký quỹ còn lại đến địa chỉ rút tiền.

tiêu đề phụ

Sự trừu tượng hóa tài khoản do EIP-2938 đề xuất cho phép các hợp đồng trở thành tài khoản cấp cao nhất trả 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 một thay đổi giao thức, một loại giao dịch trừu tượng hóa tài khoản mới yêu cầu hai opcode mới: NONCE và PAYGAS, các thay đổi đối với quy tắc của mempool và các tiện ích mở rộng để hỗ trợ sử dụng nâng cao. Vẫn có hai 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 yếu tố cần xem xét: 1) Ứng dụng một bên 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) Ứng dụng nhiều bên thuê, chẳng hạn như Tornado.cash hoặc Uniswap, nhiều người dùng và cùng một bộ Tương tác hợp đồng thông minh.

Hỗ trợ trừu tượng hóa tài khoản cho các ứng dụng nhiều bên thuê yêu cầu nghiên cứu thêm 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ợ trừu tượng hóa tài khoản một bên thuê trong bài viết này.

tiêu đề phụ

thay đổi giao thức

Một loại giao dịch mới đã được giới thiệu, cùng với hai opcodes 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 hiệu quả của nó được hiểu là RLP([nonce, target, data]) thay vì loại giao dịch hiện có. Loại hợp lệ cho loại thứ hai 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 khai thác tài khoản được chỉ định bởi hợp đồng khai thác tài khoản mục tiêu trong khi thực hiện. 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 kiểm tra xác minh dữ liệu theo một hợp đồng cụ thể. Địa chỉ đến được thay thế bằng địa chỉ hợp đồng đích. Lý do tại sao giá trị này bị bỏ qua là do địa chỉ gốc của tất cả các giao dịch tóm tắt tài khoản là một địa chỉ ENTRY_POINT đặc biệt (0xFFFF...FFF), 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 được tăng lên và giao dịch được tiếp tục.

Chi phí gas cơ sở cho các giao dịch trừu tượng hóa tài khoản được đề xuất là 15.000 thay vì 21.000 hiện tại (để phản ánh khoản 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 của 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ần được đặt thành gas còn lại cho nhóm.

Mã lệnh NONCE: Mã lệnh NONCE (0x48) đẩy NONCE của bên được gọi (nghĩa là hợp đồng mục tiêu trừu tượng hóa tài khoản) lên 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 trừu tượng hóa tài khoản.

Mã lệnh PAYGAS: Mã lệnh PAYGAS (0x49) tìm nạp hai tham số từ ngăn xếp: (trên cùng) version_number, (thứ hai 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 mã lệnh. 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ệ)

giải nén gas_price = bytes_to_int(vm.memory[memory_start: memory_start + 32])

giải nén 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_paid == Sai (nếu không thì ném ngoại lệ)

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

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

đặt globals.transaction_fee_paid = True

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

Khi kết thúc thực hiện giao dịch trừu tượng hó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 hóa 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. Bất kỳ hoàn nguyên nào sau thời điểm này sẽ chỉ được hoàn nguyên tại đây, sau đó hợp đồng không chấp nhận hoàn tiền và globals.gas_limit * globals.gas_price được chuyển cho người khai thác.

"Mempool "Loại giao dịch mới và hai opcode mới cấu thành các thay đổi ở cấp độ giao thức/đồng thuận và ngữ nghĩa của chúng tương đối dễ hiểu."tiêu đề phụ"quy tắc 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 cử viên trước khi khai thác. Geth gọi nó là"nhóm giao dịch"; Tính chẵn lẻ gọi nó là"hàng đợi giao dịch"

. Bất kể tên gọi là gì, nó là một nhóm các giao dịch nằm trong bộ nhớ đang chờ được đưa vào một khối. nghĩ về nó như một

khu vực chờ

Hiện tại, với các quy tắc về tính hợp lệ của giao dịch cố định, các công cụ khai thác và các nút khác có thể xác minh các giao dịch trong mempool của họ với nỗ lực tối thiểu, do đó tránh được các cuộc tấn công DoS. Ví dụ: nếu một người khai thác có chữ ký ECDSA hợp lệ, một nonce hợp lệ và có đủ số dư tài khoản, thì có thể chắc chắn rằng một giao dịch sẽ thực sự trả một khoản phí. Các giao dịch khác trong mempool của người khai thác chỉ có thể làm mất hiệu lực giao dịch đang chờ xử lý này nếu chúng bắt nguồ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 là tối thiểu về mặt tính toán để cho phép các công cụ khai thác và các nút có đủ niềm tin vào các bộ nhớ của họ để thực hiện chờ hoặc phát lại khối tương ứng.

Opcode Restriction

Các giao dịch trừu tượng hóa tài khoản giới thiệu độ phức tạp bổ sung với hiệu quả có thể lập trình của chúng. Các giao dịch trừu tượng hóa tài khoản không trả bất kỳ khoản gas trả trước nào và dựa vào các hợp đồng trừu tượng hóa 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 đưa ra một ngoại lệ), giao dịch không hợp lệ (như các giao dịch trừu tượng hóa không phải 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 không nhận được phí.

tiêu đề phụ

Để ngăn tính hợp lệ của 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: TRƯỚC PAYGAS): Các 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), gọi/tạo hoặc biên dịch trước bên ngoài thành bất kỳ thứ gì khác ngoài mục tiêu (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 vào hợp đồng trừu tượng hóa tài khoản trong mempool và 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.

tiêu đề phụ

Hạn chế tiền tố mã byte

Nút sẽ đưa giao dịch trừu tượng hóa tài khoản vào 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ó.

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

Do đó, một giao dịch trừu tượng tài khoản chưa thanh toán sẽ chỉ bị vô hiệu nếu có một giao dịch đang chờ xử lý khác cho cùng một hợp đồng trừu tượng 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 những 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êu đề phụ

mở rộng

Các thay đổi giao thức đã nói ở trên 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 của một bên thuê như ví hợp đồng thông minh. Các mục đích sử dụng nâng cao khác cần nới lỏng các quy tắc trên hoặc cần triển khai các ứng dụng nhiều bên thuê yêu cầu trừu tượng hóa tài khoản để cung cấp thêm hỗ trợ dưới dạng tiện ích mở rộng, ví dụ:.

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

RESERVE_GAS opcode, 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 dưới đối với gas được tiêu thụ bởi một hợp đồng trừu tượng tài khoản đang tìm cách ghi vào trạng thái hợp đồng. Điều này làm 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 làm mất hiệu lực bất kỳ giao dịch trừu tượng nào của tài khoản trong mempool.

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

tiêu đề phụ

Bước tiếp theo của công việc

Tóm tắt tài khoản EIP-2938 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 để đưa vào một trong những hard fork sắp tới. Mục tiêu của tác giả EIP rõ ràng là một hard fork sau Berlin (Berlin dự kiến ​​được lên lịch vào khoảng đầu năm 2021) và thời gian biểu của nó hiện chưa rõ ràng. Vì vậy, còn quá sớm cho EIP-2938.

Trạng thái: Ví Status hiện là ví EOA, được phân biệt bằng cách 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 bảo mật nâng cao cho Keycard. Các tính năng của ví hợp đồng thông minh như multi-sig và phục hồi mạng 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 các kiến ​​trúc dựa trên trình chuyển tiếp tập trung và không hiệu quả, như đã thảo luận trước đó.

tóm tắt

Status cũng đang đánh giá một giải pháp L2, vừa để hỗ trợ đa chuỗi trong ví của mình vừa để cung cấp quy mô cần thiết cho các trường hợp sử dụng khác nhau, như chúng tôi đã đề cập trong một bài đăng trước đó. Ví dụ: Keycard đang khám phá một mạng thanh toán có 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 hiện chưa được mạng Ethereum đá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 Names, 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 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.

tiêu đề phụ

tóm tắt

Một khía cạnh cơ bản của giao thức Ethereum là chỉ các 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 các giao dịch. Tài khoản hợp đồng (CA) không thể làm điều này. Trừu tượng tài khoản (AA) là một đề xuất 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 các giao dịch trừu tượng tài khoản mới, quyết định thanh toán phí gas thay cho họ và do đó bắt đầu thực hiện chúng một cách hiệu quả mà không cần EOA .