Hầu như nhà đầu tư am hiểu kỹ thuật nào ngồi lại với chúng tôi cũng hỏi một biến thể của cùng một câu hỏi trong mười phút đầu.

“Anh tự dùng oracle của mình à? Sao không kết nối thẳng vào Chainlink?”

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

Tóm lại: ngành khách sạn có những nhu cầu mà các mạng oracle đa dụng không được thiết kế để phục vụ tốt.

Tóm tắt nhanh, dành cho ai không sống cùng những thứ này

Hợp đồng thông minh là đoạn mã chạy trên chuỗi khối. 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 ngay bản thâ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 phòng trống của một khách sạn. Nó không thể thấy tỷ giá hiện tại. Nó không thể xác minh khách thực sự đã nhận phòng.

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

Những gì chúng tôi cần oracle của mình làm

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á linh hoạt, giải quyết tranh chấp. Mỗi quyết định đều cần dữ liệu bên ngoài đáng tin:

Đánh đổi, được nhìn nhận thẳng thắn

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

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

Độ trễ. Quyết định đặt phòng diễn ra trong vài giây. Khách đang ở trên trang, nhấp chuột, và kỳ vọng có xác nhận ngay. Việc đẩy dữ liệu qua lại qua mạng oracle đa dụng làm tăng độ trễ mà chúng tôi không thể chấp nhận cho các thao tác trên đường 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 phòng và giá.

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

Tùy biến theo nghiệp vụ. “Xác nhận check-in tại cơ sở lưu trú” không phải là một nguyên hàm oracle tiêu chuẩn. “Hòa giải tranh chấp về hoàn tiền một phần” cũng vậy. Xây dựng những thứ đó trên một mạng feed chung chung thì có thể làm được, nhưng bạn sẽ phải viết quá nhiều logic tùy biến xung quanh oracle đến mức thực chất bạn vẫn đang vận hành một nửa oracle. Chúng tôi quyết định viết luôn cả hệ thống.

Thứ 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 thiết kế riêng cho dữ liệu khách sạn và du lịch. Cái tên không mang ý nghĩa cao siêu nào; nó ngắn gọn và đội ngũ backend của chúng tôi thích nó.

Vài điều GHOST mang lại mà các oracle đa dụng không thể:

• Đường nóng dưới một giây. Truy vấn tình trạng phòng và giá trả về trong vài mili-giây vì chúng là bản chất của hệ thống, không phải cầu nối bên ngoài.
• Cấu trúc dữ liệu nhận biết ngữ cảnh. Giao thức nói chuyện bằng các khái niệm “đặt phòng”, “chính sách giá”, “chính sách hủy”, “sự kiện nhận phòng”, chứ không chỉ truyền tải những dòng số chung chung.
• Chi phí theo quy mô. Chi phí oracle cận biên tiến về không khi khối lượng lớn, và đó là điều kiện cần để mức tiết kiệm 28 đến 36 phần trăm cho nhà cung cấp có thể duy trì bền vững.
• Tổng hợp đa nguồn. GHOST gom kho phòng và giá từ mạng lưới của chúng tôi trải rộng trên hàng nghìn cơ sở lưu trú. Logic tổng hợp được tinh chỉnh riêng cho bài toán khách sạn.
• Kiểm toán độc lập. Toàn bộ hệ thống đã trải qua các cuộc kiểm toán bảo mật độc lập như một phần của quy trình rà soát hợp đồng thông minh rộng hơn của chúng tôi.

Những gì chúng tôi đánh đổi

Tôi muốn thành thật về điều này. Tự phát triển không hề miễn phí. Chúng tôi đã chấp nhận ba cái giá thật sự:

Chúng tôi không có ngay hiệu ứng mạng lưới về bảo mật của một tập validator phi tập trung lớn. Chúng tôi bù đắp bằng kiểm toán, quản trị đa chữ ký trên giao thức và chương trình săn 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 đó một cách cởi mở.

Chúng tôi gánh toàn bộ khối lượng kỹ thuật. Mỗi lần nâng cấp giao thức, mỗi bản vá bảo mật, mỗi kiểu dữ liệu mới. Tất cả đặt lên vai đội ngũ của chúng tôi. Với Chainlink, phần lớn gánh nặng đó được chia sẻ trong toàn hệ sinh thái.

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

Đặt cược, trong một câu

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

Kèo cược đó có thể không phù hợp với mọi dự án trên chuỗi khối. Với một giao thức DeFi hay 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 lĩnh vực khách sạn lại có những nhu cầu dữ liệu rất riêng, cùng áp lực kinh tế cụ thể để giữ chi phí đơn vị ở mức thấp, nên bài toán đặt ra sẽ khác.

Nếu bạn đang làm một dự án mà phải cân nhắc quyết định tương tự, chúng tôi rất sẵn lòng cùng nhau bàn bạc. Hệ sinh thái tiền mã hóa chưa nói đủ nhiều về sự đánh đổi này.

Carol

Quản lý cộng đồng, Tratok