Cho phép canisters gửi/nhận các yêu cầu HTTP – Oracle trên Internet Computer sẽ như thế nào?

Windy

11/03/2022 05:01

128

Lộ trình của IC có kế hoạch cho phép các hợp đồng thông minh gửi và nhận các yêu cầu http(s), cho phép các thùng chứa (Dapps/hợp đồng thông minh) trên IC thực hiện các yêu cầu http(s) tới các dịch vụ bên ngoài IC, từ đó tích hợp IC với thế giới Web 2.0 với nhau. Phiên bản đầu tiên của tính năng này sẽ bao gồm chức năng dịch vụ oracle điển hình, nhưng sẽ làm như vậy theo cách loại bỏ các bên thứ ba, tức là không đưa ra bất kỳ giả định tin cậy bổ sung nào.

Vào ngày 27 tháng 2, đề xuất quản trị 46519 về việc triển khai các hợp đồng thông minh để gửi các yêu cầu http(s) đã được thực hiện.

Điều này mở ra các kịch bản ứng dụng khổng lồ, chẳng hạn như lấy dữ liệu tỷ giá hối đoái cho DeFi trực tiếp từ các máy chủ bên ngoài, lấy dữ liệu thời tiết cho các dịch vụ bảo hiểm phi tập trung hoặc gửi thông báo cho người dùng cuối thông qua các kênh liên lạc truyền thống.

Những thách thức kỹ thuật của oracles

Sổ cái phi tập trung và hợp đồng thông minh trong chuỗi khối giải quyết vấn đề tin cậy của tương tác P2P, nhưng vì các hợp đồng thông minh không thể trực tiếp lấy thông tin ngoài chuỗi, nên những thông tin đó không thể được tin cậy trên chuỗi. Vì vậy, đề xuất của kế hoạch tiên tri oracles đóng một vai trò quan trọng trong việc giải quyết vấn đề liên lạc giữa blockchain và thế giới bên ngoài.

Nếu hợp đồng thông minh có thể truy cập trực tiếp vào máy chủ http(s) thông qua phương thức gọi http(s) mà không cần phụ thuộc vào máy oracle? Câu trả lời là không.

Đây là một thách thức đối với bất kỳ blockchain nào, vì các yêu cầu http(s) được gửi bởi một hợp đồng thông minh có thể nhận được các phản hồi khác nhau (chẳng hạn như thời gian hoặc số có trong phản hồi) sau khi chúng được gửi qua các bản sao/nút khác nhau. Sau khi các phản hồi khác nhau được các bản sao khác nhau nhận được, việc xử lý thêm dựa trên các phản hồi khác nhau sẽ dẫn đến trạng thái không nhất quán giữa các bản sao, do đó phá hủy tính chắc chắn của phép tính và không đạt được sự đồng thuận.

Do đó, các hợp đồng thông minh không thể trực tiếp thực hiện các yêu cầu http(s) đến các dịch vụ bên ngoài thông qua các bản sao, điều này có thể gây ra các vấn đề đáng kể cho sự đồng thuận. Đây cũng là lý do tại sao không có blockchain nào có thể trực tiếp chấp nhận dữ liệu ngoài chuỗi.

Và các thời điểm bảo mật khác nhau cho chúng ta biết rằng các liên kết của các thành phần này rất dễ gặp sự cố. Giải pháp oracle có những điểm khó khăn sau:

Có rủi ro tin cậy bên ngoài với tư cách là đại lý dữ liệu của bên thứ ba
Là một dịch vụ của bên thứ ba, oracle cần phải trả một khoản phí nhất định, điều này làm tăng chi phí phát triển
Mô hình lập trình của oracles thêm phức tạp và không định hướng

Đội ngũ R&D của IC luôn tuân thủ chiến lược phát triển “tích hợp trực tiếp”, chẳng hạn như tích hợp trực tiếp IC sẽ được đưa ra trên mạng chính trong tương lai gần với mạng BTC, và việc tích hợp trực tiếp IC đã được lên kế hoạch. sẽ được tung ra sau đó với Ethereum.

IC hy vọng sẽ cho phép các hợp đồng thực hiện cuộc gọi đến các dịch vụ Web2 để lấy và gửi dữ liệu thông qua “tích hợp trực tiếp”. Tích hợp trực tiếp là để giảm chi phí tín dụng bổ sung và các giả định, giảm rủi ro của bên thứ ba và tạo ra một môi trường hoàn toàn đáng tin cậy. Điều này sẽ phá vỡ các ranh giới vốn có của blockchain từ trước đến nay và tạo ra một thế giới blockchain mở hơn, toàn diện hơn và được sử dụng rộng rãi hơn.

Tất nhiên, sau khi hợp đồng IC có khả năng thực hiện các lệnh gọi http(s), oracle vẫn có thể hữu ích cho một số trường hợp, nhưng các lệnh gọi http(s) trực tiếp có thể bao gồm nhiều tình huống.

Sự đồng thuận HTTP

Mục tiêu của đề xuất này là thực hiện một hợp đồng thông minh (còn được gọi là canister trong IC) để cấp chức năng yêu cầu URL http(s) và nhận giá trị trả về phản hồi, không còn sử dụng phương thức GET truyền thống. Phản hồi cuộc gọi được trả về trạng thái hợp đồng thông minh theo cách xác định và yêu cầu được đưa ra trực tiếp và yêu cầu hoàn toàn đáng tin cậy và có thể xác minh được. Cụ thể, nó sẽ tập trung vào các khía cạnh sau:

Thực hiện liên kết đến các dịch vụ web và dữ liệu hiện có
Thực hiện các liên kết đến các dịch vụ kinh doanh bên ngoài, chẳng hạn như thanh toán, nhắn tin văn bản và ủy quyền
Triển khai (các) HTTP mà không có phép đọc

Làm thế nào để đạt được đồng thuận?

Làm thế nào để giải quyết vấn đề http(s) đọc và gửi các hợp đồng thông minh? Sau đây là thiết kế quy trình:

Hợp đồng thông minh của lớp thực thi đưa ra các yêu cầu http(s) thông qua API không đồng bộ do lớp hệ thống cung cấp
Yêu cầu http(s) đi vào lớp đồng thuận và mỗi nút sẽ gửi một yêu cầu đến nút chuyên dụng http(s) sau khi xác định chữ ký
Mỗi nút nhận giá trị trả về của yêu cầu, và nút sẽ ký vào giá trị trả về
Nút phát tới các nút khác trong lớp đồng thuận
Sau khi lớp đồng thuận thu thập đủ chữ ký, nó tổng hợp các chữ ký để tạo ra một khối và thực thi giá trị trả về trên chuỗi
Giá trị trả về sẽ được truyền trở lại lớp thực thi, và quá trình tính toán và cập nhật trạng thái trong hợp đồng sẽ tiếp tục

Ngay từ sớm, tất cả các nút trong mạng con sẽ thực hiện các yêu cầu và trả về các phản hồi vượt qua sự đồng thuận của IC.

Trong tương lai, các nhà phát triển có thể được phép chọn số lượng nút tham gia đồng thuận yêu cầu http(s) dựa trên các yêu cầu bảo mật của ứng dụng. Hướng khác là yêu cầu POST, được sử dụng trong các tình huống mà độ tin cậy không cao, nhưng cần có khả năng tương thích với API.

API lớp hệ thống

Chúng tôi đã triển khai một API cấp thấp trong hợp đồng hệ thống, cung cấp một phương pháp để thực hiện lệnh gọi http(s) tới các dịch vụ bên ngoài và nhận phản hồi. Sau đây là sơ đồ triển khai ban đầu:

Phương thức mới trong ic0:

Cuộc gọi nâng cao

Việc gọi API này sẽ lưu trữ yêu cầu trong một nhóm đang chờ xử lý cụ thể được các thành phần của mạng/lớp đồng thuận đọc định kỳ. Ngay sau khi thành phần này nhìn thấy một yêu cầu http(s) mới, nó sẽ đưa ra yêu cầu tới bộ điều hợp http(s) ở lớp mạng, bộ điều hợp này sẽ thực thi yêu cầu thực và cung cấp phản hồi trở lại.

Giá trị trả về phản hồi sẽ được đưa vào một nhóm HTTP đang chờ xử lý mới, giá trị trả về sẽ được ký bởi nút và chữ ký sẽ được phát tới tất cả các nút trong mạng con. Sau khi được ít nhất 2/3 số nút hỗ trợ, giá trị trả về này sẽ được ghi có vào khối thông qua sự đồng thuận và mạng con sẽ đạt được sự đồng thuận.

Khối IC ghi lại giá trị trả về của phản hồi HTTP sau khi đồng thuận sẽ được chuyển trở lại API hệ thống và được cung cấp để trả về hợp đồng thông minh đang gọi và sau đó hợp đồng thông minh sẽ thực thi logic dựa trên kết quả trả về.

Xử lý sự khác biệt trong các câu trả lời

Đối với nhiều dịch vụ dựa trên HTTP, phản hồi chứa dấu thời gian hoặc ID duy nhất, theo cách mà các nút khác nhau trong mạng con không thể đồng ý về việc nhận phản hồi.

Giải pháp là cho phép người gọi chỉ định cách phản hồi nên được xử lý trước khi nó được cung cấp cho lớp đồng thuận, cho phép nhiều danh mục phản hồi hơn (chẳng hạn như chỉ định khung thời gian) để có được sự đồng thuận, do đó cung cấp nhiều ứng dụng hơn.

Người gọi có thể chỉ định một phương thức xử lý phản hồi. Khi mỗi nút nhận giá trị trả về, mỗi nút sẽ biến đổi giá trị trả về theo một cách cụ thể hơn. Quá trình chuyển đổi có thể chỉ giữ một số trường nhất định trong giá trị trả về phản hồi, loại bỏ các giá trị khác có thể khác giữa các giá trị trả về phản hồi, chẳng hạn như dấu thời gian hoặc ID duy nhất. Quá trình chuyển đổi cũng có thể giữ lại một giá trị duy nhất mục tiêu, chẳng hạn như giá mã thông báo, từ toàn bộ quá trình phản hồi, điều này sẽ làm giảm đáng kể băng thông khối yêu cầu.

Bản đồ lộ trình

Kế hoạch sẽ được công bố vào cuối quý 1 năm 2022. Nhóm nhà phát triển của vi mạch sẽ phát triển song song trên nhiều lớp, hầu hết các kỹ thuật dự kiến sẽ được thực hiện trên lớp đồng thuận, tiếp theo là lớp mạng, lớp thực thi và lớp định tuyến thông báo.

Source: Fayefei – ICPL

Windy