Une chose qui ressort particulièrement en étudiant Babylon, c’est que les limites de Bitcoin peuvent en réalité constituer l’une de ses plus grandes forces. Bitcoin Script n’a jamais été conçu comme une plateforme généraliste de contrats intelligents. Sa simplicité a souvent été perçue comme une contrainte, mais l’architecture de Babylon suggère un autre point de vue : au lieu de demander à Bitcoin de devenir autre chose, construire un système qui respecte ces limites.
Cette philosophie de conception a attiré mon attention. Plutôt que d’étendre Bitcoin avec de nouveaux opcodes ou de s’appuyer sur des actifs tokenisés (« wrapped assets »), les Trustless Bitcoin Vaults utilisent les capacités de script existantes de Bitcoin, combinées à une vérification cryptographique au niveau du protocole, afin de coordonner les interactions avec des applications externes. La documentation souligne que le rachat et les transitions d’état entre chaînes sont vérifiés au moyen des primitives de script existantes de Bitcoin, plutôt que d’exiger un fork de Bitcoin.
Plus j’y pense, plus je me dis que les contraintes produisent souvent une meilleure ingénierie. Quand un protocole ne peut pas compter sur une programmabilité illimitée, il doit résoudre les problèmes par une coordination soigneuse, au lieu d’ajouter de la complexité à la couche de base. Cette approche me paraît différente de la tentative de faire fonctionner chaque blockchain de la même manière.
Peut-être que la vraie innovation n’est pas de faire en sorte que Bitcoin se comporte comme une plateforme de smart contract. Peut-être qu’il s’agit de concevoir des systèmes qui comprennent suffisamment bien Bitcoin pour s’intégrer à ses règles, plutôt que de les réécrire.
De fortes contraintes techniques conduisent-elles finalement à une conception de protocole plus résiliente, ou bien ralentissent-elles l’innovation sur le long terme ?
@BabylonLabs_io $BABY #baby
Cette philosophie de conception a attiré mon attention. Plutôt que d’étendre Bitcoin avec de nouveaux opcodes ou de s’appuyer sur des actifs tokenisés (« wrapped assets »), les Trustless Bitcoin Vaults utilisent les capacités de script existantes de Bitcoin, combinées à une vérification cryptographique au niveau du protocole, afin de coordonner les interactions avec des applications externes. La documentation souligne que le rachat et les transitions d’état entre chaînes sont vérifiés au moyen des primitives de script existantes de Bitcoin, plutôt que d’exiger un fork de Bitcoin.
Plus j’y pense, plus je me dis que les contraintes produisent souvent une meilleure ingénierie. Quand un protocole ne peut pas compter sur une programmabilité illimitée, il doit résoudre les problèmes par une coordination soigneuse, au lieu d’ajouter de la complexité à la couche de base. Cette approche me paraît différente de la tentative de faire fonctionner chaque blockchain de la même manière.
Peut-être que la vraie innovation n’est pas de faire en sorte que Bitcoin se comporte comme une plateforme de smart contract. Peut-être qu’il s’agit de concevoir des systèmes qui comprennent suffisamment bien Bitcoin pour s’intégrer à ses règles, plutôt que de les réécrire.
De fortes contraintes techniques conduisent-elles finalement à une conception de protocole plus résiliente, ou bien ralentissent-elles l’innovation sur le long terme ?
@BabylonLabs_io $BABY #baby