Presque chaque investisseur techniquement curieux avec lequel nous nous sommes assis pose une variante de la même question dans les dix premières minutes.

“Vous utilisez vos propres oracles ? Pourquoi ne pas simplement vous connecter à Chainlink ?”

C’est une question légitime. Chainlink est de loin le réseau d’oracles décentralisé dominant. Ils ont une solide réputation, un bilan de sécurité sérieux et un large écosystème de développeurs. S’écarter du script nous coûte quelque chose. Alors pourquoi l’avons-nous fait ?

La réponse courte : l’hôtellerie a des besoins que les réseaux d’oracles généralistes n’ont pas été conçus pour servir correctement.

Un petit rappel, pour ceux qui ne vivent pas dans cet univers

Un contrat intelligent est du code qui s’exécute sur une blockchain. Il peut détenir des actifs, appliquer des règles et libérer des paiements basés sur des conditions. Ce qu’il ne peut pas faire, nativement, c’est connaître quoi que ce soit sur le monde extérieur. Il ne peut pas lire le calendrier de disponibilité d’un hôtel. Il ne peut pas voir le taux de change actuel. Il ne peut pas vérifier qu’un client s’est effectivement enregistré.

Un oracle est le pont entre la blockchain et la réalité. Il alimente les contrats intelligents avec des données externes (prix, événements, vérification, identité) afin qu’ils puissent agir en conséquence. Si l’oracle ment ou se casse, le contrat agit sur de mauvaises informations. C’est pourquoi la conception des oracles est l’un des problèmes les plus importants dans l’ingénierie blockchain.

Ce dont nos oracles avaient besoin pour fonctionner

Les contrats intelligents de Tratok prennent beaucoup de décisions chaque jour. Remboursements, confirmations de réservation, tarification dynamique, résolution de litiges. Chacun nécessite des données externes fiables :

Le compromis, exposé honnêtement

Les réseaux d’oracles polyvalents sont conçus pour des données polyvalentes. Ils optimisent pour la largeur (flux de prix pour chaque actif, chaque chaîne) et ils ont fait un travail brillant en la matière. Mais cette largeur signifie qu’ils sont nécessairement une ou deux couches d’abstraction au-dessus de la logique de domaine spécifique dont nous avions besoin.

Pour nous, cet écart s’est transformé en trois problèmes réels:

Latence. Une décision de réservation se prend en quelques secondes. Un client est sur une page, il clique, il s’attend à une confirmation. L’envoi aller-retour des données via un réseau d’oracles polyvalent ajoute une latence que nous ne pouvions pas nous permettre pour les opérations à chaud. Nous avions besoin de temps de réponse inférieurs à la seconde pour les requêtes de disponibilité et de tarification.

Coût à l’échelle. Chaque appel d’oracle a un coût. Pour une plateforme qui vise des millions de transactions par mois, payer des frais par requête à un réseau tiers aurait inversé nos économies. Les économies que nous rendons aux fournisseurs et aux consommateurs dépendent du maintien du coût unitaire de chaque transaction proche de zéro.

Personnalisation du domaine. Une « confirmation d’enregistrement dans un établissement » n’est pas une primitive oracle standard. « L’arbitrage des litiges sur un remboursement partiel » non plus. Les construire sur un réseau de flux générique est possible, mais vous finissez par écrire tellement de logique personnalisée autour de l’oracle que vous effectively exécutez en fait la moitié d’un oracle. Nous avons décidé d’écrire simplement l’ensemble.

Ce que nous avons construit à la place : GHOST

GHOST est notre protocole oracle propriétaire, construit spécifiquement pour les données de l’hôtellerie et des voyages. Le nom ne signifie rien de prétentieux ; il est court et notre équipe backend l’a aimé.

Quelques choses que GHOST nous apporte que les oracles polyvalents ne peuvent pas:

• Chemin chaud sub-seconde. Les requêtes de disponibilité et de tarification reviennent en millisecondes parce qu’elles sont natives du système, pas pontées.
• Structures de données conscientes du domaine. Le protocole parle « réservation », « plan tarifaire », « politique d’annulation », « événement d’enregistrement », et non pas simplement des flux numériques génériques.
• Mise à l’échelle des coûts. Le coût marginal de l’oracle s’approche de zéro à volume élevé, ce qui est la seule façon dont les économies des fournisseurs de 28 à 36 pour cent sont durables.
• Agrégation multi-sources. GHOST agrège l’inventaire et les tarifs de notre réseau couvrant des milliers de propriétés. La logique d’agrégation est ajustée spécifiquement pour le cas d’usage hôtelier.
• Audit indépendant. L’ensemble du système a été soumis à des audits de sécurité indépendants dans le cadre de notre processus plus large de révision des contrats intelligents.

Ce que nous avons abandonné

Je veux être honnête à ce sujet. Passer en propriété n’est pas gratuit. Nous avons accepté trois coûts réels:

Nous n’obtenons pas la sécurité d’effet de réseau d’un grand ensemble de validateurs décentralisés prêt à l’emploi. Nous compensons avec des audits, une gouvernance multi-signatures sur le protocole et un programme de prime aux bogues continuellement mis à jour, mais c’est un modèle de confiance différent. Nous le reconnaissons ouvertement.

Nous assumons la charge d’ingénierie. Chaque mise à niveau du protocole, chaque correctif de sécurité, chaque nouveau type de données. C’est à notre équipe que cela incombe. Avec Chainlink, une grande partie de ce lourd fardeau est partagée à travers l’écosystème.

Nous n’obtenons pas l’interopérabilité gratuite avec l’écosystème DeFi plus large. Si nous voulons intégrer un protocole DeFi qui attend des flux Chainlink, nous devons construire des ponts. Nous avons déjà fait une partie de cela et nous en ferons davantage.

Le pari, en une phrase

Pour une plateforme dont la proposition de valeur fondamentale repose sur un coût de transaction marginal quasi nul et des décisions de réservation en millisecondes, posséder la couche de données était le bon compromis. Même avec la charge d’ingénierie que cela implique.

Ce pari pourrait ne pas être le bon choix pour chaque projet blockchain. Pour un protocole DeFi ou une plateforme d’actifs synthétiques, la réponse est presque toujours Chainlink. Mais l’hôtellerie est un domaine avec des besoins de données si spécifiques, et une pression économique si spécifique pour maintenir les coûts unitaires bas, que le calcul change.

Si vous travaillez sur quelque chose où vous soupesez une décision similaire, nous serions heureux de comparer nos notes. L’écosystème crypto n’en parle pas assez de ce compromis.

— Carol

Responsable de communauté, Tratok