Найбільший внесок у протистояння тиску написів?Про покращення zkSync оновленням Boojum

Написано: Haotian

Нещодавно @zksync завершив оновлення Boojum, і саме на цій підставі zkSync витримав стрес-тест Operation SYNC Inscription. Однак Boojum недооцінений ринком.

Які покращення продуктивності приносить Boojum? Чи можна розв’язати проблему стабільності децентралізованих фінансів, яку критикують? Далі поговоримо про моє розуміння:

1. Апгрейд Boojum, просто зрозумівши, дозволить zkSync завершити перехід від SNARK до STARK proof. Робочий процес приблизно такий:

Коли партія інкапсульована, ці транзакції розбиваються на кілька конкретних схем, які потім обробляються паралельно та високошвидкісно, щоб генерувати велику кількість STARK, які, нарешті, агрегуються в доказ STARK. Нарешті, доказ STARK інкапсулюється в доказ SNARK і передається в основну мережу для перевірки.

Таке поєднання STARK і SNARK забезпечує ефективну обробку великих обсягів транзакцій, одночасно зменшуючи розмір даних, що подаються в основну мережу (SNARK простіші) і більш сумісні з основною мережею.

Використання двох доказів одночасно означає, що передова технологія стиснення, технологія апаратного прискорення, оптимізація алгоритмів, ефективність агрегації пакетної обробки, оптимізація пам’яті та сховища системи Prover матимуть значне підвищення продуктивності.

2. Згідно з твітом @0xtaetaehoho, середній обсяг даних на транзакцію становив 211 байт до оновлення Boojum, і він може бути зменшений приблизно до 68 байт після оновлення, а вдосконалення технології стиснення безпосередньо значно збільшить обсяг транзакцій кожної партії на рівні 2, що значно збільшить TPS (близько 450), а вартість газу однієї транзакції знизиться (близько 65%).

Принцип не складний для розуміння, рівень 2 подає дані підтвердження статусу до даних виклику основної мережі, через обмежені дані зберігання в основній мережі, можливості паралельної обробки STARK рівня 2 та технологія обробки стиснення SNARK визначають обсяг транзакції та рівень газу, які можуть бути оброблені однією партією;

3. Раніше ZK-Rollup мав проблеми з нестабільністю при обробці низькочастотних транзакцій децентралізованих фінансів, і його вбудована тенденція не сприяла стабільності децентралізованих фінансів. Наприклад, змінна ціна децентралізованих фінансів вимагає декількох цінових каналів Oracle, і якщо дві транзакції не групуються в один і той же стан, результуючий знос транзакцій збільшиться.

Тепер обсяг транзакцій одного пакета в layer2 значно збільшився, і в блоці можна розмістити більше оновлень статусу даних Oracle. Також будуть ефективно вирішені питання стабільності децентралізованих фінансів.

Як зазначено в офіційному @anthonykrose zkSync, незалежно від того, скільки оновлень Oracle Machine міститься в блоці, весь стан блоку може бути оброблено і записано в цілому, і потрібно сплатити лише вартість запису одного стану. Це вигідно для низьких комісій, високої ефективності та стабільності додатків децентралізованих фінансів у ланцюжку ZK-Rollup.

Зрозуміло, що оновлення Boojum слід розглядати як віху для zkSync.

З одного боку, це підтверджує висновок про те, що чим більший обсяг транзакцій системи ZK, тим нижча плата за газ, тим кращий досвід, а з іншого боку, це також доводить, що ефективне застосування та підвищення продуктивності обчислювальних ресурсів, таких як технологія стиснення та апаратне прискорення офчейн-системи Prover, привнесуть нескінченну уяву в систему ZK.

Очікувалося, що після оновлення Cancun розмір блоку BLOB-об’єкта основної мережі Ethereum знизить вартість пакетних транзакцій рівня2, і тепер технічна оптимізація самої системи ZK вивела зведення серій ZK і зведення серії OP на один рівень.

Справа в тому, що ZK-Rollup набагато більш «активний», ніж OP-Rollup. Переваги технології ZK-Rollup, про які завжди говорили, були повністю доведені після апгрейду Boojum.

Довідка: Для апаратного прискорення ZK, оптимізації обчислювальної потужності тощо, будь ласка, зверніться до наступних звітів про дослідження: