jeu. Oct 28th, 2021
    Mitia Goroshevsky, Free TON, Whitepaper, Meetup

    La session AMA, principalement consacrée à la discussion sur le Whitepaper Free TON, s’est tenue le 18 août avec la participation de Mitya Goroshevsky, Pavel Prigolovko et d’autres membres de la communauté.

    Les questions posées au CTO de TON Labs reflètent parfaitement l’état de la plateforme Free TON :

    • quand le réseau principal passera-t-il au nœud Rust ?
    • comment accélérer la mise en place de la Governance 2.0 ?
    • quel est le nouveau protocole de consensus qui devrait remplacer (ou plutôt compléter) BFT ?

    La réponse à la plupart d’entre elles a été donnée par Pavel Prigolovko, qui a résumé la situation avec le développement de Free TON comme suit :

    Ce qui est développé maintenant est une chose tellement nouvelle qu’il ne sera pas possible d’utiliser l’ancienne expérience pour estimer les délais.

    Déplacement vers un nœud Rust

    Concernant le passage à un nœud Rust, Mitya Goroshevsky a noté qu’il y avait deux options à considérer.

    La première est d’avancer maintenant sans mettre en place un nouveau protocole de consensus. Dans ce cas, il faudra réaliser un audit de sécurité et préparer un protocole de transition. L’estimation optimiste pour le calendrier est de trois mois, l’estimation pessimiste est la fin de l’année. Cependant, ce n’est pas une option que le CTO lui-même aime, car il considère que c’est une perte de temps de passer à un nouveau nœud pour le simple fait du déplacement.

    La deuxième option prend en compte la mise en œuvre initiale du nouveau consensus, qui peut prendre des mois à mettre en œuvre. Combien, personne n’est prêt à prévoir maintenant.

    • S’occuper du nœud Rust et du nouveau consensus — cela ne ralentit-il pas l’ensemble de la mise en œuvre de la Governance 2.0 ?

    L’horizon est une ligne imaginaire. Il est important que Gov 2.0 ne devienne pas cet horizon. Participants à la session AMA

    Mitya a répondu qu’une équipe complètement différente est engagée dans la mise en œuvre de la gestion décentralisée de la blockchain, il n’y a donc pas une telle dépendance. Quant à l’intensification de la transition vers une nouvelle gouvernance, ici beaucoup dépend de l’activité et de la disponibilité des parties intéressées. Le système de contrat intelligent SMV est déjà à un niveau de préparation élevé et peut être lancé.

    Nouvel algorithme de consensus

    La partie principale de la session AMA a été consacrée à ce sujet. Mitya a expliqué en détail les innovations dans le Whitepaper, que nous avons écrit, et a révélé les détails techniques de l’algorithme.

    Inconvénients du protocole existant

    Selon Mitya, pour le moment, la blockchain est divisée en threads. Beaucoup de gens les appellent à tort des fragments (shards), bien qu’il soit plus correct de les appeler des threads, dans lesquels un certain nombre de validateurs sont alloués. Ils parviennent à un consensus selon le protocole BFT, signent le bloc et envoient l’en-tête de bloc et le bloc lui-même à la masterchain.

    La chaîne maître s’assure que le bloc est signé, c’est-à-dire que le bloc est vérifié uniquement par le consensus BFT du thread correspondant, après quoi l’en-tête du bloc est ajouté au bloc de la chaîne maître et le bloc lui-même est supprimé. L’envoi d’un bloc d’un fil à la chaîne maître n’est nécessaire que pour une seule chose – pour confirmer le fait d’une diffusion.

    Il y a beaucoup de problèmes avec cette approche, le plus évident est la finalisation. Pour s’assurer que le bloc est finalisé, il faut attendre que son en-tête soit inclus dans le bloc masterchain, ce qui prend au moins 10 secondes, et généralement 20-30.

    Preuve de distribution du bloc

    Il est suggéré de ne pas attendre la fin du consensus. BFT est là et le laisse rester dans le fil. Une fois que l’assembleur a libéré un bloc, ce bloc est un candidat et est immédiatement envoyé à la diffusion. Dans ce cas, il n’est pas nécessaire d’attendre la finalisation au sein du thread.

    Il est important de prouver que le bloc lui-même a été envoyé au Broadcast sans envoyer le bloc lui-même à la masterchain.

    L’envoi de blocs à la chaîne principale limite l’évolutivité de l’ensemble du réseau.

    En utilisant la signature BLS de n’importe quel échantillon de validateurs, vous pouvez agréger la signature dans une structure de 32 octets. Connaissant les clés publiques de tous les validateurs, vous pouvez prouver qu’il y a une clé publique dans cette signature. Tous les validateurs qui reçoivent un bloc préparent cette signature BLS et l’envoient à un certain nombre de vérificateurs (dans Free TON, ils sont appelés protecteurs de diffusion). Les vérificateurs collectent les signatures, et lorsque 51 % des signatures auront été collectées, il sera possible de supposer que la diffusion a eu lieu.

    Il faut passer d’une preuve de stockage à une preuve de transfert. Mitia Goroshevsky

    Désormais, au lieu d’un bloc, cette structure de 32 octets est envoyée à la chaîne maître. L’ayant reçu, la chaîne maître vérifie rapidement qu’elle contient 51% des clés publiques de l’ensemble des validateurs de la chaîne de travail (workchain) donnée, et cela suffit pour chaque chaîne de travail.

    Validation de bloc

    L’étape finale de l’algorithme de consensus consiste à déterminer un sous-ensemble aléatoire de validateurs qui valident un bloc donné. Si l’un d’eux trouve une erreur, il écrit NACK, s’il n’y a pas d’erreur, alors ACK. La masterchain a besoin de recevoir un NACK afin de lancer la procédure de vérification de ce bloc avec la participation d’un grand nombre de validateurs, car s’il s’avère que ce bloc a été signé non pas par la majorité, mais par la minorité (moins de 51%), alors il est possible de slasher sans ambiguïté tous les validateurs de ce thread qui ont créé et signé le bloc.

    Personne ne sait qui ils sont jusqu’à ce que les auditeurs vérifient le bloc et certifient dans la réponse leur évaluation ACK ou NACK.

    NACK est envoyé à tous les nœuds de la masterchain et aux autres nœuds des workchains, c’est-à-dire à tous les nœuds Free TON existants. Tout cela se passe dans un bloc, avec la vitesse de validation dans le thread lui-même — 0,5-0,6 secondes.

    Avantages du nouveau protocole

    La probabilité d’une attaque réussie sur la blockchain dans ce cas est pratiquement zéro, car il s’avère qu’un seul validateur honnête (parmi ceux sélectionnés au hasard) suffit pour effectuer un contrôle minutieux d’un bloc qui soulève des doutes. De plus, avec le nombre de validateurs dont dispose désormais Free TON, cela devient insensé pour une attaque à 51%.

    En plus de la sécurité, la vitesse est également un avantage de l’algorithme. Grâce à la mise en œuvre du nouvel algorithme de consensus, Free TON est en train de devenir le réseau le plus productif et décentralisé parmi les blockchains existantes, dont chaque nœud garantit la sécurité de l’ensemble de la plateforme.

    15
    0