Solana-ontwikkelaars stellen grote herziening voor om verborgen risico te beperken
Ontwikkelaars van Solana hebben een conceptvoorstel gepresenteerd om één gezamenlijke protocolspecificatie in te voeren. Het doel is om onafhankelijk ontwikkelde validator-software betrouwbaarder en makkelijker te onderhouden te maken.
Wat er gebeurde
Op 30 oktober publiceerde Brennan Watt, CEO van Anza en maker van Agave, een conceptvoorstel voor Solana. Watt wil één autoritatieve specificatie vastleggen die beschrijft hoe de blockchain transacties verwerkt, blocks valideert en consensus bereikt. Dit moet voorkomen dat regels verspreid liggen over verschillende software en losse technische documenten.
Het voorstel ontstaat omdat Solana inmiddels meerdere validator-implementaties kent, zoals Firedancer van Jump Crypto, naast bestaande software als Agave. Verschillen in implementaties kunnen ertoe leiden dat validators identieke transacties anders verwerken. Dat kan het netwerk verstoren.
Tot nu toe lopen protocolwijzigingen via Solana Improvement Documents, of SIMDs. Die beschrijven upgrades per stuk, maar vormen geen geïntegreerde, gezaghebbende referentie. Developers moeten daardoor soms in bestaande code duiken of eerdere besluitvorming reconstrueren om te weten welke regels actief zijn.
In het nieuwe voorstel blijven SIMDs bestaan voor de discussie over upgrades. Technische wijzigingen worden daarna als bewerking op de gedeelde protocolspecificatie ingediend. Elke wijziging moet exact aangeven hoe die transacties, netwerkcommunicatie, consensus en andere functies beïnvloedt. De wijzigingen krijgen technische review en benodigde governance-goedkeuring voordat ze als actief deel van de specificatie op Mainnet komen.
Watt heeft een conceptspecificatie gepubliceerd die achttien onderdelen van Solana’s werking bestrijkt, zoals transactieverwerking, netwerkcommunicatie, consensus, fees en validatorbeloningen. De draft is echter beperkt tot een afgebakende periode van de blockchaingeschiedenis en gaat uit van een reeds vertrouwde startstaat. Er is dus nog werk nodig om latere upgrades en langdurige compatibiliteit te dekken. De concepttekst vermeldt ook details over trusted state en een referentie-epoch 1072, en waarschuwt dat het een ontwerp is en geen aangenomen protocolwijziging.
Waarom dit telt
Voor beleggers in SOL betekent dit dat ontwikkelaars proberen technische risico’s en onduidelijkheid tussen verschillende validatorimplementaties te verminderen. Een duidelijke, gezamenlijke specificatie kan de kans op netwerk-ongelijkheid en storingen verlagen en de ontwikkeling van alternatieve validatorsoftware vergemakkelijken.
Waar je op kunt letten
- Of en wanneer de draft wordt aangenomen als officiële specificatie
- Hoe ontwikkelteams reageren, waaronder teams achter Agave en Firedancer
- Of latere updates de beperkingen van de draft oplossen en compatibiliteit over tijd vastleggen