Transférer le titre original "Limitations de mise à l'échelle des blockchains et quelles VM sont théoriquement les plus rapides"

TL;DR

Nous assistons à une évolution vers des serveurs uniques et puissants. Solana, Megaeth et le large éventail de séquenceurs uniques s’appuient tous sur une seule chose : un seul serveur à haut débit et à mémoire élevée (parmi ceux-ci, le non L2 sera toujours pratiquement le plus rapide).

J'ai récemment discuté avec un autre fondateur que je respecte beaucoup, il a mentionné que je devrais rédiger notre conversation.

Tout a commencé par une simple question: "Est-ce que Sonic parallélise l'exécution des transactions de quelque manière que ce soit?". La réponse est non. Et cela pourrait sembler être un choix étrange, puisque ces deux dernières années, si vous avez lu des articles sur la technologie VM, vous auriez vu la parallélisation presque partout. Alors pourquoi ne le faisons-nous pas?

Pour répondre à cette question, nous devons d’abord examiner comment l’ingénierie Sonic évalue ce sur quoi nous devrions travailler, nous avions une tonne de théories, qui sur le papier semblent pratiques, que nous voulions mettre en œuvre, mais les ressources physiques de l’équipe étaient limitées, alors comment choisir celle qui a le plus d’impact ? Ainsi, au lieu de travailler sur l’une de ces idées, l’équipe a décidé de passer un an à construire Aida, Aida est un outil incroyablement puissant qui nous permet de rejouer des blockchains entières (toutes) en quelques minutes au lieu de plusieurs mois avec des mesures de performance utiles. Cela signifie que nous pourrions prototyper, tester dans Aida et savoir très rapidement quelles théories tiennent la route et lesquelles ne tiennent pas.

Aida nous permet également un profilage assez puissant, ce qui conduit à des résultats tels que ;

Ainsi, avec ce qui précède en place, nous avons pu tester très rapidement et avec précision nos hypothèses de débit, nous avons donc entrepris de comparer uniquement en mémoire VM vs disque, exécution parallèle, RDMS vs KV vs fichier plat, super-ensembles, nouveaux modèles de consensus, etc

La plus grande amélioration a été DB, une augmentation de 800 %, suivie des super-ensembles, suivie par le consensus, et très bas sur cette liste, avec une modeste amélioration de 30 %, était l’exécution parallèle. Cela semble contre-intuitif, car un modèle mental pour quelque chose comme l’exécution parallèle semble intuitivement meilleur que les résultats. Alors, comment avons-nous parallélisé ? Peut-être avons-nous fait une erreur, le test était « Clairvoyance » la forme parfaite absolue d’ordre, un moteur qui connaît le tri et la parallélisation optimaux avant l’exécution (ce qui est déjà impossible dans la pratique, donc même les 30% sont plus élevés qu’ils ne devraient l’être).

Les machines virtuelles (VM) et les blockchains sont des composants très complexes, et souvent, nous mesurons les mauvaises métriques (ou nous ne mesurons pas du tout).

Ensuite, il m'a demandé: "D'où vient la vitesse de Solana alors? Ou, ce n'est pas pratiquement plus élevé que Sonic?". La réponse "Sonic est plus rapide que Solana, mais Sonic n'est pas plus rapide que ce que Solana peut être au maximum.".

Nous assistons à un mouvement vers des serveurs uniques puissants ; Solana, Megaeth, et la large gamme de séquenceurs uniques convergent tous vers une chose : un serveur unique à haut débit et haute mémoire (parmi ceux-ci, le non L2 sera toujours pratiquement le plus rapide). Cette solution, si elle est correctement optimisée, sera toujours plus rapide que plusieurs participants. Ainsi, le débit maximal optimisé de quelque chose comme Solana ou Megaeth serait plus élevé que celui de leur concurrent suivant le plus rapide qui utilise 2+ serveurs pour le consensus.

Alors la question suivante est probablement : pourquoi Sonic n'utilise-t-il pas des serveurs à leader unique ? Et la réponse ici est que ce n'est pas ce pour quoi nous optimisons. L'une de nos étoiles du nord, dont j'ai parlé en 2018, est que avec l'avènement des programmes intercommunicants, à un moment donné, un consensus est nécessaire. Supposons une intersection très fréquentée sans panneaux stop ni feux de signalisation et des centaines de voitures. La méthode la plus optimisée est que les voitures se “enregistrent” à l'intersection, puis se mettent d'accord sur un ordre de tri et la méthode la plus optimisée pour que chaque voiture se déplace pour maximiser le débit. Vous ne pouvez pas utiliser un système basé sur un leader ici, et vous ne pouvez pas supposer qu'une partie n'est pas malveillante, dans ce cas, le consensus Sonic est optimisé au point qu'il peut déjà valider sur un raspberry pi aujourd'hui sans perdre de débit, donc toutes les voitures peuvent être d'accord sur l'ordre basé sur le consensus Sonic. Sonic est optimisé pour les réseaux maillés.

Quoi qu’il en soit, des divagations aléatoires, j’espère que cela a aidé d’une manière ou d’une autre.

Avertissement :

1. Cet article est repris de [ Andre Cronje]. Tous les droits d'auteur appartiennent à l'auteur original [Andre Cronje]. Si des objections sont soulevées concernant cette reproduction, veuillez contacter le Porte Apprendreéquipe, et ils s'en chargeront rapidement.
2. Avertissement de responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
3. L'équipe Learn de la gate effectue des traductions de l'article dans d'autres langues. La copie, la distribution ou le plagiat des articles traduits est interdit sauf mention contraire.