Tác giả: Cobo Global
Mạng chủ Ethereum sắp đón nhận bản nâng cấp Pectra, đây là một bản cập nhật lớn, đồng thời giới thiệu nhiều . Trong đó, đã thực hiện một sự cải tạo đáng kể đối với , đề xuất này làm mờ ranh giới giữa EOA và , các khả năng mới mang lại ảnh hưởng đáng kể đến người dùng thông thường, các nhà cung cấp cơ sở hạ tầng và nhà phát triển.
Gần đây, đã hoàn thành trên mạng thử nghiệm và dự kiến sẽ sớm ra mắt trên mạng chủ. Bài viết này sẽ phân tích sâu về việc thực hiện , trình bày các cơ hội và rủi ro tiềm ẩn, cung cấp tham khảo cho các loại người dùng và người hành nghề.
Tổng quan
Tiêu đề chính thức của là "EIP-7702: Set EOA account code" với phụ đề "Add a new tx type that permanently sets the code for an EOA". Điều này tóm tắt rõ ràng về nội dung chính của đề xuất: cung cấp một loại giao dịch có thể thiết lập mã hợp đồng cho EOA.
Cụ thể, đề xuất này giới thiệu loại giao dịch mới có tên , cấu trúc dữ liệu như sau:
rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, value, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s])
authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]
So với loại giao dịch 0x02 thông thường, sự thay đổi chính là thêm trường . Mỗi phần tử trong đại diện cho một ủy quyền địa chỉ. Trong đó:
- chain_id là ID chuỗi có hiệu lực cho ủy quyền, dùng để chống tấn công tái phát
- nonce là nonce của địa chỉ người ủy quyền, tương tự nonce giao dịch thông thường, cũng dùng để chống tấn công tái phát
- address là địa chỉ được chỉ định để ủy quyền
- y_parity, r, s là dữ liệu chữ ký, thông qua ecrecover có thể lấy được địa chỉ authority, tức địa chỉ EOA khởi tạo ủy quyền
Mỗi giao dịch có thể chứa nhiều ủy quyền nêu trên. Cần lưu ý rằng các ủy quyền này có chữ ký độc lập, khác với chữ ký giao dịch chính, do đó có thể thực hiện thanh toán gas cho hành vi ủy quyền địa chỉ. Nhà cung cấp ví hoặc nhà phát triển ứng dụng có thể thanh toán gas cho authority, từ đó thực hiện ủy quyền EOA mà không cần authority giữ gas trên địa chỉ của mình.
Sau khi giao dịch được ghi vào chuỗi, sẽ thiết lập trường code của địa chỉ authority thành của địa chỉ được ủy quyền. DD có dạng như sau:
0xef0100 || address
Trong đó 0xef0100 là tiền tố cố định, address là địa chỉ của hợp đồng được ủy quyền. Cần lưu ý rằng, theo , người dùng không thể triển khai hợp đồng có mã bắt đầu bằng 0xef thông qua các phương thức triển khai hợp đồng thông thường (giao dịch có to trống, lệnh create/create2). Do đó, ủy quyền trên chỉ có thể được khởi tạo bởi EOA thông qua giao dịch 0x04.
Sau khi ủy quyền hoàn tất, tất cả các cuộc gọi hợp đồng đến authority sẽ sử dụng mã của địa chỉ address, đồng thời sử dụng storage của authority. Trải nghiệm sử dụng rất giống với hợp đồng proxy .
Tóm lại: cho phép EOA vừa giữ được khả năng khởi tạo giao dịch ban đầu, vừa có hiệu ứng của hợp đồng Proxy. Người dùng có thể sử dụng giao dịch để thiết lập, chỉnh sửa, hoặc xóa bỏ hợp đồng triển khai của Proxy.
Để biết thêm chi tiết kỹ thuật về , vui lòng tham khảo nguyên văn đề xuất.
Tác động và cơ hội của
là một thay đổi lớn, mang lại ảnh hưởng đáng kể đến các bên tham gia trong ngành blockchain, đồng thời cũng tạo ra nhiều cơ hội mới.
Nhà cung cấp ví hợp đồng
Từ tiêu đề và cơ chế triển khai của đề xuất, có thể thấy không cung cấp các khả năng cấp cao liên quan đến (như abstraction, abstraction, chữ ký abstraction, v.v.), mà chỉ cung cấp khả năng chuyển đổi EOA thành hợp đồng Proxy. Do đó, đề xuất này không xung đột với các cơ sở hạ tầng ví hợp đồng hiện có (như , etc.). Trái lại, có thể tích hợp gần như không cần điều chỉnh với các ví hợp đồng hiện có. Cho phép người dùng chuyển EOA thành ví , ví , từ đó tích hợp các chức năng như ký nhiều chữ ký, thanh toán , giao dịch theo lô, chữ ký passkey, v.v. Nếu các nhà cung cấp ví hợp đồng có thể tích hợp một cách nhanh chóng và trơn tru, họ có thể mở rộng đáng kể nhóm người dùng và nâng cao trải nghiệm người dùng.
Nhà phát triển DApp
Do cải thiện trải nghiệm người dùng của ví AA, nhà phát triển DApp có thể xem xét tích hợp ví AA rộng rãi hơn, mang lại trải nghiệm giao dịch tiện lợi và an toàn hơn cho người dùng với DApp. Ví dụ, tận dụng khả năng giao dịch theo lô của ví hợp đồng để thực hiện nhiều thao tác DeFi trong một giao dịch.
Từ một hướng khác, DApp cũng có thể xem xét phát triển hợp đồng Delegation tùy chỉnh theo đặc điểm của dự án, cung cấp cho người dùng các chức năng tương tác hợp đồng phức tạp.
Nhà quản lý tài sản
Đối với sàn giao dịch và nhà quản lý tài sản, thường phải quản lý hàng loạt địa chỉ làm địa chỉ nạp tiền cho người dùng, và định kỳ thực hiện việc tập trung tiền. Trong mô hình tập trung tiền truyền thống, sử dụng địa chỉ EOA làm địa chỉ nạp tiền, khi tập trung cần nạp một số lượng nhất định vào địa chỉ nạp tiền, sau đó địa chỉ nạp tiền chuyển khoản đến địa chỉ rút tiền. Toàn bộ quá trình tập trung tiền liên quan đến việc gửi nhiều giao dịch, quy trình dài và phải trả khoản phí lớn. Trong quá khứ, việc tập trung tiền của các tổ chức cũng từng gây ra tình trạng phí giao dịch trên chuỗi tăng cao và tắc nghẽn giao dịch.
Với sự xuất hiện của , EOA có thể được chuyển đổi một cách trơn tru thành ví hợp đồng, nhờ cơ chế thanh toán của , không còn cần giao dịch nạp . Đồng thời, có thể tận dụng tính lập trình được của ví hợp đồng để đóng gói nhiều giao dịch chuyển tiền tập trung vào một giao dịch duy nhất, giảm số lượng giao dịch và tiết kiệm . Cuối cùng, cải thiện hiệu quả tập trung và giảm chi phí tập trung.
Những rủi ro tiềm ẩn của
mang lại các chức năng tài khoản mới, đồng thời cũng đưa vào những rủi ro bảo mật tiềm ẩn, đòi hỏi nhà cung cấp ví, nhà phát triển hợp đồng và người dùng cần cảnh giác.
Nhà cung cấp ví
Do giới thiệu một loại giao dịch mới là , loại giao dịch này cũng liên quan trực tiếp đến người dùng thông thường. Do đó, các nhà cung cấp ví phần mềm như Metamask, Rabby và các nhà cung cấp ví phần cứng cũng cần cập nhật phần mềm để tích hợp loại giao dịch mới.
Vì có thể ủy quyền toàn bộ tài khoản, nhà cung cấp ví cần cung cấp cảnh báo đầy đủ cho người dùng trong giao diện người dùng, mức cảnh báo nên tương đương hoặc cao hơn so với Token Approve, Permit.
Nếu kiểm tra bảo mật đối với loại giao dịch mới không đủ nghiêm ngặt, có thể dẫn đến người dùng bị tấn công lừa đảo.
Người dùng thông thường
Người dùng thông thường cũng cần theo dõi các loại giao dịch mới của Ethereum, chú ý các bản cập nhật của ví phần mềm và phần cứng. Cần nhận biết và chú ý đầy đủ đối với các loại giao dịch đặc biệt này.
Đối với loại giao dịch này, cần kiểm tra kỹ lưỡng hợp đồng Delegation, nếu có đủ kiến thức kỹ thuật thì nên kiểm tra mã nguồn hợp đồng, tránh rủi ro bảo mật. Người dùng thông thường cần chú ý xem hợp đồng Delegation có mã nguồn mở và cung cấp báo cáo kiểm toán của bên thứ ba đáng tin cậy hay không.
Loại giao dịch mới này khó kiểm tra hơn các loại giao dịch trước đây và có khả năng kiểm soát ví mạnh hơn. Có thể dự đoán trong tương lai sẽ xuất hiện các cuộc tấn công lừa đảo sử dụng loại giao dịch này. Người dùng thông thường cần tích cực tích lũy kiến thức liên quan, nâng cao ý thức bảo mật.
Nhà phát triển hợp đồng
Tuy nhiên, trong kịch bản của EIP-7702, chữ ký ủy quyền tồn tại riêng biệt trong authorization_list, và bot tấn công có thể theo dõi các giao dịch ủy quyền trong bể giao dịch và gửi giao dịch ủy quyền trước, đồng thời gọi hàm khởi tạo để chiếm quyền kiểm soát ví hợp đồng. Nếu ví EOA đã có một số tài sản mã hóa, thì trong quá trình tấn công có thể trực tiếp chuyển tài sản, gây thiệt hại tài chính cho người dùng. Chúng tôi có thể dự đoán rằng trong giai đoạn đầu sau khi hoàn tất nâng cấp, chắc chắn sẽ có các cuộc tấn công dựa trên việc khởi tạo lạm dụng EIP-7702 trên chuỗi.
Sau khi nghiên cứu, hầu hết các triển khai mã hiện có trong mô hình Proxy cũ không thể an toàn khởi tạo trong kịch bản EIP-7702. Nhà phát triển nên điều chỉnh mã hiện có để tương thích với EIP-7702 trước khi cung cấp cho người dùng sử dụng. Người dùng cũng nên chú ý không ủy quyền cho các hợp đồng phiên bản cũ, để đảm bảo an toàn tài chính.
Đối với nhà phát triển, việc điều chỉnh tương thích EIP-7702 chủ yếu là kiểm tra quyền hạn của phương thức khởi tạo. Mã kiểm tra điển hình có thể như sau:
require(msg.sender == address(this), "Only self")
hoặc
require(ECDSA.recover(hash, signature) == address(this), "Only signed")
để đảm bảo chỉ EOA bản thân hoặc người giữ chữ ký hợp lệ mới có thể gọi phương thức khởi tạo. Xét đến kịch bản thanh toán gas, cách sau có thể được sử dụng phổ biến hơn.
2. Vấn đề xung đột cấu trúc lưu trữ của hợp đồng Delegation
Trong kịch bản EIP-7702, EOA có thể thường xuyên cập nhật Delegation, tương đương với nâng cấp Proxy. Do mỗi hợp đồng Delegation có thể do nhà cung cấp ví hoặc nhà phát triển DApp khác nhau cung cấp, nên cách triển khai có thể khác nhau. Điều này khác với kịch bản nâng cấp hợp đồng của một nhà phát triển duy nhất, nơi tính tương thích giữa các phiên bản dễ dàng hơn.
Cấu trúc lưu trữ biến của các hợp đồng Delegation khác nhau hầu như chắc chắn sẽ hoàn toàn khác nhau. Nếu các hợp đồng tái sử dụng cùng một Storage slot, thì có thể sẽ đọc được dữ liệu sai hoặc ghi vào dữ liệu không mong muốn, dẫn đến chức năng hợp đồng bị lỗi. Và một khi dữ liệu bị lỗi, việc sửa chữa cũng cần kỹ năng kỹ thuật cao, người dùng thông thường sẽ rất khó xử lý.
Ở đây, chúng tôi khuyến nghị nhà phát triển sử dụng chế độ quản lý Storage của ERC-7201, sử dụng không gian lưu trữ độc lập thông qua cách tiếp cận Namespace, tránh sử dụng các slot bắt đầu từ 0x0 mặc định.
3. Vấn đề quản lý quyền hạn của Delegation
EIP-7702 rất giống với hợp đồng Proxy, nhưng trong kịch bản EIP-7702, việc quản lý hợp đồng implementation được thực hiện ở cấp độ giao thức Ethereum. Tương tự như Proxy có một owner cố định không thể thay đổi. Do đó, tài khoản EOA có thể cập nhật hợp đồng bất cứ lúc nào, thay đổi bất kỳ dữ liệu nào trong không gian lưu trữ, và thực hiện bất kỳ hoạt động nào.
Nhà phát triển cần lưu ý sự khác biệt này, không thể tin tưởng vào dữ liệu trong không gian lưu trữ của EOA khi phát triển DApp, đặc biệt là những nhà phát triển quen với mô hình người dùng của Solana, Sui cần đặc biệt chú ý vấn đề này. Người dùng thông thường khi sử dụng cũng cần lưu ý vấn đề này.
Ví dụ, sau khi ủy quyền EOA cho ví đa chữ ký, quyền hạn cao nhất vẫn thuộc về chính private key của EOA.
4. Vấn đề về việc phá vỡ các giả định an toàn ban đầu do EOA mới
Trong các hợp đồng phiên bản cũ, một số giả định an toàn dựa trên người gửi là EOA có thể bị phá vỡ. Điển hình, các tiêu chuẩn hiện tại thường sử dụng mã sau để kiểm tra người gọi có phải là EOA hay không:
require(msg.sender == tx.origin, "Only EOA")
Ngoài ra, có thể còn giả định rằng EOA không có khả năng gọi hợp đồng, nên không cần giới hạn số lượng gọi hoặc kiểm tra tái nhập.
Trong kịch bản EIP-7702, ranh giới giữa EOA và CA bắt đầu mờ nhạt, EOA cũng có khả năng thực thi mã. Ngay cả khi đã vượt qua các kiểm tra trên, chuyển ETH vào EOA vẫn có thể kích hoạt fallback của hợp đồng proxy EOA, dẫn đến vấn đề tái nhập. Hoặc một số phương thức giới hạn mỗi giao dịch chỉ được gọi một lần (như phương thức phân phối khai thác một số token, phương thức mint NFT, v.v.), trong kịch bản mới có thể được thực hiện batch thông qua EOA Proxy, để thực hiện các cuộc tấn công suite không như mong đợi của nhà phát triển.
Tài liệu tham khảo
[1] EIP-3541: https://eips.ethereum.org/EIPS/eip-3541
[2] ERC-1167: https://eips.ethereum.org/EIPS/eip-1167
[3] EIP-7702: https://eips.ethereum.org/EIPS/eip-7702
[4] ERC-4337 SimpleAccount: https://github.com/eth-infinitism/account-abstraction/blob/develop/contracts/accounts/SimpleAccount.sol
[5] ERC-7201: https://eips.ethereum.org/EIPS/eip-7201
