Giải mã công nghệ: Lớp truy cập Access Layer of Open Web do Particle Network xây dựng
Tuyển chọn TechFlowTuyển chọn TechFlow
Giải mã công nghệ: Lớp truy cập Access Layer of Open Web do Particle Network xây dựng
Lấy Particle Network làm ví dụ, phân tích chi tiết các vấn đề về trải nghiệm hiện tại của sản phẩm Web3 và cách thiết kế một giải pháp kỹ thuật tổng hợp có tính định hướng.
Chuyên sâu báo cáo Web3Tác giả: Sương Tháng Mười Một, Geeker Web3
Lời mở đầu: Mặc dù ví AA đã giảm đáng kể ngưỡng sử dụng cho người dùng, ban đầu đạt được việc thanh toán phí gas thay và đăng nhập tài khoản kiểu Web2, nhưng các thiết kế liên quan đến mass adoption như đăng nhập riêng tư – giao dịch riêng tư, tài khoản AA thống nhất trên mọi chuỗi, kiến trúc chuyên dụng Intent vẫn cần tiếp tục được xây dựng thêm nền tảng từ ví AA.
Chúng ta có thể thấy nhiều giải pháp tối ưu trải nghiệm người dùng (UX), như ví MPC ZenGo hay ví hợp đồng thông minh Argent, hiệu quả trong việc hạ thấp ngưỡng sử dụng. Tuy nhiên, những giải pháp này chỉ giải quyết một phần vấn đề nêu trên, mà chưa bao quát toàn diện các khía cạnh dễ dùng của sản phẩm.
Rõ ràng, hiện tại đa số ví AA hoặc các sản phẩm tương tự vẫn chưa đủ để hỗ trợ việc áp dụng Web3 quy mô lớn. Mặt khác, xét về góc độ hệ sinh thái, phía nhà phát triển là một khía cạnh rất quan trọng. Chỉ thu hút người dùng phổ thông ở cấp độ sản phẩm nhưng thiếu ảnh hưởng tới nhà phát triển thì khó tạo thành quy mô. Việc ngày càng xuất hiện nhiều giải pháp tối ưu trải nghiệm phát triển cũng cho thấy 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ụ để phân tích kỹ lưỡng các vấn đề trải nghiệm hiện tại của sản phẩm Web3, cũng như cách thức thiết kế một bộ giải pháp công nghệ tổng hợp nhắm vào từng điểm cụ thể — và chính giải pháp tổng hợp như vậy có lẽ lại là điều kiện cần thiết cho mass adoption. Đồng thời, chiến lược kinh doanh BtoBtoC của Particle cũng chính là tư duy mà nhiều bên phát triển dự án cần học hỏi.
Phân tích toàn diện cấu trúc sản phẩm Particle
Particle Network tập trung vào giải quyết ngưỡng sử dụng cao, theo hướng tiếp cận xây dựng sản phẩm và phát triển hệ sinh thái B2B2C, đưa ra một bộ giải pháp hoàn chỉnh nhằm thúc đẩy việc áp dụng Web3 rộng rãi. Ba mô-đun cốt lõi của nó gồm:
zkWaaS — Dịch vụ Ví như Dịch vụ (Wallet-as-a-service) dựa trên bằng chứng không kiến thức (zero-knowledge proof). 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 họ thông qua SDK do Particle cung cấp. Ví này là loại ví hợp đồng thông minh không khóa (keyless) dựa trên Trừu tượng Tài khoản (Account Abstraction - AA), không chỉ thực hiện được các trường hợp cơ bản như thanh toán phí gas thay mà còn cung cấp phương thức đăng nhập riêng tư kiểu OAuth Web2 và chức năng giao dịch ẩn danh.
Particle Chain — Giải pháp Trừu tượng Tài khoản Toàn chuỗi (Omnichain Account Abstraction), nhằm giải quyết các vấn đề về triển khai, bảo trì và gọi ví hợp đồng thông minh xuyên chuỗi. Kèm theo đó là Token Gas Thống nhất (Unified Gas Token), giúp xử lý rắc rối khi phải dùng nhiều loại tiền gas khác nhau trên các chuỗi khác nhau khi giao dịch đa chuỗi.
Intent Fusion Protocol — Bao gồm ngôn ngữ DSL (Ngôn ngữ chuyên biệt) đơn giản, khuôn khổ Intent, mạng lưới Solver Intent, v.v., nhằm xây dựng một khuôn khổ tương tác Web3 dựa trên ý định (intent). Người dùng trực tiếp khai báo mục đích giao dịch thay vì thực hiện từng thao tác cụ thể, giúp thoát khỏi suy nghĩ phức tạp về lộ trình và giảm thiểu hiểu biết về cơ sở hạ tầng底层 phức tạp.
zkWaaS — Ví thông minh như dịch vụ kết hợp ZK
Về phía ví, Particle chủ yếu cung cấp SDK dưới dạng WaaS (Wallet-as-a-Service) cho các nhà phát triển dApp, với mong muốn giúp họ tích hợp vào toàn bộ khuôn khổ mass adoption Web3 hoàn chỉnh của Particle. Mô hình BtoBtoC này có một vài lợi thế rõ rệt cả về mặt thương mại lẫn hệ sinh thái:
Cạnh tranh giữa các ví dành cho người dùng cuối (C-end) đã trở nên khốc liệt, chức năng cũng khá giống nhau, nên ví C-end không còn là điểm khởi đầu tốt nữa. Mặt khác, các nhà phát triển dApp ngày càng có xu hướng tích hợp ví bên trong dApp để tránh trải nghiệm gián đoạn do người dùng phải kết nối ví, chuyển đổi giữa các ví khi giao dịch, đồng thời mở rộng khả năng tùy biến chức năng.
Chi phí thu hút khách hàng C-end rất cao, nhưng với phía B-end thì lại khác. Sự tăng trưởng người dùng của WaaS chủ yếu đến từ các dApp đã tích hợp SDK. Miễn là xây dựng tốt quan hệ kinh doanh (BD) và hỗ trợ nhà phát triển, có thể mở rộng hệ sinh thái theo kiểu "từ thành thị bao vây nông thôn".
Ví C-end hiện nay chủ yếu tập trung vào tài chính và tài sản, nhưng chúng ta khó có thể nói đây sẽ là cảnh ứng dụng chính của Web3 trong tương lai. Để thực sự đạt được việc áp dụng Web3 quy mô lớn, cần có dự án nào đó tách rời các đặc tính cơ bản hơn — danh tính người dùng (tài khoản) và hành động người dùng (gửi giao dịch), và trừu tượng hóa chúng thành một dịch vụ nền tảng, để các lớp trên có thể phát triển phong phú hơn nhờ dApp.
Từ cổng kết nối dApp trước đây, ta có thể thấy mối quan hệ gắn bó chặt chẽ giữa ví và dApp. Tăng thị phần ví tại phía dApp là cực kỳ quan trọng. Điều này mang lợi thế gần nước thuận tiện cho mô hình B2B2C.
Xây dựng một WaaS đáp ứng nhu cầu người dùng, giảm ngưỡng sử dụng và dễ tích hợp cho nhà phát triển là trụ cột thứ hai cho thành công của giải pháp. zkWaaS của Particle có ba điểm cốt lõi:
1. Đăng nhập riêng tư. Sử dụng phương thức đăng nhập Web2 truyền thống như Twitter, Google, WeChat... (xác thực OAuth) trên ví hợp đồng thông minh, giúp người dùng hoàn toàn thoát khỏi gánh nặng quản lý khóa riêng, bước vào Web3 theo cách quen thuộc và đơn giản nhất. Đồng thời sử dụng bằng chứng không kiến thức (ZK) để ẩn danh danh tính người dùng.
2. Giao dịch riêng tư. Thông qua cơ chế địa chỉ ẩn thông minh (Smart Stealth Address), thực hiện chuyển tiền ẩn danh điểm-điểm chung, và sử dụng Paymaster theo ERC4337 để địa chỉ ẩn có thể dùng tài sản miễn phí gas (nhờ nhà tài trợ gas).
3. Đầy đủ chức năng ví AA. Mô-đun ví của Particle hoàn toàn tuân thủ yêu cầu cơ bản của ERC-4337, bao gồm Bundler, EntryPoint, Paymaster, Smart Wallet Account — tất cả các thành phần quan trọng trong luồng công việc ERC-4337 — để đáp ứng trọn vẹn nhu cầu chức năng ví thông minh cho dApp hoặc người dùng.
Đăng nhập riêng tư trên ví blockchain 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), cho phép xác thực danh tính Web2 và thao tác ví bên trong hợp đồng.
JWT là một dạng bằng chứng danh tính do máy chủ cấp cho phía client, được sử dụng rộng rãi trong Internet truyền thống, client dùng bằng chứng này để xác thực danh tính mỗi lần tương tác với server.
(Nguồn ảnh: FlutterFlow Docs)
JWT có một vài trường quan trọng làm cơ sở để hợp đồng xác minh danh tính:
-
「iss」(Issuer): Xác định tổ chức phát hành JWT, tức máy chủ, ví dụ Google, Twitter, v.v.
-
「aud」(Audience): Xác định dịch vụ hoặc ứng dụng mà JWT này dùng cho, ví dụ khi đăng nhập Medium bằng Twitter, Twitter sẽ ghi rõ trong trường này rằng JWT này dành cho Medium.
-
「sub」(Subject): Là danh tính người nhận JWT, thường biểu thị bằng UID.
Trong thực tế, iss và sub hầu như không thay đổi, nếu không sẽ gây ra sự hỗn loạn lớn trong hệ thống nội bộ và các tham chiếu bên ngoài. Vì vậy, các tham số trên có thể dùng để hợp đồng xác định danh tính người dùng, người dùng hoàn toàn không cần tạo hay lưu trữ khóa riêng.
Khái niệm tương ứng với JWT là JWK (JSON Web Key), là một cặp khóa do máy chủ sở hữu. Khi phát hành JWT, máy chủ dùng khóa riêng của JWK để ký, còn khóa công khai thì công khai để các dịch vụ khác xác minh chữ ký.
Ví dụ, khi Medium dùng Twitter để đăng nhập, Medium sẽ dùng khóa công khai JWK công khai của Twitter để xác minh JWT, đảm bảo JWT đúng là do Twitter phát hành. Hợp đồng cũng dùng JWK để kiểm tra JWT.
Quy trình giải pháp đăng nhập riêng tư của Particle như sau:
Ở đây chúng ta tạm bỏ qua chi tiết mạch ZK cụ thể. Chỉ liệt kê một số điểm chính trong quy trình:
-
Hợp đồng Verifier xác minh thông tin đăng nhập chỉ nhận biết được một ZK Proof liên quan đến danh tính người dùng - JWT và một eph_pk vô hại, không thể biết trực tiếp khóa công khai ví hay thông tin JWT tương ứng, từ đó bảo vệ quyền riêng tư người dùng — bên ngoài không thể biết danh tính người đăng nhập từ dữ liệu trên chuỗi.
-
eph_pk (khóa tạm thời) là một cặp khóa dùng trong một phiên duy nhất, không phải khóa công/nhân của ví, người dùng không cần quan tâm.
-
Hệ thống này cũng có thể thực hiện xác minh ngoài chuỗi, có thể dùng cho ví hợp đồng sử dụng logic MPC.
Vì đây là giải pháp xác minh hợp đồng thực sự dựa trên phương thức đăng nhập truyền thống, người dùng còn có thể chỉ định các liên hệ xã hội khác làm người giám hộ, phòng trường hợp cực đoan như tài khoản Web2 bị xóa.
Giao dịch riêng tư dựa trên phương pháp trao đổi khóa DH
Trước khi nói đến giải pháp giao dịch riêng tư của Particle, hãy cùng tìm hiểu cách thực hiện giao dịch riêng tư cho người nhận trong hệ thống EVM hiện tại, nghĩa là ẩn địa chỉ người nhận.
Giả sử Alice là người gửi, Bob là người nhận, cả hai có một số kiến thức chung:
1. Bob tạo khóa tiêu dùng gốc (root spending key) m và địa chỉ meta ẩn danh (stealth meta-address) M. M được sinh ra từ m, quan hệ giữa chúng là M = G * m, đại diện cho một quan hệ toán học trong phép toán mật mã.
2. Alice thu được địa chỉ meta ẩn danh M của Bob bằng bất kỳ cách nào.
3. Alice tạo một khóa riêng tạm thời r, rồi dùng thuật toán generate_address(r,M) để sinh ra một địa chỉ ẩn A. Địa chỉ này là địa chỉ ẩn riêng biệt dành cho Bob, sau khi nhận tài sản, Bob sẽ kiểm soát địa chỉ này.
4. Alice sau đó sinh ra một khóa công khai tạm thời R từ khóa riêng tạm thời r, và gửi R đến hợp đồng ghi nhận khóa công khai tạm thời (hoặc bất kỳ vị trí nào cả hai chấp nhận, miễn là Bob có thể truy cập được).
5. Bob cần quét định kỳ hợp đồng ghi nhận khóa công khai tạm thời, ghi lại mọi khóa công khai mới được cập nhật. Vì hợp đồng này công khai, chứa các khóa liên quan đến giao dịch riêng tư của nhiều người, Bob chưa biết khóa nào là của Alice gửi cho mình.
6. Bob quét từng bản ghi mới, thực hiện generate_address(R,m) để tính địa chỉ ẩn. Nếu địa chỉ đó có tài sản, thì đó là địa chỉ do Alice tạo và ủy quyền cho Bob kiểm soát; nếu không thì không liên quan đến Bob.
7. Bob thực hiện generate_spending_key(R,m) để sinh khóa tiêu dùng cho địa chỉ ẩn đó, tức là p = m + hash(A), sau đó có thể kiểm soát địa chỉ A do Alice tạo.
Quy trình trên thực 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 điệp viên viết những mật mã chỉ có thể giải mã bởi nhau lên bảng thông báo công cộng, mặc dù phương pháp tạo và giải mã mật mã là công khai, nhưng chỉ hai điệp viên biết dữ liệu quan trọng bên trong, nên dù bên ngoài biết phương pháp, vẫn không thể giải mã thành công.
Quy trình trao đổi này tương tự phương pháp trao đổi khóa Diffie–Hellman nổi tiếng: cả hai bên đều có thể tính ra bí mật chung — địa chỉ ẩn A ở trên — mà không tiết lộ bí mật riêng (khóa tiêu dùng gốc m của Bob và khóa riêng tạm thời r của Alice). Nếu chưa hiểu DH, có thể dùng sơ đồ màu sắc dưới đây để hình dung.
So với DH, bước bổ sung là sau khi cả hai bên tính ra bí mật chung — địa chỉ ẩn A — thì không thể dùng A làm khóa riêng vì Alice cũng biết A. Cần xây dựng khóa tiêu dùng p = m + hash(A), coi A như khóa công khai. Vì như đã nói, chỉ Bob biết khóa tiêu dùng gốc m, từ đó Bob trở thành người kiểm soát duy nhất của địa chỉ ẩn này.
Rõ ràng, trong phương thức chuyển tiền riêng tư này, mỗi lần người nhận nhận một giao dịch mới, tiền sẽ chảy vào một địa chỉ EOA hoàn toàn mới. Người nhận có thể dùng khóa tiêu dùng gốc để lần lượt tính toán khóa tiêu dùng của từng địa chỉ, xem địa chỉ nào liên quan đến mình.
Tuy nhiên, hiện tại vẫn còn một vấn đề: địa chỉ ẩn mới tạo ra lúc đầu vẫn là tài khoản EOA, có thể chưa có ETH hay token gas, Bob không thể trực tiếp phát起 giao dịch, cần dùng chức năng Paymaster của ví hợp đồng thông minh để thanh toán phí gas thay, mới thực hiện được giao dịch riêng tư. Vì vậy cần sửa đổi một chút địa chỉ nhận:
Dùng phương pháp tính địa chỉ trong lệnh CREATE2 khi triển khai hợp đồng, kèm theo các tham số tương ứng (đặt địa chỉ ẩn A làm Owner của hợp đồng, v.v.), tính một địa chỉ Counterfactual. Đây là địa chỉ hợp đồng được tính toán nhưng chưa triển khai, tạm thời vẫn là EOA.
Alice sẽ trực tiếp chuyển tiền đến địa chỉ Counterfactual này. Khi Bob muốn dùng, chỉ cần triển khai ví hợp đồng ngay trên địa chỉ đó, từ đó có thể dùng dịch vụ thanh toán phí gas thay (bước này cũng có thể do Alice hoặc mạng Particle hoàn thành trước).
Ta có thể gọi địa chỉ Counterfactual trên là địa chỉ ẩn thông minh. Bob dùng quy trình sau để dùng tài sản trong địa chỉ ẩn thông minh một cách ẩn danh:
Nạp tiền từ bất kỳ địa chỉ nào của mình vào Paymaster, Paymaster sẽ trả lại một bằng chứng nạp tiền (phiên bản ZK).
Nhờ cơ chế AA, dùng bất kỳ địa chỉ nào (có thể không có dư) gửi UserOperation đến nút Bundler, gọi tài sản trong địa chỉ ẩn trên. Bob chỉ cần dùng một địa chỉ mới cung cấp bằng chứng nạp tiền cho Paymaster, Paymaster sẽ trả phí cho Bundler gói giao dịch.
Thực ra đây là cơ chế tương tự Tornado Cash, bằng chứng nạp tiền (phiên bản ZK) vừa chứng minh từng có một lần nạp trong tập lá cây Merkle, vừa khiến khi tiêu dùng, không ai biết cụ thể lá nào bị tiêu, từ đó cắt đứt mối liên hệ giữa người tiêu và người nạp.
Tóm lại, Particle kết hợp AA và địa chỉ ẩn, khéo léo thực hiện chuyển tiền riêng tư dưới dạng ví ẩn thông minh.
Particle Chain & Trừu tượng Tài khoản Toàn chuỗi
Particle Chain là một chuỗi POS được thiết kế riêng cho Trừu tượng Tài khoản Toàn chuỗi (Omnichain Account Abstraction). Nhìn vào thực trạng và tương lai, không thể có chuyện một chuỗi độc tôn, nâng cao trải nghiệm người dùng trong môi trường đa chuỗi là điều cực kỳ quan trọng.
Hiện tại, hệ thống Trừu tượng Tài khoản ERC4337 gặp một số vấn đề khi dùng trên nhiều chuỗi:
-
Cùng một người dùng có thể có địa chỉ khác nhau trên các chuỗi khác nhau, tùy thuộc vào thiết kế hợp đồng.
-
Người dùng quản lý ví hợp đồng trên các chuỗi khác nhau cần thao tác thủ công lặp lại trên nhiều chuỗi, như thay đổi quản trị viên. Trường hợp tệ hơn, nếu cập nhật quyền quản trị viên trên một chuỗi rồi loại bỏ phương thức xác thực cũ, thì trên các chuỗi khác sẽ không thể thay đổi hay sử dụng ví.
-
Dùng chuỗi khác nhau cần sở hữu token gas của từng chuỗi, hoặc có tiền dự trữ trên Paymaster của từng chuỗi. Đối với nhà phát triển cũng khá phiền toái, nếu muốn người dùng dùng miễn phí trong điều kiện nhất định hay thực hiện chức năng khác, cũng cần triển khai Paymaster tùy chỉnh trên mọi chuỗi và dự trữ tiền trong đó.
Giải pháp Trừu tượng Tài khoản Toàn chuỗi của Particle Chain giải quyết các điểm đau trên:
-
Tạo ví AA trên Particle Chain.
-
Dùng giao thức cầu nối tin nhắn tùy ý AMB (Arbitrary Message Bridge) như LayerZero để đồng bộ các thao tác như tạo mới, nâng cấp, thay đổi quyền... sang các chuỗi khác. Có thể hiểu các ví trên các chuỗi khác là bản sao tham chiếu của ví trên chuỗi này, chỉ cần sửa đổi ví gốc là tự động đồng bộ khắp nơi.
-
Dùng Hợp đồng Triển khai (Deployer Contract) với tham số nhất quán để đảm bảo địa chỉ ví giống nhau trên mọi chuỗi.
-
Các ví trên các chuỗi cũng có thể gọi nhau qua AMB, không nhất thiết phải khởi tạo từ Particle Chain.
-
Phát hành Unified Gas Token — token gas dùng chung trên mọi chuỗi. Nhờ cơ chế Paymaster, dùng token ERC20 để trả phí gas. Ngay cả khi không có gas hay tiền dự trữ trên Paymaster tại một chuỗi, vẫn có thể khởi tạo giao dịch xuyên chuỗi tiêu dùng Unified Gas Token tại chuỗi thỏa điều kiện.
Ngoài các mục đích trên, Particle Chain trong tương lai có thể còn dùng cho:
-
Mạng lưới phi tập trung tạo Proof và Salt cho zkWaaS.
-
Lớp khuyến khích cho Bundler trên mọi chuỗi, giúp Bundler đạt mức phi tập trung tốt hơn.
-
Làm mạng lưới Solver cho Intent Fusion Protocol.
Trong câu chuyện của Particle Chain, Unified Gas Token là công cụ bắt giá trị cốt lõi của toàn hệ sinh thái:
-
Chức năng thanh toán phí gas là nhu cầu mạnh mẽ và logic bắt giá trị đã được kiểm chứng nhiều lần trong crypto.
-
Unified Gas Token tiếp tục trừu tượng hóa thêm một lớp gas từ hệ sinh thái công chuỗi sẵn có, và sự trừu tượng này không thể thực hiện nếu thiếu Particle Chain và ví, do đó Unified Gas Token là hiện thân giá trị của toàn hệ sinh thái Particle. Sau khi có lớp gas, sự tương tác và tăng trưởng người dùng trên các chuỗi, giá trị đồng nội tệ và Unified Gas Token sẽ cùng nhau phát triển.
-
Gas thống nhất cũng là yếu tố thúc đẩy Chainless. Với người dùng, dùng một loại tiền duy nhất để thanh toán làm đơn giản hóa đáng kể quy trình sử dụng và chi phí hiểu biết. Trong tương lai, ngay cả trong môi trường đa chuỗi, người dùng có thể không cảm nhận được, không cần quan tâm đến tình trạng vận hành cơ sở hạ tầng底层. Giống như hiện nay khi dùng Web2, chúng ta tương tác với máy chủ mà không cần biết trung tâm dữ liệu ở đâu, cấu hình gì, dùng ngôn ngữ hay cơ sở dữ liệu nào.
-
Người dùng do dApp dẫn vào trực tiếp làm giàu cho Unified Gas Token, kịch bản sử dụng rất phong phú.
Intent Fusion Protocol
Thông thường, khi dùng các dApp khác nhau, chúng ta phải liên tục suy nghĩ về lộ trình sử dụng:
-
Nếu một sàn DEX không có thanh khoản cho một loại nào đó, cần kiểm tra sàn DEX khác.
-
Không biết nên chọn dApp nào trong cùng nhóm để hoàn thành giao dịch/tác vụ tốt hơn.
-
Phải Approve rồi mới dùng nhiều chức năng, vậy Approve là gì?
-
Dọn bụi ví — chuyển nhiều token nhỏ thành một loại, quy trình phiền phức.
-
Cần trải qua nhiều ứng dụng để hoàn thành mục tiêu cuối. Ví dụ vay đòn bẩy cao: trước tiên swap, thế chấp, vay, token nhận được lại swap, thế chấp, vay...
Những điều trên chỉ là phần nổi của tảng băng chìm trong thế giới DeFi hiện tại, và trong kỷ nguyên áp dụng Web3 rộng rãi với dApp ngày càng đa dạng, độ phức tạp tương tác có thể vượt xa tưởng tượng.
Vì vậy, dùng Intent thay cho các bước thao tác cụ thể mang lại trải nghiệm hoàn toàn khác biệt cho người dùng. Intent so với thao tác, giống như lập trình khai báo so với lập trình hàm. Các câu lệnh khai báo thường mang cảm giác đơn giản rõ ràng — chỉ cần khai báo mình muốn làm gì mà không cần quan tâm chi tiết đằng sau, nhưng điều này đòi hỏi底层 có nhiều lớp câu lệnh lập trình hàm được đóng gói sẵn.
Việc dùng Intent cũng vậy, cần một loạt cơ sở hạ tầng hỗ trợ. Ta có thể xem xét toàn bộ quy trình:
1. Người dùng gửi mô tả ý định của mình bằng một cách nào đó, ví dụ ngôn ngữ tự nhiên, dưới dạng RFS (Request For Solver) gửi đến mạng Solver. Solver là bộ giải thích Intent, các Solver phổ biến hiện nay như 1inch (trình tổng hợp) có thể tìm DEX tối ưu cho người dùng, nhưng so với viễn cảnh của chúng ta thì chúng chưa đủ phổ quát và mạnh mẽ.
2. Nhiều Solver phản hồi, họ cạnh tranh lẫn nhau. Các phản hồi được viết bằng ngôn ngữ Intent DSL, sau đó được client phân tích thành dạng dễ hiểu cho người dùng. Các phản hồi này chứa Input Constraints và Output Constraints, xác định giới hạn đầu vào và đầu ra. Người dùng cũng có thể tự đặt ràng buộc. Một ví dụ đơn giản: khi dùng Swap, hệ thống nhắc người dùng số lượng tối thiểu nhận được sau khi hoán đổi — đây là một dạng ràng buộc. Người dùng tự chọn giữa các phản hồi từ nhiều Solver.
3. Ký vào Intent.
4. Solver chỉ định hợp đồng thực thi cụ thể (Executor) và gửi Intent đến hợp đồng phản hồi (Reactor).
5. Reactor thu thập đầu vào cần thiết (ví dụ một loại tài sản) từ tài khoản người dùng, gửi Intent đến Executor, Executor gọi các hợp đồng logic liên quan, trả kết quả giao dịch về Reactor. Reactor kiểm tra ràng buộc, nếu đúng thì trả kết quả cho người dùng.
Ta có thể hình dung quá trình này như việc bạn nói nhu cầu cho ChatGPT nghe, dù yêu cầu phức tạp đến đâu, nó cũng có thể đưa ra kết quả cuối cùng, bạn chỉ cần hài lòng với kết quả là có thể dùng luôn, không cần quan tâm quá trình thực hiện.
Tổng kết
Particle Network đưa ra một giải pháp toàn diện: thông qua sự kết hợp ba thành phần zkWaaS, Particle Chain, Intent Fusion Protocol, đạt được đăng nhập riêng tư kiểu Web2 OAuth, giao dịch riêng tư, trừu tượng tài khoản toàn chuỗi và khuôn khổ giao dịch theo Intent. Mỗi tính năng đều giải quyết một phần điểm đau khi dùng Web3, những tiến bộ và tối ưu này sẽ trở thành nền tảng sản phẩm và công nghệ cho việc áp dụng Web3 quy mô lớn trong tương lai. Về hệ sinh thái và mô hình kinh doanh, áp dụng mô hình B2B2C, dùng WaaS làm cổng vào để kéo theo chuẩn hóa và mở rộng toàn bộ chuỗi sản phẩm, cùng xây dựng hệ sinh thái với nhà phát triển dApp, chung tay tạo nên một thế giới Web3 dễ tiếp cận 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ề con đường hiện thực hóa mass adoption Web3. Ngoài việc đánh giá từng dự án cụ thể, chúng tôi hy vọng qua các giải pháp khác nhau có thể gợi mở sự thấu hiểu về ma sát onboarding hiện tại của Web3, suy ngẫm về nhu cầu và điểm đau của người dùng, cũng như cân nhắc về sự liên kết và phát triển chung của toàn bộ hệ sinh thái.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
@godrealmx
