NieuwsCryptoZcash NU7-upgrade verkort bloktijden naar 25 seconden en bevriezt Sprout-middelen

Zcash NU7-upgrade verkort bloktijden naar 25 seconden en bevriezt Sprout-middelen

Auteur: Coincentral·

Belangrijkste punten

  • •NU7 verminderde Zcash's doelblokinterval van 75 naar 25 seconden, wat de bevestigingswachttijden voor exchanges, wallets en betaaldiensten kan verkorten.
  • •De bloksubsidie daalde van 1,5625 ZEC naar ongeveer 0,52083333 ZEC, waardoor de geplande dagelijkse uitgifte ondanks snellere blokproductie vrijwel onveranderd blijft.
  • •Een nieuw Network Sustainability Mechanisme haalt 60% van de transactiekosten uit de omloop, waarbij de heruitgifte volgens planning begint op mainnetblok 8.939.664 rond februari 2031 binnen het bestaande maximum van 21 miljoen ZEC.
  • •De activatie maakte versie 4-transacties ongeldig, waardoor circa 12.224,21 ZEC in de oorspronkelijke afgeschermde Sprout-pool onbruikbaar werd zonder goedgekeurd herstelmechanisme.
  • •Mainnet-node-operatoren zijn verplicht Zebra 7.0.0 of hoger te draaien, aangezien oudere softwareversies de bijgewerkte consensuschain niet kunnen volgen.
Zcash NU7-upgrade verkort bloktijden naar 25 seconden en bevriezt Sprout-middelen

Zcash, een proof-of-work-netwerk gebouwd rond zero-knowledge-bewijzen voor afgeschermde betalingen, activeerde zijn NU7-netwerkupgrade op 6 november op mainnetblok 3.543.405, gemijnd om 02:34 UTC. De activatie verkortte het doelblokinterval van 75 naar 25 seconden en bracht wijzigingen met zich mee in mijnbeloningen, transactiekosten en de verwerking van afgeschermde transacties. Daarnaast werd een ouder transactieformaat uitgeschakeld, waardoor middelen in Zcash's oorspronkelijke Sprout-pool onbruikbaar werden.

Doelbloktijd daalt naar 25 seconden

Onder Zcash Improvement Proposal 218 verkort NU7 de beoogde wachttijd voor transactiebevestigingen met twee derde. Onder de vorige regels kwamen blokken ongeveer elke 75 seconden binnen. Het nieuwe doel van 25 seconden kan bevestigingsvertragingen voor exchanges, wallets en betaaldiensten verkorten. Een exchange die drie bevestigingen vereist, zou bijvoorbeeld kunnen zien dat de verwachte wachttijd daalt van 225 naar 75 seconden, hoewel individuele platforms hun eigen bevestigingseisen bepalen.

Het netwerk presteerde aanvankelijk boven het nieuwe doel. Volgens gegevens van ZecStats waren de eerste 225 blokken na de activatie gemiddeld ongeveer 39 seconden, per 04:59 UTC. Zoals in andere proof-of-work-systemen fluctueren de werkelijke intervallen rond het doel, omdat de vondst van blokken probabilistisch is, waarbij moeilijkheidsaanpassingen bedoeld zijn om het gemiddelde weer richting het doel te sturen.

Afzonderlijk onderzocht CoinCentral de ZEC-handelsactiviteit en ETF-stromen rond de NU7-activatie op 6 november. Die marktwaarnemingen bewijzen niet dat de upgrade prijsveranderingen heeft veroorzaakt.

NU7 verhoogt ook de theoretische transactiecapaciteit van Orchard van ongeveer 2,9 naar 6,6 transacties per seconde. De verbetering gaat gepaard met limieten op afgeschermde activiteit binnen afzonderlijke blokken. De Zcash Foundation schat dat deze limieten de synchronisatiebandbreedte van lichtgewicht wallets in het slechtste geval met ongeveer 37% verminderen, waardoor overmatige afgeschermde activiteit wordt beperkt die anders de verwerkingsvereisten van wallets zou kunnen verhogen.

Subsidieverlaging houdt uitgifte op schema

NU7 verlaagt de geplande bloksubsidie van 1,5625 ZEC naar ongeveer 0,52083333 ZEC. De verlaging compenseert het grotere aantal blokken dat onder het nieuwe doelinterval wordt geproduceerd, waardoor de geplande dagelijkse uitgifte vrijwel onveranderd blijft. Dit verschilt van NEAR Protocol's onlangs goedgekeurde voorstel tot uitgiftesverlaging, dat gericht is op lagere jaarlijkse tokencreatie over twee jaar.

De upgrade introduceert ook een Network Sustainability Mechanisme onder ZIP 235. Dit mechanisme haalt 60% van de transactiekosten uit de omloop, terwijl miners de resterende 40% behouden. De ingehouden kosten worden niet permanent verbrand. In plaats daarvan boekt het protocol ze als fondsen die in aanmerking komen voor toekomstige uitgifte. Onder ZIP 237 begint de heruitgifte op mainnetblok 8.939.664, verwacht rond februari 2031. Het mechanisme behoudt Zcash's vierjarige halveringsschema en het maximale aanbod van 21 miljoen ZEC.

Sprout uitgeschakeld en verouderde middelen vastgezet

Een andere belangrijke wijziging betreft Sprout, Zcash's oorspronkelijke protocol voor afgeschermde transacties, dat dateert van de lancering van het netwerk in 2016 en later werd bijgestaan door de afgeschermde pools Sapling en Orchard. Onder ZIP 2003 werden versie 4-transacties ongeldig toen NU7 activeerde, waardoor overdrachten vanuit de Sprout-pool onder de nieuwe consensusregels worden voorkomen.

ZecStats registreerde circa 12.224,21 ZEC die na de activatie in Sprout achterbleven. Deze middelen zijn momenteel onbruikbaar maar zijn niet permanent verbrand, en er is momenteel geen goedgekeurd herstelmechanisme waarmee houders erbij kunnen. Elke wijziging in die status zou zelf een nieuwe consensusregel vereisen die via Zcash's netwerkupgradeproces moet worden aangenomen. De transactiebeperking reikt verder dan Sprout: andere systemen die nog versie 4-transacties aanmaken, moeten migreren naar ondersteunde formaten. Versies 5 en 6 blijven geldig, en NU7 introduceert geen extra transactieformaat of afgeschermde pool.

Node-operatoren moeten compatibele software draaien

De softwarerelease van 22 oktober van de Zcash Foundation vereiste dat mainnet-node-operatoren vóór de activatie moesten upgraden naar Zebra 7.0.0. Oudere versies kunnen de bijgewerkte consensuschain niet volgen. De release bevatte ook zeven beveiligingsadviezen en synchronisatieverbeteringen.

Zcash's uitrol volgt op andere recente wijzigingen in blockchain-infrastructuur. Een rapport van 4 november over THORChain dat Zcash-swaps herstelde, beschreef een afzonderlijke protocolupdate die de handel op meerdere netwerken herstelde. Voor Zcash-infrastructuurleveranciers veranderen NU7's consensusvereisten onmiddellijk, terwijl de werkelijke beschikbaarheid van betalingen nog steeds afhankelijk is van compatibele software, netwerkprestaties en de bevestigingsbeleidsregels van elke dienst.