„Solana v1“ gali sustabdyti RPC skaitytuvus ir pažeisti mokesčių viršutines ribas
Solana v1 operacijų formatas žada daugiau nei tris kartus daugiau vietos vienai operacijai, tačiau tam nepasiruošę RPC klientai, indeksuotojai, relayeriai ir mokesčių rėmėjai gali žlugti dviem labai skirtingais būdais: kai kurios sistemos sustoja, o kitos ir toliau veikia su netinkamais išteklių apribojimais.
„Solana“ tiesioginiame naujinimo puslapyje nuo rugsėjo 4 d. vis dar nurodoma, kad 1 versija nebuvo aktyvuota pagrindiniame tinkle. „Testnet“ yra aktyvus, o „devnet“ veikia 1140 epochoje. Rugpjūčio 28 d. paskelbtame „Solana“ pakeitimų žurnale teigiama, kad v1 operacijos bus „greitai“, todėl infrastruktūros operatoriams liko išankstinis aktyvinimo langas, kurį reikia atnaujinti.
V1 padidina maksimalią naudingąją apkrovą nuo 1 232 baitų iki 4 096 baitų, tai yra maždaug 3,3 karto. Pasenusios ir v0 operacijos išlaiko esamus apribojimus ir elgseną, todėl vartotojams ir programoms, kurios ir toliau naudoja tuos formatus, nereikia perkelti.
RPC vartotojai turi perduoti sveikąjį skaičių maxSupportedTransactionVersion: 1 naudojant getTransaction, getBlock arba blockSubscribe. Be šio pasirinkimo, v1 getTransaction užklausa grąžina klaidą -32015atlieka vieną v1 operaciją getBlock nepavyks visam blokui ir blockSubscribe skleidžia block: null ir nustoja judėti pirmoje paveiktoje vietoje.
Parametras tik nurodo RPC paslaugai aukščiausią formatą, kurį klientas gali iššifruoti. Ji neprašo v1 duomenų ir nekeičia, kaip grąžinamos senosios ir v0 operacijos.
Kiti gedimai yra tylesni. V1 perkelia skaičiavimo vienetų limitus, įkeltos paskyros duomenų limitus ir pirmumo mokesčius į transactionConfig objektas vietoj ComputeBudget nurodymus. Indeksuotojas, kuris nuolat nuskaito šias instrukcijas, praneš apie nulinį kiekvienos v1 operacijos biudžetą, nepakeldamas klaidos.
Geizerių ir gRPC vartotojai susiduria su susijusiais spąstais. Protobufas versioned vėliavėlė tinka tiek v0, tiek v1. Todėl pasenęs vartotojas gali pažymėti v1 kaip v0 ir išsaugoti tuščią biudžetą. Pataisymas yra atkurti protobuf šaknis ir patikrinti, ar nėra Message.config7 laukelis, prieš skaitant vėliavėlę.
Relayers, mokėtojai ir kiti serverio pasirašytojai taip pat turi pakeisti savo politikos patikras. Rėmėjas, kuris nuskaitydamas nustato mokesčio viršutinę ribą ComputeBudget instrukcijos nebeturi privalomos ribos, nes šios instrukcijos gali būti rodomos v1 versijoje, bet vykdomos kaip neveiksmingos. Serveriai turi identifikuoti 0x81 v1 priešdėlį ir įvesti mokesčių bei išteklių apribojimus transactionConfig. Tai yra programos valdymo gedimas, o ne sutarimo trūkumas ar įrodymas, kad lėšoms automatiškai kyla pavojus.
Onchain programos susiduria su sunkesniu apribojimu: Solana teigia, kad joks dabartinis sysvar arba syscall neatskleidžia v1 pranešimų konfigūracijos. Programos, kurios nustato savistabos elgesį ComputeBudget instrukcijos turi nustoti pasitikėti šiuo patikrinimu, kai v1 bus pradėtas naudoti.
Kam reikia naujovinti Solana v1
Minimalūs leidimai, kuriuose galima skaityti, apima @solana/kit 8.0.0, @solana/web3.js 3.0.0-rc.3, rūdys solana-* 4.2.x, Python solders 0.29.0 ir solana-go 1.23.0. 1.x web3.js eilutė gali nuskaityti 1 versiją iš 1.99.0-beta.0, bet negali jos sukurti, pasirašyti ar išsiųsti.
Jeloustouno vartotojams reikia bent yellowstone-grpc-proto 12.6.0, geizerio papildinys 15.1.1, gRPC klientas 12.0.0 arba @triton-one/yellowstone-grpc 6.0.0, priklausomai nuo jų krūvos.
1 versijos operacijų kūrimas yra neprivalomas. Komandos, kurios pasirenka, turi aiškiai nustatyti skaičiavimo vieneto ir įkeltos paskyros duomenų apribojimus, nes abiejose numatytosios vertės yra nulis, pašalina neoperaciją ComputeBudget instrukcijas, nustokite naudoti adresų paieškos lenteles ir naudokite base64 didesniems nei 1 232 baitų naudingiesiems kroviniams. Greitas terminas nėra visuotinis piniginės perkėlimas. Tai suderinamumo testas kiekvienai paslaugai, kuri gali skaityti, indeksuoti ar remti kažkieno v1 operaciją.
