Stellar sleutelt tegelijk aan twee gevoelige delen van zijn netwerk: consensus onder zware belasting en het upgraden van smart contracts. Protocol 28, met de naam Adapter, moet beide processen minder kwetsbaar maken.
De
Stellar Development Foundation
presenteerde de upgrade op 13 augustus. Adapter bestaat vooral uit drie wijzigingen: CAP-83, CAP-85 en CAP-86.
CAP-83 laat validators eerder doorwerken
De opvallendste verandering onder de motorkap zit in CAP-83.
Validators moeten nu tijdens consensus eerst een volledige set transacties ontvangen voordat bepaalde stappen verder kunnen. Als die data langzaam aankomt, kan dat het proces vertragen.
CAP-83 laat validators eerder beginnen met stemmen. Een late of ongeldige transactieset kan bovendien expliciet worden laten vallen, zodat consensus daar niet onnodig op blijft wachten.
Dat moet Stellar vooral helpen wanneer het netwerk zwaarder wordt belast.
De Foundation zegt wel dat de volledige prestatiewinst niet onmiddellijk na de mainnetupgrade zichtbaar wordt. Parallel downloaden van transactiesets wordt daarna geleidelijk ingeschakeld.
Adapter zet niet simpelweg een hogere snelheidslimiet aan. Het verandert hoe validators omgaan met transactiedata wanneer het druk wordt.
Eén update kan straks hele groepen contracten raken
Voor ontwikkelaars zit de grotere verandering waarschijnlijk in CAP-85.
Veel protocollen gebruiken meerdere exemplaren van hetzelfde
smart contract. Wanneer de gedeelde code moet worden aangepast, moeten die contracten nu vaak afzonderlijk worden bijgewerkt.
Dat creëert een ongemakkelijke periode waarin een deel al nieuwe code gebruikt en een ander deel nog de oude versie draait.
CAP-85 introduceert daarom een gedeelde, extern beheerde verwijzing naar uitvoerbare contractcode.
Wordt die centrale verwijzing aangepast, dan kunnen alle contracten die ernaar verwijzen in dezelfde atomische handeling meegaan. De update slaagt volledig of helemaal niet.
Voor grote applicaties verkleint dat het risico dat verschillende contractonderdelen tijdelijk uit de pas lopen.
CAP-86 pakt een ander upgradeprobleem aan
Nieuwe contractcode is maar de helft van het verhaal.
Ook bestaande data moet soms veranderen. Een ontwikkelaar kan bijvoorbeeld een veld toevoegen of een datastructuur anders indelen.
Dat kan nu problemen veroorzaken wanneer opgeslagen informatie niet exact overeenkomt met het formaat dat nieuwe code verwacht. Stellar zegt dat dit in bekende gevallen contracten zelfs heeft vastgezet.
CAP-86 voegt daarom nieuwe functies toe die beter omgaan met ontbrekende of extra velden.
Ontwikkelaars krijgen daarmee een vaste route om contractdata geleidelijk naar een nieuw schema te migreren. De bestaande functies blijven beschikbaar.
Adapter is vooral een upgrade voor bouwers
Daarmee is Protocol 28 minder spectaculair voor iemand die alleen
XLM verstuurt.
Twee van de drie grote wijzigingen richten zich rechtstreeks op Soroban, Stellars platform voor smart contracts. De derde versterkt het consensusproces waarop de rest van het netwerk draait.
Dat past bij de bredere technische koers die Stellar eerder inzette. CryptoBenelux schreef al over
Stellars uitbreiding van Soroban en netwerkcapaciteit.
Hoe groter applicaties worden, hoe duurder een fout tijdens een contractupdate kan uitpakken. Vooral bij
blockchain-toepassingen die betalingen of getokeniseerde activa beheren, telt een half uitgevoerde update snel zwaar.
Niet alles verandert automatisch op 16 september
De software komt in fases beschikbaar.
Stellar Core staat vanaf 13 augustus als stabiele Protocol 28-release gepland. Andere onderdelen en SDK's volgen volgens Stellar tussen 13 en 21 augustus.
Daarna volgt op 27 augustus om 17:00 UTC de geplande testnetstemming.
De mainnetstemming staat voor 16 september 2026 om 17:00 UTC. Validators moeten hun systemen voor die stap bijwerken en voorbereiden.
Dat maakt 16 september geen automatische lanceringsdatum die losstaat van het netwerk.
Protocolwijzigingen worden door Stellar via een upgradevote ingevoerd. Adapter is dus technisch klaar voor uitrol, maar mainnet moet de stap nog daadwerkelijk maken.
Validators krijgen ook een nieuwe praktische eis
CAP-83 brengt daarnaast een detail mee dat operators niet kunnen negeren.
Stellar waarschuwt dat validators vanaf Protocol 28 hun klokken goed moeten synchroniseren via NTP. Slechte tijdssynchronisatie kan volgens de Foundation juist de netwerkprestaties verslechteren.
Dat is een kleine regel met een vrij directe boodschap: snellere consensus werkt alleen wanneer de machines die eraan deelnemen dezelfde tijd betrouwbaar volgen.
Voor gewone SDK-gebruikers is de overstap veel eenvoudiger. Stellar verwacht dat de meeste integraties vooral hun SDK hoeven bij te werken.
De echte winst zit bij applicaties die groter worden
Protocol 28 verandert Stellar niet in één klap in een ander netwerk.
De upgrade pakt drie problemen aan die vooral zichtbaar worden wanneer gebruik groeit: transactiedata die consensus ophoudt, contractgroepen die lastig tegelijk te upgraden zijn en opgeslagen data die oude softwarestructuren volgt.
Dat klinkt minder spannend dan een nieuwe token of verdubbelde TPS-claim.
Voor ontwikkelaars die financiële applicaties jarenlang moeten onderhouden, zijn dit juist de wijzigingen die tellen wanneer er echt geld in de contracten zit.
Op 27 augustus krijgt Adapter zijn eerste netwerktest. Op 16 september volgt de stemming die bepaalt of Protocol 28 ook op mainnet de standaard wordt.