Nouvel article conjoint de Solana : Le mécanisme de leader concurrent de Solana résout le MEV et construit un moteur mondial de découverte des prix

Auteur : Anatoly Yakovenko

Compilé par : Deep Tide TechFlow

Vue d'ensemble

MEV est un problème fondamental dans les blockchains sans autorisation. Comme la plupart des blockchains sans autorisation, l’objectif de Solana est de minimiser le MEV que les opérateurs de chaîne extraient des utilisateurs.

L'approche de Solana consiste à réduire le MEV en maximisant la concurrence entre les dirigeants (c'est-à-dire les producteurs de blocs). Cela signifie raccourcir la durée des créneaux, réduire le nombre de créneaux programmés consécutivement par un seul leader et augmenter le nombre de leaders simultanés par créneau.

De manière générale, plus de leaders par seconde signifie que l'utilisateur dispose de plus d'options pour choisir la meilleure offre parmi les leaders entrants après avoir attendu T secondes. Plus de leaders signifie également qu'il coûte moins cher aux bons leaders de fournir un espace de bloc, ce qui permet aux utilisateurs de traiter plus facilement uniquement avec de bons leaders et d'exclure les transactions des mauvais leaders. Le marché doit décider de ce qui est bon et de ce qui est mauvais.

La vision plus large de Solana est de construire un moteur mondial de découverte de prix sans autorisation, capable de rivaliser avec les meilleures performances de n'importe quel échange centralisé (CEX).

Si un événement ayant un impact sur le marché se produit à Singapour, le message doit encore être transmis via fibre optique à la vitesse de la lumière jusqu'au CEX de New York. Avant que le message n'atteigne New York, le leader du réseau Solana aurait dû diffuser le message dans le bloc. À moins qu'une partition Internet physique ne se produise en même temps, le statut de Solana reflétera déjà le message au moment où il atteindra New York. Par conséquent, il ne devrait pas y avoir d’opportunité d’arbitrage entre CEX et Solana à New York.

Pour atteindre pleinement cet objectif, Solana a besoin de nombreux dirigeants simultanés avec des garanties de confirmation très optimistes.

Configuration de plusieurs leaders

Tout comme le planning des leaders actuel, le système configure chaque créneau avec 2 leaders au lieu d'1 leader. Pour différencier les deux leaders, un canal est étiqueté A et un canal est étiqueté B. A et B peuvent tourner indépendamment. La question à laquelle il faut répondre pour mettre en œuvre ce plan est la suivante :

• Et si les blocs A et B arrivent à des moments différents ou échouent ?

• Comment fusionner l'ordre de transaction dans les blocs A et B ?

• Comment allouer la capacité des blocs entre A et B ?

Transmission de blocs simultanés

Pour comprendre le processus spécifique, nous devons comprendre rapidement Turbine.

Le leader divise le bloc en fragments lors de sa construction. Un lot de 32 fragments est un code d'effacement de 32 fragments de code. Des lots de 64 fragments étaient signés au mercure et à la racine, et ceux-ci étaient liés au lot précédent.

Chaque fragment est envoyé via un chemin aléatoire déterministe indépendant. Le retransmetteur de chaque dernier lot signe la racine.

Du point de vue du récepteur, chaque récepteur doit recevoir 32 fragments du retransmetteur authentifié. Toutes les pièces manquantes sont réparées au hasard.

Ce nombre peut être augmenté ou diminué avec un impact minimal sur la latence.

En supposant que l'échantillonnage du chemin du fragment du retransmetteur soit suffisamment aléatoire et pondéré par les partages, les partages requis pour un réseau partitionné de manière coopérative seront bien supérieurs à ε partages, à la fois en termes d'heure d'arrivée et de données. Si le récepteur détecte que chaque lot de 32/64 fragments (configurables) arrive dans un délai T, alors il est fort probable que chaque nœud le fasse également. En effet, 32 nœuds aléatoires sont suffisamment grands et il est peu probable qu'ils se trouvent tous au hasard dans la même partition.

Si une partition se produit, un consensus doit la résoudre. Cela n'affecte pas la sécurité, mais est relativement lent.

Production multi-blocs

Si un seul bloc est transmis, chaque récepteur (y compris le prochain leader) verra les lots de fragments arriver pour chaque bloc. Si un bloc est incomplet pendant T millisecondes, le leader actuel sautera le bloc et construira un fork sans lui. Si le leader se trompe, tous les autres nœuds voteront sur le bloc et le bloc du leader sera ignoré. Le leader non fautif basculera immédiatement sur la fourchette la plus lourde indiquée par le vote.

Dans le cas de transferts multi-blocs, chaque nœud devra attendre jusqu'à T millisecondes avant de voter sur la partition de bloc observée. Avec deux leaders simultanés, les scénarios possibles sont : A, B ou A et B. Une latence supplémentaire n'est ajoutée que si le bloc est retardé. En fonctionnement normal, tous les blocs devraient arriver en même temps et chaque validateur peut voter dès que les deux arrivent. Par conséquent, T peut être proche de zéro en pratique.

Cette attaque doit se concentrer sur la question de savoir si un leader avec une très petite quantité de jetons mis en jeu peut transmettre un bloc légèrement plus tard sur la limite du slot, provoquant ainsi de manière fiable la division du réseau et le forçant à dépenser beaucoup de temps. Il est temps d'adopter un mécanisme de consensus pour résoudre les problèmes. Une partie du réseau votera pour A, une partie votera pour B et une partie du réseau votera à la fois pour A et B. Ces trois situations divisées doivent toutes être résolues par des mécanismes de consensus.

Plus précisément, l'objectif du quartier zéro devrait être de garantir que les nœuds récupèrent les blocs en même temps. Si un attaquant dispose d'un nœud coopérant dans le voisinage zéro, il peut transmettre normalement 31/64 fragments et permettre à l'attaquant de transmettre sélectivement le dernier fragment pour tenter de créer une partition. Les nœuds honnêtes peuvent détecter quels retransmetteurs sont en retard et transmettre les fragments manquants à n'importe quel nœud honnête dès qu'ils récupèrent le bloc. Les retransmetteurs peuvent continuer s'ils reçoivent le fragment de n'importe où ou s'ils le restaurent. Par conséquent, les blocs devraient être récupérés par tous les nœuds peu de temps après la récupération d’un nœud honnête. Des tests sont nécessaires pour déterminer combien de temps attendre, s'il est absolu ou pondéré par l'heure d'arrivée de chaque fragment, et si la réputation du nœud de mise doit être utilisée.

La probabilité d'avoir un leader coordonné et un retransmetteur dans chaque bloc est d'environ P parts de leader (64P parts de retransmetteur). Une participation de 1 % peut tenter des attaques par lots de ½ fragments organisés par l'attaquant en tant que leader. Par conséquent, la détection et l’atténuation doivent être suffisamment robustes.

Cette attaque a un impact minime sur le prochain leader car l'exécution asynchrone permet de reporter la capacité inutilisée. Ainsi, si le leader actuel force le leader suivant à sauter un emplacement et que le leader suivant a 4 emplacements consécutifs, la capacité inutilisée de l'emplacement ignoré peut être reportée, permettant au leader de réinclure la transaction d'emplacement ignorée.

Fusionner les blocs simultanés

Si un utilisateur envoie la même transaction aux leaders A et B afin d'augmenter les chances d'être inclus ou d'être le premier dans le bloc, cela entraînera un gaspillage de ressources. Si cela se produit, l’augmentation du nombre de leaders simultanés entraînera une amélioration des performances très limitée car ils traiteront simplement deux fois plus de transactions inutiles.

Pour éviter les transactions en double, le premier nombre de payeurs de frais déterminera dans quel canal leader la transaction est valide. Dans cet exemple, le bit le plus élevé sélectionnera A ou B. Les payeurs de frais doivent être affectés à un canal exclusif afin que le leader puisse être certain que le payeur de frais est valide et n'a pas dépensé tous ses lamports (la plus petite unité monétaire de la blockchain Solana) pour d'autres dirigeants.

Cela obligera le spammeur à payer au moins deux fois pour la transaction logiquement identique, mais afin d'augmenter la probabilité d'être la première transaction, le spammeur peut toujours envoyer la transaction logiquement identique.

Pour éviter ce comportement, les utilisateurs peuvent choisir d'inclure des frais supplémentaires de 100 % pour les commandes de gravure en plus des frais de priorité du leader. Les ordres comportant les frais les plus élevés sont exécutés en premier. Sinon, le classement premier entré, premier sorti (FIFO) est utilisé. En cas d'égalité, l'ordre est résolu à l'aide de permutations aléatoires déterministes. Par conséquent, il est plus rentable pour les spammeurs d’augmenter leurs frais de commande et d’exécuter en premier plutôt que de payer deux fois les frais d’inclusion.

Afin de gérer les séquences de transactions groupées et réorganisées, le système doit prendre en charge les transactions groupées, ce qui peut ajouter des frais de commande pour couvrir le coût de séquençage de l'ensemble de la séquence de transactions. Le payeur de frais n'est valable que sur son canal programmé, le forfait ne peut donc manipuler les séquences que sur son propre canal.

Alternativement, les frais de commande peuvent ne pas être nécessaires. Si l'ordre FIFO est utilisé et que les spammeurs se voient toujours facturer des frais prioritaires sur tous les canaux, il peut être possible de simplement permettre au marché de décider que payer N leaders pour augmenter le coût des opportunités d'inclusion équivaut probablement à payer le leader le plus proche. d'inclure d'abord la transaction dans le coût de l'opérateur.

Gérer les ressources de bloc

Dans un réseau blockchain, lorsqu'il y a deux leaders simultanés, chaque limite de capacité de bloc à l'échelle du système doit être distribuée de manière égale. Plus précisément, pas seulement la capacité totale, mais aussi chaque limite spécifique, telle que la limite de verrouillage en écriture : aucun compte ne peut écrire plus de 6 millions d'unités de calcul (CU), et chaque leader ne peut planifier que jusqu'à 24 millions d'UC. De cette manière, même dans le pire des cas, les blocs fusionnés ne dépasseront pas la limite de capacité totale du système.

Ce mécanisme peut entraîner des fluctuations des frais et une sous-utilisation des ressources, car les frais pour la priorité de planification seront déterminés par la capacité de chaque leader, et chaque leader a peu de connaissances sur l'état de planification des autres dirigeants concurrents.

Pour atténuer la sous-utilisation des ressources et les hausses de frais qui en résultent, toute capacité de bloc inutilisée doit être reportée sur les blocs futurs. Autrement dit, si le bloc fusionné actuel utilise moins de X sur les verrous d'écriture, le nombre total d'octets ou le nombre total d'unités de calcul (CU), K*X doit être ajouté au bloc suivant, où 0 < valeur maximum. L'exécution asynchrone peut être en retard d'une époque au maximum par rapport au sommet de la chaîne, de sorte que le roulement de capacité peut être assez agressif.

Sur la base des données de bloc récentes, la plupart des blocs sont généralement remplis à 80 %, tandis que la limite de verrouillage en écriture est bien inférieure à 50 %. D’une manière générale, il devrait toujours y avoir une certaine capacité disponible pour les futurs blocs. Étant donné que les blocs peuvent temporairement dépasser les limites de capacité, l'exécution doit avoir lieu de manière asynchrone par rapport au processus de consensus. Pour plus d’informations sur la proposition d’exécution asynchrone, consultez l’article APE.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!