Résumer la percée de MonadBFT Hier, Category Labs a publié l’article de MonadBFT, décrivant le mécanisme de consensus qui alimentera Monad sur le réseau principal. MonadBFT est un développement significatif dans la recherche consensuelle puisque c’est la première fois que Pipelined HotStuff devient résistant à la fourche de queue. Le tail-forking se produit lorsqu’un emplacement manqué entraîne l’abandon et le reminage de la proposition précédente. Il s’agit d’un problème grave dans les formulations précédentes de Pipelined HotStuff car il ouvre la voie à des attaques MEV multi-blocs qui déstabilisent le consensus. Atténuer ce problème est un énorme problème car il nous donne tous les avantages de Pipelined HotStuff - blocages fréquents, faible latence, grands ensembles de validateurs - tout en évitant le plus gros inconvénient. MonadBFT offre également une énorme mise à niveau pour la finalité. Il propose une finalité spéculative à un seul emplacement (500 ms) et une finalité dure à deux emplacements (1s). « Finalité spéculative » signifie « finalité qui ne reviendra qu’en cas d’équivoque (double signature) par une majorité de validateurs ». L’équivoque est une infraction majeure dans la plupart des systèmes blockchain et est généralement sanctionnée par des coups de bâton ; Plus la pénalité pour équivoque est grande, plus vous pouvez penser à une « finalité spéculative » proche de la finalité. La finalité spéculative à un emplacement est un énorme déblocage pour les applications hautes performances, qui peuvent afficher en toute confiance l’état mis à jour du monde immédiatement après la réception du bloc suivant. Ces propriétés font de MonadBFT une énorme avancée dans le consensus, et un complément digne à d’autres améliorations de la capitalisation dans Monad, notamment l’exécution asynchrone, l’exécution parallèle optimiste et MonadDb. Le reste de cet article sert de résumé de la façon dont les améliorations successives de HotStuff se sont construites les unes sur les autres, afin d’expliquer le problème que MonadBFT résout. Pour résumer : 1. HotStuff nous donne une complexité de communication linéaire afin que nous puissions avoir de grands ensembles de validateurs, mais ce n’est pas très efficace 2. Pipelined HotStuff nous donne de l’efficacité et une faible latence en proposant des blocs à chaque emplacement, mais souffre du problème des fourches arrière 3. MonadBFT nous donne une résistance à la fourche arrière et une finalité spéculative à un emplacement --- HotStuff : La complexité de la communication linéaire permet un grand nombre de nœuds Les algorithmes HotStuff se complètent au cours de plusieurs cycles de communication, qui prennent généralement la forme d’une communication « éventail out, fan in » directement des leaders aux validateurs puis aux leaders. Chaque tour commence par l’envoi d’un message direct par le leader aux autres validateurs, qui renvoient chacun un message signé attestant avoir reçu le message. À condition qu’une supermajorité (2/3) des validateurs renvoie une attestation, chaque tour se termine par l’agrégation par le leader des attestations signées dans un certificat de quorum (QC), qui sert de preuve que la supermajorité a attesté du message précédent. Les algorithmes de HotStuff ont plusieurs cycles de communication comme celui-ci. - Le premier message du leader est une proposition de bloc - Le deuxième message est le contrôle de la qualité de cette proposition de bloc - Le troisième message est un QC concernant le QC précédent (c’est-à-dire un QC-on-QC) - et ainsi de suite Si la procédure est interrompue à tout moment avant la finalité, le bloc ne se finalise pas et est éliminé ; Les transactions de ce bloc devront être réincluses dans le bloc suivant. Le protocole HotStuff original n’a pas de pipeline et comporte 3 tours de communication avant la finalité ; Le même validateur joue le rôle de leader pour chaque tour. --- Pipelined HotStuff : Un nouveau bloc à chaque emplacement augmente l’efficacité Le pipelining est ce que nous faisons tous intuitivement lorsque nous avons deux brassées de lessive à compléter. Au lieu d’attendre que la charge 1 termine le cycle complet avant de commencer la charge 2, dans le pipelining, nous mettons la charge 1 dans la sécheuse en même temps que la charge 2 va dans la laveuse. Vous pouvez considérer le HotStuff original comme cette approche naïve de la lessive (ne commencez pas sur le chargement 2 tant que le chargement 1 n’est pas complètement terminé), tandis que Pipelined HotStuff fait le comportement intuitif de faire progresser plusieurs brassées de lessive de manière échelonnée. Dans Pipelined HotStuff, nous échelonnons les propositions, de sorte qu’il y ait un nouveau bloc proposé à chaque tour, avec le nouveau bloc se greffant sur le message portant le QC du bloc précédent. Les propositions de blocs progressent vers la finalité au cours de plusieurs tours. Les avantages du pipelining sont considérables. Le pipelining augmente la densité des propositions de blocs, car une proposition de bloc est faite dans chaque créneau, ce qui augmente le débit et réduit le délai de finalité. Cependant, il y a un inconvénient majeur du pipelining, qui est mieux illustré par un exemple. Supposons que les leaders des blocs N, N+1 et N+2 soient Alice, Bob et Charlie. Si Bob manque son créneau, alors la proposition d’Alice sera également invalidée, car le message de Bob porte à la fois sa proposition et un QC pour la proposition d’Alice. Lorsque cela se produit, Charlie finit par être appelé à produire un bloc comme si la proposition d’Alice n’avait jamais existé. Nous appelons ce comportement « tail-forking », et il peut être considéré comme une mini-réorganisation de profondeur 1. La possibilité d’un tail-forking a des conséquences importantes, car les créneaux manqués ne sont pas nécessairement le fruit du hasard. S’il y a une opportunité d’extraire de la valeur en ré-minant le bloc d’Alice tout en réorganisant ou en omettant certaines transactions, alors Bob et Charlie peuvent s’entendre pour que Bob rate intentionnellement son emplacement, déclenchant ainsi une opportunité pour Charlie de réexploiter le bloc d’Alice. C’est un inconvénient important des protocoles HotStuff en pipeline (dont certains sont aujourd’hui dans le réseau principal). --- MonadBFT change cela MonadBFT est le premier protocole à permettre le pipelining tout en rendant l’algorithme résistant à la fourche de queue. Cette résistance à la fourche arrière provient de la procédure de repli lorsque Bob manque son emplacement, ce qui permet aux validateurs de rassembler leurs connaissances collectives de la proposition d’Alice et son niveau de consensus au sein de l’ensemble des validateurs. En particulier, sous MonadBFT, si Bob manque son créneau, alors la procédure de repli fait que les validateurs se communiquent entre eux avec des attestations signées indiquant s’ils ont vu le bloc d’Alice. Si la supermajorité atteste du blocage d’Alice, alors Charlie est obligé de proposer à nouveau le bloc d’Alice. Si Charlie souhaite proposer un bloc différent, il doit fournir une attestation signée par la majorité des validateurs attestant qu’il n’a pas vu le bloc d’Alice à temps. Dans le cas typique où Charlie propose à nouveau le bloc d’Alice, il peut ensuite proposer son bloc au tour suivant. Il en résulte deux propriétés importantes : la résistance à la fourche arrière et la finalité spéculative à fente unique. Nous avons déjà parlé de la résistance à la fourche de queue, mais comprenons l’impact sur la finalité. Comme précédemment, supposons que les leaders des blocs N, N+1 et N+2 sont Alice, Bob et Charlie. Sous Pipelined 2-Phase HotStuff - c’est-à-dire avant MonadBFT - en tant que validateur (ou nœud complet), vous ne pouvez pas finaliser la proposition de bloc d’Alice tant que vous n’avez pas vu la proposition de bloc de Charlie. Pourquoi? Parce que si vous finalisez dès que vous voyez la proposition de Bob, il est possible que Bob se moque de vous en vous transmettant UNIQUEMENT sa proposition, et qu’il prévoit en fait de ne pas envoyer sa proposition à tout le monde, manquant ainsi son créneau. Mais dans MonadBFT, dès que vous voyez la proposition de Bob, vous pouvez « spéculativement » finaliser la proposition d’Alice car la proposition de Bob inclut un QC sur la proposition d’Alice, ce qui est la preuve que les 2/3 du réseau attestent de la proposition d’Alice. Même si Bob se moque de vous en vous transmettant UNIQUEMENT sa proposition, et qu’il va finir par manquer son créneau, vous savez qu’une grande majorité de la chaîne a vu la proposition d’Alice et, lorsqu’ils participeront à la procédure de repli, signeront à nouveau la proposition d’Alice. La seule façon pour que le blocage d’Alice ne soit pas finalisé est si les validateurs tergiversent et signent en disant qu’ils n’ont pas vu le message d’Alice. Cette erreur est facilement prouvable - nous avons signé des messages contradictoires de leur part. Si la pénalité de l’équivoque est substantielle - et elle devrait l’être - cette finalité « spéculative » n’est en réalité pas vraiment si spéculative. --- À retenir MonadBFT est un développement extrêmement excitant pour le consensus, et constitue un complément digne d’autres améliorations de composition dans Monad, notamment l’exécution asynchrone, l’exécution parallèle optimiste et MonadDb. Félicitations à @MohammadMJalal1 et à @KushalBabel pour cette percée importante. MonadBFT sera bientôt mis en œuvre sur Monad Testnet, qui met actuellement en œuvre Pipelined 2-Phase HotStuff. Pour en savoir plus, consultez l’article de blog et l’article en lien dans le prochain tweet.