Voorstel voor Solana plaatst gedeelde specificatie centraal bij protocolwijzigingen

Wat er gebeurde

Anza-ceo Brennan Watt opende op 30 oktober het voorstel om een gedeelde specificatie te gebruiken als één technisch dossier voor netwerkwijzigingen. Het voorstel staat nog ter discussie en verandert de regels van Solana niet.

Het huidige SIMD-proces blijft het beginpunt voor ideeën. Daarna zouden gedetailleerde wijzigingen als pull requests ingediend worden in de gedeelde specificatie. Technische review, goedkeuring van bijdragers en eventuele governance-approvals blijven bestaan. Een pull request zou samengevoegd worden wanneer de wijziging actief wordt op Mainnet.

Watt stelt dat individuele voorstellen nu verschillend kunnen beschrijven hoe het protocol zich gedraagt. Dat maakt het volgens hem moeilijker om alle onderdelen van het netwerk te overzien. Een gemeenschappelijke specificatie zou ook duidelijker maken welke eisen gelden voor ontwikkelaars die onafhankelijke implementaties maken.

Het conceptdocument telt 18 hoofdstukken en behandelt zaken zoals transacties, netwerk, state transitions en consensus. Het gebruikt Mainnet epoch 1072 als referentiepunt en gaat uit van een vertrouwde snapshot uit die epoch of een andere staat die geverifieerd is naar de root van die epoch. Het document definieert niet de eerste bank van epoch 1073 en stelt dat een latere Mainnet-activatie een herziene specificatie vereist.

Een gebruiker met de naam alnoki vroeg of een geschreven document interacties kan missen die in clientimplementaties zitten. Watt antwoordde dat sommige wijzigingen mogelijk een prototype naast de specificatie nodig hebben om vertrouwen te geven. Die uitwisseling stelde geen testvereisten vast.

Als er brede overeenstemming komt, zijn volgens Watt de volgende stappen om SIMD-0001 te updaten en te beslissen wat de baseline-specificatie wordt en waar die gehost wordt. Er is geen keuze gemaakt over adoptie of een implementatiedatum.

Waarom dit telt

Een gezamenlijke specificatie kan zorgen voor meer samenhang tussen voorstellen en voor duidelijkere regels voor ontwikkelaars. Voor beleggers betekent dit dat toekomstige protocolwijzigingen mogelijk centraler en technisch eenduidiger worden voorbereid, maar er is nog geen besluit of tijdpad.