AcasăCentrul de știri LBank
Solana triplează capacitatea de tranzacții cu actualizarea v1
solana-triples-transaction-capacity-with-v1-upgrade
Solana triplează capacitatea de tranzacții cu actualizarea v1
Solana intenționează să majoreze dimensiunea maximă a tranzacțiilor de la 1.232 de bytes la 4.096 de bytes miercuri, pe mainnet. Transaction v1 rămâne opțională, în timp ce formatele legacy și v0 continuă să funcționeze în limitele de dimensiune existente. Aplicațiile care citesc blocuri trebuie să suporte versiunea 1 sau riscă erori atunci când întâlnesc noul format. V1 elimină tabelele de căutare a adreselor și stochează limitele resurselor direct în metadatele de configurare ale fiecărei tranzacții. Roadmap-ul oficial al Solana indică activarea pe mainnet ca fiind în așteptare, ceea ce face ca programarea pentru 9 septembrie să poată fi încă modificată.
2026-09-07 Sursă:crypto.news

Solana vizează 9 septembrie pentru Tranzacția v1, un nou format care mărește dimensiunea serializată maximă a tranzacțiilor de la 1.232 de octeți la 4.096 de octeți.

Rezumat
  • Solana intenționează să mărească dimensiunea maximă a tranzacțiilor de la 1.232 de octeți la 4.096 de octeți miercuri pe mainnet.
  • Tranzacția v1 rămâne opțională, în timp ce formatele legacy și v0 continuă să funcționeze sub limitele de dimensiune existente.
  • Aplicațiile care citesc blocuri trebuie să suporte versiunea unu sau riscă erori la întâlnirea noului format.
  • V1 elimină tabelele de căutare a adreselor și stochează limitele de resurse direct în metadatele de configurare ale fiecărei tranzacții.
  • Foaia de parcurs oficială a Solana etichetează activarea pe mainnet ca fiind în așteptare, făcând ca programul din 9 septembrie să poată fi încă modificat.

Creșterea oferă dezvoltatorilor de aproximativ 3,3 ori mai mult spațiu pentru tranzacții. Foaia de parcurs oficială a Solana spune că capacitatea suplimentară poate găzdui dovezi cu cunoștință zero (zero-knowledge proofs), operațiuni multisemnatură mari, loturi și anumite scheme de semnături onchain.

Operațiunile mari trebuiau anterior împărțite în mai multe tranzacții atunci când instrucțiunile, semnăturile și informațiile contului depășeau limita de 1.232 de octeți. Acest proces adăuga complexitate, deoarece o tranzacție putea reuși în timp ce o altă etapă eșua.

Tranzacția v1 ar putea permite dezvoltatorilor să combine mai multe dintre aceste instrucțiuni într-o singură operațiune atomică. Fiecare instrucțiune fie reușește, fie întreaga tranzacție eșuează. Acest model ar putea beneficia rutele de tranzacționare, transferurile confidențiale, operațiunile cross-chain și aplicațiile care procesează dovezi criptografice complexe.

Actualizarea nu mărește limita Solana de 64 de conturi referențiate per tranzacție. Aplicațiile pot include mai multe date și instrucțiuni, dar nu pot interacționa automat cu mai multe conturi.

Tranzacțiile Solana existente vor rămâne valide

Tranzacția v1 este opțională. Portofelele și aplicațiile pot continua să trimită tranzacții legacy și v0 sub limita existentă de 1.232 de octeți. Utilizatorii nu trebuie să migreze tokenuri, să schimbe SOL sau să finalizeze o revendicare înainte de activare.

Dezvoltatorii trebuie să adopte în mod deliberat noul format pentru a accesa capacitatea sa mai mare. Documentația Solana identifică trei formate suportate: legacy, v0 și v1. Fiecare format organizează adresele conturilor și limitele de resurse diferit.

Formatul v0 utilizează tabele de căutare a adreselor (Address Lookup Tables, sau ALTs) pentru a reprezenta adresele conturilor prin indecși comprimați de un octet. V1 elimină ALTs și plasează adresele complete ale conturilor de 32 de octeți direct în cadrul tranzacției.

Aceasta creează un compromis. V1 oferă o capacitate generală mai mare, dar aplicațiile care se bazează în mare măsură pe tabelele de căutare ar putea consuma mai mulți octeți pentru a reprezenta aceleași conturi. Analiza tehnică a Solana a constatat că 90% dintre tranzacțiile eșantionate ar adăuga mai puțin de 1.400 de octeți atunci când sunt convertite de la v0 la v1.

Furnizorii de infrastructură trebuie să-și actualizeze software-ul

Principalul risc de compatibilitate se aplică serviciilor care citesc blocuri și tranzacții. Furnizorii de apeluri de procedură la distanță (remote procedure call - RPC) trebuie să-și seteze versiunea maximă suportată a tranzacțiilor la unu. În caz contrar, cererile ar putea eșua atunci când întâlnesc o tranzacție v1.

Indexatorii, exploratoarele de blocuri și serviciile de analiză trebuie, de asemenea, să-și modifice modul de recuperare a limitelor de resurse. Tranzacțiile legacy și v0 plasează limitele de calcul și setările taxelor de prioritate în instrucțiunile ComputeBudget. V1 le stochează într-o configurație dedicată a tranzacției.

Serviciile învechite ar putea, prin urmare, afișa informații incorecte. De exemplu, o exploratoare ar putea afișa o taxă de prioritate zero, chiar dacă utilizatorul a plătit una. Sponsorii de taxe și aplicațiile care verifică limitele tranzacțiilor trebuie să citească noua configurație, în loc să scaneze instrucțiunile de tip vechi.

Aplicațiile care trimit tranzacții v1 trebuie să seteze explicit limitele unităților de calcul și ale datelor încărcate, deoarece ambele sunt implicite zero. Dezvoltatorii ar trebui să testeze construcția, semnarea și decodificarea tranzacțiilor înainte de a muta traficul de producție la acest format.

9 septembrie rămâne o dată țintă de activare

Vicepreședintele Tehnologiei la Fundația Solana, Jacob Creech, a identificat 9 septembrie ca fiind data planificată pentru mainnet. Așa cum a raportat anterior crypto.news, actualizarea este inclusă în lansarea Agave 4.2 a Anza.

Cu toate acestea, foaia de parcurs oficială încă etichetează funcția mainnet ca fiind „neactivată”. De asemenea, se precizează că programul de lansare al Anza este „provizoriu și poate suferi modificări”. Testnet și devnet au activat deja funcția, conform celei mai recente pagini de stare a Fundației.

Creșterea dimensiunii provine din SIMD-0296, în timp ce SIMD-0385 definește formatul v1. Jacob Creech și Andrew Fitzgerald au fost co-autori ai ambelor propuneri.

Plafonul de 4.096 de octeți a fost selectat parțial deoarece patru kilobiți se potrivesc cu o dimensiune comună a paginii de memorie utilizată de hardware-ul validatorului. Tranzacțiile mai mari vor consuma, de asemenea, lățime de bandă suplimentară, deși actualizarea nu introduce nicio taxă separată percepută per octet.

Tranzacția v1 rămâne separată de reducerile de rentă ale Solana, țintele de slot mai scurte și redesenarea consensului Alpenglow. Într-o acoperire anterioară, crypto.news a raportat că Alpenglow vizează o finalitate de aproximativ 150 de milisecunde, octombrie rămânând un obiectiv de dezvoltare, mai degrabă decât o dată de activare garantată.