Tác động của EIP-3074 đối với ví và DApp

Trung cấp6/11/2024, 7:40:39 AM
Bài viết này giới thiệu tác động sáng tạo của EIP-3074 đối với EOA. Bằng cách cho phép EOA chuyển quyền kiểm soát sang hợp đồng Invoker, nó có được khả năng hoạt động đa chức năng giống như hợp đồng. Điều này không chỉ cải thiện đáng kể trải nghiệm người dùng mà còn định hình lại phương thức ủy quyền hiện có để làm cho nó an toàn hơn mà không thay đổi trải nghiệm người dùng.

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 (Tài khoản thuộc sở hữu bên ngoài) chuyển quyền kiểm soát sang một hợp đồng cụ thể, do đó có được khả năng thực hiện phong phú giống như hợp đồng. Trước EIP-3074, EOA chỉ có thể thực hiện một thao tác cho mỗi giao dịch, chẳng hạn như phê duyệt ERC20 hoặc hoán đổi trên Uniswap. Sau EIP-3074, EOA có thể thực hiện nhiều thao tác cùng một lúc hoặc thậm chí hoàn thành các nhiệm vụ không thể tưởng tượng trước đây. Nói một cách đơn giản, EIP-3074 giúp nâng cao đáng kể trải nghiệm người dùng và phương thức ủy quyền mã thông báo quen thuộc sẽ được định hình lại, tăng tính bảo mật mà không thay đổi trải nghiệm người dùng.

Hơn nữa, thông qua EIP-3074, EOA không người theo lệnh long cần tự gửi giao dịch đến chuỗi, loại bỏ rắc rối khi phải tăng ETH để trả phí giao dịch.

Hợp đồng gọi

Hợp đồng có thể có được quyền kiểm soá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ể giành quyền kiểm soát EOA: EOA phải ký bằng khóa riêng và nội dung của chữ ký sẽ chỉ rõ đó là hợp đồng Invoker nào và Invoker được phép thực hiện những thao tác nào.

Nội dung chữ ký EOA sẽ chỉ rõ hợp đồng Invoker nào (địa chỉ invoker) và ủy quyền cho các hoạt động của hợp đồng Invoker đó (commit)

Quá trình thực hiện thực tế có thể sẽ như thế này:

  1. Alice ký bằng khóa riêng EOA của mình và sau đó đưa nội dung chữ ký và chữ ký cho Relayer Relayer
  2. mang chuỗi đến thực hiện hợp đồng Invoker
  3. Invoker xác minh chữ ký. Sau khi vượt qua xác minh, nó có thể thực hiện các hoạt động như một EOA, chẳng hạn như phê duyệt USDC, sau đó chuyển đến Uniswap để sàn giao dịch và cuối cùng chuyển một số USDC sang Relayer dưới dạng phí xử lý.

Lưu ý 1: Relayer là không cần thiết. Alice cũng có thể mang nội dung và con dấu chữ ký của riêng mình vào chuỗi.

Sau khi Invoker xác minh chữ ký và bắt đầu thực hiện thao tác, nó sẽ được thực thi dưới dạng Alice EOA, giống như có được quyền kiểm soát (hạn chế) EOA.

Tuy nhiên, cần lưu ý rằng giá trị nonce của EOA sẽ không tăng lên sau khi thực thi, do đó cùng một chữ ký có thể được sử dụng lại (long như nonce EOA vẫn không thay đổi), vì vậy Invoker cần thực hiện cơ chế nonce của riêng mình để tránh phát lại.

Nếu hợp đồng Invoker không phải là Replay-proof, cùng một ủy quyền có thể được thực hiện mọi lúc.

Để giới thiệu về cơ chế hoạt động thực tế của EIP-3074, vui lòng tham khảo: Giới thiệu về EIP3074

Application

Batchcall

Cho phép người dùng hợp nhất việc thực hiện nhiều giao dịch thành một, tiết kiệm quá trình nhiều chữ ký được ủy quyền và một số chi phí Gas.

Lưu ý: Điều này sẽ yêu cầu dApp cũng hỗ trợ chức năng Batchcall, chẳng hạn như EIP-5792, hiện đang được cộng đồng thúc đẩy. Nếu không, dApp sẽ chỉ nhắc người dùng ký một lần cho mỗi thao tác nếu nó coi người dùng là EOA bình thường.

Khóa phiên

Người dùng cũng có thể cho phép bên thứ ba hành động thay mặt họ trong một số điều kiện nhất định. Khóa đại diện trong sơ đồ dưới đây là bên thứ ba được ủy quyền; chính sách truy cập là hạn chế thực thi, chẳng hạn như giới hạn nó chỉ hoạt động Uniswap, chuyển tối đa 1 ETH mỗi ngày, thời hạn hiệu lực ủy quyền, v.v. Các điều kiện này được thiết kế và kiểm tra trong hợp đồng Invoker. long khi kiểm tra được thông qua, bên thứ ba có thể thực hiện các hoạt động như EOA của người dùng.


Telegram Bot có thể được cấp quyền cụ thể để thực hiện các hoạt động thay mặt cho EOA của người dùng

Giấy phép ETH bản địa

long khi các điều kiện được đáp ứng (nghĩa là chữ ký Giấy phép là hợp pháp), việc chuyển nhượng ETH có thể được thực hiện với tư cách là người ủy quyền EOA, đạt được hiệu lực của Giấy phép ETH gốc.

Lệnh giới hạn

Người dùng điền vào giới hạn lệnh điều kiện và khi các điều kiện được đáp ứng, nó có thể được thực thi dưới dạng EOA của người dùng, bao gồm phê duyệt mã thông báo cho DEX, đi đến DEX để đổi, v.v. So với Lệnh giới hạn do chính DEX cung cấp, người dùng không cần gửi giao dịch đến DEX để phê duyệt trước.

Khi Alice hoàn thành lệnh, cô ấy sẽ thực hiện phê duyệt cùng một lúc, loại bỏ sự cần thiết phải phê duyệt trước.

Nếu điều kiện được thiết kế tổng quát hơn, nó sẽ trở nên giống như một hợp đồng Ý định: long khi các điều kiện do người dùng chỉ định được đáp ứng, bất kỳ ai cũng có thể thực hiện ý định dưới tên EOA của họ.

long khi điều kiện Ý định được đáp ứng, bất kỳ ai cũng có thể bắt đầu thực thi nhân danh EOA của người dùng

Phục hồi xã hội

Khi người dùng mất khóa riêng EOA, cô ấy (Alice) có thể sử dụng ủy quyền EIP-3074 mà cô ấy đã ký, cùng với chữ ký của người được ủy quyền của cô ấy (Chồng và Đại lý ủy thác) để chuyển tất cả tài sản của EOA. Trong thực tế, những gì được thu hồi là tài sản (có thể chuyển nhượng), không phải là sự kiểm soát tài khoản. Sau khi khóa riêng EOA bị mất, EOA không thể sử dụng người theo lệnh long được.

Khi người dùng mất khóa riêng EOA, những người được ủy quyền khác có thể ký và ủy quyền chuyển tài sản EOA.

Tác động của EIP-3074

Cải thiện phương thức ủy quyền mã thông báo và có khả năng thay thế phê duyệt / giấy phép?

Hiện tại, dApps được thiết kế theo giả định rằng người dùng là EOA: người dùng phải "phê duyệt trước" và "phê duyệt đủ số tiền" cho hợp đồng dApp. Điều này có nghĩa là người dùng không cần phải trực tuyến mọi lúc, chờ dApp thực thi hoặc liên tục phê duyệt lại, cải thiện đáng kể trải nghiệm người dùng. Đối với các ứng dụng được kích hoạt có điều kiện như lệnh giới hạn hoặc DCA, người dùng có thể không trực tuyến khi các điều kiện được đáp ứng, vì vậy họ cần phê duyệt trước một số tiền đủ lớn để hợp đồng dApp thực hiện và đó có thể là một quá trình lặp đi lặp lại.

Người dùng phải phê duyệt trước một số tiền đủ lớn cho dApp để dApp có thể hoạt động bằng tiền của mình.

Nhưng cũng cần phải tin tưởng dApp hoặc tránh phê duyệt dApp giả mạo và có thể xóa phê duyệt ngay lập tức

Các chế độ cho phép xuất hiện sau đó, chẳng hạn như mã thông báo gốc EIP-2612 hoặc Permit2 không phải là bản địa, tất cả đều để cải thiện trải nghiệm sử dụng và bảo mật của chế độ phê duyệt: người dùng không người theo lệnh long cần phê duyệt số tiền lớn cho mỗi hợp đồng dApp (và mỗi mã thông báo phải được phê duyệt một lần). Thay vào đó, người dùng chỉ cần "ký tên" để ủy quyền cho hợp đồng dApp "rút số tiền quy định" trong "thời gian quy định". Điều này không chỉ làm giảm đáng kể bề mặt tấn công mà còn nâng cao đáng kể trải nghiệm người dùng.

Người dùng chỉ cần đăng nhập off-chain và có thể chỉ định số lượng và thời hạn hiệu lực, cung cấp trải nghiệm người dùng và bảo mật tốt hơn so với phê duyệt.

Nhưng trên thực tế, không chỉ được chấp thuận, chế độ cấp phép đã được sử dụng như một phương thức tấn công lừa đảo thường xuyên (1,2,3): nạn nhân đã ký nhầm những gì họ nghĩ là giấy phép cho dApp nhưng thực tế đã được trao cho kẻ tấn công.

Khi người dùng ký giấy phép, họ chỉ có thể xem ai sẽ ủy quyền, nhưng họ không biết những thao tác nào sẽ được ghép nối với nó để thực hiện.

Lưu ý: Thiết kế giấy phép hiện tại không tương thích với các dApp hoạt động lặp đi lặp lại, chẳng hạn như DCA hoặc các ứng dụng thanh toán thông thường khác. Điều này là do giấy phép có cơ chế bảo vệ phát lại, vì vậy sau khi quá trình chuyển hoàn tất, cùng một giấy phép không thể được sử dụng lại, điều đó có nghĩa là người dùng phải ký giấy phép trước cho mỗi hoạt động lặp đi lặp lại trong tương lai.

Tuy nhiên, EIP-3074 mang đến cơ hội thay đổi: khi các nhà phát triển dApp biết rằng EOA có thể thực hiện các hoạt động phức tạp khác nhau thông qua Invoker, thiết kế tương tác dApp không lệnh người theo lệnh long cần phải hy sinh bảo mật để cải thiện trải nghiệm người dùng, chẳng hạn như "người dùng phê duyệt trước một số tiền lớn" và "người dùng ký thông báo giấy phép để ủy quyền rút tiền". Thay vào đó, người dùng buộc các hoạt động dApp để phê duyệt và thực hiện thực thi nguyên tử thông qua Invoker: phê duyệt và các hoạt động dApp được thực hiện thành công cùng nhau hoặc chúng thất bại cùng nhau. Không có khả năng thành công để phê duyệt một mình, vì vậy người dùng có thể tự tin rằng sự chấp thuận này là dành cho hoạt động này. Và người dùng đang sử dụng ủy quyền chữ ký off-chain, vì vậy trải nghiệm người dùng cũng giống như cho phép! Điều này có nghĩa là dApp sẽ không người theo lệnh long cần chế độ cấp phép! Trong tương lai, ví có thể trực tiếp cấm hoặc tiến hành xem xét nghiêm ngặt hơn các yêu cầu chữ ký giấy phép, mà không phải lo lắng về việc liệu nó có khiến người dùng không sử dụng một số dApp hay không (mà lần lượt được sử dụng để lừa đảo).

Người dùng không người theo lệnh long chỉ đơn giản là ủy quyền cho một địa chỉ nhất định, nhưng ủy quyền cho một địa chỉ nhất định và phải làm gì, và thậm chí xem kết quả thực thi mô phỏng.

Lưu ý: Điều này không có nghĩa là lừa đảo có thể bị chặn hoàn toàn! Người dùng vẫn có thể bị lừa vào các trang web lừa đảo và các trang web lừa đảo vẫn có thể tổ chức các hoạt động phê duyệt hoặc chuyển giao để người dùng ký, nhưng tại thời điểm này, người dùng ít nhất có thể thấy chữ ký này sẽ làm gì và ví thậm chí có thể mô phỏng kết quả thực hiện hiển thị và trình bày chúng cho người dùng, để người dùng có thể biết rõ ai sẽ mất bao nhiêu tiền và ai sẽ kiếm được bao nhiêu tiền. So với các giấy phép không biết kết quả thực hiện hoặc thậm chí hoạt động nào, người dùng có nhiều thông tin hơn để quyết định có ủy quyền hay không. Mặc dù nó không phải là một phương pháp chữa trị hoàn hảo, nhưng nó vẫn sẽ là một cải tiến đáng kể cho tình hình hiện tại.

Cách Ví tiền xử lý nonces EOA

Thiết kế EIP-3074 hiện tại sẽ bao gồm giá trị nonce EOA trong nội dung chữ ký, long khi EOA gửi giao dịch đến chuỗi để thực hiện và thay đổi giá trị nonce, tất cả các ủy quyền EIP-3074 ban đầu sẽ bị vô hiệu.

Nếu người dùng ủy quyền cho người khác vận hành EOA, chẳng hạn như Khóa phiên hoặc phương pháp Khôi phục xã hội được đề cập ở trên, nonce của EOA phải được ngăn không cho thay đổi. Mặt khác, cần phải ký lại tất cả các ủy quyền và đưa chúng cho người được ủy thác, điều này có tác động đáng kể đến trải nghiệm người dùng và tính mạnh mẽ của cơ chế.

Nếu người dùng được ủy quyền tự vận hành, không cần phải ngăn chặn cụ thể nonce EOA bị thay đổi, vì chữ ký EIP-3074 vẫn dự kiến sẽ được thực hiện trước một thời hạn nhất định như giao dịch. Chỉ là ví cần quản lý nhiều giao dịch EIP-3074 hơn của EOA: nếu có EIP-3074 chữ ký đang chờ được tải lên chuỗi, thì các giao dịch của chính EOA sẽ phải đợi.

Lưu ý: Bản thân hợp đồng Invoker sẽ (và nên) duy trì một tập hợp các cơ chế nonce, vì vậy sau khi chữ ký được sử dụng, nó vẫn cần được ký lại, bất kể nonce EOA có thay đổi hay không.

Khóa phiên và Phục hồi xã hội rất có thể sẽ phải đợi cho đến khi EIP-3074 thay đổi các quy tắc để loại bỏ nonce EOA khỏi nội dung chữ ký trước khi chúng có thể được áp dụng trên quy mô lớn. Do đó, ví chỉ cần tập trung vào trường hợp sử dụng "hoạt động do người dùng ủy quyền" và coi chữ ký EIP-3074 là một giao dịch. Không cần phải lo lắng về việc tránh gửi giao dịch EOA hoặc thay đổi nonce EOA.

Tuy nhiên, cần lưu ý rằng nếu người dùng muốn mang nội dung chữ ký EIP-3074 của riêng mình vào chuỗi, sẽ có hai nhược điểm:

  1. Người dùng cần ký hai lần: một lần cho chữ ký EIP-3074 và một lần cho chữ ký giao dịch on-chain
  2. .
  3. Vì giao dịch on-chain sẽ thêm 1 vào nonce EOA trước khi giao dịch bắt đầu thực hiện, nonce EOA trong chữ ký EIP-3074 của người dùng cần được thêm trước 1 để khớp với nonce EOA +1 do chính chuỗi gây ra.

Vì chuỗi sẽ thêm 1 vào nonce EOA trước, việc xác minh chữ ký EIP-3074 sẽ không thành công do nonce EOA không khớp.

Nếu người dùng thêm 1 vào nonce EOA trong chữ ký EIP-3074 trước khi tự đưa nó vào chuỗi, quá trình xác minh có thể tiến hành suôn sẻ.

Tóm tắt và Điểm nổi bật

  • EIP-3074 cho phép EOA có được khả năng thực thi phong phú giống như hợp đồng, mở ra nhiều kịch bản ứng dụng mới.
  • Điều này sẽ không chỉ cải thiện đáng kể trải nghiệm người dùng mà còn thay đổi phương thức ủy quyền mã thông báo hiện tại, giúp an toàn hơn trong khi vẫn duy trì cùng trải nghiệm người dùng.
  • Hơn nữa, EIP-3074 là một chữ ký đơn giản và người dùng không nhất thiết phải mang chữ ký lên chuỗi để thực thi, vì vậy không cần phải lo lắng về việc thu thập ETH để trả phí giao dịch.
  • Việc sử dụng EIP-3074 bao gồm Batch Call, Session Key, Native ETH Permit, Lệnh giới hạn và Social Recovery. Nhiều trong số này trước đây không thể đạt được đối với EOA và một số, giống như Lệnh giới hạn, yêu cầu các phương pháp ủy quyền trước không an toàn để được sử dụng.
  • EIP-3074 cũng sẽ thay đổi phương thức ủy quyền token hiện tại. Phương thức phê duyệt trực tiếp ủy quyền cho một địa chỉ cụ thể có quyền rút mã thông báo vô thời hạn và nó yêu cầu EOA của người dùng gửi giao dịch để thực hiện phê duyệt, vì vậy trải nghiệm người dùng và bảo mật không tốt; Phương thức cho phép chỉ yêu cầu người dùng ký và mỗi chữ ký sẽ chỉ định số tiền và thời hạn hiệu lực, giúp cải thiện đáng kể trải nghiệm người dùng và bảo mật so với phê duyệt.
  • Tuy nhiên, giấy phép vẫn thường xuyên được sử dụng trong các trò gian lận. Khi ký, người dùng chỉ biết ủy quyền cho ai, ủy quyền bao nhiêu và thời hạn hiệu lực, nhưng họ không biết ủy quyền này dùng để làm gì. "Nó dùng để làm gì" sẽ là một chữ ký (hoặc giao dịch) khác. Các dApp thông thường sẽ cho phép người dùng ký giấy phép và "nó dùng để làm gì", nhưng chúng vẫn sẽ là hai chữ ký khác nhau, vì vậy khi được yêu cầu ký giấy phép, cả người dùng và ví đều không thể biết giấy phép này sẽ được sử dụng để làm gì.
  • Với EIP-3074, người dùng (1) không cần phải phê duyệt trước một số tiền lớn cho dApp mà chỉ cần phê duyệt khi có hoạt động, có hiệu lực tương tự như giấy phép; (2) nó chỉ là một chữ ký đơn giản và không cần phải lo lắng về việc thu thập ETH để trả phí giao dịch, giống như giấy phép; (3) mỗi phê duyệt được gắn với một hoạt động cụ thể và được ký với nhau, vì vậy người dùng có thể biết rõ phê duyệt này dùng để làm gì, điều này sẽ an toàn hơn giấy phép!
  • Hy vọng rằng EIP-3074 có thể thay thế thành công các chế độ phê duyệt và cho phép hiện tại và cung cấp cho người dùng một phương thức ủy quyền an toàn hơn.

Tuyên bố từ chối trách nhiệm:

  1. Bài viết này được in lại từ [imToken Labs]. Tất cả bản quyền thuộc về tác giả gốc [Không có gì]. Nếu có ý kiến phản đối bản in lại này, vui lòng liên hệ với nhóm Gate Learn và họ sẽ xử lý kịp thời.
  2. Tuyên bố từ chối trách nhiệm: Các quan điểm và ý kiến được trình bày trong bài viết này chỉ là của tác giả và không cấu thành bất kỳ lời khuyên đầu tư nào.
  3. Bản dịch bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được đề cập, việc sao chép, phân phối hoặc đạo văn các bài báo đã dịch đều bị cấm.

EIP-3074

Giấy phép ETH bản địa

Tác động của EIP-3074

Tóm tắt và nổi bật

Tác động của EIP-3074 đối với ví và DApp

Trung cấp6/11/2024, 7:40:39 AM
Bài viết này giới thiệu tác động sáng tạo của EIP-3074 đối với EOA. Bằng cách cho phép EOA chuyển quyền kiểm soát sang hợp đồng Invoker, nó có được khả năng hoạt động đa chức năng giống như hợp đồng. Điều này không chỉ cải thiện đáng kể trải nghiệm người dùng mà còn định hình lại phương thức ủy quyền hiện có để làm cho nó an toàn hơn mà không thay đổi trải nghiệm người dùng.

EIP-3074

Giấy phép ETH bản địa

Tác động của EIP-3074

Tóm tắt và nổi bật

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 (Tài khoản thuộc sở hữu bên ngoài) chuyển quyền kiểm soát sang một hợp đồng cụ thể, do đó có được khả năng thực hiện phong phú giống như hợp đồng. Trước EIP-3074, EOA chỉ có thể thực hiện một thao tác cho mỗi giao dịch, chẳng hạn như phê duyệt ERC20 hoặc hoán đổi trên Uniswap. Sau EIP-3074, EOA có thể thực hiện nhiều thao tác cùng một lúc hoặc thậm chí hoàn thành các nhiệm vụ không thể tưởng tượng trước đây. Nói một cách đơn giản, EIP-3074 giúp nâng cao đáng kể trải nghiệm người dùng và phương thức ủy quyền mã thông báo quen thuộc sẽ được định hình lại, tăng tính bảo mật mà không thay đổi trải nghiệm người dùng.

Hơn nữa, thông qua EIP-3074, EOA không người theo lệnh long cần tự gửi giao dịch đến chuỗi, loại bỏ rắc rối khi phải tăng ETH để trả phí giao dịch.

Hợp đồng gọi

Hợp đồng có thể có được quyền kiểm soá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ể giành quyền kiểm soát EOA: EOA phải ký bằng khóa riêng và nội dung của chữ ký sẽ chỉ rõ đó là hợp đồng Invoker nào và Invoker được phép thực hiện những thao tác nào.

Nội dung chữ ký EOA sẽ chỉ rõ hợp đồng Invoker nào (địa chỉ invoker) và ủy quyền cho các hoạt động của hợp đồng Invoker đó (commit)

Quá trình thực hiện thực tế có thể sẽ như thế này:

  1. Alice ký bằng khóa riêng EOA của mình và sau đó đưa nội dung chữ ký và chữ ký cho Relayer Relayer
  2. mang chuỗi đến thực hiện hợp đồng Invoker
  3. Invoker xác minh chữ ký. Sau khi vượt qua xác minh, nó có thể thực hiện các hoạt động như một EOA, chẳng hạn như phê duyệt USDC, sau đó chuyển đến Uniswap để sàn giao dịch và cuối cùng chuyển một số USDC sang Relayer dưới dạng phí xử lý.

Lưu ý 1: Relayer là không cần thiết. Alice cũng có thể mang nội dung và con dấu chữ ký của riêng mình vào chuỗi.

Sau khi Invoker xác minh chữ ký và bắt đầu thực hiện thao tác, nó sẽ được thực thi dưới dạng Alice EOA, giống như có được quyền kiểm soát (hạn chế) EOA.

Tuy nhiên, cần lưu ý rằng giá trị nonce của EOA sẽ không tăng lên sau khi thực thi, do đó cùng một chữ ký có thể được sử dụng lại (long như nonce EOA vẫn không thay đổi), vì vậy Invoker cần thực hiện cơ chế nonce của riêng mình để tránh phát lại.

Nếu hợp đồng Invoker không phải là Replay-proof, cùng một ủy quyền có thể được thực hiện mọi lúc.

Để giới thiệu về cơ chế hoạt động thực tế của EIP-3074, vui lòng tham khảo: Giới thiệu về EIP3074

Application

Batchcall

Cho phép người dùng hợp nhất việc thực hiện nhiều giao dịch thành một, tiết kiệm quá trình nhiều chữ ký được ủy quyền và một số chi phí Gas.

Lưu ý: Điều này sẽ yêu cầu dApp cũng hỗ trợ chức năng Batchcall, chẳng hạn như EIP-5792, hiện đang được cộng đồng thúc đẩy. Nếu không, dApp sẽ chỉ nhắc người dùng ký một lần cho mỗi thao tác nếu nó coi người dùng là EOA bình thường.

Khóa phiên

Người dùng cũng có thể cho phép bên thứ ba hành động thay mặt họ trong một số điều kiện nhất định. Khóa đại diện trong sơ đồ dưới đây là bên thứ ba được ủy quyền; chính sách truy cập là hạn chế thực thi, chẳng hạn như giới hạn nó chỉ hoạt động Uniswap, chuyển tối đa 1 ETH mỗi ngày, thời hạn hiệu lực ủy quyền, v.v. Các điều kiện này được thiết kế và kiểm tra trong hợp đồng Invoker. long khi kiểm tra được thông qua, bên thứ ba có thể thực hiện các hoạt động như EOA của người dùng.


Telegram Bot có thể được cấp quyền cụ thể để thực hiện các hoạt động thay mặt cho EOA của người dùng

Giấy phép ETH bản địa

long khi các điều kiện được đáp ứng (nghĩa là chữ ký Giấy phép là hợp pháp), việc chuyển nhượng ETH có thể được thực hiện với tư cách là người ủy quyền EOA, đạt được hiệu lực của Giấy phép ETH gốc.

Lệnh giới hạn

Người dùng điền vào giới hạn lệnh điều kiện và khi các điều kiện được đáp ứng, nó có thể được thực thi dưới dạng EOA của người dùng, bao gồm phê duyệt mã thông báo cho DEX, đi đến DEX để đổi, v.v. So với Lệnh giới hạn do chính DEX cung cấp, người dùng không cần gửi giao dịch đến DEX để phê duyệt trước.

Khi Alice hoàn thành lệnh, cô ấy sẽ thực hiện phê duyệt cùng một lúc, loại bỏ sự cần thiết phải phê duyệt trước.

Nếu điều kiện được thiết kế tổng quát hơn, nó sẽ trở nên giống như một hợp đồng Ý định: long khi các điều kiện do người dùng chỉ định được đáp ứng, bất kỳ ai cũng có thể thực hiện ý định dưới tên EOA của họ.

long khi điều kiện Ý định được đáp ứng, bất kỳ ai cũng có thể bắt đầu thực thi nhân danh EOA của người dùng

Phục hồi xã hội

Khi người dùng mất khóa riêng EOA, cô ấy (Alice) có thể sử dụng ủy quyền EIP-3074 mà cô ấy đã ký, cùng với chữ ký của người được ủy quyền của cô ấy (Chồng và Đại lý ủy thác) để chuyển tất cả tài sản của EOA. Trong thực tế, những gì được thu hồi là tài sản (có thể chuyển nhượng), không phải là sự kiểm soát tài khoản. Sau khi khóa riêng EOA bị mất, EOA không thể sử dụng người theo lệnh long được.

Khi người dùng mất khóa riêng EOA, những người được ủy quyền khác có thể ký và ủy quyền chuyển tài sản EOA.

Tác động của EIP-3074

Cải thiện phương thức ủy quyền mã thông báo và có khả năng thay thế phê duyệt / giấy phép?

Hiện tại, dApps được thiết kế theo giả định rằng người dùng là EOA: người dùng phải "phê duyệt trước" và "phê duyệt đủ số tiền" cho hợp đồng dApp. Điều này có nghĩa là người dùng không cần phải trực tuyến mọi lúc, chờ dApp thực thi hoặc liên tục phê duyệt lại, cải thiện đáng kể trải nghiệm người dùng. Đối với các ứng dụng được kích hoạt có điều kiện như lệnh giới hạn hoặc DCA, người dùng có thể không trực tuyến khi các điều kiện được đáp ứng, vì vậy họ cần phê duyệt trước một số tiền đủ lớn để hợp đồng dApp thực hiện và đó có thể là một quá trình lặp đi lặp lại.

Người dùng phải phê duyệt trước một số tiền đủ lớn cho dApp để dApp có thể hoạt động bằng tiền của mình.

Nhưng cũng cần phải tin tưởng dApp hoặc tránh phê duyệt dApp giả mạo và có thể xóa phê duyệt ngay lập tức

Các chế độ cho phép xuất hiện sau đó, chẳng hạn như mã thông báo gốc EIP-2612 hoặc Permit2 không phải là bản địa, tất cả đều để cải thiện trải nghiệm sử dụng và bảo mật của chế độ phê duyệt: người dùng không người theo lệnh long cần phê duyệt số tiền lớn cho mỗi hợp đồng dApp (và mỗi mã thông báo phải được phê duyệt một lần). Thay vào đó, người dùng chỉ cần "ký tên" để ủy quyền cho hợp đồng dApp "rút số tiền quy định" trong "thời gian quy định". Điều này không chỉ làm giảm đáng kể bề mặt tấn công mà còn nâng cao đáng kể trải nghiệm người dùng.

Người dùng chỉ cần đăng nhập off-chain và có thể chỉ định số lượng và thời hạn hiệu lực, cung cấp trải nghiệm người dùng và bảo mật tốt hơn so với phê duyệt.

Nhưng trên thực tế, không chỉ được chấp thuận, chế độ cấp phép đã được sử dụng như một phương thức tấn công lừa đảo thường xuyên (1,2,3): nạn nhân đã ký nhầm những gì họ nghĩ là giấy phép cho dApp nhưng thực tế đã được trao cho kẻ tấn công.

Khi người dùng ký giấy phép, họ chỉ có thể xem ai sẽ ủy quyền, nhưng họ không biết những thao tác nào sẽ được ghép nối với nó để thực hiện.

Lưu ý: Thiết kế giấy phép hiện tại không tương thích với các dApp hoạt động lặp đi lặp lại, chẳng hạn như DCA hoặc các ứng dụng thanh toán thông thường khác. Điều này là do giấy phép có cơ chế bảo vệ phát lại, vì vậy sau khi quá trình chuyển hoàn tất, cùng một giấy phép không thể được sử dụng lại, điều đó có nghĩa là người dùng phải ký giấy phép trước cho mỗi hoạt động lặp đi lặp lại trong tương lai.

Tuy nhiên, EIP-3074 mang đến cơ hội thay đổi: khi các nhà phát triển dApp biết rằng EOA có thể thực hiện các hoạt động phức tạp khác nhau thông qua Invoker, thiết kế tương tác dApp không lệnh người theo lệnh long cần phải hy sinh bảo mật để cải thiện trải nghiệm người dùng, chẳng hạn như "người dùng phê duyệt trước một số tiền lớn" và "người dùng ký thông báo giấy phép để ủy quyền rút tiền". Thay vào đó, người dùng buộc các hoạt động dApp để phê duyệt và thực hiện thực thi nguyên tử thông qua Invoker: phê duyệt và các hoạt động dApp được thực hiện thành công cùng nhau hoặc chúng thất bại cùng nhau. Không có khả năng thành công để phê duyệt một mình, vì vậy người dùng có thể tự tin rằng sự chấp thuận này là dành cho hoạt động này. Và người dùng đang sử dụng ủy quyền chữ ký off-chain, vì vậy trải nghiệm người dùng cũng giống như cho phép! Điều này có nghĩa là dApp sẽ không người theo lệnh long cần chế độ cấp phép! Trong tương lai, ví có thể trực tiếp cấm hoặc tiến hành xem xét nghiêm ngặt hơn các yêu cầu chữ ký giấy phép, mà không phải lo lắng về việc liệu nó có khiến người dùng không sử dụng một số dApp hay không (mà lần lượt được sử dụng để lừa đảo).

Người dùng không người theo lệnh long chỉ đơn giản là ủy quyền cho một địa chỉ nhất định, nhưng ủy quyền cho một địa chỉ nhất định và phải làm gì, và thậm chí xem kết quả thực thi mô phỏng.

Lưu ý: Điều này không có nghĩa là lừa đảo có thể bị chặn hoàn toàn! Người dùng vẫn có thể bị lừa vào các trang web lừa đảo và các trang web lừa đảo vẫn có thể tổ chức các hoạt động phê duyệt hoặc chuyển giao để người dùng ký, nhưng tại thời điểm này, người dùng ít nhất có thể thấy chữ ký này sẽ làm gì và ví thậm chí có thể mô phỏng kết quả thực hiện hiển thị và trình bày chúng cho người dùng, để người dùng có thể biết rõ ai sẽ mất bao nhiêu tiền và ai sẽ kiếm được bao nhiêu tiền. So với các giấy phép không biết kết quả thực hiện hoặc thậm chí hoạt động nào, người dùng có nhiều thông tin hơn để quyết định có ủy quyền hay không. Mặc dù nó không phải là một phương pháp chữa trị hoàn hảo, nhưng nó vẫn sẽ là một cải tiến đáng kể cho tình hình hiện tại.

Cách Ví tiền xử lý nonces EOA

Thiết kế EIP-3074 hiện tại sẽ bao gồm giá trị nonce EOA trong nội dung chữ ký, long khi EOA gửi giao dịch đến chuỗi để thực hiện và thay đổi giá trị nonce, tất cả các ủy quyền EIP-3074 ban đầu sẽ bị vô hiệu.

Nếu người dùng ủy quyền cho người khác vận hành EOA, chẳng hạn như Khóa phiên hoặc phương pháp Khôi phục xã hội được đề cập ở trên, nonce của EOA phải được ngăn không cho thay đổi. Mặt khác, cần phải ký lại tất cả các ủy quyền và đưa chúng cho người được ủy thác, điều này có tác động đáng kể đến trải nghiệm người dùng và tính mạnh mẽ của cơ chế.

Nếu người dùng được ủy quyền tự vận hành, không cần phải ngăn chặn cụ thể nonce EOA bị thay đổi, vì chữ ký EIP-3074 vẫn dự kiến sẽ được thực hiện trước một thời hạn nhất định như giao dịch. Chỉ là ví cần quản lý nhiều giao dịch EIP-3074 hơn của EOA: nếu có EIP-3074 chữ ký đang chờ được tải lên chuỗi, thì các giao dịch của chính EOA sẽ phải đợi.

Lưu ý: Bản thân hợp đồng Invoker sẽ (và nên) duy trì một tập hợp các cơ chế nonce, vì vậy sau khi chữ ký được sử dụng, nó vẫn cần được ký lại, bất kể nonce EOA có thay đổi hay không.

Khóa phiên và Phục hồi xã hội rất có thể sẽ phải đợi cho đến khi EIP-3074 thay đổi các quy tắc để loại bỏ nonce EOA khỏi nội dung chữ ký trước khi chúng có thể được áp dụng trên quy mô lớn. Do đó, ví chỉ cần tập trung vào trường hợp sử dụng "hoạt động do người dùng ủy quyền" và coi chữ ký EIP-3074 là một giao dịch. Không cần phải lo lắng về việc tránh gửi giao dịch EOA hoặc thay đổi nonce EOA.

Tuy nhiên, cần lưu ý rằng nếu người dùng muốn mang nội dung chữ ký EIP-3074 của riêng mình vào chuỗi, sẽ có hai nhược điểm:

  1. Người dùng cần ký hai lần: một lần cho chữ ký EIP-3074 và một lần cho chữ ký giao dịch on-chain
  2. .
  3. Vì giao dịch on-chain sẽ thêm 1 vào nonce EOA trước khi giao dịch bắt đầu thực hiện, nonce EOA trong chữ ký EIP-3074 của người dùng cần được thêm trước 1 để khớp với nonce EOA +1 do chính chuỗi gây ra.

Vì chuỗi sẽ thêm 1 vào nonce EOA trước, việc xác minh chữ ký EIP-3074 sẽ không thành công do nonce EOA không khớp.

Nếu người dùng thêm 1 vào nonce EOA trong chữ ký EIP-3074 trước khi tự đưa nó vào chuỗi, quá trình xác minh có thể tiến hành suôn sẻ.

Tóm tắt và Điểm nổi bật

  • EIP-3074 cho phép EOA có được khả năng thực thi phong phú giống như hợp đồng, mở ra nhiều kịch bản ứng dụng mới.
  • Điều này sẽ không chỉ cải thiện đáng kể trải nghiệm người dùng mà còn thay đổi phương thức ủy quyền mã thông báo hiện tại, giúp an toàn hơn trong khi vẫn duy trì cùng trải nghiệm người dùng.
  • Hơn nữa, EIP-3074 là một chữ ký đơn giản và người dùng không nhất thiết phải mang chữ ký lên chuỗi để thực thi, vì vậy không cần phải lo lắng về việc thu thập ETH để trả phí giao dịch.
  • Việc sử dụng EIP-3074 bao gồm Batch Call, Session Key, Native ETH Permit, Lệnh giới hạn và Social Recovery. Nhiều trong số này trước đây không thể đạt được đối với EOA và một số, giống như Lệnh giới hạn, yêu cầu các phương pháp ủy quyền trước không an toàn để được sử dụng.
  • EIP-3074 cũng sẽ thay đổi phương thức ủy quyền token hiện tại. Phương thức phê duyệt trực tiếp ủy quyền cho một địa chỉ cụ thể có quyền rút mã thông báo vô thời hạn và nó yêu cầu EOA của người dùng gửi giao dịch để thực hiện phê duyệt, vì vậy trải nghiệm người dùng và bảo mật không tốt; Phương thức cho phép chỉ yêu cầu người dùng ký và mỗi chữ ký sẽ chỉ định số tiền và thời hạn hiệu lực, giúp cải thiện đáng kể trải nghiệm người dùng và bảo mật so với phê duyệt.
  • Tuy nhiên, giấy phép vẫn thường xuyên được sử dụng trong các trò gian lận. Khi ký, người dùng chỉ biết ủy quyền cho ai, ủy quyền bao nhiêu và thời hạn hiệu lực, nhưng họ không biết ủy quyền này dùng để làm gì. "Nó dùng để làm gì" sẽ là một chữ ký (hoặc giao dịch) khác. Các dApp thông thường sẽ cho phép người dùng ký giấy phép và "nó dùng để làm gì", nhưng chúng vẫn sẽ là hai chữ ký khác nhau, vì vậy khi được yêu cầu ký giấy phép, cả người dùng và ví đều không thể biết giấy phép này sẽ được sử dụng để làm gì.
  • Với EIP-3074, người dùng (1) không cần phải phê duyệt trước một số tiền lớn cho dApp mà chỉ cần phê duyệt khi có hoạt động, có hiệu lực tương tự như giấy phép; (2) nó chỉ là một chữ ký đơn giản và không cần phải lo lắng về việc thu thập ETH để trả phí giao dịch, giống như giấy phép; (3) mỗi phê duyệt được gắn với một hoạt động cụ thể và được ký với nhau, vì vậy người dùng có thể biết rõ phê duyệt này dùng để làm gì, điều này sẽ an toàn hơn giấy phép!
  • Hy vọng rằng EIP-3074 có thể thay thế thành công các chế độ phê duyệt và cho phép hiện tại và cung cấp cho người dùng một phương thức ủy quyền an toàn hơn.

Tuyên bố từ chối trách nhiệm:

  1. Bài viết này được in lại từ [imToken Labs]. Tất cả bản quyền thuộc về tác giả gốc [Không có gì]. Nếu có ý kiến phản đối bản in lại này, vui lòng liên hệ với nhóm Gate Learn và họ sẽ xử lý kịp thời.
  2. Tuyên bố từ chối trách nhiệm: Các quan điểm và ý kiến được trình bày trong bài viết này chỉ là của tác giả và không cấu thành bất kỳ lời khuyên đầu tư nào.
  3. Bản dịch bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được đề cập, việc sao chép, phân phối hoặc đạo văn các bài báo đã dịch đều bị cấm.
Bắt đầu giao dịch
Đăng ký và giao dịch để nhận phần thưởng USDTEST trị giá
$100
$5500