Trừu tượng hóa tài khoản so với trừu tượng hóa tài khoản gốc

Nói một cách đơn giản, Trừu tượng hóa tài khoản trong ERC-4337 là cơ sở hạ tầng tùy chọn trên blockchain. Bạn có thể chọn có chấp nhận nó hay không. Sau khi được thông qua, nó cung cấp các chức năng tương tự như Tài khoản hợp đồng (CA), chẳng hạn như multisig, thanh toán phí gas bằng mã thông báo ERC-20, phục hồi xã hội, v.v. Nhiều nhà cung cấp dịch vụ, như stackup, đang làm việc trên cơ sở hạ tầng này. Tuy nhiên, cơ sở hạ tầng này chưa được áp dụng rộng rãi vì những lý do sau:

• Vấn đề về Bundler: Chỉ có các Bundler mới tham gia xác minh, dẫn đến sự phụ thuộc quá mức vào các Bundler.
• Lợi nhuận không đủ cho các nhà đóng gói: Điều này chủ yếu là do quy mô nhỏ, đòi hỏi nhiều DApp hơn để chọn cơ sở hạ tầng Trừu tượng tài khoản nhằm tiết kiệm phí gas.
• Sự tập trung của các nhà đóng gói: Các nhà đóng gói tập trung ở một số nhà cung cấp (Alchemy, Pimlico, Stackup), gây ra rủi ro tập trung hóa.
• Tỷ lệ giữ chân: Ngoài airdrop, tỷ lệ giữ chân người dùng đối với các dịch vụ Trừu tượng tài khoản là rất thấp.

Nhiều giải pháp Lớp 2 triển khai Trừu tượng tài khoản trực tiếp trên chuỗi gốc để giảm phí gas. Điều này được gọi là Trừu tượng tài khoản gốc. Tuy nhiên, cách tiếp cận này cũng có các vấn đề khác, chẳng hạn như người dùng không muốn tính năng này không thể từ chối, khả năng chuỗi chéo hạn chế và thiếu tính linh hoạt tổng thể.

Bài viết này đề cập đến một số thuật ngữ, chẳng hạn như sự phân biệt giữa EOA và CA (nói một cách đơn giản, Metamask là EOA, hợp đồng là CA), cũng như các bộ đóng gói (trong hệ sinh thái Trừu tượng tài khoản, người dùng gửi UserOperations đến các bộ đóng gói để đóng gói và trên- xử lý chuỗi, thay vì gửi chúng đến trình xác thực nút/Mempool). Để xem giải thích chi tiết, bạn có thể click vào link 2 bài viết nêu trên và tham khảo các bài viết đã đăng trước đó trên Gate Learn.

RIP-7560 là gì?

RIP-7560 là một đề xuất cải tiến cho việc trừu tượng hóa tài khoản (EIP-2938/ERC-4337). Giới thiệu loại giao dịch mới “AA_TX_TYPE” kết hợp các vai trò khác ngoài người bán gói (người xây dựng khối/người xác thực nút) trong giai đoạn thực hiện và xác minh giao dịch. Nó không còn chỉ dựa vào người bán gói để đóng gói và gửi trên chuỗi, do đó giải quyết được các vấn đề tập trung đã đề cập trước đó. Ngoài ra, RIP-7560 còn cung cấp thiết kế tiêu chuẩn hóa để đảm bảo sự phù hợp cao hơn cho những người áp dụng trong tương lai. Bài viết này sẽ trình bày chi tiết hơn về các tiêu chuẩn được cải thiện nhờ đề xuất RIP-7560 và giải quyết các mối lo ngại được nêu ra.

Sự thay đổi cơ bản nhất

Đây là sự thay đổi giao thức lớp đồng thuận \
Đề xuất sớm nhất về việc trừu tượng hóa tài khoản thực tế đã được đưa ra vào tháng 9 năm 2020 EIP-2938. Cuối cùng nó đã được cộng đồng chấp nhận và triển khai trên Ethereum. Lý do tại sao ERC-4337 cuối cùng được thông qua thay vì 2938 là vì 4337 không yêu cầu thay đổi ở lớp đồng thuận, khiến cộng đồng tương đối dễ dàng chấp nhận hơn.

Không giống như ERC-4337, đề xuất RIP-7560 sẽ liên quan đến những thay đổi lớn hơn, cụ thể là ở cấp độ giao thức lớp đồng thuận (tiền tố RIP chỉ ra rằng đây là đề xuất cấp độ thấp hơn để cải thiện công nghệ Rollup). Lợi ích tương ứng mà nó mang lại là khả năng tránh phụ thuộc trực tiếp vào cơ sở hạ tầng của chuỗi gốc L2.

Giới thiệu loại giao dịch mới \
Một loại giao dịch mới đã được giới thiệu: loại giao dịch thứ tư, còn được gọi là “AA_TX_TYPE” (thực tế đã được đề xuất trong EIP-2938 cũ). Nó không chỉ hỗ trợ tất cả các chức năng của một CA thông thường (chẳng hạn như thanh toán phí gas và các chức năng thanh toán tự động định kỳ được đề cập trong bài viết của Visa), mà không giống như ERC-4337, nó còn cho phép các EOA hiện tại gửi giao dịch. Điều này có nghĩa là đề xuất này nhằm mục đích thúc đẩy việc áp dụng rộng rãi hơn.

Logic thực hiện giao dịch

Đề xuất này tương thích với tiêu chuẩn ERC-4337 và áp dụng logic giao dịch tách biệt thực thi và xác minh, yêu cầu nhiều Gas hơn. Ngoài ra, theo tài liệu, việc thực hiện giao dịch cũng giống như ERC-4337, trong đó tất cả các bước trong giai đoạn xác minh phải được hoàn thành mà không được hoàn nguyên. Sau khi xác minh, dữ liệu cuộc gọi sẽ được gửi đến tài khoản để thực hiện. Sau khi thực hiện, Paymaster có thể thực hiện logic sau giao dịch. Quá trình thực hiện hoàn chỉnh được minh họa trong sơ đồ sau.

Sơ đồ thực thi (Nguồn: Tài liệu GitHub của RIP-7560)

Mối quan tâm chính về đề xuất

Tác giả nêu ra những lo ngại sau trong cuộc thảo luận trên diễn đàn Ethereum Magicians: RIP-7560: Tóm tắt tài khoản gốc

Nó có hạn chế sự phát triển của các dịch vụ trừu tượng hóa tài khoản dựa trên mục đích không?

Những người tham gia chính trong các dịch vụ dựa trên mục đích dự kiến sẽ là Uniswap V4 và UniswapX, trong đó UniswapX có kế hoạch phát triển các dịch vụ trừu tượng hóa tài khoản. Ngoài ra, một hướng tương tự đã được ERC-7521 đề xuất. Đáp lại các cuộc thảo luận của cộng đồng, một trong những tác giả của đề xuất này, Yoav Weiss, đã đề cập rằng cùng với RIP-7560, còn có một quy tắc xác minh trừu tượng hóa tài khoản được gọi là ERC-7562. Thiết kế hệ thống ý định chỉ có thể tương thích với RIP-7560 chứ không tương thích với quy tắc xác minh. Sau đó, một mạng giải quyết ý định riêng biệt có thể được sử dụng, cho phép tận hưởng các lợi ích của RIP-7560 mà không xung đột với thiết kế ý định.

Rủi ro không thể đảo ngược

Một số người trong cộng đồng đã đặt câu hỏi liệu đề xuất này có giống với việc “cố gắng nhúng hệ điều hành vào kim loại trần” hay không, có gây ra rủi ro đáng kể hay không. Về vấn đề này, Yoav Weiss đã trả lời: Đề xuất này dành cho các chuỗi chọn nhúng hệ điều hành (chẳng hạn như ERC-4337) vào kim loại trần, cụ thể là chuỗi L2 chọn triển khai tính năng trừu tượng hóa tài khoản gốc. Có đủ sự lựa chọn trong hệ sinh thái Ethereum và người dùng có thể chọn các chuỗi L2 khác chưa triển khai tính năng trừu tượng hóa tài khoản gốc.

Sự phức tạp và cân nhắc chi phí

Về những lo ngại về sự phức tạp và dẫn đến chi phí cao của đề xuất, Dror Tirosh, một trong những tác giả, đã trả lời rằng đây là bản chất cố hữu của việc trừu tượng hóa tài khoản. Việc trừu tượng hóa tài khoản xuất phát từ thực tế là chúng tôi muốn xác thực dữ liệu bên ngoài bằng mã EVM chung. Việc loại bỏ sự phức tạp này sẽ khiến các nhà sản xuất khối gặp phải các cuộc tấn công DoS hoặc yêu cầu loại bỏ việc sử dụng mã EVM chung, điều này làm mất đi mục đích phát triển công nghệ trừu tượng hóa tài khoản.

Phần kết luận

Hiện tại, ít nhất các nhà cung cấp cơ sở hạ tầng trừu tượng hóa tài khoản, chẳng hạn như người sáng lập Stackup, hoan nghênh những thay đổi như vậy ở lớp đồng thuận, cho thấy rằng các vấn đề cốt lõi của dịch vụ trừu tượng hóa tài khoản hiện tại vẫn còn phổ biến. Nếu không có đủ dApp áp dụng giải pháp này để giảm Phí Gas và giới thiệu các tính năng giống CA thân thiện với người dùng thì các nhà cung cấp gói sẽ không thu được lợi nhuận và tỷ lệ giữ chân người dùng sẽ không bao giờ tăng. Tuy nhiên, nếu các dịch vụ được phát triển dựa trên đề xuất này có thể hỗ trợ liền mạch các EOA hiện có trên chuỗi để hỗ trợ việc trừu tượng hóa tài khoản một cách nguyên bản, thì chúng tôi sẽ tiến gần hơn đến mục tiêu cuối cùng (áp dụng hàng loạt, trừu tượng hóa tài khoản hỗ trợ Metamask, v.v.) và trải nghiệm người dùng khi tương tác với DApps sẽ được cải thiện dần dần.