1/ SIMD-0186: Специфікація розміру завантажених транзакцій стандартизує, як Solana обчислює загальні дані облікового запису, які завантажує txn. Він визначає безпечний для консенсусу метод, щоб кожен клієнт обчислював однаковий розмір і робив розмір txn передбачуваним. Ось що він виправляє і як працює 🧵

2. Попередні реалізації розміру даних txn були неінтуїтивними та надто складними. Завантаження облікового запису програми, особливо за допомогою BPF Upgradeable Loader, мало складні крайові випадки, які ускладнювали незалежні реалізації.

3/ SIMD-0186 робить правила простими і зрозумілими: кожен завантажений рахунок рахується рівно один раз. Програми, що використовують BPF Upgradeable Loader, включають свої програмні дані, додають 64 байти на обліковий запис для метаданих, а ALT додають плоскі 8,248 байтів кожен.

4. Чому це важливо для розробників: завантажені дані облікового запису обмежені на tx, і новий розрахунок може бути значно вищим або нижчим для певних txn. Txn, які встановили ліміт розміру завантажених даних облікового запису, можуть потребувати відповідного коригування. Txns, які наближаються до їхнього максимального ліміту в 64 МБ, тепер можуть вийти з ладу.

5. За замовчуванням обмеження на передавання становить 64 МБ (16 тис. CU). Ви можете знизити його за допомогою інструкції з обчислення бюджету SetLoadedAccountsDataSizeLimit. Зниження цього ліміту може покращити планування завдяки нижчій вартості сплачених зборів.

6. Чому існує обмеження розміру завантажених даних? Подібно до ліміту CU на tx, валідатори отримують передбачуваний облік завантажених даних облікового запису txn. SIMD-0186 гарантує, що клієнти валідаторів досягають однакових результатів розміру даних txn, усуваючи ризик консенсусу та спрощуючи розробку клієнтів.