Mécanisme de leadership concurrent de Solana : Résoudre le MEV et construire un moteur mondial de découverte des prix
TechFlow SélectionTechFlow Sélection
Mécanisme de leadership concurrent de Solana : Résoudre le MEV et construire un moteur mondial de découverte des prix
La vision plus vaste de Solana est de créer un moteur mondial de découverte des prix sans autorisation, capable de rivaliser avec les meilleures performances de n'importe quelle bourse centralisée (CEX).
Dédié à des analyses Web3 approfondiesAuteur : Anatoly Yakovenko
Traduction : TechFlow
Aperçu
L'AME (valeur extractible par minage) est un problème fondamental dans les blockchains sans permission. Comme la plupart des blockchains sans permission, Solana vise à minimiser l'AME extraite par les opérateurs de chaîne depuis les utilisateurs.
L'approche adoptée par Solana consiste à réduire l'AME en maximisant la concurrence entre les leaders (producteurs de blocs). Cela implique de raccourcir le temps des fentes (slots), de réduire le nombre de fentes consécutifs attribués à un seul leader et d'augmenter le nombre de leaders concurrents par fente.
En général, plus il y a de leaders par seconde, plus les utilisateurs ont d'options après une attente de T secondes pour choisir l'offre la plus avantageuse parmi les leaders entrants. Un plus grand nombre de leaders signifie également que les bons leaders peuvent proposer de l'espace dans les blocs à moindre coût, ce qui permet aux utilisateurs de facilement privilégier les transactions avec ces leaders tout en excluant celles des mauvais leaders. Le marché devrait décider ce qui est bon ou mauvais.
La vision plus large de Solana est de construire un moteur mondial de découverte de prix sans permission capable de rivaliser avec les meilleures performances de n'importe quelle bourse centralisée (CEX).
Si un événement impactant le marché se produit à Singapour, l'information doit encore voyager via fibre optique à la vitesse de la lumière jusqu'à une CEX à New York. Avant même que le message n'atteigne New York, les leaders du réseau Solana devraient déjà avoir diffusé cette information dans leurs blocs. À moins qu'une partition physique d'Internet ne se produise simultanément, lorsque le message atteint New York, l'état de Solana aura déjà intégré cette information. Par conséquent, il ne devrait pas exister d'opportunité d'arbitrage entre la CEX new-yorkaise et Solana.
Pour atteindre pleinement cet objectif, Solana a besoin de nombreux leaders concurrents ainsi que de garanties de confirmation hautement optimistes.
Configurer plusieurs leaders
Comme pour le calendrier actuel des leaders, le système attribuera désormais deux leaders par fente au lieu d'un seul. Pour distinguer les deux leaders, un canal sera marqué A et l'autre B. A et B peuvent tourner indépendamment. La mise en œuvre de ce plan soulève plusieurs questions :
-
Que se passe-t-il si les blocs A et B arrivent à des moments différents ou échouent ?
-
Comment fusionner l'ordre des transactions contenues dans les blocs A et B ?
-
Comment répartir la capacité des blocs entre A et B ?
Transmission de blocs concurrents
Pour comprendre précisément le processus, examinons rapidement Turbine.
Lorsqu’un leader construit un bloc, il le divise en fragments. Un lot de 32 fragments forme un code d’effacement de 32 fragments codés. Un lot de 64 fragments est haché et sa racine signée ; celle-ci est liée au lot précédent.
Chaque fragment est envoyé via un chemin aléatoire déterministe indépendant. La racine de chaque dernier lot est signée par le relais (retransmetteur) correspondant.
Du point de vue du récepteur, chaque destinataire doit recevoir 32 fragments provenant de relais validés. Tout fragment manquant est récupéré aléatoirement.
Ce nombre peut être augmenté ou diminué avec peu d’impact sur la latence.
En supposant que l’échantillonnage des chemins de fragments par les relais soit suffisamment aléatoire et pondéré par parts, la quantité de parts nécessaire pour partitionner conjointement le réseau excédera largement ε parts, tant en termes de temps d’arrivée que de données. Si un récepteur détecte que 32/64 fragments par lot (configurable) sont arrivés dans un délai T, il est probable que tous les nœuds soient dans le même cas. En effet, 32 nœuds aléatoires forment un échantillon suffisamment grand pour qu’il soit improbable qu’ils se retrouvent tous aléatoirement dans la même partition.
En cas de partition, le consensus devra la résoudre. Cela n’affecte pas la sécurité, mais la résolution est relativement lente.
Production multiple de blocs
Dans le cas de la transmission d’un seul bloc, chaque récepteur (y compris le prochain leader) observe l’arrivée des lots de fragments de chaque bloc. Si un bloc n’est pas complet dans un délai de T millisecondes, le leader actuel passe ce bloc et construit un fork sans celui-ci. Si le leader fait erreur, tous les autres nœuds votent pour le bloc, et le bloc du leader est ignoré. Un leader non défaillant bascule immédiatement vers le fork le plus lourd indiqué par les votes.
Dans le cas de la transmission de blocs multiples, chaque nœud devra attendre jusqu’à T millisecondes avant de voter sur la partition observée des blocs. Avec deux leaders concurrents, les cas possibles sont : A, B, ou A et B. Le retard supplémentaire n’est ajouté qu’en cas de bloc retardé. En fonctionnement normal, tous les blocs devraient arriver simultanément, et chaque validateur pourrait voter immédiatement dès que les deux sont reçus. Ainsi, T pourrait pratiquement être proche de zéro.
La menace principale à contrer est la suivante : un leader disposant d’une très faible mise en jeu (stake) pourrait-il transmettre légèrement plus tard son bloc exactement à la limite de la fente, provoquant systématiquement une scission du réseau et forçant celui-ci à passer beaucoup de temps à résoudre le conflit via le mécanisme de consensus ? Une partie du réseau voterait pour A, une autre pour B, et une troisième pour A et B. Ces trois scénarios de division devraient être résolus par consensus.
Plus précisément, l’objectif devrait être d’assurer que tous les nœuds récupèrent les blocs simultanément. Si un attaquant dispose d’un nœud coordonné dans le voisinage zéro, il pourrait transmettre normalement 31/64 fragments et choisir sélectivement de retarder le dernier fragment afin de tenter de créer une partition. Les nœuds honnêtes peuvent détecter quels relais retardent et pousser immédiatement les fragments manquants vers eux dès qu’un nœud honnête récupère le bloc. Les relais peuvent continuer, s’ils reçoivent des fragments ou les reconstruisent depuis n’importe où. Ainsi, le bloc devrait être récupéré par tous les nœuds peu de temps après qu’un seul nœud honnête l’ait récupéré. Des tests seront nécessaires pour déterminer le temps d’attente optimal, s’il doit être absolu ou pondéré par l’heure d’arrivée de chaque fragment, et s’il convient d’utiliser la réputation des nœuds selon leur mise en jeu.
La probabilité que les leaders et relais collaborent dans chaque bloc est environ P_leader × stake (64 × P_relayer × stake). Un stake de 1 % permettrait à un attaquant d’essayer d’attaquer dans la moitié des lots de fragments programmés par lui en tant que leader. La détection et l’atténuation doivent donc être suffisamment robustes.
Cette attaque a peu d’impact sur le prochain leader, car l’exécution asynchrone permet de reporter la capacité inutilisée. Ainsi, si le leader actuel force le prochain leader à sauter une fente, et que ce dernier dispose de 4 fentes consécutives, la capacité inutilisée de la fente sautée peut être reportée, permettant au leader de réinclure les transactions de la fente sautée.
Fusion des blocs concurrents
Si un utilisateur envoie la même transaction simultanément aux leaders A et B pour augmenter ses chances d’inclusion ou pour figurer en tête du bloc, cela entraînera un gaspillage de ressources. Dans ce cas, augmenter le nombre de leaders concurrents aurait un effet marginal sur les performances, car ils traiteraient simplement deux fois plus de transactions inutiles.
Pour éviter les doublons, les N bits les plus significatifs du payeur de frais détermineront dans quel canal leader la transaction est valide. Dans cet exemple, le bit le plus élevé choisira A ou B. Le payeur de frais doit être affecté à un canal exclusif, afin que le leader puisse vérifier que le payeur est valide et n’a pas dépensé tous ses lamports (unité monétaire minimale sur la blockchain Solana) auprès d’un autre leader.
Cela obligera les spammeurs à payer au moins deux fois les frais pour des transactions logiquement identiques, bien qu'ils puissent néanmoins envoyer plusieurs fois la même transaction pour augmenter leur probabilité d'être traités en premier.
Pour dissuader ce comportement, l'utilisateur peut choisir d'ajouter, en plus des frais prioritaires vers le leader, un droit de commande entièrement brûlé (100 % destruction). Les commandes avec les frais les plus élevés sont exécutées en premier. Sinon, l'ordre FIFO (premier entré, premier sorti) s'applique. En cas d'égalité, un mélange déterministe aléatoire départage les ordres. Ainsi, pour un spammeur, augmenter ses frais de commande et être exécuté en premier est plus rentable que de payer deux fois les frais d'inclusion.
Pour gérer les paquets et les séquences de transactions réordonnées, le système doit prendre en charge les transactions groupées, auxquelles on peut ajouter un droit de commande couvrant le coût de tri de toute la séquence. Le payeur de frais n'est valide que dans son canal désigné, donc les regroupements ne peuvent manipuler la séquence que dans leur propre canal.
Alternativement, les droits de commande pourraient ne pas être nécessaires. Si le tri FIFO est utilisé et que les spammeurs paient toujours des frais prioritaires dans tous les canaux, il pourrait suffire de laisser le marché décider du coût d’envoi à N leaders pour augmenter les chances d’inclusion versus le coût d’envoi au leader le plus susceptible d’inclure la transaction en premier.
Gestion des ressources du bloc
Dans un réseau blockchain avec deux leaders concurrents, chaque limite de capacité de bloc au niveau système doit être divisée équitablement. Plus précisément, non seulement la capacité totale, mais aussi chaque limite spécifique — comme la limite d’écriture (aucun compte ne peut dépasser 6 millions d’unités de calcul (CUs)), et chaque leader ne pouvant programmer au maximum 24 millions de CUs de transactions. Ainsi, même dans le pire des cas, le bloc fusionné ne dépassera pas les limites totales du système.
Ce mécanisme pourrait entraîner des fluctuations de frais et une sous-utilisation des ressources, car les frais de priorité dépendront de la capacité de chaque leader, chacun ayant peu d’informations sur l’état de planification des autres leaders concurrents.
Pour atténuer la sous-utilisation des ressources et les hausses de frais qui en résultent, toute capacité inutilisée du bloc devrait être reportée aux blocs futurs. Autrement dit, si le bloc fusionné actuel utilise X unités de moins que la limite en écriture, en octets totaux ou en unités de calcul (CUs), alors K×X devrait être ajouté au bloc suivant, avec 0 < K < 1, jusqu’à un certain maximum. L’exécution asynchrone pouvant être en retard d’une époque par rapport au sommet de la chaîne, le report de capacité peut être assez agressif.
Selon les données récentes, la majorité des blocs sont généralement remplis à 80 %, tandis que la limite d’écriture est bien en dessous de 50 %. En général, les blocs futurs devraient toujours disposer d’une certaine capacité de secours. Étant donné qu’un bloc pourrait temporairement dépasser les limites de capacité, l’exécution doit être asynchrone par rapport au processus de consensus. Pour plus de détails sur la proposition d’exécution asynchrone, voir l'article APE.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
