Gần như mọi nhà đầu tư tò mò về mặt kỹ thuật mà chúng tôi đã ngồi lại cùng đều hỏi một biến thể nào đó của cùng một câu hỏi trong mười phút đầu tiên.

“Bạn đang sử dụng các oracle của riêng mình? Tại sao không chỉ kết nối với Chainlink?”

Đây là một câu hỏi hợp lý. Chainlink là mạng oracle phi tập trung thống trị cho đến nay. Họ có danh tiếng mạnh mẽ, hồ sơ bảo mật nghiêm túc và một hệ sinh thái nhà phát triển rộng lớn. Đi chệch khỏi kịch bản phải trả một cái giá cho chúng tôi. Vậy tại sao chúng tôi lại làm vậy?

Câu trả lời ngắn gọn: ngành khách sạn có những nhu cầu mà các mạng oracle mục đích chung không được xây dựng để phục vụ tốt.

Một bài hướng dẫn nhanh, dành cho bất kỳ ai không sống trong lĩnh vực này

Hợp đồng thông minh là mã chạy trên blockchain. Nó có thể nắm giữ tài sản, thực thi quy tắc và giải ngân thanh toán dựa trên các điều kiện. Điều nó không thể làm, một cách tự nhiên, là biết bất cứ điều gì về thế giới bên ngoài. Nó không thể đọc lịch availability của khách sạn. Nó không thể xem tỷ giá hối đoái hiện tại. Nó không thể xác minh rằng khách đã thực sự nhận phòng.

Oracle là cầu nối giữa blockchain và thực tế. Nó cung cấp dữ liệu bên ngoài (giá cả, sự kiện, xác minh, danh tính) vào các hợp đồng thông minh để chúng có thể hành động dựa trên dữ liệu đó. Nếu oracle nói dối hoặc hỏng, hợp đồng sẽ hành động dựa trên thông tin sai lệch. Đó là lý do tại sao thiết kế oracle là một trong những vấn đề có mức cược cao nhất trong kỹ thuật blockchain.

Những gì chúng tôi cần các oracle của mình thực hiện

Các hợp đồng thông minh của Tratok xử lý rất nhiều quyết định mỗi ngày. Hoàn tiền, xác nhận đặt phòng, định giá động, giải quyết tranh chấp. Mỗi quyết định đều cần dữ liệu bên ngoài đáng tin cậy:

Sự đánh đổi, được trình bày một cách trung thực

Các mạng lưới oracle đa năng được thiết kế cho dữ liệu đa năng. Chúng tối ưu hóa cho chiều rộng (luồng giá cho mọi tài sản, mọi chuỗi) và chúng đã làm rất tốt việc đó. Nhưng chiều rộng đó có nghĩa là chúng nhất thiết phải ở một hoặc hai lớp trừu tượng trên logic miền cụ thể mà chúng ta cần.

Đối với chúng tôi, khoảng cách đó đã trở thành ba vấn đề thực sự:

Độ trễ. Một quyết định đặt phòng diễn ra trong vài giây. Một khách đang ở trên trang, họ nhấp vào, họ mong đợi một xác nhận. Việc gửi dữ liệu khứ hồi qua một mạng lưới oracle đa năng tạo ra độ trễ mà chúng tôi không thể chấp nhận được cho các hoạt động trên đường dẫn nóng. Chúng tôi cần thời gian phản hồi dưới một giây cho các truy vấn về tình trạng còn phòng và giá cả.

Chi phí ở quy mô lớn. Mỗi lần gọi oracle đều có chi phí. Đối với một nền tảng đang hướng tới hàng triệu giao dịch mỗi tháng, việc trả phí cho mỗi truy vấn cho một mạng lưới bên thứ ba sẽ đảo ngược kinh tế của chúng tôi. Các khoản tiết kiệm mà chúng tôi đang trao lại cho các nhà cung cấp và người tiêu dùng phụ thuộc vào việc giữ cho chi phí đơn vị của mỗi giao dịch gần bằng không.

Tùy chỉnh miền. “Xác nhận nhận phòng tài sản” không phải là một nguyên hàm oracle tiêu chuẩn. Cũng không phải là “phân xử tranh chấp về hoàn tiền một phần.” Xây dựng những thứ đó trên một mạng lưới luồng dữ liệu chung là có thể, nhưng bạn kết thúc việc viết quá nhiều logic tùy chỉnh xung quanh oracle đến mức bạn thực sự đang chạy một nửa của một cái gì đó. Chúng tôi quyết định chỉ viết toàn bộ.

Những gì chúng tôi xây dựng thay thế: GHOST

GHOST là giao thức oracle độc quyền của chúng tôi, được xây dựng có mục đích cho dữ liệu lưu trú và du lịch. Tên này không mang tính khoe khoang gì; nó ngắn gọn và đội ngũ backend của chúng tôi thích nó.

Một số điều mà GHOST mang lại cho chúng tôi mà các oracle đa năng không thể:

• Đường dẫn nóng dưới một giây. Các truy vấn về tình trạng còn phòng và giá cả trả về trong mili giây vì chúng là bản địa của hệ thống, không phải được kết nối cầu nối.
• Cấu trúc dữ liệu nhận biết miền. Giao thức nói về “đặt phòng,” “kế hoạch giá,” “chính sách hủy,” “sự kiện nhận phòng,” không chỉ các nguồn cấp số liệu số chung chung.
• Mở rộng chi phí. Chi phí oracle biên tiến gần bằng không ở khối lượng cao, đây là cách duy nhất để tiết kiệm của nhà cung cấp từ 28 đến 36 phần trăm là bền vững.
• Tổng hợp đa nguồn. GHOST tổng hợp inventory và giá cả từ mạng lưới của chúng tôi trải rộng hàng nghìn tài sản. Logic tổng hợp được điều chỉnh cụ thể cho trường hợp sử dụng khách sạn.
• Kiểm toán độc lập. Toàn bộ hệ thống đã trải qua kiểm toán bảo mật độc lập như một phần của quy trình xem xét hợp đồng thông minh rộng hơn của chúng tôi.

Những gì chúng tôi từ bỏ

Tôi muốn thành thật về điều này. Đi theo con đường độc quyền không miễn phí. Chúng tôi chấp nhận ba chi phí thực sự:

Chúng tôi không có được bảo mật hiệu ứng mạng của một bộ xác thực phi tập trung lớn ngay từ đầu. Chúng tôi bù đắp bằng kiểm toán, quản trị đa chữ ký trên giao thức, và một chương trình tiền thưởng lỗi được cập nhật liên tục, nhưng đó là một mô hình tin cậy khác. Chúng tôi thừa nhận điều này một cách cởi mở.

Chúng tôi gánh vác công việc kỹ thuật. Mọi nâng cấp giao thức, mọi bản vá bảo mật, mọi loại dữ liệu mới. Đó là trách nhiệm của đội ngũ chúng tôi. Với Chainlink, nhiều công việc nặng nhọc đó được chia sẻ trên toàn hệ sinh thái.

Chúng tôi không có khả năng tương tác miễn phí với hệ sinh thái DeFi rộng lớn hơn. Nếu chúng tôi muốn tích hợp với một giao thức DeFi yêu cầu nguồn cấp Chainlink, chúng tôi phải xây dựng cầu nối. Chúng tôi đã làm một phần điều này và sẽ làm thêm.

Cược lớn, trong một câu

Đối với một nền tảng mà đề xuất giá trị cốt lõi phụ thuộc vào chi phí giao dịch biên gần bằng không và các quyết định đặt phòng chỉ trong mili giây, việc sở hữu lớp dữ liệu là sự đánh đổi đúng đắn. Ngay cả khi đi kèm với gánh nặng về kỹ thuật.

Cược đó có thể không đúng cho mọi dự án blockchain. Đối với giao thức DeFi hoặc nền tảng tài sản tổng hợp, câu trả lời gần như luôn là Chainlink. Nhưng ngành khách sạn là một lĩnh vực có những nhu cầu dữ liệu rất cụ thể, và áp lực kinh tế rất cụ thể để giữ chi phí đơn vị thấp, khiến phép tính thay đổi.

Nếu bạn đang làm việc trên một dự án mà bạn đang cân nhắc một quyết định tương tự, chúng tôi rất sẵn lòng so sánh ghi chú. Hệ sinh thái crypto không nói về sự đánh đổi này đủ thường xuyên.

— Carol

Quản Lý Cộng Đồng, Tratok