Comment Monad évolue-t-il l'EVM tout en préservant la décentralisation ? MonadBFT est l'algorithme de consensus utilisé dans Monad, c'est la première implémentation résistante aux tailforks de Hotstuff (qu'est-ce que cela signifie ?) Voici comment MonadBFT peut évoluer vers des milliers de validateurs tout en étant performant 🧵

1/7 Mécanismes de consensus Le mécanisme que les blockchains utilisent pour s'assurer que de nouveaux blocs sont approuvés par une majorité de validateurs. Les algorithmes de consensus jusqu'à présent ne peuvent pas évoluer au-delà de quelques centaines de validateurs, car la complexité augmente en fonction du carré du nombre de validateurs (dans la plupart des cas). Puisque chaque validateur communique avec tous les autres validateurs pour s'accorder sur les blocs : n validateurs x n messages = n au carré de messages. Ainsi, la complexité augmente considérablement avec le nombre de validateurs.

2/7 Hotstuff est un algorithme de consensus qui peut évoluer de manière linéaire (proportionnellement au nombre de validateurs) en évitant la messagerie de tous à tous et en permettant à un seul "leader" de communiquer avec tous les validateurs pour le consensus. Ainsi, Hotstuff peut évoluer plus efficacement que le consensus PBFT traditionnel, mais il est vulnérable aux attaques de tailforking. MonadBFT est la première implémentation résistante aux tailforks de Hotstuff.

3/7 Qu'est-ce que le tailforking ? Le tailforking se produit lorsque le prochain leader (validateur proposant le prochain bloc), intentionnellement ou accidentellement, omet d'inclure le QC du bloc valide du leader précédent dans sa proposition pour le nouveau bloc. (QC signifie certificat de quorum, qui est une preuve que tous les validateurs ont convenu du bloc précédent) En conséquence, le bloc précédent, bien qu'étant valide et ayant le soutien de la majorité, reste non engagé et finit par être orphelin ou remplacé par un bloc différent à la même hauteur. Cela perturbe le mécanisme d'incitation : les proposeurs honnêtes peuvent ne pas recevoir de récompenses de bloc ou de frais si leur bloc est ignoré, encourageant un comportement déloyal et affaiblissant la sécurité du réseau.

4/7 Comment fonctionne MonadBFT ? → Un leader (Alice) diffuse une proposition de bloc signée à tous les autres nœuds (diffusion), qui reconnaissent sa validité en envoyant une attestation signée au prochain leader Bob (réception). → Bob agrège les attestations en un "Certificat de Quorum" (QC) → Bob diffuse le QC à tous les nœuds, qui attestent de sa réception en envoyant un message au 3ème leader (Charlie) qui agrège ces attestations. Comme les attestations concernent un QC, nous appelons ce nouveau QC un QC-sur-QC. → Charlie envoie le QC-sur-QC à tout le monde. Dès la réception du QC-sur-QC, tout le monde sait que le bloc d'Alice a été finalisé.

5/7 Pipelining Dans l'histoire ci-dessus, Bob et Charlie n'envoient que des QC ou des QC-sur-QC, mais en réalité, les propositions sont en pipeline : le message de Bob contient à la fois le QC pour le bloc d'Alice et aussi le contenu d'un nouveau bloc. Le message de Charlie contient le QC pour le bloc de Bob (qui est un QC-sur-QC pour le bloc d'Alice) et contient également les transactions pour un nouveau bloc. Lorsque les validateurs envoient une attestation pour le message de Bob, ils attestent à la fois de la validité du bloc de Bob et de la validité du QC. Ce pipelining augmente le débit du réseau puisque chaque créneau produit un nouveau bloc.

6/7 Raptorcast : le protocole de propagation des blocs de Monad MonadBFT exige que le leader envoie des propositions de blocs à chaque validateur. Cependant, les blocs peuvent être assez volumineux : 10 000 transactions/s * 200 octets/tx = 2 Mo/s. Envoyer directement à 200 validateurs nécessiterait 400 Mo/s. Idéalement, les validateurs ne devraient pas avoir une bande passante de téléchargement aussi élevée. C'est là que Raptorcast entre en jeu. → Les blocs sont codés par effacement par le leader (le codage par effacement signifie que le message est décomposé en un ensemble de morceaux, et il peut être décodé à partir d'un sous-ensemble suffisamment grand de ces morceaux) → Le leader distribue un ensemble différent de morceaux à tous les validateurs du réseau (les validateurs ayant une mise plus élevée reçoivent proportionnellement plus) → Chaque validateur retransmet ses morceaux à tous les autres validateurs du réseau De cette manière, toute la bande passante du réseau est utilisée pour propager les propositions de blocs.