Giới thiệu: Mặc dù ví AA đã giảm đáng kể rào cản gia nhập của người dùng và đạt được thanh toán gas và đăng nhập tài khoản web2, nhưng các khía cạnh liên quan đến việc áp dụng hàng loạt, chẳng hạn như đăng nhập bí mật, giao dịch bí mật, omnichain AA và giao thức tổng hợp ý định, vẫn cần phát triển hơn nữa trên nền tảng của AA.

Mặc dù chúng tôi thấy các giải pháp tối ưu hóa UX khác nhau như ví MPC của ZenGo hoặc ví hợp đồng thông minh như Argent giúp giảm thiểu rào cản người dùng một cách hiệu quả, nhưng chúng chỉ giải quyết một phần các vấn đề nói trên mà không giải quyết đầy đủ các mối lo ngại về khả năng sử dụng tổng thể của sản phẩm.

Rõ ràng, hầu hết các ví AA hoặc các sản phẩm tương tự vẫn chưa thể hỗ trợ việc áp dụng rộng rãi Web3. Mặt khác, từ góc độ hệ sinh thái, phía nhà phát triển là một khía cạnh quan trọng. Chỉ riêng sự hấp dẫn đối với người dùng thông thường mà không có đủ tác động về phía nhà phát triển thì khó có thể đạt được khả năng mở rộng. Sự xuất hiện ngày càng nhiều các giải pháp tối ưu hóa trải nghiệm của nhà phát triển cho thấy tầm quan trọng ngày càng tăng của phía nhà phát triển trong hệ sinh thái sản phẩm.

Lấy Mạng Hạt làm ví dụ, chúng tôi sẽ giải thích chi tiết về những thách thức UX hiện tại mà các sản phẩm Web3 phải đối mặt và thảo luận cách thiết kế một giải pháp kỹ thuật toàn diện, có mục tiêu. Loại giải pháp tích hợp này có thể là điều kiện cần thiết để áp dụng đại trà. Ngoài ra, chiến lược kinh doanh BtoBtoC của Particle đóng vai trò là một cách tiếp cận đáng chú ý mà nhiều nhóm dự án có thể thấy có lợi.

Phân tích cấu trúc sản phẩm hạt

Particle Network, với trọng tâm cốt lõi là giảm bớt các rào cản sử dụng, áp dụng cách tiếp cận phát triển sinh thái và xây dựng sản phẩm B2B2C, cung cấp giải pháp toàn diện cho việc áp dụng rộng rãi Web3. Các mô-đun cốt lõi của nó bao gồm ba thành phần chính:

zkWaaS đề cập đến dịch vụ ví không có kiến thức. Các nhà phát triển có thể nhanh chóng tích hợp các mô-đun ví thông minh vào dApp của họ bằng SDK của Particle. Ví này là ví hợp đồng thông minh không cần chìa khóa dựa trên tính trừu tượng của tài khoản, cho phép thanh toán gas và cung cấp thông tin đăng nhập bí mật OAuth theo kiểu Web2 và các giao dịch bí mật.

Chuỗi hạt - Sơ đồ trừu tượng tài khoản Omnichain chuyên dụng được thiết kế cho Particle nhằm mục đích giải quyết các thách thức về triển khai, bảo trì và gọi trên chuỗi chéo cho ví hợp đồng thông minh. Nó cũng bao gồm Mã thông báo khí hợp nhất, đơn giản hóa việc sử dụng các mã thông báo khí khác nhau trong các giao dịch đa chuỗi.

Giao thức kết hợp ý định - Bao gồm Ngôn ngữ dành riêng cho miền (DSL), khung Ý định, Mạng bộ giải ý định, v.v., để xây dựng khung tương tác Web3 dựa trên ý định. Người dùng khai báo trực tiếp ý định giao dịch của họ thay vì thực hiện từng hoạt động cụ thể, giải phóng họ khỏi những cân nhắc về đường dẫn phức tạp và giảm nhu cầu tìm hiểu cơ sở hạ tầng cơ bản phức tạp.

zkWaaS - Ví dưới dạng dịch vụ không có kiến thức

Về mặt ví, Particle chủ yếu cung cấp SDK cho các nhà phát triển dApp dưới dạng Ví dưới dạng dịch vụ (WaaS). Mục đích là cho phép các nhà phát triển tích hợp vào khuôn khổ áp dụng hàng loạt Web3 toàn diện của mình. Cách tiếp cận BtoBtoC này có một số lợi thế từ cả góc độ kinh doanh và hệ sinh thái:

Thị trường ví tiêu dùng có tính cạnh tranh cao và các chức năng ngày càng trở nên giống nhau. Ví tiêu dùng không còn là điểm vào tối ưu. Mặt khác, các nhà phát triển dApp thích tích hợp ví trong ứng dụng của họ để nâng cao trải nghiệm người dùng và cung cấp nhiều tính năng tùy chỉnh hơn.

Việc thu hút người dùng ở phía người tiêu dùng rất tốn kém, nhưng phía doanh nghiệp thì lại khác. Sự tăng trưởng người dùng của WaaS chủ yếu bắt nguồn từ các dApp được tích hợp với SDK. Với sự phát triển kinh doanh và quan hệ nhà phát triển hiệu quả, hệ sinh thái có thể mở rộng một cách tự nhiên.

Ví tiêu dùng hiện tại chủ yếu tập trung vào tài chính và tài sản, những thứ này có thể không đại diện cho các kịch bản chính cho tương lai của Web3. Để đạt được việc áp dụng Web3 rộng rãi, các tính năng cơ bản như nhận dạng người dùng (tài khoản) và hoạt động của người dùng (bắt đầu giao dịch) phải được trừu tượng hóa thành một dịch vụ cơ bản, để lại các kịch bản phong phú hơn được xử lý bởi dApps.

Trong lịch sử, điểm vào của dApps đã cho thấy mối quan hệ chặt chẽ giữa ví và dApps. Việc tăng thị phần của ví về phía dApp là rất quan trọng. Điều này đặc biệt có lợi cho mô hình B2B2C.

Để xây dựng một giải pháp đáp ứng nhu cầu của người dùng, giảm rào cản gia nhập và tạo điều kiện cho nhà phát triển tích hợp, zkWaaS của Particle đóng vai trò là thành phần then chốt với ba tính năng cốt lõi:

1. Đăng nhập bí mật: Tận dụng các phương thức đăng nhập Web2 truyền thống như xác minh OAuth từ các nền tảng như Twitter, Google, WeChat, v.v., trên ví hợp đồng thông minh. Điều này cho phép người dùng hoàn toàn giải phóng bản thân khỏi những ràng buộc về quản lý khóa riêng, truy cập Web3 theo cách quen thuộc và đơn giản nhất. Đồng thời, danh tính người dùng được che giấu bằng cách sử dụng bằng chứng không có kiến thức.

2. Giao dịch bí mật: Thực hiện chuyển giao quyền riêng tư điểm-điểm thông qua cơ chế Địa chỉ tàng hình thông minh, đảm bảo quyền riêng tư toàn cầu trong giao dịch. Ngoài ra, việc sử dụng Paymaster của ERC-4337 cho phép sử dụng tài sản không cần gas cho Địa chỉ tàng hình thông minh (tài trợ gas).

3. Chức năng ví AA toàn diện: Mô-đun ví của Particle hoàn toàn tuân thủ các yêu cầu cơ bản của ERC-4337. Nó bao gồm các thành phần thiết yếu như Bundler, EntryPoint, Paymaster, Tài khoản ví thông minh, v.v., bao gồm tất cả các khía cạnh quan trọng của quy trình làm việc ERC-4337. Giải pháp toàn diện này đáp ứng hiệu quả nhu cầu chức năng của DApp hoặc người dùng ví thông minh.

Đăng nhập bí mật cho ví trên chuỗi dựa trên tài khoản Web2

Giải pháp đăng nhập bí mật của Particle sử dụng JSON Web Tokens (JWT), cho phép xác thực danh tính Web2 và hoạt động ví trong hợp đồng thông minh.

JWT là một hình thức chứng minh danh tính được sử dụng rộng rãi trong các ứng dụng internet truyền thống, do máy chủ cấp cho máy khách. Máy khách sử dụng bằng chứng này để xác thực danh tính trong mỗi lần tương tác với máy chủ.

(Nguồn: Tài liệu FlutterFlow)

Có một số trường chính trong JWT làm cơ sở cho việc xác minh danh tính theo hợp đồng:

·”iss” (Nhà phát hành) cho biết nhà phát hành JWT, tức là máy chủ, chẳng hạn như Google, Twitter, v.v.

·”aud” (Đối tượng): Chỉ định dịch vụ hoặc ứng dụng mà JWT hướng tới. Ví dụ: khi đăng nhập vào Medium bằng Twitter, JWT do Twitter cấp sẽ bao gồm trường này cho biết khả năng áp dụng của nó đối với Medium.

·”sub” (Chủ đề): Đề cập đến danh tính người dùng nhận JWT, thường được xác định bởi UID.

Trong thực tế, “iss” và “sub” thường không đổi để tránh nhầm lẫn đáng kể giữa hệ thống nội bộ và tham chiếu bên ngoài. Do đó, hợp đồng có thể sử dụng các tham số này để xác định danh tính người dùng, loại bỏ nhu cầu người dùng tạo và bảo vệ khóa riêng.

Tương ứng với JWT là khái niệm JSON Web Key (JWK), một tập hợp các cặp khóa trên máy chủ. Khi phát hành JWT, máy chủ ký nó bằng khóa riêng của JWK, trong khi khóa chung tương ứng được công khai để các dịch vụ khác xác minh chữ ký.

Ví dụ: khi Medium sử dụng Twitter để đăng nhập, Medium sẽ xác thực JWT bằng cách sử dụng JWK công khai của Google để xác nhận tính xác thực của nó – rằng nó thực sự do Google phát hành. Việc xác minh JWT trong hợp đồng cũng sẽ liên quan đến việc sử dụng JWK.

Quy trình giải pháp đăng nhập bảo mật của Particle được mô tả theo sơ đồ bên dưới:

Chúng tôi sẽ bỏ qua mạch ZK cụ thể ở đây, chỉ nêu bật một số điểm chính trong quy trình:

Hợp đồng Người xác minh xác thực thông tin đăng nhập sẽ chỉ nhận biết Bằng chứng ZK liên quan đến danh tính JWT của người dùng và eph_pk. Nó không thể trực tiếp lấy khóa công khai hoặc thông tin JWT của ví tương ứng, đảm bảo quyền riêng tư của người dùng và ngăn các thực thể bên ngoài xác định người dùng đăng nhập từ dữ liệu trên chuỗi.

eph_pk (cặp khóa tạm thời) là cặp khóa được sử dụng trong một phiên duy nhất và không phải là cặp khóa công khai của ví. Người dùng không cần phải quan tâm đến nó.

Hệ thống này hỗ trợ xác minh ngoài chuỗi và có thể được sử dụng cho các ví hợp đồng sử dụng logic như MPC (Tính toán nhiều bên).

Vì đây là giải pháp xác minh hợp đồng thực sự dựa trên các phương thức đăng nhập truyền thống nên người dùng cũng có thể chỉ định các liên hệ xã hội khác làm người giám hộ trong các trường hợp nghiêm trọng, chẳng hạn như tài khoản Web2 bị vô hiệu hóa.

Giao dịch bí mật dựa trên trao đổi khóa DH

Trước khi thảo luận về các giao dịch bí mật của Particle, hãy xem xét cách đạt được các giao dịch bí mật cho người nhận trong hệ thống EVM hiện có, đặc biệt là ẩn địa chỉ của người nhận.

Giả sử Alice là người gửi và Bob là người nhận, cả hai bên đều có chung một số kiến thức:

1. Bob tạo khóa chi tiêu gốc (m) và địa chỉ meta ẩn (M). M có thể được tạo bởi m và mối quan hệ của chúng được biểu thị bằng M = G * m, biểu thị mối quan hệ toán học trong các hoạt động mã hóa.

2. Alice lấy được địa chỉ meta lén lút M của Bob bằng mọi cách.

3. Alice tạo một khóa riêng tạm thời (r) và sử dụng thuật toán generate_address(r, M) để tạo một địa chỉ ẩn (A). Địa chỉ này đóng vai trò như một địa chỉ tàng hình chuyên dụng được chuẩn bị cho Bob, với việc Bob giành được quyền kiểm soát sau khi nhận được tài sản.

4. Alice tạo một khóa pubkey tạm thời (R) dựa trên khóa riêng r tạm thời và gửi nó đến hợp đồng ghi lại khóa pubkey tạm thời (hoặc bất kỳ vị trí nào được hai bên thống nhất mà Bob có thể truy cập).

5. Bob định kỳ quét hợp đồng ghi khóa pubkey tạm thời, ghi lại mọi pubkey tạm thời được cập nhật. Vì hợp đồng pubkey phù du là công khai và chứa các khóa liên quan đến giao dịch quyền riêng tư do người khác gửi nên Bob không biết Alice đã gửi cho anh ấy xem khóa nào.

6. Bob quét từng bản ghi được cập nhật, thực thi generate_address(R, m) để tính địa chỉ ẩn. Nếu có tài sản trong địa chỉ đó, điều đó có nghĩa là Alice đã tạo và ủy quyền địa chỉ đó cho Bob kiểm soát; mặt khác, nó không liên quan đến Bob.

7. Bob thực thi generate_spending_key(R, m) để tạo khóa chi tiêu cho địa chỉ ẩn đó, tức là p = m + hash(A). Sau đó, Bob có thể kiểm soát địa chỉ A do Alice tạo ra.

Quá trình được mô tả đơn giản hóa nhiều phép toán phức tạp. Toàn bộ quá trình trao đổi thông tin giống như hai đặc vụ bí mật viết những tin nhắn khó hiểu trên bảng thông báo công cộng, những tin nhắn chỉ có nhau mới có thể giải mã được. Mặc dù phương pháp tạo và giải mã các tin nhắn này là công khai nhưng dữ liệu quan trọng cần thiết cho cả hai tác nhân chỉ có họ mới biết. Do đó, ngay cả khi người ngoài hiểu được phương pháp này thì việc giải mã thành công vẫn khó nắm bắt.

Quá trình trao đổi này hơi giống với phương pháp trao đổi khóa Diffie–Hellman nổi tiếng. Nếu không tiết lộ bí mật của họ (khóa chi tiêu gốc của Bob (m) và khóa riêng tư tạm thời của Alice (r)), cả hai bên có thể tính toán một bí mật chung – địa chỉ ẩn (A) đã đề cập trước đó. Nếu không quen với trao đổi DH, việc hiểu ẩn dụ có thể được dễ dàng hơn bằng cách sử dụng sơ đồ bên dưới.

Một bước bổ sung so với DH là sau khi tính toán bí mật chung - địa chỉ ẩn (A), nó không thể được sử dụng trực tiếp làm khóa riêng vì Alice cũng biết A. Cần phải xây dựng khóa chi tiêu (p = m + hash (A)) coi A là khóa chung. Như đã đề cập trước đó, chỉ Bob biết khóa chi tiêu gốc (m), khiến Bob trở thành người kiểm soát duy nhất địa chỉ ẩn này.

Rõ ràng, trong phương thức chuyển giao quyền riêng tư này, đối với mỗi giao dịch mới nhận được, tiền sẽ chuyển vào một địa chỉ EOA hoàn toàn mới. Người nhận có thể sử dụng khóa chi tiêu gốc để tính toán lặp lại khóa chi tiêu cho từng địa chỉ, thử nghiệm để tìm ra khóa chi tiêu thực sự được liên kết với chúng.

Tuy nhiên, vẫn còn một vấn đề. Ban đầu, địa chỉ ẩn mới được tạo này vẫn là tài khoản EOA và có thể thiếu ETH hoặc các token gas khác. Bob không thể bắt đầu giao dịch trực tiếp và cần sử dụng Paymaster của ví hợp đồng thông minh để thanh toán gas nhằm đạt được các giao dịch bí mật. Do đó, cần có một số sửa đổi đối với địa chỉ người nhận:

Sử dụng phương pháp tính toán địa chỉ từ hàm CREATE2 trong quá trình triển khai hợp đồng, cùng với các tham số tương ứng (đặt địa chỉ ẩn A làm chủ sở hữu hợp đồng, v.v.), tính toán địa chỉ Phản thực tế. Đây là địa chỉ hợp đồng được tính toán chưa được triển khai, hiện là EOA.

Alice trực tiếp chuyển tiền đến địa chỉ Phản thực này. Khi Bob muốn sử dụng nó, anh ấy trực tiếp tạo một ví hợp đồng tại địa chỉ này, cho phép gọi dịch vụ thanh toán gas (bước này cũng có thể được xử lý trước bởi Alice hoặc mạng Particle).

Chúng ta có thể gọi địa chỉ Phản thực nói trên là Địa chỉ Tàng hình Thông minh. Bob sử dụng ẩn danh các tài sản theo Địa chỉ ẩn danh thông minh này thông qua quy trình sau:

·Gửi tiền Paymaster từ bất kỳ địa chỉ nào của anh ấy và Paymaster sẽ trả lại bằng chứng quỹ (dựa trên ZK).

·Với cơ chế AA, sử dụng bất kỳ địa chỉ nào khác, có thể không có số dư, để gửi UserOperation đến nút Bundler, gọi nội dung theo địa chỉ tàng hình đã đề cập. Bob chỉ cần cung cấp bằng chứng về tiền cho Paymaster bằng địa chỉ mới và Paymaster thanh toán cho Bundler phí đóng gói giao dịch.

Quá trình này tương tự như cách Tornado Cash hoạt động. Bằng chứng quỹ (dựa trên ZK) có thể chứng minh rằng việc nạp tiền đã xảy ra trong tập hợp các nút lá trên cây Merkle. Tuy nhiên, khi chi tiêu, không ai có thể xác định số tiền của nút lá cụ thể nào đã được tiêu thụ, do đó cắt đứt kết nối giữa người tiêu dùng và người nạp tiền.

Tóm lại, Particle kết hợp AA với các địa chỉ ẩn một cách khéo léo, đạt được các giao dịch chuyển tiền bí mật thông qua hình thức ví tàng hình thông minh.

Tóm tắt tài khoản chuỗi hạt và Omnichain

Chuỗi hạt là chuỗi POS được thiết kế để trừu tượng hóa tài khoản Omnichain. Xem xét cả hiện tại và tương lai, sự thống trị của một chuỗi là khó xảy ra. Nâng cao trải nghiệm người dùng trong kịch bản đa chuỗi là rất quan trọng.

Hiện tại, hệ thống trừu tượng hóa tài khoản ERC4337 có thể gặp phải một số vấn đề nhất định trong tình huống đa chuỗi:

• Địa chỉ của cùng một người dùng trên các chuỗi khác nhau có thể không đồng nhất, tùy thuộc vào thiết kế của hợp đồng.
• Việc quản lý các ví hợp đồng chuỗi khác nhau yêu cầu thao tác thủ công trên nhiều chuỗi, chẳng hạn như thay đổi quản trị viên. Trong trường hợp xấu hơn, nếu quyền của quản trị viên được cập nhật trên một chuỗi, sau đó loại bỏ phương thức xác thực cũ của quản trị viên thì sẽ không thể thực hiện thay đổi trên các chuỗi khác, khiến ví không thể sử dụng được.
• Việc sử dụng các chuỗi khác nhau yêu cầu phải có mã thông báo gas cho mỗi chuỗi hoặc tiền được lưu trữ trước trong Paymaster của mỗi chuỗi. Đối với các nhà phát triển, điều này có thể gây rắc rối. Nếu họ muốn người dùng sử dụng một số điều kiện nhất định với chi phí bằng 0 hoặc triển khai các chức năng khác, họ cần triển khai Paymasters tùy chỉnh của mình trên mỗi chuỗi và cấp vốn trước cho chúng.

Tính năng trừu tượng hóa tài khoản Omnichain của Particle Chain giải quyết các điểm yếu trên:

• Thiết lập ví AA trên Chuỗi hạt.
• Sử dụng LayerZero và các giao thức chuỗi chéo Cầu thông báo tùy ý (AMB) khác để đồng bộ hóa các hoạt động khác nhau, chẳng hạn như tạo, nâng cấp và thay đổi quyền đối với các chuỗi khác. Nó có thể được hiểu là ví trên các chuỗi khác là tham chiếu đến ví trên chuỗi đó, với các sửa đổi đối với phần chính đồng bộ hóa với tất cả các ví.
• Đảm bảo địa chỉ thống nhất cho các ví trên mỗi chuỗi thông qua Hợp đồng người triển khai tham số nhất quán.
• Các ví trên các chuỗi khác nhau cũng có thể gọi cho nhau thông qua AMB, không nhất thiết phải được bắt đầu từ Chuỗi hạt.
• Phát hành mã thông báo khí hợp nhất. Cơ chế Paymaster triển khai ERC20 dưới dạng phí gas. Ngay cả trên chuỗi không có gas hoặc tiền được lưu trữ trước trong Paymaster, các giao dịch chuỗi chéo sử dụng mã thông báo gas thống nhất có thể được bắt đầu trên các chuỗi tuân thủ.

Ngoài các trường hợp sử dụng nêu trên, Chuỗi hạt cũng có thể được sử dụng cho:

• Mạng phi tập trung để chứng minh zkWaaS và tạo muối.
• Các lớp khuyến khích dành cho Người đóng gói trên các chuỗi khác nhau, hỗ trợ Người đóng gói đạt được sự phân cấp cao hơn.
• Đóng vai trò là mạng giải quyết cho Giao thức kết hợp ý định.

Trong câu chuyện về Chuỗi hạt, mã thông báo khí hợp nhất đóng vai trò là đề xuất giá trị cốt lõi cho toàn bộ hệ sinh thái:

• Chức năng thanh toán phí gas là logic nắm bắt giá trị và nhu cầu mạnh mẽ được xác thực nhiều lần trong không gian tiền điện tử.
• Mã thông báo khí hợp nhất tóm tắt khái niệm về các lớp khí từ hệ sinh thái chuỗi công cộng hiện có. Sự trừu tượng này, nếu không có Chuỗi hạt và ví, sẽ không thể đạt được. Do đó, mã thông báo khí thống nhất thể hiện sự hiện thực hóa giá trị cho toàn bộ hệ sinh thái Hạt. Với lớp khí, sự tương tác, tăng trưởng của người dùng và giá trị của mã thông báo gốc trên các chuỗi khác nhau có mối quan hệ cùng có lợi với mã thông báo khí thống nhất.
• Khí thống nhất cũng là một trong những yếu tố thúc đẩy đạt được Chainless. Đối với người dùng, việc sử dụng một loại tiền tệ duy nhất giúp đơn giản hóa rất nhiều quá trình sử dụng và hiểu biết về chi phí. Trong tương lai, ngay cả trong kịch bản đa chuỗi, người dùng có thể không biết và không cần quan tâm đến hoạt động của cơ sở hạ tầng cơ bản. Tương tự như cách hiện tại trên Web2, chúng ta tương tác với máy chủ mà không quan tâm đến vị trí của trung tâm dữ liệu, cấu hình của chúng hoặc ngôn ngữ và cơ sở dữ liệu mà chúng sử dụng.
• Người dùng được dApp nhập trực tiếp trao quyền cho mã thông báo gas hợp nhất, cung cấp nhiều trường hợp sử dụng.

Giao thức kết hợp ý định

Thông thường, khi sử dụng nhiều dApp khác nhau, người dùng liên tục cần xem xét các đường dẫn sử dụng:

• Nếu không có thanh khoản trên một DEX thì cần phải kiểm tra một DEX khác.
• Chọn dApp phù hợp nhất trong cùng danh mục cho một giao dịch hoặc nhiệm vụ.
• Hiểu khái niệm “Phê duyệt” trước khi có thể sử dụng nhiều tính năng.
• Dọn sạch ví, chuyển đổi nhiều lượng token nhỏ thành một token cụ thể - một quá trình tẻ nhạt.
• Hoàn thành nhiều bước trên các ứng dụng khác nhau để đạt được mục tiêu cuối cùng. Ví dụ: trong hoạt động cho vay có đòn bẩy cao: hoán đổi, đặt cọc, vay, lấy token, sau đó hoán đổi lại, đặt cọc và vay.

Nội dung trên chỉ thể hiện cái nhìn thoáng qua về bối cảnh DeFi hiện tại và khi chúng ta bước vào kỷ nguyên áp dụng rộng rãi các dApp đa dạng trong Web3, độ phức tạp của các tương tác có thể vượt xa trí tưởng tượng của chúng ta.

Do đó, việc thay thế các bước thao tác cụ thể bằng ý định mang lại trải nghiệm rất khác biệt cho người dùng. Ý định, so với hoạt động, giống như lập trình khai báo và lập trình chức năng. Những câu tuyên bố thường mang lại cảm giác thẳng thắn, chỉ yêu cầu tuyên bố về những việc cần phải làm mà không quan tâm đến những chi tiết tiếp theo. Điều này đòi hỏi các cấp độ khác nhau của các câu lệnh lập trình hàm được đóng gói trong các lớp bên dưới.

Tương tự, việc sử dụng Intents cần có sự hỗ trợ từ hàng loạt tiện ích. Hãy kiểm tra toàn bộ quá trình:

1. Người dùng gửi Ý định của họ, mô tả chúng theo cách nào đó, chẳng hạn như ngôn ngữ tự nhiên, dưới dạng RFS (Yêu cầu Bộ giải), được gửi tới mạng Bộ giải. Bộ giải là một trình thông dịch cho các ý định và các bộ giải phổ biến như 1inch, một công cụ tổng hợp, tìm kiếm DEX tối ưu cho người dùng. Tuy nhiên, những Bộ giải này, so với tầm nhìn của chúng tôi, có thể không đủ linh hoạt và mạnh mẽ.

2. Nhiều Người giải quyết phản ứng, cạnh tranh với nhau. Những phản hồi này được viết bằng ngôn ngữ Intent DSL, sau đó được khách hàng phân tích cú pháp thành dạng dễ hiểu cho người dùng. Những phản hồi này bao gồm Ràng buộc đầu vào và Ràng buộc đầu ra, xác định ranh giới của đầu vào và đầu ra. Người dùng cũng có thể tự mình chỉ định các ràng buộc. Một ví dụ đơn giản để hiểu: khi sử dụng Swap, người dùng sẽ được nhắc về số tiền tối thiểu họ có thể nhận được sau khi swap, đây là một dạng ràng buộc. Người dùng chọn từ các phản hồi được cung cấp bởi nhiều Bộ giải.

3. Ký ý định.

4. Bộ giải chỉ định một Người thực thi hợp đồng thực thi cụ thể và gửi ý định tới Lò phản ứng hợp đồng phản hồi.

5. Reactor thu thập các đầu vào cần thiết (chẳng hạn như một nội dung cụ thể) từ tài khoản của người dùng, gửi ý định cho Executor và sau khi gọi hợp đồng logic có liên quan, trả về đầu ra của giao dịch cho Reactor. Reactor kiểm tra các ràng buộc và nếu đúng sẽ trả về kết quả đầu ra cho người dùng.

Chúng tôi có thể hình dung quá trình này giống như thể bạn đang giải thích các yêu cầu của mình với ChatGPT. Bất kể yêu cầu phức tạp đến mức nào, nó có thể mang lại kết quả cuối cùng cho bạn. Miễn là bạn hài lòng với kết quả, bạn có thể sử dụng nó trực tiếp mà không cần quan tâm đến quy trình cơ bản.

Phần kết luận

Particle Network đã đề xuất một giải pháp toàn diện: thông qua hình thức tích hợp của zkWaaS, Chuỗi hạt và Giao thức kết hợp ý định, nó đạt được thông tin đăng nhập quyền riêng tư Web2 OAuth, giao dịch quyền riêng tư, trừu tượng hóa tài khoản omnichain và mô hình giao dịch dựa trên mục đích. Mỗi tính năng giải quyết một phần các điểm yếu khi sử dụng Web3. Những tiến bộ và tối ưu hóa này sẽ đóng vai trò là nền tảng cho việc áp dụng rộng rãi các sản phẩm và công nghệ Web3 trong tương lai. Về hệ sinh thái và mô hình kinh doanh, áp dụng mô hình B2B2C, sử dụng WaaS làm điểm khởi đầu để thúc đẩy khả năng mở rộng và tiêu chuẩn hóa toàn bộ chuỗi sản phẩm, đồng xây dựng hệ sinh thái với các nhà phát triển dApp và cùng nhau tạo ra Web3 có ngưỡng thấp, trải nghiệm cao thế giới dành cho người dùng.

Tất nhiên, các dự án khác nhau có cách hiểu khác nhau về lộ trình triển khai để áp dụng rộng rãi Web3. Ngoài việc xem xét kỹ lưỡng các dự án cụ thể, chúng tôi hy vọng sẽ sử dụng các giải pháp khác nhau để nêu bật sự hiểu biết về những trở ngại khi triển khai mà Web3 hiện đang gặp phải, việc cân nhắc nhu cầu và điểm yếu của người dùng cũng như những cân nhắc về kết nối và phát triển chung của toàn bộ hệ sinh thái.

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

1. Bài viết này được in lại từ [极客 Web3], Mọi bản quyền thuộc về tác giả gốc [雾月，极客Web3]. Nếu có ý kiến phản đối việc tái bản này, vui lòng liên hệ với nhóm Gate Learn , họ sẽ xử lý kịp thời.
2. Tuyên bố miễn trừ trách nhiệm pháp lý: Các quan điểm và ý kiến 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. Việc 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 viết đã dịch đều bị cấm.