Brennan Watt, PDG d’Anza, propose une spécification de protocole en 18 chapitres pour Solana (SOL)

Crypto News and Tradfi News - COINOTAG · 2026-11-05T23:55:07.000Z

• Le 30 octobre, Brennan Watt, PDG d’Anza, a proposé de regrouper l’examen des SIMD de Solana dans une spécification de protocole commune. • Dans une note de développement publiée le 5 novembre, la Solana Foundation a confirmé l’ouverture des discussions sur l’unification de la spécification. • Le projet de spécification de protocole de Watt compte 18 chapitres et fait référence à l’époque 1072 du réseau principal. Un règlement unique, trois clients Comment un réseau dont les règles sont appliquées par trois clients validateurs développés indépendamment doit-il décider de ce que sont réellement ces règles ? C’est la question à laquelle sont désormais confrontés les développeurs de Solana (SOL), après que Brennan Watt, PDG d’Anza, a proposé de regrouper l’examen des changements de protocole dans une spécification commune unique. Le 30 octobre, Watt a publié sa proposition, intitulée « Passer à une spécification de protocole », sur le forum de discussion des documents d’amélioration de Solana (SIMD). Le 5 novembre, la Solana Foundation, qui coordonne le développement global de Solana, a publié une note de développement confirmant que les discussions sur l’unification de la spécification et la révision de la procédure d’examen avaient officiellement commencé. Jusqu’à présent, les documents SIMD servaient à la fois de mécanisme d’examen des changements de règles et, dans les faits, de référence décrivant le fonctionnement du protocole du réseau. Le débat s’ouvre alors que le cours de Solana (SOL) accuse un repli de 6,8 % au cours des dernières 24 heures. Ce mouvement de marché prolonge le recul sous les 100 $ plutôt que de constituer une réaction à la proposition elle-même ; les niveaux que surveillent désormais les traders figurent dans l’analyse technique de Solana. Selon Watt, le processus actuel permet de recueillir efficacement les propositions, mais laisse les règles déjà en vigueur dispersées dans le code des validateurs et dans les documents de proposition individuels. Il a écrit qu’un même comportement pouvait être décrit de façon légèrement différente à plusieurs endroits et qu’il était difficile de repérer toutes les parties concernées par un changement. Sa solution maintient les discussions sur les idées, l’examen technique et toute approbation de gouvernance nécessaire, tout en faisant passer le changement concret par une demande de fusion visant la spécification commune. Ainsi, différents logiciels de validation peuvent appliquer des règles identiques à partir d’une seule source examinée. Les demandes de fusion approuvées dans la spécification resteraient ouvertes jusqu’à l’activation d’un changement sur le réseau principal, afin que la documentation reste conforme aux règles effectivement appliquées. Les SIMD qui ne sont pas encore activés migreraient vers le nouveau format tout en conservant leurs identifiants. Le suivi des propositions existantes serait ainsi préservé, même si la spécification commune remplaçait les documents individuels comme référence.

• Anza CEO Brennan Watt proposed moving Solana SIMD review into a common protocol specification on October 30.
• The Solana Foundation confirmed the specification-unification discussion in a November 5 development notice.
• Watt's draft protocol specification spans 18 chapters and references mainnet epoch 1072.
One Rulebook, Three Clients
How should a network whose rules are enforced by three independently built validator clients decide what those rules actually are? That question now sits before Solana (SOL) developers after Anza CEO Brennan Watt proposed moving the review of protocol changes into a single shared specification. Watt published the proposal, titled “Move to a protocol specification,” on the Solana improvement document (SIMD) discussion board on October 30. The Solana Foundation, which coordinates Solana development at large, followed on November 5 with a development notice confirming that discussion on unifying the specification and revising the review procedure had formally begun. SIMD documents have until now served as both the review vehicle for rule changes and, in practice, the record of what the network's protocol does. The debate opens as the Solana (SOL) price absorbs a 6.8% pullback over the past 24 hours, a market move that extends a retreat below $100 rather than a reaction to the proposal itself; the levels traders now watch sit in Solana technical analysis. Watt's argument is that the existing process accumulates proposals well but leaves the rules already in force scattered across validator code and individual proposal documents. The same behavior, he wrote, can be described slightly differently in several places, and finding every area a change touches is difficult. His remedy keeps idea discussion, technical review and any required governance approval in place, while the concrete change itself moves into a pull request against the common specification, letting different validator software implement identical rules from one reviewed source. Approved specification pull requests would remain open until a change activates on mainnet, so the documentation stays aligned with the rules actually running. SIMDs not yet activated would migrate into the new format while keeping their identifiers, which preserves tracking for existing proposals even after the common specification becomes the reference instead of per-proposal documents.
Draft Anchored to Epoch 1072
Watt's draft Solana protocol specification runs to 18 chapters covering transactions and messages, network communication, state transitions and consensus, with forward-compatibility rules referenced to mainnet epoch 1072. The draft starts from a verified epoch snapshot or a state authenticated through that epoch's state root, which means trust in the starting state itself is an input supplied outside the document. Its scope is deliberately bounded: it sets no rules for replaying the chain from genesis, it stops at epoch 1072, and it does not define the first block of the next epoch. Anchoring the draft to one epoch keeps its rules forward-looking: changes after 1072 get checked against a fixed baseline rather than rewritten history. The Foundation's specification repository shares the same aim, consolidating consensus-critical rules into one complete and unambiguous reference that validator implementations can draw on. Until now, individual SIMD documents carried the concrete rule changes, a record that includes SIMD-0286, the proposal that raised the block compute limit to 100 million compute units. Earlier protocol work took a comparable single-target route with Alpenglow's 150 ms finality target. Client diversity is the backdrop the Foundation named in its notice: Agave, Firedancer and Mithril are separate codebases, and each piece of validator node software must reach the same outcome from the same input in transaction processing and consensus. The same rules govern how transactions are ordered and executed, the territory where effects such as maximal extractable value arise, and a divergence between implementations at that scale is not a paperwork problem; it can split the chain itself. The staking weight behind validator votes makes that risk financial as well as technical. For readers new to that side of the network, staking SOL on Solflare shows where client choices end up in practice.
Adoption and Timeline Undecided
Participant alnoki argued in the open thread that a written specification can miss internal dependencies visible in client implementations, and that no document alone may capture every interaction between them. Watt replied that sufficient confidence may require proof-of-concept implementations built alongside the documentation, and agreed that proposal identifiers should be assigned at the formal specification review stage. How to flag re-review when a specification changes mid-implementation remains under examination. The proposal itself sits at step one, with opinions being collected and revisions to the SIMD procedure document deferred until broad agreement; neither adoption of the change nor an application schedule has been set. The question therefore returns in its sharpest form: can one document describe Solana precisely enough that three independent implementations cannot disagree? On the record so far, the answer is still open.