Je suis revenu à la documentation et j’ai passé plus de temps que prévu sur deux points : la tolérance aux pannes de Kadcast et les règles de finalité du protocole.
Au début, l’utilisation par Kadcast de la DHT de Kademlia semblait assez directe. Les nœuds peuvent mettre à jour leurs tables de routage quand des pairs disparaissent, et la présence de plusieurs pairs dans chaque compartiment offre des chemins alternatifs lorsqu’un nœud tombe en panne. Mais cela m’a amené à me poser une question : à quelle vitesse le réseau peut-il s’adapter quand les nœuds rejoignent, quittent ou deviennent constamment peu fiables ? Et une participation très inégale pourrait-elle créer des zones plus faibles dans la structure de routage ?
Le modèle d’état de consensus était encore plus intéressant.
Un bloc de @Dusk peut passer par les états acceptée, attestée, confirmée, puis finalement final. Ce qui m’a aidé à mieux comprendre, c’est la différence entre un bloc attesté et un bloc accepté. Si des itérations précédentes ont échoué, un bloc réussi peut être accepté tout en restant remplaçable. Plus il y a eu d’itérations échouées, plus la confirmation peut prendre du temps.
Par exemple, avec deux itérations précédentes ayant échoué, les règles exigent quatre blocs consécutifs attestés ou confirmés avant qu’un bloc accepté devienne confirmé.
Cela soulève, pour moi, des questions en matière de sécurité et de décentralisation. Ce mécanisme offre-t-il une protection suffisante contre l’instabilité temporaire du réseau sans rendre la finalité inutilement lente ? Et comment le protocole se comporte-t-il lorsque les défaillances sont corrélées entre beaucoup de nœuds plutôt qu’isolées ?
Je me demande aussi comment l’évolution des tables de routage et la finalité du consensus interagissent pendant des périodes de perturbation sérieuse du réseau.
Ma compréhension continue d’évoluer, donc j’aimerais beaucoup entendre comment d’autres interprètent ces compromis.
Quels scénarios de défaillance pensez-vous que Kadcast gère particulièrement bien ? Et quels de ses postulats pourraient être mis à l’épreuve ?
$DUSK #dusk
#dusk $DUSK @Dusk
Au début, l’utilisation par Kadcast de la DHT de Kademlia semblait assez directe. Les nœuds peuvent mettre à jour leurs tables de routage quand des pairs disparaissent, et la présence de plusieurs pairs dans chaque compartiment offre des chemins alternatifs lorsqu’un nœud tombe en panne. Mais cela m’a amené à me poser une question : à quelle vitesse le réseau peut-il s’adapter quand les nœuds rejoignent, quittent ou deviennent constamment peu fiables ? Et une participation très inégale pourrait-elle créer des zones plus faibles dans la structure de routage ?
Le modèle d’état de consensus était encore plus intéressant.
Un bloc de @Dusk peut passer par les états acceptée, attestée, confirmée, puis finalement final. Ce qui m’a aidé à mieux comprendre, c’est la différence entre un bloc attesté et un bloc accepté. Si des itérations précédentes ont échoué, un bloc réussi peut être accepté tout en restant remplaçable. Plus il y a eu d’itérations échouées, plus la confirmation peut prendre du temps.
Par exemple, avec deux itérations précédentes ayant échoué, les règles exigent quatre blocs consécutifs attestés ou confirmés avant qu’un bloc accepté devienne confirmé.
Cela soulève, pour moi, des questions en matière de sécurité et de décentralisation. Ce mécanisme offre-t-il une protection suffisante contre l’instabilité temporaire du réseau sans rendre la finalité inutilement lente ? Et comment le protocole se comporte-t-il lorsque les défaillances sont corrélées entre beaucoup de nœuds plutôt qu’isolées ?
Je me demande aussi comment l’évolution des tables de routage et la finalité du consensus interagissent pendant des périodes de perturbation sérieuse du réseau.
Ma compréhension continue d’évoluer, donc j’aimerais beaucoup entendre comment d’autres interprètent ces compromis.
Quels scénarios de défaillance pensez-vous que Kadcast gère particulièrement bien ? Et quels de ses postulats pourraient être mis à l’épreuve ?
$DUSK #dusk
#dusk $DUSK @Dusk
