Chi tiết ảnh hưởng của EIP-3074 đến ví và DApp
Tuyển chọn TechFlowTuyển chọn TechFlow
Chi tiết ảnh hưởng của EIP-3074 đến ví và DApp
EIP-3074 trao cho EOA khả năng thực thi phong phú như hợp đồng, mở ra nhiều trường hợp sử dụng mới.
Chuyên sâu báo cáo Web3Tác giả: Nic @ imToken Labs
EIP-3074
Trải nghiệm sử dụng tốt hơn và an toàn hơn
EIP-3074 cho phép EOA chuyển quyền kiểm soát sang một hợp đồng được chỉ định, nhờ đó có được khả năng thực thi phong phú như các hợp đồng.
Trước EIP-3074, mỗi lần EOA gửi giao dịch chỉ có thể thực hiện một thao tác duy nhất, ví dụ như approve ERC20 hoặc đổi tài sản trên Uniswap; sau khi áp dụng EIP-3074, EOA có thể hoàn thành nhiều thao tác cùng lúc, thậm chí mở ra những ứng dụng trước đây chưa từng tưởng tượng tới.
Tóm lại, EIP-3074 nâng cao đáng kể trải nghiệm người dùng. Cách thức ủy quyền hiện tại cũng sẽ được tái cấu trúc để tăng tính bảo mật mà không làm ảnh hưởng đến trải nghiệm sử dụng.
Hơn nữa, thông qua EIP-3074, EOA không còn cần tự gửi giao dịch lên chuỗi, do đó cũng không phải lo lắng về việc phải tích lũy ETH trước để trả phí giao dịch.
Hợp đồng Invoker
Hợp đồng có thể nhận được quyền kiểm soát từ EOA được gọi là hợp đồng Invoker. Tất nhiên, không phải bất kỳ hợp đồng nào cũng có thể nhận quyền kiểm soát: EOA phải ký bằng khóa riêng, nội dung chữ ký sẽ rõ ràng xác định hợp đồng Invoker nào và các thao tác nào được phép thực hiện bởi Invoker.
Nội dung chữ ký của EOA sẽ rõ ràng xác định địa chỉ của hợp đồng Invoker (invoker address) và các hành động được ủy quyền cho Invoker (commit).
Quy trình thực thi thực tế sẽ diễn ra như sau:
-
Alice dùng khóa riêng của EOA để ký, sau đó gửi nội dung ký và chữ ký cho Relayer.
-
Relayer mang dữ liệu này lên chuỗi để thực thi trong hợp đồng Invoker.
-
Invoker xác minh chữ ký, nếu hợp lệ thì sẽ thực hiện các thao tác dưới danh nghĩa EOA, ví dụ như approve USDC, sau đó trao đổi tài sản trên Uniswap, rồi dùng một phần USDC để trả phí cho Relayer.
Ghi chú 1: Relayer không bắt buộc, Alice cũng có thể tự mang nội dung ký và chữ ký lên chuỗi.
Sau khi Invoker xác minh chữ ký và bắt đầu thực thi, mọi hành động đều được thực hiện dưới danh nghĩa EOA của Alice – giống như đã nhận được quyền kiểm soát (có giới hạn) đối với EOA đó.
Tuy nhiên cần lưu ý rằng, sau khi thực thi xong, giá trị nonce của EOA sẽ không tăng lên. Do đó, cùng một chữ ký có thể bị sử dụng lại (miễn là nonce của EOA vẫn chưa đổi), vì vậy Invoker cần tự triển khai cơ chế chống replay riêng.
Nếu hợp đồng Invoker không có biện pháp chống replay, thì cùng một lần ủy quyền có thể bị thực thi liên tục.
Tìm hiểu thêm về cách hoạt động thực tế của EIP-3074, vui lòng tham khảo: https://medium.com/taipei-ethereum-meetup/eip3074-%E7%B0%A1%E4%BB%8B-2a880b918234
Các ứng dụng
Batchcall
Cho phép người dùng gộp nhiều giao dịch tách biệt thành một thao tác duy nhất, tiết kiệm quá trình ký duyệt nhiều lần và giảm chi phí gas.
Ghi chú: Điều này yêu cầu DApp phải hỗ trợ chức năng Batchcall, ví dụ như EIP-5792 đang được cộng đồng đề xuất. Nếu không, DApp vẫn coi người dùng là EOA bình thường và sẽ nhắc người dùng ký riêng cho từng thao tác.
Tìm hiểu thêm về EIP-5792, vui lòng sao chép liên kết vào trình duyệt: https://eips.ethereum.org/EIPS/eip-5792
Session Key
Người dùng cũng có thể cho bên thứ ba thực hiện thao tác thay mình trong điều kiện giới hạn, ví dụ như delegate key trong hình là bên được ủy quyền; access policy là các điều kiện giới hạn hành động, ví dụ chỉ được thao tác trên Uniswap, tối đa chuyển đi 1 ETH mỗi ngày, thời hạn hiệu lực của ủy quyền, v.v.
Các điều kiện này được thiết kế và kiểm tra bên trong hợp đồng Invoker. Chỉ khi vượt qua kiểm tra thì bên thứ ba mới được thực hiện thao tác dưới danh nghĩa EOA của người dùng.
Bot Telegram có thể được cấp quyền cụ thể để thực hiện thao tác dưới danh nghĩa EOA của người dùng.
Native ETH Permit
Miễn là điều kiện thỏa mãn (tức chữ ký permit hợp lệ), có thể thực hiện chuyển ETH dưới danh nghĩa EOA của người ủy quyền, đạt được hiệu quả tương tự "Permit" dành cho ETH gốc.
Limit Order
Người dùng điền điều kiện lệnh giới hạn, khi điều kiện đạt được, hệ thống sẽ thực hiện dưới danh nghĩa EOA của họ, bao gồm cả việc approve tài sản số cho DEX và thực hiện hoán đổi trên DEX. So với lệnh giới hạn do chính DEX cung cấp, người dùng không cần phải gửi giao dịch approve trước cho DEX.
Khi Alice khớp lệnh, thao tác Approve sẽ được thực hiện ngay lập tức, không cần phải Approve trước.
Nếu điều kiện được thiết kế linh hoạt hơn, nó sẽ trở thành một hợp đồng Intent: bất cứ khi nào điều kiện do người dùng đặt ra được đáp ứng, bất kỳ ai cũng có thể thực hiện hành động thay mặt họ dưới danh nghĩa EOA.
Chỉ cần điều kiện Intent được đáp ứng, bất kỳ ai cũng có thể khởi tạo thực thi dưới danh nghĩa EOA của người dùng.
Social Recovery
Khi người dùng mất khóa riêng của EOA, họ có thể dựa vào ủy quyền EIP-3074 đã ký trước đó, kết hợp với chữ ký từ những người được ủy quyền (ví dụ Husband và Trust Agent) để chuyển toàn bộ tài sản khỏi EOA. Trên thực tế, cái được khôi phục là tài sản (có thể chuyển đi), chứ không phải quyền kiểm soát tài khoản. Sau khi mất khóa riêng, EOA đó sẽ không thể sử dụng được nữa.
Khi người dùng mất khóa riêng EOA, những người được ủy quyền trước đó có thể ký để chuyển tài sản khỏi EOA.
Tác động của EIP-3074
Cải thiện phương thức ủy quyền tài sản, thậm chí thay thế approve/permit?
Hiện tại, DApp đều được thiết kế với giả định người dùng sử dụng EOA: người dùng phải "approve trước" và "approve một lượng tài sản lớn" cho hợp đồng DApp, để đảm bảo họ không cần luôn trực tuyến, chờ DApp thực thi hay phải liên tục approve lại — điều này cải thiện đáng kể trải nghiệm sử dụng.
Ví dụ, các ứng dụng kích hoạt theo điều kiện như lệnh giới hạn hay DCA, người dùng không nhất thiết phải trực tuyến khi điều kiện xảy ra, nên cần approve trước một lượng tài sản đủ lớn để DApp thực thi, thậm chí thực hiện nhiều lần.
Người dùng phải approve trước một lượng tài sản lớn cho DApp để DApp dễ dàng thao tác với tiền của họ.
Tuy nhiên, điều này đòi hỏi người dùng phải tin tưởng DApp hoặc tránh approve cho DApp giả mạo, đồng thời cần có khả năng thu hồi approval nhanh chóng.
Sau này xuất hiện mô hình permit, như EIP-2612 hoặc Permit2 phi bản địa, nhằm cải thiện trải nghiệm và độ an toàn so với mô hình approve: người dùng không cần approve một lượng lớn tài sản cho từng hợp đồng DApp (và mỗi tài sản đều phải approve riêng), mà chỉ cần "ký một lần" để cho phép DApp rút một lượng tài sản nhất định trong một khoảng thời gian xác định. Như vậy vừa thu hẹp đáng kể bề mặt tấn công, vừa nâng cao trải nghiệm người dùng.
Tìm hiểu thêm chi tiết EIP-2612, vui lòng sao chép liên kết sau vào trình duyệt: https://eips.ethereum.org/EIPS/eip-2612
Chi tiết Permit2, vui lòng sao chép liên kết sau vào trình duyệt: https://medium.com/taipei-ethereum-meetup/uniswap-permit2-introduction-858ae3dddf18
Người dùng chỉ cần ký ngoài chuỗi, có thể chỉ định số lượng tài sản và thời gian hiệu lực, mang lại trải nghiệm và độ an toàn vượt trội so với approve.
Tuy nhiên trên thực tế, mô hình permit vẫn thường xuyên bị lợi dụng để lừa đảo: nạn nhân vô tình ký một permit tưởng là dành cho DApp nhưng thực chất lại cấp cho kẻ tấn công.
Khi ký permit, người dùng chỉ thấy được họ đang ủy quyền cho ai, chứ không biết hành động này sẽ được kết hợp với thao tác gì khác.
Ghi chú: Hơn nữa, thiết kế permit hiện tại không tương thích với các DApp yêu cầu thao tác lặp lại như DCA hay thanh toán định kỳ. Vì permit có cơ chế chống replay, nên sau một lần chuyển tiền, permit đó không thể dùng lại — điều này buộc người dùng phải ký trước permit cho từng lần thực hiện trong tương lai.
Tìm hiểu thêm các sự việc mô hình permit bị lợi dụng để lừa đảo, vui lòng sao chép liên kết sau vào trình duyệt:
https://x.com/realScamSniffer/status/1783027808723435727https://x.com/realScamSniffer/status/1784932506174967970https://x.com/realScamSniffer/status/1786738218962223226
Tuy nhiên, EIP-3074 mang lại cơ hội thay đổi: khi nhà phát triển DApp biết rằng EOA có thể thực hiện các thao tác phức tạp thông qua Invoker, họ sẽ không còn phải đánh đổi giữa trải nghiệm và bảo mật — ví dụ như "approve trước một lượng tài sản lớn" hay "người dùng ký thông báo permit cho phép rút tiền".
Thay vào đó, người dùng sẽ gắn liền thao tác DApp với approve, thực hiện nguyên tử (Atomic) thông qua Invoker: hoặc cả hai cùng thành công, hoặc cùng thất bại — không thể xảy ra trường hợp approve thành công riêng lẻ. Do đó, người dùng hoàn toàn yên tâm rằng lần approve này chỉ dành cho thao tác hiện tại.
Hơn nữa, người dùng sử dụng phương thức ủy quyền ký ngoài chuỗi, nên trải nghiệm giống hệt permit! Điều này có nghĩa DApp sẽ không còn cần mô hình permit nữa! Trong tương lai, ví có thể trực tiếp chặn hoặc kiểm tra nghiêm ngặt các yêu cầu ký permit, mà không cần lo lắng việc này làm người dùng không dùng được một số DApp (nhưng lại khiến họ dễ bị lừa đảo).
Người dùng không còn chỉ đơn thuần ủy quyền cho một địa chỉ, mà còn biết rõ địa chỉ đó được làm gì, thậm chí có thể xem trước kết quả mô phỏng thực thi.
Ghi chú: Điều này không có nghĩa loại bỏ hoàn toàn lừa đảo! Người dùng vẫn có thể bị dẫn đến trang web giả mạo, nơi có thể dựng lên thao tác approve hoặc chuyển tiền để yêu cầu ký. Tuy nhiên lúc này, người dùng ít nhất có thể thấy rõ chữ ký này dùng để làm gì, ví thậm chí có thể hiển thị kết quả mô phỏng thực thi để người dùng biết rõ ai sẽ mất tiền, ai sẽ nhận được tiền. So với permit không thể biết mục đích hay kết quả thực thi, người dùng giờ đây có nhiều thông tin hơn để quyết định có nên ủy quyền hay không. Mặc dù không hoàn hảo, nhưng đây vẫn là bước cải thiện lớn so với hiện trạng.
Ví nên xử lý EOA nonce như thế nào
Thiết kế EIP-3074 hiện tại bao gồm giá trị nonce của EOA trong nội dung chữ ký. Do đó, chỉ cần EOA gửi một giao dịch lên chuỗi làm thay đổi nonce, tất cả các ủy quyền EIP-3074 trước đó sẽ lập tức mất hiệu lực.
Nếu người dùng ủy quyền cho người khác thao tác thay EOA, ví dụ như mô hình Session Key hay Social Recovery nêu trên, thì nonce của EOA cần được giữ nguyên — nếu không, họ phải ký lại toàn bộ ủy quyền và gửi cho người được ủy thác, gây ảnh hưởng lớn đến trải nghiệm và độ ổn định của cơ chế.
Nếu người dùng tự thực hiện thao tác ủy quyền, thì không cần quá lo ngại về việc nonce EOA bị thay đổi, vì chữ ký EIP-3074 cũng như giao dịch thông thường, đều được kỳ vọng thực thi trong một khoảng thời gian nhất định. Tuy nhiên, ví cần quản lý thêm giao dịch EIP-3074 của EOA: nếu có chữ ký EIP-3074 đang chờ lên chuỗi, thì giao dịch do chính EOA gửi phải chờ đợi.
Ghi chú: Hợp đồng Invoker tự thân (và nên) duy trì một cơ chế nonce riêng, do đó sau khi dùng chữ ký, cần ký lại — bất kể nonce EOA có thay đổi hay không.
Session Key và Social Recovery rất có thể phải đợi đến khi EIP-3074 sửa đổi quy tắc, loại bỏ nonce EOA khỏi nội dung chữ ký, mới có thể được áp dụng rộng rãi. Do đó, ví chỉ cần tập trung vào trường hợp "người dùng tự ủy quyền thao tác", và coi chữ ký EIP-3074 như một giao dịch bình thường — như vậy sẽ không cần lo ngại về việc EOA gửi giao dịch hay thay đổi nonce.
Tuy nhiên cần lưu ý, nếu người dùng tự mang chữ ký EIP-3074 của mình lên chuỗi, sẽ có hai nhược điểm:
-
Người dùng phải ký hai lần: một lần cho chữ ký EIP-3074, một lần cho giao dịch lên chuỗi.
-
Vì giao dịch lên chuỗi sẽ tăng nonce EOA lên +1 ngay trước khi thực thi, nên trong chữ ký EIP-3074, giá trị nonce EOA phải được +1 trước để khớp với sự thay đổi này.
Việc tự lên chuỗi sẽ làm tăng nonce EOA lên +1 trước, dẫn đến việc xác minh chữ ký EIP-3074 thất bại do nonce không khớp.
Nếu người dùng tăng trước giá trị nonce trong chữ ký EIP-3074 lên +1 trước khi lên chuỗi, thì việc xác minh sẽ thành công.
Tổng kết và điểm chính
-
EIP-3074 giúp EOA có được khả năng thực thi phong phú như hợp đồng, mở ra nhiều ứng dụng mới.
-
Điều này không chỉ nâng cao trải nghiệm người dùng, mà còn thay đổi phương thức ủy quyền hiện tại, giúp tăng tính bảo mật mà không ảnh hưởng đến trải nghiệm.
-
Hơn nữa, EIP-3074 chỉ là chữ ký đơn thuần, người dùng không nhất thiết phải tự mang chữ ký lên chuỗi thực thi, do đó không cần lo lắng về việc phải tích lũy ETH để trả phí giao dịch.
-
Ứng dụng của EIP-3074 bao gồm Batch Call, Session Key, Native ETH Permit, Limit Order, Social Recovery. Nhiều ứng dụng trong số này trước đây EOA không thể thực hiện, một số như Limit Order cần phương pháp tiền ủy quyền kém an toàn.
-
EIP-3074 cũng sẽ thay đổi cách ủy quyền hiện tại. Phương thức approve trực tiếp cấp quyền rút tài sản vô thời hạn cho một địa chỉ nhất định, và yêu cầu EOA phải gửi một giao dịch trước để approve — trải nghiệm và độ an toàn đều kém. Permit chỉ cần người dùng ký, mỗi lần ký đều xác định rõ số lượng tài sản và thời gian hiệu lực, cải thiện đáng kể so với approve.
-
Tuy nhiên, permit vẫn thường xuyên bị lợi dụng để lừa đảo: khi ký, người dùng chỉ biết được họ đang ủy quyền cho ai, bao nhiêu tài sản và trong bao lâu, nhưng không biết "ủy quyền này để làm gì". "Làm gì" sẽ là một chữ ký (hoặc giao dịch) riêng. DApp bình thường sẽ yêu cầu người dùng ký cả permit và "lệnh làm gì", nhưng chúng vẫn là hai chữ ký riêng biệt, do đó khi được yêu cầu ký permit, người dùng và ví không thể biết permit này sẽ được dùng để làm gì.
-
Với EIP-3074, người dùng (1) không cần approve trước một lượng lớn tài sản cho DApp, mà chỉ approve khi có thao tác — hiệu quả như permit; (2) chỉ cần ký đơn thuần, không cần lo tích ETH trả phí — giống như permit; (3) mỗi lần approve đều gắn liền với một thao tác cụ thể, được ký cùng lúc, người dùng rõ ràng biết lần approve này "để làm gì" — an toàn hơn hẳn so với permit!
-
Hy vọng EIP-3074 có thể thành công thay thế mô hình approve và permit hiện tại, mang lại phương thức ủy quyền an toàn hơn cho người dùng.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
@imTokenOfficial
