1/ SIMD-0186: De specificatie voor de grootte van geladen transactiegegevens standaardiseert hoe Solana de totale accountgegevens berekent die een transactie laadt. Het definieert een consensusveilige methode zodat elke client dezelfde grootte berekent en maakt de transactie-grootte voorspelbaar. Dit is wat het oplost en hoe het werkt 🧵

2/ De eerdere implementaties voor txn-gegevensgrootte waren niet intuïtief en te complex. Het laden van programmarekeningen, vooral met de BPF Upgradeable Loader, had gecompliceerde randgevallen die onafhankelijke implementaties moeilijk maakten.

3/ SIMD-0186 maakt de regels eenvoudig en expliciet: elk geladen account wordt precies één keer geteld. Programma's die de BPF Upgradeable Loader gebruiken, bevatten hun programmadatum, voegen 64 bytes per account toe voor metadata en ALTs voegen elk een vast bedrag van 8.248 bytes toe.

4/ Waarom het belangrijk is voor ontwikkelaars: de geladen accountgegevens zijn beperkt per transactie en de nieuwe berekening kan aanzienlijk hoger of lager zijn voor bepaalde transacties. Transacties die hun limiet voor de grootte van geladen accountgegevens instellen, moeten mogelijk dienovereenkomstig aanpassen. Transacties die dicht bij hun maximale limiet van 64MB zijn, kunnen nu mislukken.

5/ De standaard tx-brede limiet is 64 MB (16k CUs). Je kunt deze verlagen met de SetLoadedAccountsDataSizeLimit compute budget instructie. Het verlagen van die limiet kan de planning verbeteren door lagere kosten per betaalde vergoedingen.

6/ Waarom een limiet voor de grootte van geladen gegevens? Vergelijkbaar met de per-tx CU-limiet, krijgen validators voorspelbare boekhouding voor de geladen accountgegevens van een transactie. SIMD-0186 zorgt ervoor dat validatorclients identieke resultaten voor de gegevensgrootte van transacties behalen, waardoor het consensusrisico wordt verwijderd en de ontwikkeling van clients wordt vereenvoudigd.