BNB Chain активував хардфорк Pasteur в основній мережі BNB Smart Chain о 02:30 за UTC 25 серпня, запровадивши три зміни, зосереджені на безпеці мостів, авторизації валідаторів та пропускній здатності блоків.
Мережа підтвердила, що Pasteur працює після запланованої активації. BSC продовжувала генерувати блоки з існуючим інтервалом 450 мілісекунд, причому одразу після оновлення не було публічно повідомлено про значні збої.
Pasteur об'єднує BEP-682, BEP-695 та BEP-675 в рамках ширшого плану оновлення BEP-673. Ці зміни працювали в тестовій мережі Chapel BSC з 21 липня, перш ніж досягти основної мережі.
BEP-682 змінює спосіб, яким BSC перевіряє легкі блоки, що надсилаються через кросчейн-інфраструктуру. До Pasteur процес перевірки не відхиляв явно дубльовані записи в наданому списку валідаторів.
Таким чином, сформований запит міг включати одного й того ж валідатора більше одного разу. Окремий підрахунок цих записів ризикував створити враження, що схвалення мосту має підтримку більшої кількості незалежних валідаторів, ніж це було насправді.
Pasteur відхиляє повторювані записи валідаторів перед обчисленням того, чи досягнуто необхідного порогу голосування. Кожне схвалення тепер має надходити від окремого валідатора, щоб легкий блок відповідав вимозі супербільшості.
BNB Chain не повідомляв, що зловмисники експлуатували цей недолік, або не приписував йому жодних попередніх втрат активів. Зміна є превентивною корекцією перевірки мостів, а не відповіддю на розкриту крадіжку.
Кросчейн-інфраструктура залишається головною проблемою безпеки в децентралізованих мережах. У пов'язаних матеріалах атаки на мости спричинили мільярдні кумулятивні збитки через скомпрометовані ключі, недоліки контрактів та слабку перевірку повідомлень.
BEP-695 закриває прогалини, пов'язані з ротацією ключів валідаторів, штрафами та управлінням. Коли валідатор замінює свій ключ оператора, попередній ключ тепер втрачає свої права на управління.
Пропозиція також запобігає валідаторам уникати очікуваних штрафів шляхом ротації своїх ключів. Процеси слешингу та видалення залишаються прив'язаними до валідатора, а не зникають при зміні адреси його оператора.
Pasteur далі блокує обмеженим адресам використання офчейн-підписів для участі в управлінні. BNB Chain вже запобігав прямому голосуванню занесених до чорного списку адрес, але ці облікові записи потенційно могли підписувати голоси, а інша адреса надсилати їх.
Оновлені контракти управління перевіряють початкового підписанта перед підрахунком делегованого голосу. Якщо цей підписант обмежений, голос відхиляється незалежно від того, який обліковий запис його подає.
BEP-675 запроваджує опціональний маршрут для спеціалізованих будівельників для надсилання блоків, які вони вже виконали. Валідатори перевіряють запропонований блок на відповідність правилам консенсусу, підписують його та транслюють перед завершенням повної перевірки виконання.
Попередній маршрут вимагав, щоб і будівельник, і валідатор виконували транзакції, перш ніж валідатор підписував. Це дублювання споживало частину короткого вікна блоків BSC і могло залишати блоки нижче їхньої максимальної пропускної здатності під час періодів високого попиту.
Будівельники можуть продовжувати використовувати попередній процес. Новий маршрут має бути увімкнений через інтерфейс віддаленого виклику процедур (RPC) мережі, даючи учасникам час для його інтеграції.
BNB Chain заявив, що маршрут може вміщати більше транзакцій у кожен блок, але його опубліковані показники продуктивності походили з контрольованого тестування, а не з активності основної мережі.
Тести на QANet, внутрішньому середовищі, розробленому для відображення географічно розподілених валідаторів, збільшили пропускну здатність з 1 237 до 2 324 транзакцій за секунду. Середнє споживання газу на блок зросло з 46,35 мільйона до 84,15 мільйона, тоді як ліміт газу в 100 мільйонів залишався незмінним.
Pasteur не збільшує ліміт газу блоку і не зменшує інтервал блоку в 450 мілісекунд, запроваджений оновленням Fermi. Його прирости пропускної здатності залежать від того, чи приймуть будівельники BEP-675 і чи надсилатимуть повніші блоки.
BNB Chain вимагав від операторів вузлів встановити клієнтську версію 1.7.7 перед активацією. Операторам також потрібно було видалити застаріле поле EnableBAL, оскільки залишення його у файлі конфігурації запобігало запуску оновленого клієнта.
Як повідомлялося раніше, BNB Chain попередив операторів про необхідність завершити обов'язкове оновлення Pasteur до хардфорку. Оператори, які використовували несумісне програмне забезпечення, ризикували вийти з синхронізації з основною мережею.
Наступні докази будуть отримані з фактичного використання блоків, пропускної здатності транзакцій, показників пропущених блоків та продуктивності валідаторів. Ці вимірювання покажуть, чи переноситься покращення пропускної здатності QANet на стабільний попит основної мережі.
BNB
