Sau một năm thử nghiệm tại hiện trường, API3 đang ra mắt một loạt bản cập nhật cho Airnode RRP (giao thức yêu cầu-phản hồi), sẽ cải thiện đáng kể trên phiên bản pre-alpha.
Thuật ngữ
API3 muốn Airnode trở thành công cụ mặc định để tích hợp API vào hợp đồng thông minh và API3 cần sự chấp nhận mạnh mẽ của nhà phát triển cho việc này. Bước đầu tiên của việc áp dụng một công cụ là hiểu nó và cần có một thuật ngữ tối thiểu và rõ ràng để tạo điều kiện thuận lợi. Phiên bản tiền alpha đã tích lũy một số vấn đề sẽ được xử lý trong bản cập nhật này bằng cách đổi tên các khái niệm bên dưới.
Khách hàng -> Người yêu cầu
Trong giai đoạn tiền alpha, hợp đồng (hoặc ít khả năng hơn là EOA) thực hiện yêu cầu (makeRequest ()) được gọi là khách hàng. Đây là một điểm nhầm lẫn vì:
- Tại sao thực thể đưa ra yêu cầu lại không được gọi là người yêu cầu, mà lại là gọi bằng tên khác (xem bên dưới)?
- Khách hàng có thể chỉ định một địa chỉ khác để được gọi lại trong yêu cầu của họ. Sau đó, tên trở thành câu hỏi về mặt ngữ nghĩa. (Khách hàng là ai, người đưa ra yêu cầu hay người được gọi lại với phản hồi?)
Giải pháp rất đơn giản: Gọi hợp đồng đưa ra yêu cầu là người yêu cầu.
Người yêu cầu -> Nhà tài trợ
Trong giai đoạn tiền alpha, pháp nhân thanh toán chi phí gas thực hiện yêu cầu của khách hàng được gọi là người yêu cầu. Một lần nữa, có hai vấn đề:
- Người yêu cầu đã không thực sự đưa ra yêu cầu. Vai trò của họ chỉ là tài trợ cho các yêu cầu của khách hàng.
- Thuật ngữ người yêu cầu hiện được sử dụng để chỉ các khách hàng (xem ở trên), vì vậy API3 không còn có thể sử dụng nó nữa.
Kết quả là, API3 đã chọn một cái tên mô tả nhiều hơn về những gì người yêu cầu làm, đó là nhà tài trợ.
Ví được chỉ định -> Ví tài trợ
Ví được chỉ định trong giai đoạn tiền alpha là ví mà Airnode đã chỉ định cho người yêu cầu để cung cấp chi phí cho các yêu cầu của khách hàng. Điều này đề cập đến phiên bản pre-pre-alpha của giao thức trong đó Airnode phải chủ động chỉ định các ví này bằng cách thực hiện giao dịch cho mỗi ví. Tên hiện tại gây khá nhiều hiểu lầm. Thay vào đó, API3 đã sử dụng ví nhà tài trợ, tương ứng với chức năng của nó.
Xác nhận -> Tài trợ
Trong giai đoạn tiền alpha, người yêu cầu xác nhận một khách hàng, có nghĩa là cho phép nó sử dụng ví được chỉ định của họ. Tương tự như “ví được chỉ định”, đây chỉ là một biệt ngữ được tạo ra và có thể gây hiểu lầm với mọi người. Thay vào đó, bây giờ chỉ đơn giản nói rằng nhà tài trợ tài trợ cho người yêu cầu, có nghĩa là cho phép người đó sử dụng ví tài trợ của họ.
Yêu cầu thông thường -> Yêu cầu mẫu
Trong giai đoạn tiền alpha, một yêu cầu thông thường (hay gọi tắt là yêu cầu) là một yêu cầu trong đó khách hàng đề cập đến một mẫu yêu cầu cho các tham số. Điều này bây giờ được gọi là một yêu cầu mẫu cho rõ ràng.
Cập nhật chức năng
API3 giảm bớt sự xung đột trong cách thức hoạt động của giao thức, chủ yếu bằng cách giảm số lượng giao dịch mà cả hai bên cần thực hiện.
Airnodes được xác định bằng địa chỉ của ví BIP 44 mặc định
Trong giai đoạn tiền alpha, airnodeId xác định một Airnode là hash của địa chỉ ví chính của nó (có nguồn gốc từ đường dẫn m). Hiện tại, API3 sử dụng địa chỉ của ví BIP 44 mặc định (có nguồn gốc từ đường dẫn m / 44 ‘/ 60’ / 0 ‘/ 0/0), được gọi là địa chỉ Airnode. Điều này có nghĩa là khi bạn cắm bộ nhớ mà bạn sử dụng để triển khai Airnode của mình, địa chỉ sẽ hiện lên trên Metamask là địa chỉ Airnode của bạn.
Khóa công khai mở rộng Airnode thuộc về một đường dẫn mới
Trong giai đoạn tiền alpha, nhà khai thác Airnode cần thông báo khóa công khai mở rộng (xpub) bắt nguồn từ nút HD với đường dẫn m. Bây giờ, đường dẫn đã thông báo cần thuộc về nút HD với đường dẫn m / 44 ‘/ 60′ / 0’. Điều này có nghĩa là nếu bạn sử dụng xpub của Airnode để lấy địa chỉ bằng đường dẫn 0/0, bạn sẽ nhận được địa chỉ Airnode.
Địa chỉ Airnode là Airnode admin
Khi hợp đồng yêu cầu phải xin phép Airnode để đưa người yêu cầu vào whitelist, để cho phép tài khoản đưa người yêu cầu vào whitelist, v.v., hợp đồng yêu cầu người gọi phải là địa chỉ Airnode, tức là không còn phải chỉ định địa chỉ quản trị Airnode riêng nữa. Điều này đã hợp lý hóa đáng kể quy trình triển khai và luồng người dùng cho các sản phẩm quản lý Airnode trong tương lai như ChainAPI và Giao diện người dùng quản lý Airnode.
Airnode cung cấp địa chỉ hợp đồng của người ủy quyền trong khi thực hiện kiểm tra người ủy quyền
Trong giai đoạn tiền alpha, Airnodes đặt các địa chỉ hợp đồng ủy quyền của họ trên chuỗi và việc kiểm tra ủy quyền được thực hiện dựa trên các hợp đồng tại các địa chỉ này. Tuy nhiên, điều này không cung cấp bất kỳ đảm bảo nào, vì Airnode không phải tuân theo kết quả ủy quyền (tức là có thể thực hiện các yêu cầu trái phép và ngược lại). Thay vào đó, bây giờ API3 yêu cầu Airnode cung cấp địa chỉ người ủy quyền trong khi thực hiện lệnh gọi checkAuthorizationStatuses (), điều này sẽ giúp ích cho các điểm tiếp theo.
Airnode không tạo bản lưu trữ on-chain
Luồng người dùng pre-alpha bắt đầu bằng cách gọi “ví chính” của Airnode setAirnodeParameters () để đặt địa chỉ quản trị của nó và thông báo địa chỉ hợp đồng ủy quyền và khóa công khai mở rộng của nó trên chuỗi. Điều này gây ra xung đột tích hợp không cần thiết. Ví dụ: ai cấp tiền cho ví chính Airnode của đối tác API3? Điều gì sẽ xảy ra nếu đối tác API3 thực sự không muốn thực hiện bất kỳ giao dịch nào, bất kể là có ai cung cấp chi phí?
Ngoài việc xóa địa chỉ admin và các thông báo về địa chỉ hợp đồng người ủy quyền ở trên, API3 cũng không còn yêu cầu các khóa công khai mở rộng phải được thông báo trên chuỗi (điều này có ý nghĩa vì chúng không thể được xác minh trên chuỗi, tương tự như trường hợp ủy quyền ở trên), dẫn đến việc Airnodes không còn cần tạo bất kỳ bản ghi trên chuỗi nào để hoạt động.
Việc thực hiện được ký bởi ví Airnode
Ngoài việc người yêu cầu chỉ định địa chỉ mà họ muốn yêu cầu được thực hiện, API3 cũng yêu cầu ví Airnode ký vào cặp ID-phản hồi yêu cầu. Mặc dù phương pháp trước đây được bảo mật trong đó người yêu cầu có thể chắc chắn rằng ví phản hồi cho họ là ví được kiểm soát bởi Airnode tương ứng (vì họ lấy địa chỉ của nó từ xpub của Airnode), tuy nhiên họ không thể chứng minh điều đó các hợp đồng khác trên chuỗi đang bị hạn chế. Với việc bổ sung yêu cầu này, giao thức giờ đây sẽ có thể được sử dụng trong nhiều tình huống khác nhau. Bản cập nhật này hoàn toàn minh bạch đối với người yêu cầu và người vận hành node.
Thay thế mã trạng thái bằng chuỗi lỗi
API3 không còn trả về mã trạng thái giống HTTP nữa mà thay vào đó là một chuỗi lỗi. Các chuỗi lỗi này sẽ cho phép các nhà phát triển gỡ lỗi các vấn đề một cách dễ dàng bằng cách sử dụng các công cụ như RRP Explorer. Ngoài ra, API3 đã ngừng thực hiện các yêu cầu bị lỗi (có thể được coi là một lệnh gọi lại lỗi) vì nhận thấy rằng việc xử lý lỗi cho các yêu cầu oracle là một khái niệm quá sớm và các nhà phát triển dường như không biết phải làm gì với nó, dẫn đến điều này có khả năng gây hại nhiều hơn lợi.
Tất cả các nhà tài trợ đều có ví tài trợ được chỉ định cho mỗi Airnode theo mặc định
Mỗi nhà tài trợ được xác định bằng địa chỉ của họ và ví tài trợ của họ được chỉ định ngầm theo đường dẫn.
Nói cách khác, một nhà tài trợ có thể tính toán địa chỉ ví tài trợ tương ứng của họ cho một Airnode (sử dụng xpub của nó) và yêu cầu người yêu cầu sử dụng nó để đưa ra yêu cầu ngay lập tức mà không cần bất kỳ giao dịch sơ bộ nào (trong khi pre-alpha yêu cầu một giao dịch để được chỉ định “requester index”).
Địa chỉ nhà tài trợ là admin nhà tài trợ
Người yêu cầu trong giai đoạn tiền alpha được xác định bằng chỉ số và cần có địa chỉ admin được liên kết để cho phép tương tác (tức là chỉ admin người yêu cầu mới có thể xác nhận ứng dụng khách). Các nhà tài trợ được xác định bằng địa chỉ của họ, vì vậy API3 có thể sử dụng địa chỉ này trực tiếp làm admin. Lưu ý rằng đây là bản cập nhật tương tự đã xóa Airnode admin và sử dụng địa chỉ nhận dạng của nó làm admin.
Địa chỉ ví được chỉ định đã bị xóa khỏi các đối số của người ủy quyền
Trong giai đoạn tiền alpha, người ta có thể triển khai các trình ủy quyền kiểm tra requestId, airnodeId, endpointId, requesterIndex, IndicWallet và clientAddress. Với bản cập nhật mới, người ủy quyền có thể kiểm tra requestId, airnode, endpointId, nhà tài trợ, người yêu cầu. Lưu ý rằng hầu hết trong số này là những cái tên được thảo luận trong phần Thuật ngữ ở trên, nhưng sự khác biệt đáng chú ý là API3 không còn có địa chỉ ví (nhà tài trợ) được chỉ định.
Không thể xác định điểm đến rút tiền
Kể từ bây giờ, khi nhà tài trợ yêu cầu rút tiền, Airnode sẽ gửi tiền đến địa chỉ nhà tài trợ (thay vì một địa chỉ tùy ý được chỉ định trong yêu cầu rút tiền). Điều này ngụ ý rằng nếu bạn đang gỡ bỏ Airnode của mình, bạn có thể chỉ cần gửi tất cả số dư ví tài trợ đến địa chỉ của nhà tài trợ.
Các hợp đồng quản trị và ủy quyền được triển khai
Đây có lẽ là cập nhật quan trọng nhất cho đến nay. Giao thức pre-alpha để lại các ủy quyền sơ khai và chỉ cho phép truy cập điểm cuối. API3 đã triển khai hai trình cấp phép cấp cao, DaoRequesterRrpAuthorizer (được kiểm soát bởi API3 DAO và các địa chỉ được ủy quyền) và AirnodeRequesterRrpAuthorizer (được kiểm soát bởi các địa chỉ Airnode và các địa chỉ được ủy quyền bởi chúng). Hơn nữa, chức năng quản trị cấp thấp hơn được triển khai như một chuỗi kế thừa, có thể dễ dàng được sử dụng lại để xây dựng các hợp đồng cần chức năng whitelist / blacklist tương tự (ví dụ: dAPI).
Triển khai RrpBeaconServer.sol
Beacon là một điểm dữ liệu trực tiếp duy nhất trên chuỗi. Máy chủ Beacon là một hợp đồng người yêu cầu chứa các báo hiệu có thể lập chỉ mục bởi ID mẫu yêu cầu. Nó cũng có thể được coi là một thư viện nguồn cấp dữ liệu Airnode đơn, có khả năng mở rộng cao mà bạn có thể sử dụng riêng lẻ hoặc xây dựng các dAPI. API3 đang có kế hoạch sử dụng nhiều beacons với giao thức đăng ký xuất bản (PSP), tuy nhiên hợp đồng này là phiên bản sơ bộ được xây dựng trên RRP. Chức năng quản trị của hợp đồng này được thực hiện bằng cách sử dụng lại các hợp đồng quản trị được tạo cho người ủy quyền.
Kết luận
Bài viết này có thể khiến bạn choáng ngợp nếu bạn chưa quen lắm với pre-alpha, nhưng đừng lo lắng! RRP được hoàn thiện theo cách độc lập dễ hiểu hơn nhiều so với việc di chuyển từ giai đoạn tiền alpha.
Có thể bạn quan tâm:
Lưu ý: Đây là nội dung được tài trợ, Coin68 không trực tiếp ủng hộ bất cứ thông tin gì từ bài viết trên và không đảm bảo tính trung thực của bài viết. Bạn đọc nên tự tiến hành nghiên cứu trước khi đưa ra các quyết định có ảnh hưởng đến bản thân hay doanh nghiệp của mình và sẵn sàng chịu trách nhiệm cho những lựa chọn của bản thân. Bài viết trên không nên được xem như là một lời khuyên đầu tư.
