Je pensais que la partie intéressante serait le hachage du bloc Bitcoin lui-même. En fait, il s’agissait de ce que Babylon attend comme taille.
Au premier abord, cela ressemble à un simple détail d’implémentation. Un hachage de bloc a un format connu, donc définir sa taille attendue paraît presque inutile. Après avoir passé plus de temps à lire la logique de validation avec le traitement des points de contrôle et l’intégration Bitcoin, j’ai commencé à le voir différemment.
Un protocole comme Babylon dépend d’informations qui arrivent depuis une autre chaîne sans que leur sens change en chemin. Chaque point de contrôle, chaque preuve et chaque décision d’un validateur commencent par l’hypothèse que les données traitées correspondent à ce que le Bitcoin a réellement produit. Si quelque chose d’aussi fondamental que la taille attendue d’un hachage de bloc est traité avec souplesse, alors chaque couche au-dessus hérite d’une incertitude supplémentaire.
Cela est devenu encore plus intéressant en le comparant à la manière dont Babylon valide les données de genèse et reconstruit l’état depuis le début. Le réseau consacre un effort surprenant à rejeter des informations qui semblent presque correctes, car le « presque » suffit à fragmenter l’état entre les participants. Les petites règles de validation sont vraiment des règles de coordination.
Je me suis aussi mis à réfléchir aux coûts opérationnels. Rejeter des données mal formées à l’étape la plus précoce possible coûte moins cher que de les laisser passer par le stockage de vérification et le consensus avant de découvrir l’erreur. La valeur n’est pas seulement la sécurité. C’est une utilisation des ressources prévisible pour l’ensemble des validateurs.
Je me suis intéressé à la cryptographie et j’en suis venu à penser en termes de discipline. Parfois, la fiabilité commence par refuser de traiter des données qui ne sont qu’un octet de l’erreur.
@BabylonLabs_io
#baby $BABY
Au premier abord, cela ressemble à un simple détail d’implémentation. Un hachage de bloc a un format connu, donc définir sa taille attendue paraît presque inutile. Après avoir passé plus de temps à lire la logique de validation avec le traitement des points de contrôle et l’intégration Bitcoin, j’ai commencé à le voir différemment.
Un protocole comme Babylon dépend d’informations qui arrivent depuis une autre chaîne sans que leur sens change en chemin. Chaque point de contrôle, chaque preuve et chaque décision d’un validateur commencent par l’hypothèse que les données traitées correspondent à ce que le Bitcoin a réellement produit. Si quelque chose d’aussi fondamental que la taille attendue d’un hachage de bloc est traité avec souplesse, alors chaque couche au-dessus hérite d’une incertitude supplémentaire.
Cela est devenu encore plus intéressant en le comparant à la manière dont Babylon valide les données de genèse et reconstruit l’état depuis le début. Le réseau consacre un effort surprenant à rejeter des informations qui semblent presque correctes, car le « presque » suffit à fragmenter l’état entre les participants. Les petites règles de validation sont vraiment des règles de coordination.
Je me suis aussi mis à réfléchir aux coûts opérationnels. Rejeter des données mal formées à l’étape la plus précoce possible coûte moins cher que de les laisser passer par le stockage de vérification et le consensus avant de découvrir l’erreur. La valeur n’est pas seulement la sécurité. C’est une utilisation des ressources prévisible pour l’ensemble des validateurs.
Je me suis intéressé à la cryptographie et j’en suis venu à penser en termes de discipline. Parfois, la fiabilité commence par refuser de traiter des données qui ne sont qu’un octet de l’erreur.
@BabylonLabs_io
#baby $BABY