Coinbase gần đây đã công bố một giao thức thanh toán mới: x402. Vì x402 được Coinbase khởi xướng, nên giao thức này tự nhiên hỗ trợ Base Sepolia và được mặc định sử dụng. Hơn nữa, nó đã hỗ trợ chuỗi Solana, chứng minh rằng x402 không bị ràng buộc với bất kỳ chuỗi cụ thể nào.

https://github.com/coinbase/x402

Để hiểu rõ hơn về quy trình, tôi đã tạo một kho lưu trữ mới (https://github.com/gin-lsl/x402-solana-demo) chứa tất cả các thành phần Máy chủ, Máy khách và Bộ điều phối. Ở đây, Koa được chọn làm nền tảng cơ sở để cho phép máy khách truy cập vào một giao diện cụ thể do máy chủ cung cấp bằng cách thanh toán bằng USDC của Devnet (một mã thông báo tùy chỉnh).

Một số giải thích

Đầu tiên, tôi tạo mã thông báo tương ứng bằng công cụ spl-token, bạn có thể xem tại đây: https://solscan.io/token/9gKBTRXgVTszU31A12oJKKSy6aje8LyoVvNfSimembHo?cluster=devnet

Solana được chọn vì chuỗi này rất thân thiện với nhà phát triển, cung cấp số lượng token thử nghiệm gần như không giới hạn cho mọi người phát triển và thử nghiệm. Nó không đặt ra bất kỳ rào cản nào, không yêu cầu đăng nhập, không yêu cầu liên kết bất kỳ tài khoản mạng xã hội nào và không yêu cầu ví có số dư trên mạng chính.

Nếu bạn cần chạy dự án, bạn cần tạo tệp .env, điền các biến môi trường cần thiết, sau đó khởi động máy chủ và chạy mã máy khách trong thiết bị đầu cuối:

Giải thích mã

Vì đây chỉ là mục đích trình diễn, chúng chỉ được đặt ở một vị trí. Dưới đây là một số mô tả chính về tài liệu:

solana.ts

Nó cung cấp một giao diện gọi là "/solana/get-balance", mà chúng tôi cho là một giao diện có giá trị và cần một khoản phí nhỏ để gọi. Là Máy chủ, nó tương ứng với các phần (5) đến (8) trong sơ đồ trình tự, và cụ thể hơn là phần (7).

Thông thường, máy chủ chỉ xử lý logic nghiệp vụ và không cần xử lý các giao dịch trên chuỗi. Do đó, ngay cả khi các nhà phát triển hệ thống không quen thuộc với Web3, họ vẫn có thể tích hợp các phương thức thanh toán Web3 với những thay đổi tối thiểu trong logic nghiệp vụ.

facilitator.ts

Nó triển khai các khả năng của Facilitator, chủ yếu cung cấp các giao diện /supported, /verify và /settle, được sử dụng để truy vấn các chuỗi hiện đang được hỗ trợ, xác minh dữ liệu giao dịch và cung cấp khả năng thanh toán trên chuỗi. Đây là nơi nó tương tác với chuỗi, yêu cầu khóa riêng để thanh toán phí giao dịch trên chuỗi. Về mặt kiến trúc, nó độc lập với Máy chủ (tức là solana.ts), tương ứng với (9) và (10) trong sơ đồ trình tự;

Ngay cả khi bạn quyết định tự cung cấp dịch vụ Facilitator, phần mã này thực sự đã được chuẩn hóa, và về cơ bản bạn có thể sử dụng trực tiếp mẫu chính thức mà không cần phải tự triển khai. Tuy nhiên, hiện tại hỗ trợ chính thức chỉ mới đầy đủ cho nền tảng cơ bản. Nếu bạn muốn sử dụng các chuỗi khác, cần phải thực hiện một số công việc điều chỉnh. Điều này chủ yếu bao gồm việc gửi các giao dịch mô phỏng đến chuỗi để xác minh giao dịch (nếu đó là chuỗi mà "x402" đã hỗ trợ, bạn có thể trực tiếp gọi hàm verify), và chính thức gửi các giao dịch đến chuỗi và chờ xác nhận cuối cùng (nếu đó là chuỗi mà "x402" đã hỗ trợ, bạn có thể trực tiếp gọi hàm settlement).

Đối với chuỗi Solana, sau khi yêu cầu đến POST /settle, hàm settle trong "x402/facilitator" sẽ được gọi. Sau khi xác minh, sendTransaction trên RPC được gọi để gửi giao dịch, và sau đó waitForRecentTransactionConfirmation được sử dụng để chờ và xác nhận kết quả giao dịch. Mã liên quan được cung cấp bởi @solana/kit. Phần EVM tuân theo logic tương tự.

x402-middleware.ts

Được sử dụng để kết nối Máy chủ và Facilitator, nó hoạt động như một phần mềm trung gian Koa, bảo vệ các API yêu cầu thanh toán để truy cập. Mã này tham chiếu đến mã nguồn chính thức "x402-express". Chức năng của nó là tự động trả về trạng thái 402 và chuyển tiếp các yêu cầu /verify và /settle.

Mã của tôi trong phần này về cơ bản chỉ tập hợp các tham số khác nhau và chuyển tiếp chúng đến bộ điều phối hoặc trả về cho máy khách. Để dễ kiểm tra và tránh đi sâu vào chi tiết, tôi đã viết hầu hết các tham số dưới dạng giá trị cố định. Bao gồm:

• Việc đặt maxAmountRequired thành một giá trị rất lớn sẽ thực sự được xác thực ở phía máy khách. Nếu số tiền người dùng cần thanh toán cao hơn giá trị này, một ngoại lệ sẽ được ném trực tiếp.
• Tài sản được đặt thành mã thông báo do chúng tôi tự tạo: 9gKBTRXgVTszU31A12oJKKSy6aje8LyoVvNfSimembHo, thay vì địa chỉ mã thông báo được tích hợp sẵn trong x402. Trên mạng chính, đây sẽ là địa chỉ USDC chính thức.

Điều thú vị là x402-express triển khai mô hình onion giống Koa bằng cách viết lại các hàm trên Response. Do đó, trong middleware của họ dành cho Express, luồng thực tế là verify -> business logic -> settlement. Việc gửi lên blockchain diễn ra sau khi thực thi business logic, khớp với sơ đồ trình tự ở trên. Việc triển khai logic này rất đơn giản trong Koa, nhưng cần thêm một số mã trong Express, đó có thể là lý do tại sao họ ưu tiên cung cấp middleware Express.

thanh toán-khách hàng-fetch.ts

Hoạt động như một máy khách, nó khởi tạo các yêu cầu đến máy chủ, tương ứng với các bước từ 1 đến 4 trong sơ đồ. Quá trình này sử dụng các hàm hỗ trợ do "x402-fetch" cung cấp để tự động xử lý trạng thái 402, tạo chữ ký bằng khóa riêng của ví máy khách và gửi lại dữ liệu.

Nó sẽ cố gắng yêu cầu trực tiếp giao diện. Khi gặp lỗi 402, nó sẽ đọc nội dung trả về (nội dung này phải chứa phiên bản x402 được máy chủ hỗ trợ, hiện được cố định ở mức 1, và các tham số cần thiết cho máy chủ), ký giao dịch bằng khóa riêng của bạn, sau đó tuần tự hóa thông tin giao dịch và gửi lại đến URL gốc thông qua Tiêu đề X-PAYMENT.

Sau khi hiểu được cấu trúc cơ bản của dự án, chúng ta có thể chạy Máy chủ và Máy khách bằng các lệnh sau:

Kết quả thực hiện và nhật ký của khách hàng:

nghĩ

Theo tôi, nếu những nỗ lực trước đây của các nhà phát triển Web3 nhằm mục đích giảm bớt rào cản gia nhập để người dùng thông thường sử dụng Web3, giúp người dùng cuối dễ dàng sử dụng hệ sinh thái Web3 hơn (thanh toán, đầu tư, v.v.), thì x402 hiện tại được tạo ra để giảm bớt rào cản gia nhập để các nhà phát triển Web2 có thể tiếp cận các kênh thanh toán Web3.

Mặc dù các chức năng hỗ trợ được cung cấp trong mục x402/client rất hữu ích, nhưng chúng chỉ thực hiện đúng chức năng của mình. Người dùng hiện đã có thể dễ dàng thanh toán bằng USDC và các loại tiền tệ khác thông qua ví của mình. Do đó, xét về mặt tương đối, x402 có lẽ quan trọng hơn đối với các nhà phát triển và nhà cung cấp dịch vụ.

Tuy nhiên, việc áp dụng rộng rãi x402 vẫn sẽ gặp phải nhiều vấn đề. Các công ty lớn có hệ thống thanh toán nội bộ riêng, và họ sẽ có thái độ và tốc độ riêng về cách tích hợp các tiêu chuẩn mới. Việc tích hợp một phương thức thanh toán mới vào hệ thống hiện có chắc chắn sẽ là một quá trình dài và gian nan. Hơn nữa, các công ty lớn sẽ phải cân nhắc các tác động pháp lý khi tích hợp các phương thức thanh toán, điều này có thể buộc họ phải từ bỏ các phương thức thanh toán tiện lợi hơn và tiếp tục sử dụng các giải pháp truyền thống, phức tạp.

Có lẽ các nhà cung cấp Node RPC sẽ thích điều này hơn. Ngoài việc cung cấp các giao diện cơ bản, các nhà cung cấp RPC còn cung cấp nhiều API nâng cao, giao diện tăng tốc giao dịch, v.v. Nếu những thứ này có thể được cung cấp thông qua x402, có lẽ nhiều người sẽ có thể trải nghiệm dịch vụ của họ hơn.

Cuối cùng, xin lưu ý rằng bản thân x420 chỉ là một giao thức thanh toán cơ bản. Tầm quan trọng của nó nằm ở việc đề xuất một bộ thông số kỹ thuật được chuẩn hóa. Với một tiêu chuẩn được công nhận, các nhà phát triển và công ty ở mọi quy mô sẽ dễ dàng hợp tác để cải thiện toàn bộ hệ sinh thái. Chúng ta nên xem xét việc đề xuất các tiêu chuẩn mới một cách lý trí và tránh rơi vào những cái bẫy câu chuyện do những kẻ thổi phồng đặt ra.

Bài viết này được viết bởi ZAN Team (tài khoản X @zan_team ).