Оголошення про обов’язкове оновлення основної мережі TRON: GreatVoyage-v4.8.1 (Democritus) вже випущено
Команда розробників ядра TRON офіційно запустила GreatVoyage-v4.8.1 (кодова назва Democritus) 4 лютого 2026 року. Це версія з обов’язковим оновленням. Всі повні вузли (включно з вузлами для створення блоків суперпредставниками) обов’язково мають завершити оновлення до 9 березня 2026 року 23:59 (час Сінгапуру / UTC+8). Недосягнення цієї дати призведе до неможливості синхронізувати блоки, що може спричинити переривання створення блоків або недоступність сервісів. I. У чому основна цінність цього оновлення? 1. Перший офіційний повний підтримка ARM64 архітектури + JDK 17 Це значний прорив у сумісності апаратного забезпечення екосистеми TRON. На ARM64 середовищі обов’язково використовувати JDK 17 + RocksDB v9.7.4 (повністю видалено підтримку LevelDB). Архітектура x86_64 продовжує вимагати JDK 8 (більш високі версії можуть спричинити несправності з анотаціями, NPE, помилками синхронізації тощо). Додаткові обчислення з плаваючою точкою виконуються через StrictMath і частково закодовані для ARM64, щоб забезпечити повну відповідність даних основної мережі x86. Для операторів вузлів, майн-пулів і організацій, які прагнуть використовувати дешевші хмарні сервери (Graviton, Ampere тощо), це означає значне зниження довгострокових апаратних витрат. 2. Вирівнювання поведінки TVM з Ethereum EIP-6780: SELFDESTRUCT — масштабне оновлення Реалізовано через TIP-6780 (параметри мережі #94, за замовчуванням вимкнено, потрібно голосування спільноти для увімкнення). Найважливіша зміна: лише у випадку виклику SELFDESTRUCT у тій же транзакції, що й створення контракту, дані облікового запису дійсно знищуються (код + збереження + сам обліковий запис). Якщо у наступних транзакціях викликається: 1/ Не буде видалено збереження та код, лише переказ балансу (включно з TRX, заставленим TRX, TRC10) 2/ Якщо цільова адреса — це сам контракт, баланс не буде знищено 3/ Витрати Energy на цю операцію зросли з 0 до 5000, що значно підвищує поріг зловживань Це ще більше зближує поведінку смарт-контрактів TRON з Ethereum EVM, що сприяє кращій інтеграції між ланцюгами, DeFi-протоколам і безпеці. 3. Повна зміцнення стабільності та безпеки мережевого рівня (P2P) 1/ Додано обмеження частоти повідомлень для одного Peer (SyncBlockChainMessage, FetchInvDataMessage — обмеження 3 QPS, P2P_DISCONNECT — 1 QPS), ефективно захищає від атак на виснаження ресурсів 2/ Виправлено проблему, коли light node неправильно визначав з’єднання як FORKED, замість більш точної позначки LIGHT_NODE_SYNC_FAIL 3/ Оптимізовано логування аномалій синхронізації gt lastNum / gt highNoFork, тепер виводиться лише ключова інформація, зменшено шум у логах 4/ Деталізовано коди причин роз’єднання: помилка підпису → BAD_BLOCK, невірна перевірка повідомлення Hello → INCOMPATIBLE_PROTOCOL тощо 5/ Всі спільні поля PeerConnection зроблено volatile + оптимізовано порядок присвоєння, щоб усунути проблеми з паралельною видимістю Ці зміни забезпечують більш стабільну синхронізацію вузлів у високонавантажених, міждержавних і складних мережевих умовах, підвищують стійкість до атак. 4. Значне покращення API та досвіду роботи з подіями 1/ Додано eth_getBlockReceipts — повертає всі транзакційні квитанції для цілого блоку 2/ Додано /wallet/getpaginatednowwitnesslist — дозволяє у реальному часі пагінувати та запитувати голоси свідків за поточний період (за кількістю голосів у порядку спадання) 3/ При невдачі eth_call повертає більш детальну інформацію про revert reason (відповідно до поведінки Ethereum) 4/ Оптимізовано продуктивність великих запитів до eth_getLogs / eth_getFilterLogs (видалено дублікати bitIndex, значно зменшено кількість безкорисних звернень до бази даних) 5/ Видалено перемикач для запису bloom-фільтрів, за замовчуванням дані зберігаються у section-bloom, що забезпечує цілісність історичних подій без залежності від налаштувань 5. Інші корисні покращення 1/ Повна стандартизація конфігураційних файлів: дозволяються лише поля з повного шаблону, інші вважаються недійсними або застарілими 2/ Функціонал SolidityNode і KeystoreFactory офіційно інтегровано у FullNode, запуск через –solidity / –keystore-factory для спрощення розгортання 3/ TIP-767: перенесено терміни закінчення пропозиції (параметри мережі #92) у мережеве управління 4/ Оптимізація управління ресурсами RocksDB, maxOpenFiles можна налаштувати (за замовчуванням 5000), щоб уникнути витоків пам’яті II. Рекомендований графік оновлення 1/ Вузли для створення блоків суперпредставниками → негайно плануйте поетапне оновлення без простоїв 2/ Постачальники DApp / RPC → оновлюйте в першу чергу, зосереджуючись на тестуванні eth_call, eth_getLogs, SELFDESTRUCT 3/ Звичайні повні вузли / сервісні дані → швидко плануйте оновлення, уникаючи крайньої дати 9 березня 4/ Розробка / тестове середовище → рекомендується синхронізувати оновлення, особливо у приватних ланцюгах з плаваючою точкою (pow тощо), враховуючи ARM64 Офіційні авторитетні матеріали (рекомендується одразу зберегти) • Завантаження релізу та GPG-підпис: • Детальний посібник з розгортання українською (рекомендується строго слідувати цим інструкціям): • Глибокий англійський аналіз (Medium): ARM-сумісність, вирівнювання EVM, підвищення стабільності мережі — Democritus є ключовим кроком у розвитку інфраструктури TRON 2026 року. @justinsuntron @trondao #TRONEcoStar
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Оголошення про обов’язкове оновлення основної мережі TRON: GreatVoyage-v4.8.1 (Democritus) вже випущено
Команда розробників ядра TRON офіційно запустила GreatVoyage-v4.8.1 (кодова назва Democritus) 4 лютого 2026 року. Це версія з обов’язковим оновленням.
Всі повні вузли (включно з вузлами для створення блоків суперпредставниками) обов’язково мають завершити оновлення до 9 березня 2026 року 23:59 (час Сінгапуру / UTC+8). Недосягнення цієї дати призведе до неможливості синхронізувати блоки, що може спричинити переривання створення блоків або недоступність сервісів.
I. У чому основна цінність цього оновлення?
1. Перший офіційний повний підтримка ARM64 архітектури + JDK 17
Це значний прорив у сумісності апаратного забезпечення екосистеми TRON.
На ARM64 середовищі обов’язково використовувати JDK 17 + RocksDB v9.7.4 (повністю видалено підтримку LevelDB).
Архітектура x86_64 продовжує вимагати JDK 8 (більш високі версії можуть спричинити несправності з анотаціями, NPE, помилками синхронізації тощо).
Додаткові обчислення з плаваючою точкою виконуються через StrictMath і частково закодовані для ARM64, щоб забезпечити повну відповідність даних основної мережі x86.
Для операторів вузлів, майн-пулів і організацій, які прагнуть використовувати дешевші хмарні сервери (Graviton, Ampere тощо), це означає значне зниження довгострокових апаратних витрат.
2. Вирівнювання поведінки TVM з Ethereum EIP-6780: SELFDESTRUCT — масштабне оновлення
Реалізовано через TIP-6780 (параметри мережі #94, за замовчуванням вимкнено, потрібно голосування спільноти для увімкнення).
Найважливіша зміна: лише у випадку виклику SELFDESTRUCT у тій же транзакції, що й створення контракту, дані облікового запису дійсно знищуються (код + збереження + сам обліковий запис).
Якщо у наступних транзакціях викликається:
1/ Не буде видалено збереження та код, лише переказ балансу (включно з TRX, заставленим TRX, TRC10)
2/ Якщо цільова адреса — це сам контракт, баланс не буде знищено
3/ Витрати Energy на цю операцію зросли з 0 до 5000, що значно підвищує поріг зловживань
Це ще більше зближує поведінку смарт-контрактів TRON з Ethereum EVM, що сприяє кращій інтеграції між ланцюгами, DeFi-протоколам і безпеці.
3. Повна зміцнення стабільності та безпеки мережевого рівня (P2P)
1/ Додано обмеження частоти повідомлень для одного Peer (SyncBlockChainMessage, FetchInvDataMessage — обмеження 3 QPS, P2P_DISCONNECT — 1 QPS), ефективно захищає від атак на виснаження ресурсів
2/ Виправлено проблему, коли light node неправильно визначав з’єднання як FORKED, замість більш точної позначки LIGHT_NODE_SYNC_FAIL
3/ Оптимізовано логування аномалій синхронізації gt lastNum / gt highNoFork, тепер виводиться лише ключова інформація, зменшено шум у логах
4/ Деталізовано коди причин роз’єднання: помилка підпису → BAD_BLOCK, невірна перевірка повідомлення Hello → INCOMPATIBLE_PROTOCOL тощо
5/ Всі спільні поля PeerConnection зроблено volatile + оптимізовано порядок присвоєння, щоб усунути проблеми з паралельною видимістю
Ці зміни забезпечують більш стабільну синхронізацію вузлів у високонавантажених, міждержавних і складних мережевих умовах, підвищують стійкість до атак.
4. Значне покращення API та досвіду роботи з подіями
1/ Додано eth_getBlockReceipts — повертає всі транзакційні квитанції для цілого блоку
2/ Додано /wallet/getpaginatednowwitnesslist — дозволяє у реальному часі пагінувати та запитувати голоси свідків за поточний період (за кількістю голосів у порядку спадання)
3/ При невдачі eth_call повертає більш детальну інформацію про revert reason (відповідно до поведінки Ethereum)
4/ Оптимізовано продуктивність великих запитів до eth_getLogs / eth_getFilterLogs (видалено дублікати bitIndex, значно зменшено кількість безкорисних звернень до бази даних)
5/ Видалено перемикач для запису bloom-фільтрів, за замовчуванням дані зберігаються у section-bloom, що забезпечує цілісність історичних подій без залежності від налаштувань
5. Інші корисні покращення
1/ Повна стандартизація конфігураційних файлів: дозволяються лише поля з повного шаблону, інші вважаються недійсними або застарілими
2/ Функціонал SolidityNode і KeystoreFactory офіційно інтегровано у FullNode, запуск через –solidity / –keystore-factory для спрощення розгортання
3/ TIP-767: перенесено терміни закінчення пропозиції (параметри мережі #92) у мережеве управління
4/ Оптимізація управління ресурсами RocksDB, maxOpenFiles можна налаштувати (за замовчуванням 5000), щоб уникнути витоків пам’яті
II. Рекомендований графік оновлення
1/ Вузли для створення блоків суперпредставниками → негайно плануйте поетапне оновлення без простоїв
2/ Постачальники DApp / RPC → оновлюйте в першу чергу, зосереджуючись на тестуванні eth_call, eth_getLogs, SELFDESTRUCT
3/ Звичайні повні вузли / сервісні дані → швидко плануйте оновлення, уникаючи крайньої дати 9 березня
4/ Розробка / тестове середовище → рекомендується синхронізувати оновлення, особливо у приватних ланцюгах з плаваючою точкою (pow тощо), враховуючи ARM64
Офіційні авторитетні матеріали (рекомендується одразу зберегти)
• Завантаження релізу та GPG-підпис:
• Детальний посібник з розгортання українською (рекомендується строго слідувати цим інструкціям):
• Глибокий англійський аналіз (Medium):
ARM-сумісність, вирівнювання EVM, підвищення стабільності мережі — Democritus є ключовим кроком у розвитку інфраструктури TRON 2026 року.
@justinsuntron @trondao #TRONEcoStar