Que devient un paiement Rayls si des validateurs tombent en panne en cours de transfert ?
J’ai compilé Axyl, le client de consensus Rayls, à partir du code source, lancé 4 validateurs sur mon ordinateur portable et les ai fait planter pendant des paiements en cours.
Un validateur hors service : 240 paiements sur 240 ont été réglés. La plus longue pause a duré 2,58 s.
Deux validateurs hors service : la chaîne s’est arrêtée jusqu’à leur retour. Un nœud a tout de même accepté mon paiement en 15 ms, sans erreur, et celui-ci a été réglé 41 s plus tard. Les 45 paiements envoyés pendant ces interruptions ont tous été réglés, entre 8 et 69 s après leur soumission.
Même nonce envoyé à deux validateurs, 24 fois : les deux ont renvoyé un hash, mais un seul paiement a été réglé à chaque fois. Aucune double dépense.
Donc, dans cette configuration, le système se bloque, mais ne crée pas de bifurcation. La leçon pour les applications : recevoir un hash ne signifie pas que le paiement est effectué.
Sur le testnet public, 150 paiements ont affiché une médiane de 2,44 s entre la soumission et la réception du reçu, telle que mesurée depuis un seul client. Cela inclut environ 0,4 s d’aller-retour réseau.
Limites : un seul ordinateur portable, uniquement des plantages, échantillons réduits, aucun paiement sur le mainnet. Un validateur redémarré a divergé lors d’un premier essai chaotique. Je n’ai pas pu reproduire le problème et l’ai signalé en privé à Rayls.
Données et code : https://github.com/anshxft/rayls-axyl-failure-tests
Ceci ne constitue pas un conseil financier.+
J’ai compilé Axyl, le client de consensus Rayls, à partir du code source, lancé 4 validateurs sur mon ordinateur portable et les ai fait planter pendant des paiements en cours.
Un validateur hors service : 240 paiements sur 240 ont été réglés. La plus longue pause a duré 2,58 s.
Deux validateurs hors service : la chaîne s’est arrêtée jusqu’à leur retour. Un nœud a tout de même accepté mon paiement en 15 ms, sans erreur, et celui-ci a été réglé 41 s plus tard. Les 45 paiements envoyés pendant ces interruptions ont tous été réglés, entre 8 et 69 s après leur soumission.
Même nonce envoyé à deux validateurs, 24 fois : les deux ont renvoyé un hash, mais un seul paiement a été réglé à chaque fois. Aucune double dépense.
Donc, dans cette configuration, le système se bloque, mais ne crée pas de bifurcation. La leçon pour les applications : recevoir un hash ne signifie pas que le paiement est effectué.
Sur le testnet public, 150 paiements ont affiché une médiane de 2,44 s entre la soumission et la réception du reçu, telle que mesurée depuis un seul client. Cela inclut environ 0,4 s d’aller-retour réseau.
Limites : un seul ordinateur portable, uniquement des plantages, échantillons réduits, aucun paiement sur le mainnet. Un validateur redémarré a divergé lors d’un premier essai chaotique. Je n’ai pas pu reproduire le problème et l’ai signalé en privé à Rayls.
Données et code : https://github.com/anshxft/rayls-axyl-failure-tests
Ceci ne constitue pas un conseil financier.+