shareyourthinking

Engagement de fiabilité de la dépendance à l’attestation du smart contract

J’y pense depuis quelques jours, car j’ai déjà ajouté des dépendances tierces à des smart contracts et la question se heurte toujours au même mur : que se passe-t-il pour mon protocole si la dépendance tombe en panne.

Newton exige que les applications valident une attestation BLS dans leur smart contract avant d’exécuter. Sans attestation valide, pas d’exécution.

Voilà le mécanisme d’application : c’est aussi une dépendance irréductible.

Une fois qu’un protocole déploie cette exigence dans un contrat immuable, il s’est engagé à ce que le réseau d’opérateurs de Newton soit disponible pour chaque transaction que ce contrat traitera jamais.

Ce n’est pas une critique. C’est un choix de conception avec de vraies implications.

Un protocole intégrant Newton ne fait plus seulement confiance à son propre code.

Il fait confiance à un quorum d’opérateurs mis en jeu pour évaluer des politiques et produire des attestations pour chaque transaction indéfiniment. La whitepaper traite de la censure via le forçage de l’inclusion. Elle ne traite pas de ce qui se passe lors d’une dégradation réelle du réseau d’opérateurs : pas la censure, mais plutôt le sous-débit ou une panne partielle.
#newt
Je pense en fait que l’engagement de fiabilité est la question la plus importante pour les équipes de protocole qui évaluent Newton, plus que l’ensemble des fonctionnalités de conformité. Ajouter une dépendance à un smart contract est permanent d’une manière qui n’existe pas lorsque l’on en ajoute une à un service web.
#NEWT
Ce que je n’ai pas encore compris, c’est s’il existe un mode de dégradation maîtrisée : une façon pour un protocole de basculer pendant des indisponibilités des opérateurs plutôt que de s’arrêter complètement.
#ShareYourThinking $LAB $HMSTR
@NewtonProtocol $NEWT #Newt