Kể từ năm 2022, trừu tượng tài khoản đã trở thành một chủ đề được thảo luận rộng rãi, và khung cơ bản trong lĩnh vực trừu tượng tài khoản tập trung vào EIP-4337 dường như đã trở thành một sự thống nhất trong ngành công nghiệp. Sự phổ biến của khái niệm ý định đã làm nổi bật tầm quan trọng của các thành phần tương tác người dùng ngưỡng thấp này.

Tuy nhiên, EIP-4337 vẫn còn những điểm đau như sự phân mảnh tài khoản thông minh và trải nghiệm người dùng rất phân mảnh của trừơng trình trừơng tài khoản xuyên chuỗi. Bài viết này khám phá cách thúc đẩy phát triển lĩnh vực trừơng tài khoản dưới gần cứng EIP-4337, lấy các dự án như Biconomy, Safe Core và Particle Network làm ví dụ.

Hiểu khái niệm về trừu tượng hóa dòng giao dịch từ góc nhìn của trừu tượng hóa dòng giao dịch

Về trừu tượng hóa tài khoản, Vitalik đã chỉ ra nhiều lần rằng đó là điều kiện cần thiết để hạ thấp ngưỡng của người dùng Ethereum và đạt được sự chấp nhận hàng loạt. Tầm nhìn cốt lõi của nó là cho phép người dùng tùy chỉnh phương thức xác minh chữ ký và tận hưởng thanh toán gas, đồng thời có thể bắt đầu giao dịch trên chuỗi mà không cần bất kỳ tài sản nào (thường được gọi là giao dịch không gas). Chỉ bằng cách nhận ra những điều kiện tiên quyết này, các ứng dụng Web3 mới có thể cải thiện tỷ lệ chuyển đổi người dùng của họ. Mặc dù các đề xuất trừu tượng không phải tài khoản trước đây hoặc ví hợp đồng thông minh có thể đạt được trải nghiệm tương tự, nhưng chúng không đủ linh hoạt và hiệu quả. Ví dụ: Gnosis Safe vẫn yêu cầu địa chỉ EOA để kích hoạt các giao dịch và chi phí gas mà nó liên quan là cực kỳ cao. Việc trừu tượng hóa tài khoản nhằm mục đích tối ưu hóa cấu trúc cơ bản của các tài khoản hợp đồng thông minh, mở đường cho thế hệ tiếp theo của hệ thống tài khoản thông minh. Nhưng nếu chúng ta nhìn vào các đề xuất trừu tượng hóa tài khoản thực tế, chúng ta sẽ thấy rằng trọng tâm của chúng không phải là chính mô hình tài khoản. Ví dụ: các đề xuất liên quan đến trừu tượng hóa tài khoản như EIP-86, EIP-4337 và EIP-6900 tập trung vào việc trừu tượng hóa / mô-đun hóa toàn bộ quá trình xử lý giao dịch từ khi bắt đầu đến khi được nhận bởi các nút, cũng như xác minh chữ ký, thanh toán gas, v.v., thay vì tập trung vào sự trừu tượng hóa của cấu trúc tài khoản. Một sự trừu tượng của cấu trúc tài khoản. Do đó, có vẻ thích hợp hơn khi gọi các đề xuất hiện tại khác nhau là "trừu tượng hóa luồng giao dịch". Nếu chúng ta hiểu những đề xuất trừu tượng hóa tài khoản nổi tiếng đó từ góc độ trừu tượng hóa luồng giao dịch, chúng ta có thể dễ dàng nắm bắt những điểm chính của chúng: loại trừu tượng hóa giao dịch này thực sự nhằm mục đích mang lại trải nghiệm người dùng về việc nhập và sử dụng sản phẩm cấp Web2 vào hệ thống Ethereum. Điều này có thể ở dạng danh sách đen / danh sách trắng, bắt đầu giao dịch mà không cần xác minh danh tính trong một khoảng thời gian nhất định, giao dịch không có gas, thanh toán tiền tệ fiat, v.v.

(Nguồn hình ảnh: Zengo)

Tuy nhiên, một số người có thể hỏi: Liệu những điều này có thể đạt được với các ví hợp đồng thông minh hiện có trong quá khứ không? Giá trị của các giải pháp trừu tượng tài khoản như EIP-4337 nằm ở đâu?

Bản chất của EIP-4337: Giải pháp tối ưu cục bộ cho Việc Trừu Tượng Tài Khoản trong Hệ Sinh Thái Ethereum

Như câu hỏi ở trên đã chỉ ra, trong khi những ví điện tử thông minh trước đó thực sự có thể đạt được các chức năng đã đề cập, nhưng phương pháp triển khai thường là nguyên thủy và thường phụ thuộc vào cơ sở hạ tầng của bên thứ ba tập trung cao. Ví dụ, trong quá khứ, giải pháp truyền khí gas yêu cầu sự giới thiệu của các nút truyền gas của bên thứ ba (EIP-2771). Ngoài ra, đã thiếu các tiêu chuẩn thống nhất giữa các ví thông minh khác nhau, điều này đã làm trở ngại cho việc phát triển và triển khai các thành phần bổ sung. Nhu cầu cốt lõi của các EIP liên quan đến trừu tượng tài khoản khác nhau là giải quyết những thiếu sót này hiện diện trong các dự án ví khác nhau bằng cách giới thiệu một khung chuẩn được thiết kế đặc biệt cho các ví hợp đồng thông minh. Sự tiến bộ này nhằm mục đích chuyển cấu trúc tài khoản trong hệ sinh thái Ethereum từ một cấu trúc chức năng cơ bản sang một cấu trúc thông minh phức tạp hơn với khả năng cao hơn.

(Nguồn ảnh: Springer Link)

Điều này tương tự như tình hình trước khi ERC-20 hoặc ERC-721, nơi các phương pháp triển khai, chức năng và các chức năng/giao diện cung cấp của nhiều token không nhất quán. Những không nhất quán này đã làm chậm sự phát triển của cơ sở hạ tầng bên thứ ba bổ sung và kiểm định mã (rất khó để tưởng tượng làm thế nào các ứng dụng DeFi có thể phát triển đến mức độ hiện tại mà không có giao thức ERC-20).

Các tiêu chuẩn triển khai cho các giao thức/tính năng tiêu chuẩn là tiền đề cho thiết kế theo mô-đun, và việc phát triển theo mô-đun gần như là một tiền đề cho bất kỳ lĩnh vực nào nhắm đến sự phát triển sôi động (chia sẻ lao động là nguyên tắc đầu tiên để cải thiện hiệu suất).

Cuối cùng, EIP-4337 nổi bật.

EIP-4337 là một giải pháp cục bộ tối ưu, nhưng một số quan điểm trong khung việc này cần được tối ưu hóa

EIP-4337 xác định một bộ tiêu chuẩn giao diện hoàn chỉnh, làm rõ các mô-đun được mong đợi trong ví thông minh tuân thủ giao thức 4337 và các chức năng / giao diện mà mỗi mô-đun nên triển khai. Ví dụ: các thành phần như bundler, entry và paymaster nên cung cấp những hàm có thể gọi nào bên ngoài. Với các hướng dẫn này, sự tương tác giữa các thành phần khác nhau trở nên rõ ràng hơn, tạo điều kiện tích hợp các ý tưởng thiết kế mô-đun vào thiết kế trừu tượng tài khoản và ví thông minh. Các nhà phát triển làm việc trên các mô-đun ví cũng được hưởng lợi đáng kể. Tuy nhiên, nhìn hoàn toàn từ quan điểm của người dùng, giá trị do mô hình phát triển ví thông minh mô-đun mang lại có thể không rõ ràng ngay lập tức vì những thay đổi trong ví trừu tượng hóa tài khoản có thể không sờ thấy được trong ngắn hạn. Tuy nhiên, nhìn vào trung và dài hạn, giá trị của các giao thức như EIP-4337 giống với ERC-20 và ERC-721. Nó đặt nền tảng cho sự phát triển lâu dài của ví trừu tượng tài khoản, đánh dấu một cột mốc quan trọng. Tuy nhiên, EIP-4337 vẫn còn nhiều vấn đề chưa được giải quyết, chẳng hạn như:

1. Trừu tượng hóa tài khoản không đủ dễ tích hợp, dẫn đến các nhà phát triển khác nhau vô tình “phát minh lại bánh xe”.

2. Tương thích kém giữa các module tài khoản, dẫn đến một hệ sinh thái bị phân mảnh.

3. Sự phân mảnh cao của các hệ sinh thái trừu tượng tài khoản trên các chuỗi khác nhau, khiến việc cung cấp trải nghiệm thống nhất và chất lượng cao cho người dùng cuối và nhà phát triển trở nên thách thức.

Dưới đây, chúng tôi sẽ đi sâu vào các giải pháp cho những vấn đề này.

Giải pháp tối ưu hóa 1: Plugin Trừu tượng Hóa Tài khoản Sẽ Trở Thành Cấu hình Cơ bản

Một trong những điểm trọng tâm cốt lõi trong các cuộc thảo luận hiện tại về trừu tượng hóa tài khoản là tăng cường mô-đun hóa của các ví trừu tượng hóa tài khoản và tinh chỉnh cụ thể từng mô-đun hơn. Ví dụ, Biconomy, dựa trên EIP-4337 (EIP-6900 tinh chỉnh hơn sẽ được giới thiệu trong tương lai), đề xuất trừu tượng hóa tài khoản cắm và chạy để thúc đẩy phát triển mô-đun của hệ sinh thái trừu tượng hóa tài khoản.

(Nguồn hình ảnh: Biconomy)

Công cụ trừu tượng tài khoản được gọi là thực chất là để thiết lập một giao thức xác định rõ các mô-đun chính liên quan đến một ví hợp đồng thông minh, đề cập đến các giao diện/chức năng mà các mô-đun này nên triển khai, và xác định tên và phương pháp gọi của các giao diện này. Các nhà phát triển bên thứ ba sau đó sẽ tạo ra các thành phần với các chi tiết khác nhau dựa trên ý tưởng của họ, đảm bảo rằng các thành phần này tuân thủ theo yêu cầu được quy định trong giao thức.

Với v2 của Biconomy, dựa trên EIP-4337 như là khung giao thức, đã đưa ra các tiêu chuẩn chi tiết hơn và giới thiệu một bộ giao diện không được đề cập trong EIP-4337. Trong khi khai báo các chức năng mà người gói, ví hợp đồng thông minh, paymaster và các mô-đun khác nên có, Biconomy cho phép các nhà phát triển bên thứ ba triển khai các mô-đun với các tính năng tương tự nhưng phiên bản khác nhau sử dụng các chi tiết mã khác nhau, miễn là họ tuân thủ theo hướng dẫn giao thức do Biconomy thiết lập (tương thích với EIP-4337).

(Các tiêu chuẩn giao diện được đề xuất bởi Biconomy chỉ ra các chức năng mà các nhà phát triển mô-đun bên thứ ba nên triển khai trong các mô-đun của họ cho các cuộc gọi bên ngoài). Ngoài ra, Biconomy giới thiệu khẩu hiệu “Module Store.” tích cực khuyến khích việc ra mắt một SDK mô-đun trừu tượng tài khoản trong khi khuyến khích các nhà phát triển gửi các mô-đun trừu tượng tài khoản được thiết kế bởi họ. Sáng kiến này nhằm mục đích thúc đẩy “mô-đun dưới dạng dịch vụ,” cho phép tất cả các dự án ví tuân thủ giao thức EIP-4337 áp dụng trực tiếp các mô-đun trừu tượng tài khoản được phát triển bên ngoài này. Người dùng hiện đã có nhiều lựa chọn đa dạng hơn về việc sử dụng các mô-đun khi tạo tài khoản thông minh qua giao diện người dùng.

Sự linh hoạt không chỉ giúp phân chia công việc mà còn giúp người dùng chuyển đổi hoặc thêm/xóa một số chức năng cụ thể trong ví thông minh một cách nhanh chóng. Nó cho phép tinh chỉnh độ tinh mịch của các thành phần. Biconomy chỉ ra rằng mức độ linh hoạt cao hơn trong một ví hợp đồng thông minh, thì càng ít thay đổi cần phải thực hiện khi cập nhật hoặc nâng cấp nó. Không cần phải cập nhật hợp đồng Ví Hợp Đồng Thông Minh hiện tại của người dùng hoặc sử dụng DelegateCall, chỉ cần cập nhật một số mô-đun bên ngoài, giúp việc thay thế các thành phần cụ thể trở nên thuận tiện cho các người dùng hoặc nhà phát triển khác nhau.

Trong kế hoạch trừu tượng hóa tài khoản cập nhật sắp tới của Biconomy, họ cũng sẽ xem xét EIP-6900, điều này tạo điều kiện thuận lợi hơn cho việc phân chia mô-đun so với EIP-4337.

Giải pháp tối ưu hóa 2: Phân đoạn mô-đun cụ thể hơn để giải quyết vấn đề phân mảnh tài khoản

Về EIP-6900, Safe (trước đây là Gnosis Safe) đã phát hành một bản tóm tắt giao thức Safe Core Protocol vào tháng 8 năm nay, nơi mà rút nhiều ý tưởng từ EIP-6900.

(Sơ đồ EIP-6900) EIP-6900 nêu bật một vấn đề phổ biến trong trừu tượng hóa tài khoản mô-đun hiện tại, đó là "sự phân mảnh" của các tài khoản, hoặc vấn đề đảo. Ví dụ: trong khi các nhà cung cấp mô-đun trừu tượng tài khoản khác nhau hoặc các DApp khác nhau có thể tương thích với EIP-4337, mức độ trừu tượng của nó trên các mô-đun khác nhau là không đủ, với độ chi tiết tương đối thấp. Kịch bản này cho phép các nhà phát triển mô-đun tài khoản thông minh tự do "quá mức" (tài khoản thông minh là thành phần cốt lõi lưu trữ thông tin người dùng, ghi lại xác thực giao dịch tùy chỉnh và xử lý logic thanh toán gas) để tạo các mô-đun với các thuộc tính duy nhất. Do đó, theo thời gian, các dự án ví khác nhau có xu hướng thiết kế các mô-đun tài khoản thông minh với các thuộc tính riêng biệt. Xu hướng này buộc các nhà cung cấp mô-đun trừu tượng hóa tài khoản khác phải ưu tiên khả năng tương thích với các nhà cung cấp mô-đun tài khoản thông minh cụ thể, dần dần hình thành chuỗi cung ứng thượng nguồn-hạ nguồn cố định. Điều này chắc chắn dẫn đến sự phân mảnh và cô lập của hệ sinh thái mô-đun trừu tượng tài khoản (tương tự như những ngày đầu trong ngành công nghiệp máy tính, nơi các nhà phát triển hệ điều hành phải xem xét khả năng tương thích với phần cứng từ các nhà sản xuất khác nhau). Để giải quyết vấn đề phân mảnh hệ sinh thái và tăng cường khả năng tương thích giữa các mô-đun trừu tượng hóa tài khoản được phát triển bởi các nhà cung cấp khác nhau, cách tiếp cận tối ưu là tiếp tục trừu tượng hóa các tài khoản ví hợp đồng thông minh và tinh chỉnh mức độ chi tiết của phân đoạn mô-đun. Theo các nguyên tắc được nêu trong EIP-6900, sách trắng Giao thức lõi an toàn đã thực hiện tối ưu hóa chi tiết cho Tài khoản thông minh (tài khoản ví thông minh của người dùng). Giao thức lõi an toàn chia nhỏ các mô-đun có thể gọi trong mỗi tài khoản ví thông minh thành nhiều danh mục khác nhau như plugin, móc, trình xác thực chữ ký, bộ xử lý chức năng và hơn thế nữa. Các mô-đun tài khoản thông minh nhằm mục đích càng nhẹ càng tốt, chỉ lưu trữ dữ liệu và chức năng thiết yếu, đồng thời ủy thác các chức năng có thể di chuyển cho "bộ xử lý chức năng" hoặc các mô-đun được phân đoạn tương tự. Cách tiếp cận này phù hợp với nguyên tắc của Occam's Razor - "các thực thể không nên được nhân lên một cách không cần thiết". Nếu bản thân tài khoản thông minh đủ nhẹ và không liên quan đến các chi tiết quá phức tạp, các tài khoản thông minh được phát triển bởi các nhà cung cấp khác nhau sẽ thể hiện cấu trúc nội bộ gần gũi hơn và khả năng tương thích cao hơn.

Giao thức Safe Core cũng giới thiệu một hệ thống đăng ký (tương tự như Cửa hàng Ứng dụng iPhone), trong đó chứa tất cả các mô-đun được phê duyệt và có sẵn. Người dùng có thể chọn mô-đun nào để kích hoạt, và mỗi khi một mô-đun mới được kích hoạt, nó phải được xử lý qua Manger.

Nói chung, UserOperation trước tiên sẽ kích hoạt một plugin, và sau đó Manger sẽ kiểm tra xem trạng thái của plugin có bình thường không (được ghi lại trong sổ đăng ký). Nếu bình thường, yêu cầu của plugin sẽ được cho phép. Nếu cần, plugin sẽ gọi một số chức năng do Hook cung cấp hoặc chọn không. Sau đó, trạng thái của tài khoản thông minh liên quan đến UserOperation sẽ được thay đổi.

Thực hiện phương pháp phân đoạn mô-đun tinh tế và quy trình lập lịch được đề cập ở trên, Safe Core Protocol cố gắng triển khai một tập hợp các giao thức tương tác mô-đun trừu tượng tài khoản mã nguồn mở. Ý tưởng cốt lõi là làm cho tài khoản thông minh nhẹ và đơn giản như tài khoản EOA để tăng cường tính tương thích giữa các mô-đun tài khoản thông minh từ các nhà cung cấp khác nhau.

Giải pháp tối ưu hóa 3: Tài khoản Omnichain với khái niệm tài khoản thống nhất trên các chuỗi khác nhau

Tuy nhiên, bất chấp các giải pháp nói trên, vẫn còn một vấn đề quan trọng chưa được giải quyết: các chuỗi khác nhau và các giải pháp Lớp 2 khác nhau đang thúc đẩy các chi tiết triển khai trừu tượng tài khoản khác nhau, nhiều trong số đó xung đột với EIP-4337, chẳng hạn như zkSync Era, Starknet, Flow, v.v. Điều này phân mảnh ví UX cho người dùng. Ví dụ: địa chỉ ví thông minh trên Starknet không thể hợp nhất với các địa chỉ trên Arbitrum. Ngoài ra, trong môi trường đa chuỗi, người dùng đã triển khai độc lập các tài khoản thông minh trên các chuỗi khác nhau và dữ liệu người dùng tương ứng của họ thường nằm rải rác trên các hợp đồng này. Nếu dữ liệu người dùng như khóa cần được cập nhật, các giao dịch cần được bắt đầu nhiều lần trên nhiều chuỗi, gây khó khăn cho việc đảm bảo tính nhất quán của Tài khoản thông minh. Vitalik trước đây đã đề xuất một giải pháp tài khoản thông minh được thống nhất trên toàn bộ chuỗi và dễ quản lý. Giải pháp này sử dụng Ethereum hoặc ZK-Rollup có độ bảo mật cao làm chuỗi nguồn và triển khai hợp đồng Keystore để lưu trữ khóa toàn cầu của người dùng. Sau đó, tất cả các tài khoản hợp đồng thông minh trên Lớp 2 chia sẻ khóa toàn cầu được lưu trữ trong hợp đồng Keystore.

(Nguồn hình ảnh: https://vitalik.ca/general/2023/06/20/deeperdive.html)

Tuy nhiên, giải pháp này phát sinh chi phí đáng kể. Bất cứ khi nào các khóa toàn cục được ghi trong hợp đồng Keystore trên chuỗi nguồn thay đổi, mỗi tài khoản trên L2 / chuỗi đích cần đồng bộ hóa các khóa mới thông qua các tương tác chuỗi chéo. Chi phí tương tác chuỗi chéo giữa Ethereum và Lớp 2 là quá cao để người dùng chịu đựng. Hơn nữa, điều quan trọng cần lưu ý là các tài khoản hợp đồng thông minh khác với EOA. Loại thứ hai, do cách tiếp cận tạo địa chỉ độc đáo của chúng, vốn đã được thống nhất trên nhiều chuỗi EVM. Nhưng các tài khoản hợp đồng thông minh hoàn toàn khác, khiến người dùng gặp khó khăn trong việc có được các tài khoản hợp đồng thông minh có cùng địa chỉ trên các chuỗi khác nhau. Đáp lại, Particle Network đã đề xuất phương pháp riêng của mình. Mặc dù ý tưởng chung về phương pháp của họ phù hợp với khái niệm của Vitalik, tập trung vào việc tách Lưu trữ và Mã của tài khoản thông minh, Particle Network dự định sử dụng một chuỗi độc lập — Particle Network Chain — làm cơ sở dữ liệu Lưu trữ hoàn chỉnh cho các tài khoản thông minh. Họ có kế hoạch đồng bộ hóa các thay đổi đối với Bộ nhớ của tài khoản với bộ nhớ cục bộ của Tài khoản trên các chuỗi khác thông qua các giải pháp nhắn tin chuỗi chéo của bên thứ ba (chẳng hạn như LayerZero, CCIP, Axelar, Connext, v.v.).

Cấu trúc Trừu tượng Tài khoản đa chuỗi của Particle Network

Đặc biệt, hệ thống trừu tượng tài khoản Omnichain của Mạng Hạt giúp người dùng có địa chỉ hợp đồng thông minh thống nhất trên các chuỗi EVM khác nhau. Điều này đòi hỏi triển khai một bộ Hợp đồng Triển khai trên các chuỗi khác nhau; người dùng phải kích hoạt việc tạo ra các tài khoản mới trên Chuỗi Mạng Hạt, sau đó Chuỗi Hạt sẽ kích hoạt Hợp đồng Triển khai trên tất cả các chuỗi để đảm bảo các địa chỉ tài khoản hợp đồng thông minh được tạo ra cho người dùng trên các chuỗi khác nhau là nhất quán. Hoặc người dùng có thể tham gia vào các tương tác đa chuỗi thông qua các hợp đồng trên chuỗi Hạt mà không cần biết về các chuỗi khác, và có thể sử dụng Token Khí Đồng Nhất như một phương pháp thanh toán thông universal cho phí giao dịch.

Trừu tượng hóa tài khoản Omnichain cũng cho phép các hoạt động của người dùng chuỗi chéo bằng cách bắt đầu các giao dịch trên chuỗi đích thông qua các hoạt động của người dùng và thanh toán gas tương ứng trên chuỗi nguồn. Ví dụ: điều này cho phép người dùng mua NFT trên Base bằng $USDC của Polygon.

Tuy nhiên, giải pháp của Particle Network đòi hỏi mức độ hợp tác cao giữa Hợp đồng Deployer và thành phần nhắn tin chuỗi chéo để đạt được sự đồng bộ hóa của các tài khoản đa chuỗi và lưu trữ chuỗi nguồn. Điều này thực sự đặt ra yêu cầu cao hơn đối với oracle hoặc cầu nối thông điệp chuỗi chéo được sử dụng (dường như là một vấn đề phổ biến trong tất cả các giải pháp liên quan đến khả năng tương tác omnichain). Tuy nhiên, đồng bộ hóa tài khoản chuỗi chéo của người dùng có thể linh hoạt cấu hình sự kết hợp của các Message Bridge khác nhau, thay vì dựa vào một cầu nối duy nhất. Ví dụ: nó có thể được cấu hình như một chiến lược 2/3, dựa trên xác nhận của bất kỳ hai LayerZero, Axelar và Connext nào để xác nhận các thay đổi lưu trữ trên chuỗi đích. Đây có thể là một giải pháp tiềm năng cho vấn đề phụ thuộc một điểm.

Tích hợp mạng lưới Omnichain mượt mà trên cả EVM và không phải EVM là Một Bước Tiếp Theo Hướng Tới Sự Trừu Tượng Tài Khoản Omnichain trong Hệ Sinh Thái Ethereum

Mặc dù có quản lý khóa và tài khoản hợp nhất trên các chuỗi EVM, vẫn có những khu vực để tối ưu hóa trong trừu tượng hóa tài khoản omnichain. Các chuỗi không tương thích EVM như Aptos, Solana, Sui, v.v., không thể đảm bảo địa chỉ tài khoản hợp đồng thông minh nhất quán với địa chỉ tài khoản trên chuỗi EVM. Hơn nữa, các chuỗi không phải EVM sẽ gặp khó khăn khi áp dụng khái niệm trừu tượng hóa tài khoản chuỗi chéo được đề xuất trong cuộc thảo luận trước nếu chúng không triển khai giao thức ERC-4337 với một giải pháp tương đương. Ngoài ra, có chỗ để cải thiện trong các dự án ví tương thích với EIP-4337. Các nút Bundler được sử dụng bởi hầu hết các ví thông minh được chạy chính thức độc lập, đôi khi thậm chí tách biệt với nhau, tạo ra nhiều rủi ro khác nhau (chẳng hạn như rủi ro liên quan đến khả năng chống kiểm duyệt và tính khả dụng). Xây dựng một giao diện người dùng thống nhất trải dài trên phần lớn các chuỗi chứng tỏ là vô cùng thách thức. Một giải pháp tiềm năng là giới thiệu một thiết kế tập trung vào mục đích, thêm một lớp bổ sung trên sự trừu tượng hóa tài khoản omnichain. Lớp này kết hợp hệ sinh thái EIP-4337 của Ethereum hoặc các cơ sở trừu tượng hóa tài khoản gốc của các chuỗi khác (ví dụ: zkSync) như các trường hợp cụ thể thuộc loại Bộ giải / Lò phản ứng, với nhiệm vụ chọn Bộ giải thích hợp là trách nhiệm cấp trên. Lấy Particle Network làm ví dụ, nó đề xuất một triển khai ngắn gọn và trừu tượng lấy ý định làm trung tâm. Các dự án trừu tượng hóa tài khoản khác nhau chỉ đơn thuần là các trường hợp được bao gồm trong danh mục Bộ giải trong lược đồ ý định. Thứ nhất, giao diện người dùng chuyển đổi các yêu cầu ngôn ngữ tự nhiên hoặc bất kỳ tương tác nào của người dùng thành các mô tả lập trình cụ thể bao gồm các ràng buộc đầu vào và đầu ra (Nói cách khác, đây là những điều kiện cho phép đầu vào đáp ứng yêu cầu của người dùng và kết quả đầu ra nằm trong một phạm vi cụ thể). Sau đó, trong mạng Solver, (các) giao dịch chuyển tiếp Solver cụ thể chứa các ràng buộc đầu vào và đầu ra chính xác đối với các hợp đồng Solver được triển khai trên chuỗi (Solver không chỉ bao gồm cơ sở hạ tầng nút mà còn cả các thành phần hợp đồng trên chuỗi). Hợp đồng Solver truyền chỉ thị Intent đến hợp đồng Reactor (quản lý tài khoản người dùng trên chuỗi), ủy quyền cho người sau gọi các mô-đun khác để thực hiện tương tác cuối cùng. Khung này cho phép các yêu cầu của người dùng được xử lý ban đầu bởi mạng Solver, giảm bớt nhu cầu cho người dùng hiểu các chuỗi cơ bản hoặc các sơ đồ trừu tượng hóa tài khoản khác nhau, một nhiệm vụ được giao cho Bộ giải để xây dựng các giải pháp cụ thể. Tuy nhiên, những khái niệm này vẫn là khung lý thuyết, với các chi tiết triển khai đang chờ Particle Network xây dựng thêm. Rõ ràng là một thị trường Bộ giải cạnh tranh sẽ xuất hiện trong tương lai, cho phép người dùng bắt đầu đặt giá thầu trong đó nhiều Bộ giải đề xuất các giải pháp riêng biệt. Thông qua các giao dịch mô phỏng cục bộ, giải pháp tối ưu có thể được lựa chọn và các ưu đãi tương ứng có thể được cung cấp cho Bộ giải của họ. Cấu trúc khuyến khích sẽ được định hình bởi các nhà thiết kế giao thức của mạng Solver (Particle Network nhằm mục đích sử dụng token PNT làm token khuyến khích cho thị trường đấu giá Solver của mình). Hiện tại, bản chất của ý định che chắn các chi tiết phức tạp của các lớp thấp hơn và trừu tượng hóa một lớp cao hơn. Thiết kế phân lớp này, tương tự như giao thức TCP / IP, rất cần thiết để cải thiện cả trải nghiệm người dùng và trải nghiệm nhà phát triển trong khả năng tương tác liền mạch trên các chuỗi.

Chào đón Sự Thụ hưởng Mạnh mẽ của Sự Trừu tượng Hóa Tài khoản

Sau khi tối ưu hóa khung EIP-4337 trong hệ sinh thái Ethereum từ nhiều khía cạnh và nâng cao khả năng tương tác mượt mà trên các hệ sinh thái Ethereum và không phải Ethereum, chúng tôi tin rằng, để hỗ trợ việc tiếp nhận hàng loạt của việc trừu tượng hóa tài khoản, chúng ta vẫn cần một sản phẩm vượt ra ngoài cả hai bên cung và cầu. Sản phẩm này nên giảm độ phức tạp cho người dùng cuối sử dụng nhiều dịch vụ sản phẩm Web3 khác nhau trong khi tập trung vào việc giảm rào cản nhập cửa của các nhà phát triển. Một trong những sản phẩm tối ưu thực hiện vai trò này là Particle Network's Modular Smart Wallet-as-a-Service Stack:

Kiến trúc Dịch vụ Ví Thông Minh của Particle Network

• Dịch vụ cung cấp một API thân thiện với người dùng, cho phép các nhà phát triển tích hợp một cách mượt mà các chức năng trừu tượng tài khoản modul vào ứng dụng của họ.
• Nhà phát triển có thể sử dụng dịch vụ này để tạo và quản lý tài khoản omnichain, thực hiện tương tác qua nhiều chuỗi khối và sử dụng phương thức thanh toán phí thống nhất.
• Các dịch vụ như vậy sẽ cung cấp cho các nhà phát triển cách tiện lợi và linh hoạt hơn để xây dựng ứng dụng đa chuỗi và thúc đẩy việc áp dụng rộng rãi của trừu tượng hóa tài khoản.

Ngoài các tính năng thân thiện với nhà phát triển ở trên, khía cạnh quan trọng nhất của ngăn xếp Ví Thông Minh Modul dưới dạng Dịch vụ của Mạng Particle là việc xây dựng một hệ sinh thái mở cho miền trừu tượng tài khoản, dựa trên tính toán chữ ký và hướng tới nhà phát triển. Bên cạnh các mô-đun sản phẩm trừu tượng tài khoản nội bộ của họ, Mạng Particle tích hợp các loại sản phẩm và dịch vụ trừu tượng tài khoản khác nhau. Việc tích hợp này giúp tăng tốc việc áp dụng các sản phẩm và dịch vụ trên toàn bộ miền trừu tượng tài khoản cho nhà phát triển.

(Thiết kế theo mô-đun của Ví thông minh Dịch vụ Ví dưới dạng Dịch vụ) Hãy để công nghệ phục vụ nhu cầu của người dùng. Sau khi giải quyết các hạn chế của khung ERC-4337, việc cải thiện trải nghiệm của nhà phát triển sẽ dẫn đến sự xuất hiện của nhiều sản phẩm với trải nghiệm người dùng xuất sắc, tăng tốc quá trình chuyển đổi của Web3 từ một ngành công nghiệp tài chính thân thiện với crypto-punk sang một ngành công nghiệp thân thiện với người tiêu dùng đại chúng.

免责声明：

1. Bài viết này được sao chép từ [ Web3 của Gate.io]. Tất cả bản quyền thuộc về tác giả gốc [Peter Pan, CTO và đồng sáng lập viên của Particle Network & Faust, Geek Web3]. Nếu có ý kiến phản đối về việc tái bản này, vui lòng liên hệ với Gate Họcđội, và họ sẽ xử lý nó ngay lập tức.
2. Miễn trừ trách nhiệm: Các quan điểm và ý kiến được thể hiện trong bài viết này chỉ thuộc về tác giả và không đại diện cho bất kỳ lời khuyên đầu tư nào.
3. Các bản dịch của 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 nêu ra, việc sao chép, phân phối hoặc sao chép trội các bài viết đã dịch là không được phép.