Lấy Particle Network làm ví dụ, công nghệ diễn giải các vấn đề trải nghiệm của các sản phẩm Web3 hiện tại

Tác giả: Wuyue, Geek Web3

Giới thiệu: Mặc dù ví AA đã hạ ngưỡng cho người dùng xuống một mức độ lớn và ban đầu nhận ra thanh toán gas và đăng nhập tài khoản web2, thiết kế liên quan đến việc áp dụng hàng loạt, chẳng hạn như đăng nhập quyền riêng tư - giao dịch riêng tư, tài khoản AA hợp nhất toàn chuỗi và kiến trúc chuyên dụng có ý định, vẫn cần được thêm vào trên cơ sở AA.

Mặc dù chúng ta có thể thấy nhiều giải pháp tối ưu hóa UX, chẳng hạn như ví MPC như ZenGo hoặc ví hợp đồng thông minh như Argent, giúp hạ thấp ngưỡng hiệu quả cho người dùng, nhưng chúng chỉ giải quyết được một số vấn đề trên và không bao gồm đầy đủ tính dễ sử dụng 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 hàng loạt Web3. Mặt khác, từ quan điểm sinh thái, phía nhà phát triển là một cấp độ rất quan trọng, chỉ hấp dẫn đối với người dùng thông thường về mặt sản phẩm, nhưng rất khó để hình thành quy mô vì không đủ ảnh hưởng đến phía nhà phát triển. **Sự xuất hiện của ngày càng nhiều giải pháp tối ưu hóa trải nghiệm phát triển đã chứng minh tầm quan trọng của phía nhà phát triển đối với hệ sinh thái sản phẩm.

Chúng tôi sẽ lấy Particle Network làm ví dụ để giải thích chi tiết các vấn đề kinh nghiệm hiện tại của các sản phẩm Web3 và cách thiết kế một giải pháp kỹ thuật toàn diện, đây có thể là điều kiện cần thiết để áp dụng hàng loạt. Đồng thời, chiến lược kinh doanh BtoBtoC của Particle là một ý tưởng mà nhiều bên dự án cần học hỏi. **

** Cấu trúc sản phẩm hạt giải pháp đầy đủ **

Với cốt lõi là giải quyết ngưỡng sử dụng, Particle Network đề xuất một bộ giải pháp hoàn chỉnh cho việc áp dụng Web3 quy mô lớn với ý tưởng xây dựng sản phẩm B2B2C và phát triển sinh thái. Các mô-đun cốt lõi của nó là ba:

**zkWaaS, một dịch vụ Wallet-as-a-service (WaaS) dựa trên bằng chứng không có kiến thức. **Các nhà phát triển có thể nhanh chóng tích hợp mô-đun ví thông minh vào dApp của riêng họ dựa trên SDK do Particle cung cấp. Ví là một ví hợp đồng thông minh không cần chìa khóa dựa trên sự trừu tượng hóa tài khoản, không chỉ có thể nhận ra các tình huống cơ bản của AA như thanh toán gas mà còn cung cấp các phương thức đăng nhập quyền riêng tư OAuth kiểu Web2 và các giao dịch riêng tư và các chức năng khác.

Particle Chain - Một giải pháp trừu tượng hóa tài khoản Omnichain dành riêng cho Particle, dành riêng cho việc giải quyết việc triển khai, bảo trì và gọi ví hợp đồng thông minh xuyên chuỗi. Ngoài ra còn có Unified Gas Token (Unified Gas Token) để giải quyết rắc rối khi sử dụng các đồng gas khác nhau cho các giao dịch đa chuỗi.

**Intent Fusion Protocol, bao gồm ngôn ngữ DSL (Ngôn ngữ dành riêng cho miền) ngắn gọn, Intent Framework, Intent Solver Network, v.v., được sử dụng để xây dựng một tập hợp các khung tương tác Web3 dựa trên mục đích. Người dùng trực tiếp khai báo ý định giao dịch của họ thay vì thực hiện từng hành động cụ thể, giải phóng người dùng khỏi suy nghĩ đường dẫn rườm rà và giảm sự hiểu biết của họ về cơ sở hạ tầng cơ bản phức tạp.

zkWaaS - Ví thông minh dưới dạng dịch vụ kết hợp với ZK

Về phía ví, Particle chủ yếu cung cấp SDK cho các nhà phát triển dApp dưới dạng WaaS (Smart Contract Wallet-as-a-Service), để cho phép các nhà phát triển truy cập vào khung tùy chọn hàng loạt Web3 hoàn chỉnh của nó. Giải pháp BtoBtoC này có một số lợi thế từ quan điểm kinh doanh và sinh thái:

**Sự cạnh tranh của ví C-end thuần túy đã trở nên nóng bỏng và các chức năng tương đối giống nhau và ví C-end không còn là điểm khởi đầu tốt. Mặt khác, các nhà phát triển dApp ngày càng có xu hướng xây dựng ví vào dApps để tránh mất trải nghiệm khi người dùng cần chuyển đổi ví khi kết nối ví và giao dịch, đồng thời cung cấp nhiều tính năng tùy chỉnh hơn.

** Chi phí thu hút khách hàng cao ở phía C, nhưng nó khác ở phía B. **Tăng trưởng người dùng WaaS chủ yếu được thúc đẩy bởi dApps được tích hợp với SDK. Miễn là mối quan hệ giữa BD và các nhà phát triển tốt, toàn bộ hệ sinh thái có thể được mở rộng theo phong cách “thành phố bao quanh nông thôn”.

**Hiện tại, ví C-end chủ yếu tập trung vào tài chính và tài sản, và rất khó để chúng tôi nói rằng đây là kịch bản chính của Web3 trong tương lai. Để thực sự đạt được sự chấp nhận hàng loạt của Web3, phải có các dự án trừu tượng hóa các tính năng cơ bản hơn - danh tính người dùng (tài khoản) và hoạt động của người dùng (gửi giao dịch / giao dịch) như một dịch vụ cấp thấp và bàn giao các kịch bản phong phú hơn của lớp trên cho dApp.

Từ lối vào kết nối dApp trước đó, bạn có thể quan sát mối quan hệ ràng buộc chặt chẽ giữa ví và dApp. ** Điều rất quan trọng là tăng thị phần của ví càng nhiều càng tốt về phía dApp. Đây là ưu tiên hàng đầu cho mô hình B2B2C. **

Xây dựng một WaaS đáp ứng nhu cầu của người dùng, giảm rào cản gia nhập và dễ dàng cho các nhà phát triển truy cập là một trụ cột khác cho sự thành công của giải pháp. zkWaaS của hạt có ba lõi:

**1. Đăng nhập quyền riêng tư. **Sử dụng các phương thức đăng nhập Web2 truyền thống trên ví hợp đồng, chẳng hạn như đăng nhập Twitter, Google, WeChat và các phương thức xác minh OAuth khác, người dùng hoàn toàn có thể thoát khỏi xiềng xích quản lý khóa riêng và vào Web3 một cách quen thuộc và đơn giản nhất. Đồng thời, bằng chứng không có kiến thức được sử dụng để ẩn danh tính người dùng.

2. Giao dịch bảo mật. ** Thực hiện chuyển khoản riêng tư phổ quát ngang hàng thông qua cơ chế Địa chỉ ẩn thông minh và sử dụng ERC4337 Paymaster để cho phép Địa chỉ ẩn sử dụng tài sản (nhà tài trợ khí) mà không cần gas.

**3. Hoàn thành chức năng ví AA. ** Mô-đun ví của Particle tuân thủ đầy đủ các yêu cầu cơ bản của ERC-4337, bao gồm Bundler, EntryPoint, Paymaster, Tài khoản Ví thông minh và các phần quan trọng khác của quy trình làm việc ERC-4337, một cửa để đáp ứng các yêu cầu chức năng của DAPP hoặc người dùng đối với ví thông minh.

Đăng nhập quyền riêng tư ví on-chain dựa trên tài khoản web2

Giải pháp đăng nhập riêng tư của Particle sử dụng JWT (Json Web Token), có thể được sử dụng để xác thực danh tính Web2 và hoạt động ví trong hợp đồng.

JWT là một loại chứng chỉ nhận dạng do máy chủ cấp cho máy khách được sử dụng rộng rãi trong Internet truyền thống và máy khách dựa vào bằng chứng này để xác thực mỗi khi tương tác với máy chủ.

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

·" iss" (Nhà phát hành) cho biết nhà xuất bản của JWT, nghĩa là máy chủ, chẳng hạn như Google, Twitter, v.v.

·" aud" (Đối tượng) cho biết dịch vụ hoặc ứng dụng được JWT sử dụng, nếu bạn đăng nhập vào Medium bằng Twitter, thì trường này sẽ cho biết rằng JWT áp dụng cho Medium khi Twitter phát hành JWT.

·" sub" (Chủ đề) đề cập đến danh tính của người dùng chấp nhận JWT, thường được đánh dấu bằng UID.

Trong thực tế, ISS và tàu ngầm sẽ không thay đổi trong phần lớn các trường hợp, nếu không nó sẽ mang lại một mớ hỗn độn lớn của các hệ thống bên trong và các tham chiếu bên ngoài. Do đó, các tham số này có thể được hợp đồng sử dụng để xác định danh tính của người dùng, ** để người dùng hoàn toàn không cần tạo và giữ khóa riêng. **

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

Ví dụ: nếu bạn đăng nhập vào Twitter trên Medium, Medium sẽ xác minh JWT bằng khóa công khai JWK mà Google đã công khai để xác nhận rằng JWT là xác thực - rằng nó thực sự do Google cấp. JWK cũng được sử dụng để xác nhận hợp đồng của JWT.

Luồng giải pháp đăng nhập riêng tư của Particle được hiển thị trong hình sau:

Trong số đó, chúng tôi sẽ bỏ qua mạch ZK cụ thể ở đây. Chỉ liệt kê một vài điểm chính trong quy trình:

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

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

Hệ thống này cũng có thể được sử dụng để 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.

Vì đây là một chương trình xác minh hợp đồng thực sự dựa trên thông tin đăng nhập truyền thống, 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ộ của họ trong trường hợp các tình huống rất khắc nghiệt như hủy tài khoản Web2.

Giao dịch riêng tư dựa trên phương thức trao đổi khóa DH

Trước khi nói về giải pháp giao dịch riêng tư của Particle, trước tiên chúng ta hãy kiểm tra cách đạt được các giao dịch riêng tư cho ** người nhận ** trong hệ thống EVM hiện có, nghĩa là ẩn địa chỉ của người nhận.

Giả sử rằng Alice là người gửi và Bob là người nhận, và chúng ta có một số kiến thức chung:

1. Bob tạo khóa chi tiêu gốc m và địa chỉ meta tàng hình M. M có thể được tạo ra bởi m và mối quan hệ giữa hai là M = G * m, đại diện cho mối quan hệ toán học trong các hoạt động mật mã.

2. Alice có được địa chỉ meta tàng hình của Bob M theo bất kỳ cách nào.

3. Alice tạo khóa riêng tạm thời r và sử dụng generate_address thuật toán (r, M) để tạo địa chỉ ẩn A. **Địa chỉ này là địa chỉ ẩn **** độc quyền của Bob và Bob có quyền kiểm soát địa chỉ sau khi nhận được tài sản. **

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

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

6. Bob quét từng bản ghi được cập nhật và thực hiện generate_address (R, m) để tính toán địa chỉ được biên tập. Nếu có một tài sản trong địa chỉ, nó được tạo bởi Alice và được ủy quyền kiểm soát bởi Bob, nếu không nó không liên quan gì đến Bob.

7. Bob thực thi generate_spending_key (R, m) để tạo khóa riêng của người tiêu dùng cho địa chỉ ẩn, tức là p = m + băm (A), sau đó có thể kiểm soát địa chỉ A do Alice tạo.

Mô tả quy trình trên thực sự đơn giản hóa rất nhiều phép toán phức tạp, ** Toàn bộ quá trình trao đổi thông tin tình báo giống như hai gián điệp viết ra một số từ mã chỉ có thể được giải mã bởi nhau trên bảng thông báo công khai, ** Mặc dù các phương pháp tạo và giải mã các từ mã là công khai, chỉ có hai gián điệp biết dữ liệu quan trọng cần thiết ở giữa, vì vậy ngay cả khi thế giới bên ngoài biết các phương pháp tạo và giải mã các từ mã, chúng vẫn không thể được giải mã trơn tru.

Quá trình trao đổi này giống như phương pháp trao đổi khóa Diffie-Hellman nổi tiếng, trong đó cả hai bên có thể tính toán bí mật được chia sẻ - Địa chỉ ẩn A ở trên - mà không tiết lộ bí mật tương ứng của họ (khóa riêng của người tiêu dùng gốc của Bob m và khóa riêng tạm thời của Alice r). **Nếu bạn không biết về trao đổi DH, bạn có thể sử dụng sơ đồ nhuộm màu sau đây để hiểu nó một cách ẩn dụ.

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

Rõ ràng, với phương thức chuyển khoản riêng tư này, mỗi khi người nhận nhận được một giao dịch mới, tiền cho giao dịch đó sẽ chảy vào một địa chỉ EOA hoàn toàn mới. Người nhận có thể sử dụng khóa riêng tiêu thụ root để tính toán khóa riêng tiêu thụ của từng địa chỉ riêng biệt để xem địa chỉ nào thực sự liên quan đến mình.

Nhưng bây giờ có một vấn đề khác, địa chỉ ẩn mới được tạo này vẫn là tài khoản EOA lúc đầu, có thể không có mã thông báo gas như ETH trên đó, Bob không có cách nào để trực tiếp bắt đầu giao dịch, ** cần sử dụng chức năng Paymaster của ví hợp đồng thông minh để thanh toán gas, để đạt được các giao dịch riêng tư. **Do đó, cần thực hiện một số thay đổi đối với địa chỉ nhận:

Tính toán địa chỉ phản thực tế bằng phương pháp tính địa chỉ trong phương pháp CREATE2 khi hợp đồng được triển khai, với các tham số tương ứng (đặt địa chỉ ẩn A làm chủ sở hữu của hợp đồng, v.v.). Đây là một địa chỉ hợp đồng được tính toán, nhưng hợp đồng vẫn chưa được triển khai, và nó vẫn là EOA cho thời điểm hiện tại.

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

Chúng ta có thể gọi địa chỉ Phản thực tế ở trên là địa chỉ tàng hình thông minh. Bob sử dụng quy trình sau để sử dụng ẩn danh nội dung theo địa chỉ Smart Cloak:

Nạp tiền Paymaster thông qua bất kỳ địa chỉ nào của riêng bạn và Paymaster sẽ trả lại bằng chứng tiền (ZK).

Với cơ chế AA, gửi một UserOperation đến nút Bundler với bất kỳ địa chỉ nào khác (có thể không có số dư) để gọi các tài sản theo địa chỉ ẩn ở trên. Bob chỉ cần cung cấp bằng chứng về tiền cho Paymaster với một địa chỉ mới và Paymaster thanh toán cho giao dịch đóng gói Bundler.

Điều này thực sự tương tự như cách Tornado Cash hoạt động, thông qua bằng chứng quỹ (ZK), có thể chứng minh rằng có một khoản nạp tiền trong tập hợp các nút lá trên cây Merkle và không ai có thể biết nút lá nào đã được tiêu thụ khi nó được chi tiêu, để cắt đứt kết nối giữa người tiêu dùng và người gửi tiền.

Tóm lại, Particle kết hợp AA và địa chỉ ẩn, và khéo léo thực hiện chuyển khoản riêng tư dưới dạng ví ẩn thông minh.

Chuỗi hạt &; Trừu tượng hóa tài khoản chuỗi đầy đủ

Particle Chain là một chuỗi POS được thiết kế để trừu tượng hóa tài khoản Omnichain. Tập trung vào tình hình hiện tại và tương lai, không thể trở thành một thế giới chuỗi đơn và điều quan trọng là phải cải thiện trải nghiệm người dùng trong môi trường làm việc đa chuỗi.

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

Địa chỉ của cùng một người dùng trong 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.

Người dùng cần lặp lại thủ công các thao tác quản lý giữa nhiều chuỗi để quản lý ví hợp đồng trên các chuỗi khác nhau, chẳng hạn như thay đổi quản trị viên. Tệ hơn nữa, nếu đặc quyền quản trị viên được cập nhật trên một chuỗi và sau đó phương thức xác thực quản trị viên cũ bị loại bỏ, ví không thể thay đổi trên các chuỗi khác.

Để sử dụng các chuỗi khác nhau, bạn cần có tiền gas trong mỗi chuỗi hoặc có tiền gửi trước trong Paymaster trên mỗi chuỗi. Ngoài ra còn có một số rắc rối nhất định cho các nhà phát triển, nếu họ muốn người dùng sử dụng hoặc triển khai các chức năng khác với chi phí bằng không trong một số điều kiện nhất định, họ cũng cần triển khai Paymaster tùy chỉnh của riêng mình trên mỗi chuỗi và gửi tiền vào đó.

** Trừu tượng hóa tài khoản chuỗi đầy đủ của Particle Chain giải quyết các điểm đau trên: **

Xây dựng ví AA trên Particle Chain.

Thông qua giao thức chuỗi chéo AMB (Arbitrary Message Bridge) như LayerZero, các hoạt động khác nhau, chẳng hạn như tạo mới, nâng cấp, thay đổi quyền, v.v., được đồng bộ hóa với các chuỗi khác. **Có thể hiểu rằng các ví khác trên chuỗi là tham chiếu đến các ví trên chuỗi và chỉ cần sửa đổi phần thân chính để được đồng bộ hóa với tất cả các ví.

**Hợp đồng Deployer với các thông số nhất quán để đảm bảo rằng địa chỉ ví trên mỗi chuỗi giống nhau. **

Ví giữa các chuỗi cũng có thể gọi cho nhau thông qua AMB, không phải tất cả đều được bắt đầu từ Particle Chain.

** Phát hành Unified Gas Token, một đồng tiền gas toàn chuỗi. **ERC20 được thực hiện bởi cơ chế Paymaster như một khoản phí gas. Ngay cả khi không có gas hoặc Paymaster tiền gửi trước trên một chuỗi nhất định, bạn có thể bắt đầu giao dịch chuỗi chéo trên một chuỗi đủ điều kiện để sử dụng Mã thông báo khí hợp nhất.

Ngoài những công dụng trên, Particle Chain còn có thể được sử dụng trong tương lai:

Một mạng lưới phi tập trung được tạo ra bởi zkWaaS’s Proof and Salt.

Lớp khuyến khích của mỗi chuỗi Bundler giúp Bundler đạt được sự phân quyền tốt hơn.

Mạng Solver như một Intent Fusion Protocol.

Trong câu chuyện của Particle Chain, Unified Gas Token là giá trị cốt lõi nắm bắt của toàn bộ hệ sinh thái:

Chức năng thanh toán phí gas là một logic nắm bắt nhu cầu và giá trị mạnh mẽ đã được xác minh nhiều lần trong tiền điện tử.

Unified Gas Token trừu tượng hóa khái niệm về lớp khí từ hệ sinh thái chuỗi công cộng hiện có và sự trừu tượng này không thể đạt được nếu không có Particle Chain và ví, vì vậy Unified Gas Token là một sự rút giá trị của toàn bộ hệ sinh thái của Hạt. Với lớp gas, sự tương tác và tăng trưởng của người dùng của từng chuỗi và giá trị của đồng nội tệ cùng có lợi và cộng sinh với Unified Gas Token.

Khí thống nhất cũng là một trong những yếu tố thúc đẩy việc hiện thực hóa Chainless. Đối với người dùng, thanh toán bằng một loại tiền tệ duy nhất giúp đơn giản hóa cao quy trình và hiểu chi phí. Trong tương lai, ngay cả trong kịch bản đa chuỗi, người dùng có thể sẽ không nhạy cảm và không cần quan tâm đến hoạt động của cơ sở hạ tầng cơ bản. Cũng giống như hiện tại trong Web2, chúng tôi không quan tâm phòng máy tính nằm ở khu vực nào, cấu hình nào, ngôn ngữ nào được sử dụng và cơ sở dữ liệu nào hoạt động.

Người dùng được nhập bởi dApp trực tiếp trao quyền cho Unified Gas Token và các kịch bản sử dụng rất phong phú.

Giao thức Intent Fusion

** Thông thường, chúng ta cần liên tục suy nghĩ về đường dẫn sử dụng khi sử dụng các dApp khác nhau: **

Nếu không có thanh khoản trên một DEX, bạn cần xem xét một DEX khác.

Tôi không biết dApp nào cùng loại nên chọn để hoàn thành giao dịch hoặc giao dịch tốt hơn.

· Phê duyệt sau đó có rất nhiều tính năng để sử dụng, và những gì được phê duyệt?

Ví phủi, nhiều mã thông báo nhỏ thành một loại tiền tệ nhất định, quá trình này rất rườm rà.

Để đạt được mục tiêu cuối cùng, phải mất nhiều ứng dụng. Chẳng hạn như cho vay đòn bẩy cao: hoán đổi, cầm cố, vay, nhận Token rồi hoán đổi, cầm cố, vay…

Trên đây chỉ là phần nổi của tảng băng trôi trong thế giới DeFi hiện tại của chúng ta và trong thời đại áp dụng hàng loạt Web3, nơi dApps đang trở nên đa dạng hơn, các tương tác có thể phức tạp hơn nhiều so với bạn nghĩ.

Do đó, việc thay thế các bước vận hành cụ thể bằng ý định có thể rất khác nhau đối với trải nghiệm người dùng. Ý định không chỉ là hoạt động, giống như lập trình khai báo là lập trình hàm. Các câu lệnh khai báo có xu hướng cảm thấy đơn giản và dễ hiểu, chỉ cần khai báo những gì tôi sẽ làm và không quan tâm đến các chi tiết, và điều này đòi hỏi một loạt các câu lệnh lập trình chức năng được gói gọn ở phía dưới.

Sau đó, việc sử dụng Ý định cũng không ngoại lệ, và nó cũng cần được hỗ trợ bởi một loạt các cơ sở. Chúng ta hãy xem xét toàn bộ quá trình:

**1. Người dùng gửi đến mạng Bộ giải dưới dạng RFS (Yêu cầu Bộ giải), chẳng hạn như ngôn ngữ tự nhiên. ** Bộ giải là một trình thông dịch ý định và có những trình tổng hợp như 1inch có thể tìm thấy dex tốt nhất cho người dùng, nhưng chúng không đủ chung chung và đủ mạnh so với tầm nhìn của chúng tôi.

**2. Nhiều Bộ giải trả lời lẫn nhau và họ đang cạnh tranh. Những phản hồi này được viết bằng ngôn ngữ Intent DSL và được khách hàng phân tích cú pháp thành một dạng dễ hiểu cho người dùng. Các 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 giữa đầu vào và đầu ra. Người dùng cũng có thể chỉ định các ràng buộc của riêng họ. Một ví dụ đơn giản để hiểu: khi sử dụng Hoán đổi, người dùng sẽ được nhắc đến số tiền tối thiểu có thể nhận được sau khi hoán đổi, đây là một ràng buộc. Người dùng tự chọn trong số các phản hồi của nhiều Bộ giải.

3. Ký Ý định.

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

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

Chúng ta có thể nghĩ đến quy trình này khi bạn nói với ChatGPT về các yêu cầu, dù yêu cầu phức tạp đến đâu, anh ấy cũng có thể tạo ra 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 trực tiếp mà không cần quan tâm đến quy trình.

Tóm tắt

Particle Network đề xuất một giải pháp toàn diện: thông qua bộ ba zkWaaS, Particle Chain và Intent Fusion Protocol, đăng nhập quyền riêng tư Web2 OAuth, giao dịch riêng tư, trừu tượng hóa tài khoản toàn chuỗi và mô hình giao dịch ý định được thực hiện. Mỗi tính năng sẽ bao gồm một số điểm đau của việc sử dụng Web3 và những tiến bộ và tối ưu hóa này sẽ trở thành nền tảng sản phẩm và công nghệ cho việc áp dụng hàng loạt Web3 trong tương lai. Về mặt sinh thái và mô hình kinh doanh, mô hình B2B2C được áp dụng, WaaS được sử dụng làm lối vào để thúc đẩy tiêu chuẩn hóa quy mô lớn của toàn bộ chuỗi sản phẩm và hệ sinh thái được xây dựng với các nhà phát triển dApp để cùng nhau tạo ra một thế giới Web3 với ngưỡng thấp và trải nghiệm cao 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 hàng loạt Web3. Ngoài việc xem xét các dự án cụ thể, chúng tôi hy vọng sẽ dẫn đến sự hiểu biết về ma sát trên bo mạch mà Web3 hiện đang phải đối mặt, phản ánh nhu cầu và điểm đau của người dùng và xem xét kết nối và phát triển chung của toàn bộ hệ sinh thái.