1/ SIMD-0186: Die Spezifikation der geladenen Transaktionsdatengröße standardisiert, wie Solana die gesamte Kontodatenmenge berechnet, die eine Transaktion lädt. Sie definiert eine konsenssichere Methode, sodass jeder Client die gleiche Größe berechnet und die Transaktionsgrößen vorhersagbar macht. Hier ist, was es behebt und wie es funktioniert 🧵

2/ Die vorherigen Implementierungen zur Größenbestimmung von Transaktionsdaten waren unintuitiv und übermäßig komplex. Das Laden von Programmkonten, insbesondere mit dem BPF Upgradeable Loader, hatte komplizierte Randfälle, die unabhängige Implementierungen erschwerten.

3/ SIMD-0186 macht die Regeln einfach und eindeutig: Jedes geladene Konto wird genau einmal gezählt. Programme, die den BPF Upgradeable Loader verwenden, fügen ihre Programmdaten hinzu, addieren 64 Bytes pro Konto für Metadaten und ALTs fügen jeweils pauschal 8.248 Bytes hinzu.

4/ Warum es für Entwickler wichtig ist: Die geladenen Kontodaten sind pro Transaktion begrenzt, und die neue Berechnung könnte für bestimmte Transaktionen erheblich höher oder niedriger sein. Transaktionen, die ihre Größe der geladenen Kontodaten begrenzen, müssen möglicherweise entsprechend angepasst werden. Transaktionen, die nahe an ihrem maximalen Limit von 64 MB sind, könnten jetzt fehlschlagen.

5/ Das standardmäßige tx-weite Limit beträgt 64 MB (16k CUs). Sie können es mit der Compute-Budget-Anweisung SetLoadedAccountsDataSizeLimit senken. Das Senken dieses Limits kann die Planung verbessern, da die Kosten pro gezahlten Gebühren niedriger sind.

6/ Warum gibt es ein Limit für die Größe der geladenen Daten? Ähnlich wie beim CU-Limit pro Transaktion erhalten Validatoren eine vorhersehbare Abrechnung für die geladenen Kontodaten einer Transaktion. SIMD-0186 stellt sicher, dass Validator-Clients identische Ergebnisse zur Datengröße von Transaktionen erzielen, wodurch das Konsensrisiko beseitigt und die Entwicklung von Clients vereinfacht wird.