SLV v0.9.911 Ajoute un support pour les opérations clientes de BAM, faisant progresser Solana vers un calque transparent d'exécution adapté à l'usage institutionnel

SLV v0.9.911 Ajoute un support pour les opérations clientes de BAM, faisant progresser Solana vers un calque transparent d'exécution adapté à l'usage institutionnel

SLV v0.9.911 Ajoute un support pour les opérations clientes de BAM, faisant progresser Solana vers un calque transparent d'exécution adapté à l'usage institutionnel
ELSOUL LABO B.V. (Siège: Amsterdam, Pays-Bas; PDG: Fumitake Kawasaki), Validators DAO, annonce la sortie de SLV V0.9.911, un cadre opérationnel ouvert pour les validateurs Solana. Cette version ajoute du soutien pour le lancement et l'exploitation du client Block Assembly Marketplace (BAM) développé par Jito Les labos.
Avec cette version, l'introduction et le changement du client BAM peuvent maintenant être traités de manière reproductible. Au lieu de s'appuyer sur des procédures spécifiques à l'exploitant ou sur une expertise opérationnelle individuelle, SLV permet aux validateurs de démarrer les opérations clientes BAM avec une seule commande.
Le validateur d'Epics DAO a déjà migré vers les opérations client BAM en utilisant SLV et est actuellement en production.

Ce que BAM vise à réaliser: confiance vérifiable dans la chaîne

BAM conceptual overview
Le marché de l'assemblage de blocs (BAM), développé par Jito Labs, est une initiative qui s'appuie sur Solanas déjà performante exécution sur la chaîne et cherche à permettre d'expliquer et de vérifier, après le fait, les règles en vertu desquelles les transactions ont été exécutées.
Par rapport à d'autres blockchains, Solana a un avantage évident dans le débit de transaction et la latence. Cependant, au fur et à mesure que le réseau arrive à maturité et que sa base d'utilisateurs s'étend, la question clé est de savoir si les transactions peuvent être traitées rapidement et si le processus d'exécution lui-même peut être expliqué en termes de logique et de règles par lesquelles il s'est produit.
En particulier, les institutions et les utilisateurs d'entreprises ne fonctionnent pas uniquement avec des capitaux propres. Ils gèrent les biens du client ou des gardiens et sont donc responsables non seulement des résultats, mais aussi du processus d'exécution lui-même. Ils sont tenus d'expliquer aux comités internes des risques, aux vérificateurs externes et, dans certains cas, aux organismes de réglementation pourquoi une opération a été exécutée dans des conditions et dans un ordre précis.
Ce n'est pas une préoccupation théorique. Sur les marchés financiers traditionnels, ces exigences sont déjà une pratique courante. La meilleure information sur l'exécution et la présentation de l'analyse des coûts de transaction sont des exemples typiques. Il ne suffit pas d'indiquer quel échange ou quel lieu a été utilisé; la logique d'exécution elle-même doit être expliquée.
Dans les environnements d'exécution en chaîne d'aujourd'hui, il est difficile pour des tiers de vérifier pourquoi les transactions ont été commandées d'une manière particulière ou quelle logique a déterminé leur placement. Indépendamment de l'intention, ce manque d'explication suffit à décourager la stake institutionnelle.
BAM s'attaque à ce problème en rendant la commande de transaction vérifiable par des mécanismes cryptographiques. Bien qu'il soit possible de prouver que les transactions ont été ordonnées selon une logique définie, les opérateurs de nœuds BAM eux-mêmes ne peuvent pas inspecter le contenu des transactions ou manipuler arbitrairement l'ordre.
Ce que BAM vise finalement à établir n'est pas un modèle qui repose sur la confiance de certains opérateurs, mais un modèle dans lequel la logique d'exécution elle-même est vérifiable. Cette exécution sur la chaîne va au-delà d'être simplement rapide, vers un environnement qui est explicable, vérifiable et approprié pour les rapports officiels.

Le défi actuel: planning flexible mais opaque

Aujourd'hui, Solana permet un haut degré de liberté dans la façon dont la commande de transaction est traitée. Plusieurs planificateurs fonctionnent en parallèle, chacun avec une logique, des caractéristiques de calendrier et des stratégies de priorisation différentes.
Bien que cette diversité permette l'expérimentation et l'optimisation, il est également difficile d'expliquer systématiquement, d'un point de vue externe, qui règle l'ordre des transactions. Selon le client, le chemin d'acheminement ou la configuration opérationnelle, il n'est pas toujours possible d'exclure les décisions de commande qui ne peuvent pas être observées de l'extérieur.
Ce n'est pas une intention malveillante. Même lorsque tous les opérateurs agissent de bonne foi, un environnement d'exécution qui ne peut être expliqué ou vérifié est intrinsèquement incompatible avec les exigences des institutions et des entreprises.
Même si les problèmes ne se manifestent pas immédiatement, cette opacité s'accumule comme risque d'exécution et incertitude de vérification. En conséquence, l'utilisation en chaîne reste en grande partie limitée aux utilisateurs individuels et aux applications expérimentales, tandis que le capital à grande échelle et l'adoption d'entreprises ont du mal à se concrétiser.

Leçons de Ethereums Precedent

Des défis similaires sont déjà apparus dans l'écosystème d'Ethereum. Avec l'introduction de la séparation entre les proposants et les constructeurs, la concurrence dans la construction de blocs a augmenté, mais cela a également conduit à une concentration des constructeurs et à la privatisation des flux d'ordre.
Alors que les utilisateurs et les applications cherchaient une meilleure exécution, ils s'appuyaient de plus en plus sur des relations privées avec des constructeurs spécifiques, ce qui rendait la commande de transactions plus difficile à observer de l'extérieur. Bien que cette structure ait parfois amélioré l'efficacité à court terme, elle a finalement entraîné une plus grande opacité et une centralisation.
Au sein de la communauté Ethereum aujourd'hui, des efforts sont en cours pour rétablir la transparence grâce à des approches telles que l'édification de blocs basés sur les ETE. Cela reflète une reconnaissance post-hoc de l'importance de l'explication à la couche d'exécution.
BAM est conçu en tenant compte de ces précédents, en intégrant la vérifiabilité et la transparence dès le départ plutôt que de tenter de les moderniser plus tard.

Progrès accomplis dans la mise en œuvre SLV V0.9.911

Les principes de conception des BAM's ne comptent que s'ils peuvent être appliqués et appliqués dans la pratique. Même un système bien conçu ne parvient pas à améliorer la transparence s'il reste difficile de le déployer ou d'y accéder uniquement pour un petit nombre d'opérateurs.
SLV V0.9.911 intègre le lancement et le fonctionnement du client BAM SLVC'est le flux de travail standard. Cela élimine la dépendance à l'égard de l'expertise individuelle de l'exploitant et des procédures ad hoc lors du passage à BAM.
Être capable de se déployer d'une manière reproductible est une condition préalable à l'adoption généralisée d'une couche d'exécution vérifiable. Ce communiqué représente une étape concrète vers l'intégration de BAM dans l'infrastructure opérationnelle de Solana en tant que mise en œuvre, pas seulement en tant que concept.

État d ' avancement validateur d'Epics DAO

Epics DAO validator running BAM client
Le validateur d'Epics DAO a déjà migré vers les opérations client BAM en utilisant SLV et continue de fonctionner en production. Cela démontre que BAM ne se limite pas à la conception conceptuelle, mais fonctionne activement dans le cadre des opérations de validation réelles.
De plus, du point de vue des opérations de validateur, l'utilisation du client BAM permet de séparer la logique de l'ingestion de transaction et de la commande des processus d'exécution et de vote de base du validateur.
Traditionnellement, la charge associée à l'entrée de transaction et à l'ordre a été étroitement couplée avec le chemin d'exécution du validateur. Avec une configuration basée sur BAM, cependant, la charge de traitement liée à la réception et à la programmation des transactions peut être traitée comme une préoccupation distincte.
Cela permet aux validateurs de se concentrer plus directement sur l'exécution et le vote, tout en permettant une conception opérationnelle dans laquelle les charges de travail avec des caractéristiques différentes sont traitées séparément. Cela n'affirme pas une amélioration directe du rendement, mais souligne plutôt que la séparation des responsabilités opérationnelles et des domaines de charge élargit les options de conception disponibles pour les opérations de validation.

L'avenir

La transparence vérifiable de l'ordre et de l'exécution des transactions que BAM vise à fournir est un élément clé pour faire progresser Solana vers un environnement d'exécution adapté à l'utilisation institutionnelle et d'entreprise.
SLV sert de base pour traduire cette orientation en opérations pratiques. A l'avenir, des validateurs, RPC l'infrastructure, le réseautage et les applications décentralisées seront traités non pas comme des cibles d'optimisation isolées, mais comme des composantes interdépendantes qui déterminent collectivement la qualité de l'exécution et la confiance. Par cette approche, l'infrastructure opérationnelle de Solana continuera d'évoluer.