Kaj se natančno spreminja?
Solana skrajšuje ciljni čas proizvodnje bloka (slot time) na glavnem omrežju s 400 milisekund na 350 milisekund. Po poročanju CryptoSlate se je ta sprememba aktivirala na začetku epohe 1019, a si zaradi tako imenovanega enoepohskega zamika (one-epoch delay) omrežje ohranja obstoječe parametre, novi 350ms cilj pa začne dejansko veljati šele od epohe 1020.
Samo za pojasnitev pojmov: slot time je ciljni interval, v katerem naj bi se proizvedel en blok. Epoha je daljše časovno okno, sestavljeno iz številnih slotov, po katerem se uveljavijo nekatere spremembe parametrov. Compute units (računske enote) so mera tega, koliko računanja sme vsebovati blok.
Zakaj se hkrati znižuje omejitev računanja na blok?
To je jedro celotne zgodbe. Po CryptoSlate bloki dobijo krajši ciljni interval proizvodnje, ne pa tudi večjega dovoljenega obsega računanja na sekundo. V praksi to pomeni, da mora biti vsak posamezni blok, ko se bloki proizvajajo pogosteje, "lažji", da celotna obremenitev omrežja in validatorjev na enoto časa ostane približno konstantna.
Logika je preprosta: samo pospešitev blokov brez prilagoditve računske omejitve bi pomenila več računanja na sekundo, kar bi lahko obremenilo validatorje in ogrozilo stabilnost omrežja. Znižanje omejitve na blok je torej varovalka, ne stranski učinek.
Kako daleč so pri tem testna omrežja?
Po CryptoSlate je uvedba drugod dlje kot na glavnem omrežju:
| Omrežje | Stanje ciljnega časa bloka |
|---|---|
| Mainnet | prehod s 400 ms na 350 ms (dejansko od epohe 1020) |
| Testnet | efektivni cilj 200 ms |
| Devnet | cilj 300 ms, aktivirana vrata 250 ms, a zaenkrat še ne učinkujejo |
Testnet in Devnet torej služita kot predstopnja, kjer se agresivnejše vrednosti testirajo prej, preden pridejo na glavno omrežje.
Od kod izvira ta sprememba?
CryptoSlate se sklicuje na Solanin changelog s 6. avgusta, kjer so ti parametri opisani. Postopno skrajševanje časa bloka je del širše dolgoročne prizadevanja Solane za nižjo latenco omrežja.
Kaj zaenkrat še ni jasno?
Iz razpoložljivega vira ne izhaja natančen koledarski datum, kdaj bo nastopila epoha 1020, niti konkretna številčna vrednost, za koliko točno se znižuje omejitev računanja na blok. Prav tako iz tega vira ni dokazano, kakšen realen vpliv bo imela sprememba na latenco transakcij, provizije ali stabilnost omrežja za končne uporabnike. To se bo pokazalo šele glede na obnašanje glavnega omrežja po epohi 1020.
Na kaj biti pozoren pri tovrstnih spremembah?
Pri prilagoditvah parametrov blockchaina na ravni protokola je koristno spremljati tri stvari: ali se sprememba dejansko aktivira v napovedani epohi, ali ne pride do nenačrtovanih izpadov ali upočasnitve proizvodnje blokov, in ali se prepustnost (število transakcij na sekundo) realno spreminja ali ostaja stabilna. Prav zato, ker Solana tu namerno ohranja računanje na sekundo konstantno, sta glavni metriki za preverjanje bolj latenca in stabilnost kot pa surova prepustnost.
charliedesk si to spremembo beleži, da jo bo mogoče kasneje primerjati s tem, kar se bo na omrežju dejansko zgodilo po epohi 1020.