У цій статті блогу більше розповідається про децентралізацію в OP Labs, оскільки ми підтримуємо інженерів екосистеми, які створюють систему відмови від OP Stack, і Optimism Collective, що створює свою першу пораду безпеки.

Критична дискусія на шляху до зрілості блокчейна полягає в тому, як, у якому обсязі та коли проводити децентралізацію. У цьому повідомленні блогу розповідається трохи більше про те, що ми думаємо про цей процес в OP Labs, оскільки ми підтримуємо інженерів екосистеми, які створюють систему відмови від OP Stack, і Optimism Collective, що створює свою першу пораду безпеки.

У пізнавальній статті на форумі Ethereum Magicians, Віталік Бутерін викладає план дій щодо досягнення 2-го етапу децентралізації, найважливішого етапу для будь-якої мережі 2-го рівня, що прагне децентралізації. Ця посада стала основою для багатьох дискусій щодо технічної децентралізації в Optimism Collective за останні два роки. Ми твердо переконані, що всі блокчейни другого рівня повинні приділяти пріоритетну увагу досягненню цієї стадії децентралізації якнайшвидше (і безпечніше!), щоб забезпечити більш надійну, безпечну та по-справжньому децентралізовану екосистему.

Щоб нагадати всім, що потрібно для досягнення накопичувального рівня 2, ось критерії, викладені у вихідному повідомленні Віталіка Бутерина:

Требования:

• В случае, если в коде нет ошибок/ багов, не должно быть какой-либо группы акторов, которая могла бы, даже единогласно, опубликовать корень состояния, отличный от вывода кода.

Эта несколько неуклюжая формулировка («ЕСЛИ в коде нет ошибок, ТО никто не сможет его переопределить») предназначена для того, чтобы разрешить использование советов безопасности способами, которые явно ограничиваются вынесением решений по неоспоримым ошибкам, например, следующим образом:

• В объединении используются две или более независимые реализации функции перехода состояний (например, два отдельных средства доказательства мошенничества, два отдельных средства доказательства достоверности или по одному каждого из них), и совет безопасности может выносить решения только в том случае, если они не согласны с этим, что может произойти только в том случае, если есть баг.

• Если кто-то отправляет транзакцию или серию транзакций, которые содержат два действительных доказательства для двух разных state roots, после обработки одних и тех же данных (т. е. «доказывающий не согласен сам с собой»), контроль временно переходит к совету безопасности.

• Если действительные доказательства не представлены в течение >= 7 дней (т. е. «доказательство застряло»), контроль временно переходит к совету безопасности.

• Обновления разрешены, но с задержкой >= 30 дней.

Подводя итог, можно сказать, что для того, чтобы снять свои «тренировочные колеса» и достичь децентрализации Этапа 2, роллапы должны иметь надежную систему защиты от сбоев, несколько функционирующих механизмов проверки, а роллапы, в которых есть совет безопасности или подобная организация, должны соответствовать определенным критериям.

Що робить етап 2, чого не робить етап 1, то це гарантує, що не існує будь-якої групи учасників, яка могла б «навіть одноголосно опублікувати state root, відмінний від виведення коду». L2 рівня 1 все ще має якусь версію мультипідпису або поради безпеки, яка може гіпотетично (хоча і не без витрат) змінити корінь стану ланцюжка, щоб піддати цензурі або ініціювати недійсний висновок коштів. Це не зовсім безнадійно. Видалення цієї можливості ще більше децентралізує мережі та гарантує користувачам невід'ємну можливість виходу із системи.

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

При переході до етапу 2 у проектах можна використовувати підхід «спочатку в глибину»: якнайшвидше дістатися до етапу 1 з доказом однієї несправності, а потім придумати, як створити систему доказу множинних несправностей, щоб досягти статусу етапу 2. Компанія Optimism, навпаки, використовувала підхід «спочатку в ширину», метою якого є створення функціональної багатофункціональної мережі, що швидко росте. Інженери екосистеми створюють першу реалізацію системи відмови від стійкості таким чином, щоб забезпечити такий підхід. Тим часом, оскільки все це створюється відкрито, з використанням стека з відкритим вихідним кодом інші розробники в екосистемі змогли почати створювати безліч інших реалізацій паралельно з роботою над першою захищеною від збоїв реалізацією.

Ми знаємо, як важливо зробити все правильно з першої спроби. Сьогодні інженери OP Stack заклали основу для швидкого мультизахисного розширення та працюють над досягненням статусу Stage 1 згідно з L2Beat. Але Bedrock створювався з нуля з урахуванням децентралізації другого етапу. Ми не зацікавлені у досягненні Стадії 1 просто заради того, щоб сказати, що ми це зробили. З першого дня це було лише частиною нашого прагматичного плану з досягнення Етапу 2 якнайшвидше та безпечніше...

Етап 2 – це кінець гри. Ось як це виглядає на практиці:

Ми знали, що для того, щоб розставити пріоритети у досягненні етапу 2, нам потрібно розробити кодову базу, яка полегшить цей етап. Нам потрібна була модульність, представлена ​​оновленням Bedrock, щоб гарантувати, що після того, як для стека OP буде розроблена функціонуюча, надійна та стійка до відмови, розробники екосистеми зможуть використовувати її модульні надздатності, щоб допомогти нам розробити не одну чи дві, а безліч альтернативних перевірочних систем. механізми.

У той же час нам потрібно було переконатися, що навіть непередбачені технологічні розробки не зроблять застарілим OP Stack. Поточна структура стека OP гарантує, що розробники можуть замінювати перевірочні компоненти, увімкнувши в них технологію ZK, що колись загрожувала зростанню Optimistic накопичувальних пакетів. Мережі в екосистемі Optimism який завжди повинні використовувати механізми підтвердження оптимізму. Ми очікуємо, що вони зможуть використати досягнення в технології ZK та відродження плазми, або комбінація всіх трьох механізмів у відмовостійкій системі їхнього ланцюжка..

На проектування стека OP та виконання оновлення Bedrock потрібен час, але результат цих інвестицій дозволив всій екосистемі швидко прискорити наш прогрес у розробці найближчими місяцями та надалі. Це означає, що час було витрачено правильно та стратегічно.

До цього часу цей підхід приносив величезні плоди. Доказом цього є те, як швидко альтернативні клієнти стали популярними з моменту запуску Bedrock, і скільки команд в екосистемі нині також працюють над альтернативними стійкими до відмови. На додаток до OP Labs і всім альтернативним супроводжуючим клієнтів (Test in Prod, команда reth і Base, Nethermind, a16z crypto і Кай Чен і команда Hildr), які використовуються як критично важливі залежності в стеку OP, в даний час команди над альтернативними доказами помилок працюють команда State Channels, RISCZero, O(1) Labs, AltLayer, Protolambda (в OP Labs), а також інженери Віллем Олдінг та Ерік Ту, а також geohotz та його початкова робота над Cannon.

Ось як це виглядатиме:

Стек OP є потрійною загрозою. Він є модульним і має відкритий вихідний код, що означає, що вся міць стека може потрапити до рук третьої «загрози» — надзвичайно творчої та блискучої спільноти розробників. Інженерам OP Labs знадобляться роки, щоб розробити, протестувати та реалізувати численні схеми перевірки, необхідні для децентралізації другого етапу. Надаючи найкращі інструменти в руки провідних розробників та інженерів ядра нашої екосистеми, будь-хто, хто зацікавлений в успіху Optimism, може розробити компоненти, які допоможуть досягти нашої мети.

Щоб досягти етапу децентралізації 1 і перейти на етап 2, мережам необхідно щось на кшталт поради безпеки — мультипідпис, за допомогою якого можна керувати оновленнями протоколу, який обслуговують щонайменше 8 незалежних осіб із порогом підпису 75% або вище.

Восени 2023 року розпочалася серйозна робота з створення першої заради безпеки екосистеми Оптимізму, що складається з людей, які не входять до Фонду. Перші 14 членів заради безпеки екосистеми Оптимізму були ратифіковані голосуванням керівництва у грудні 2023 року, а ще одне голосування - це питання про те, чи слід ділитися ключами оновлення з Радою безпеки під час проміжної «Фазі 0», також було успішним.

Одна з цінностей Optimism – технології з відкритим вихідним кодом. Подібно до того, як інженери екосистеми створюють відкритий стек OP з відкритим вихідним кодом, ліцензований MIT, так і рада безпеки буде створюватися відкрито, наприклад публічна хартія, відкритий вихідний код виконання, та прозорі операції. Це відповідає двом із трьох керівних принципів, які лягли в основу структури Ради безпеки: прозорість та спільність.

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

От і все. Це мем.

L2 недостатньо досягти Стадії 1 і обмежити використання тренувальних коліс, як і раніше покладаючись на єдиний механізм перевірки для забезпечення системи захисту від збоїв, що зароджується. Крім того, ефективність єдиної системи захисту від збоїв залежить від сили Ради безпеки, яка може нею керувати. На першому етапі Рада безпеки з 14 осіб була ратифікована Управлінням Оптимізму для управління безпекою Суперчейна, і ключовою метою у 2024 році є те, щоб ця рада безпеки керувала ключами оновлення екосистеми під керівництвом Управління Оптимізму. та незалежно від Фонду Оптимізму.

Більша частина планування та розвитку OP Labs за останні півтора роки була спрямована на те, щоб поставити всю екосистему Optimism у таке становище, коли досягнення децентралізації другого етапу не тільки реалістичне, а й досяжне. Ми раді здійснити цю подорож наступного року разом з усіма іншими членами колективу!

Посилання на оригінальну статтю:

https://blog.oplabs.co/endgame-is-stage-2/

У цій статті блогу більше розповідається про децентралізацію в OP Labs, оскільки ми підтримуємо інженерів екосистеми, які створюють систему відмови від OP Stack, і Optimism Collective, що створює свою першу пораду безпеки.

Критична дискусія на шляху до зрілості блокчейна полягає в тому, як, у якому обсязі та коли проводити децентралізацію. У цьому повідомленні блогу розповідається трохи більше про те, що ми думаємо про цей процес в OP Labs, оскільки ми підтримуємо інженерів екосистеми, які створюють систему відмови від OP Stack, і Optimism Collective, що створює свою першу пораду безпеки.

У пізнавальній статті на форумі Ethereum Magicians, Віталік Бутерін викладає план дій щодо досягнення 2-го етапу децентралізації, найважливішого етапу для будь-якої мережі 2-го рівня, що прагне децентралізації. Ця посада стала основою для багатьох дискусій щодо технічної децентралізації в Optimism Collective за останні два роки. Ми твердо переконані, що всі блокчейни другого рівня повинні приділяти пріоритетну увагу досягненню цієї стадії децентралізації якнайшвидше (і безпечніше!), щоб забезпечити більш надійну, безпечну та по-справжньому децентралізовану екосистему.

Щоб нагадати всім, що потрібно для досягнення накопичувального рівня 2, ось критерії, викладені у вихідному повідомленні Віталіка Бутерина:

Требования:

• В случае, если в коде нет ошибок/ багов, не должно быть какой-либо группы акторов, которая могла бы, даже единогласно, опубликовать корень состояния, отличный от вывода кода.

Эта несколько неуклюжая формулировка («ЕСЛИ в коде нет ошибок, ТО никто не сможет его переопределить») предназначена для того, чтобы разрешить использование советов безопасности способами, которые явно ограничиваются вынесением решений по неоспоримым ошибкам, например, следующим образом:

• В объединении используются две или более независимые реализации функции перехода состояний (например, два отдельных средства доказательства мошенничества, два отдельных средства доказательства достоверности или по одному каждого из них), и совет безопасности может выносить решения только в том случае, если они не согласны с этим, что может произойти только в том случае, если есть баг.

• Если кто-то отправляет транзакцию или серию транзакций, которые содержат два действительных доказательства для двух разных state roots, после обработки одних и тех же данных (т. е. «доказывающий не согласен сам с собой»), контроль временно переходит к совету безопасности.

• Если действительные доказательства не представлены в течение >= 7 дней (т. е. «доказательство застряло»), контроль временно переходит к совету безопасности.

• Обновления разрешены, но с задержкой >= 30 дней.

Подводя итог, можно сказать, что для того, чтобы снять свои «тренировочные колеса» и достичь децентрализации Этапа 2, роллапы должны иметь надежную систему защиты от сбоев, несколько функционирующих механизмов проверки, а роллапы, в которых есть совет безопасности или подобная организация, должны соответствовать определенным критериям.

Що робить етап 2, чого не робить етап 1, то це гарантує, що не існує будь-якої групи учасників, яка могла б «навіть одноголосно опублікувати state root, відмінний від виведення коду». L2 рівня 1 все ще має якусь версію мультипідпису або поради безпеки, яка може гіпотетично (хоча і не без витрат) змінити корінь стану ланцюжка, щоб піддати цензурі або ініціювати недійсний висновок коштів. Це не зовсім безнадійно. Видалення цієї можливості ще більше децентралізує мережі та гарантує користувачам невід'ємну можливість виходу із системи.

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

При переході до етапу 2 у проектах можна використовувати підхід «спочатку в глибину»: якнайшвидше дістатися до етапу 1 з доказом однієї несправності, а потім придумати, як створити систему доказу множинних несправностей, щоб досягти статусу етапу 2. Компанія Optimism, навпаки, використовувала підхід «спочатку в ширину», метою якого є створення функціональної багатофункціональної мережі, що швидко росте. Інженери екосистеми створюють першу реалізацію системи відмови від стійкості таким чином, щоб забезпечити такий підхід. Тим часом, оскільки все це створюється відкрито, з використанням стека з відкритим вихідним кодом інші розробники в екосистемі змогли почати створювати безліч інших реалізацій паралельно з роботою над першою захищеною від збоїв реалізацією.

Ми знаємо, як важливо зробити все правильно з першої спроби. Сьогодні інженери OP Stack заклали основу для швидкого мультизахисного розширення та працюють над досягненням статусу Stage 1 згідно з L2Beat. Але Bedrock створювався з нуля з урахуванням децентралізації другого етапу. Ми не зацікавлені у досягненні Стадії 1 просто заради того, щоб сказати, що ми це зробили. З першого дня це було лише частиною нашого прагматичного плану з досягнення Етапу 2 якнайшвидше та безпечніше...

Етап 2 – це кінець гри. Ось як це виглядає на практиці:

Ми знали, що для того, щоб розставити пріоритети у досягненні етапу 2, нам потрібно розробити кодову базу, яка полегшить цей етап. Нам потрібна була модульність, представлена ​​оновленням Bedrock, щоб гарантувати, що після того, як для стека OP буде розроблена функціонуюча, надійна та стійка до відмови, розробники екосистеми зможуть використовувати її модульні надздатності, щоб допомогти нам розробити не одну чи дві, а безліч альтернативних перевірочних систем. механізми.

У той же час нам потрібно було переконатися, що навіть непередбачені технологічні розробки не зроблять застарілим OP Stack. Поточна структура стека OP гарантує, що розробники можуть замінювати перевірочні компоненти, увімкнувши в них технологію ZK, що колись загрожувала зростанню Optimistic накопичувальних пакетів. Мережі в екосистемі Optimism який завжди повинні використовувати механізми підтвердження оптимізму. Ми очікуємо, що вони зможуть використати досягнення в технології ZK та відродження плазми, або комбінація всіх трьох механізмів у відмовостійкій системі їхнього ланцюжка..

На проектування стека OP та виконання оновлення Bedrock потрібен час, але результат цих інвестицій дозволив всій екосистемі швидко прискорити наш прогрес у розробці найближчими місяцями та надалі. Це означає, що час було витрачено правильно та стратегічно.

До цього часу цей підхід приносив величезні плоди. Доказом цього є те, як швидко альтернативні клієнти стали популярними з моменту запуску Bedrock, і скільки команд в екосистемі нині також працюють над альтернативними стійкими до відмови. На додаток до OP Labs і всім альтернативним супроводжуючим клієнтів (Test in Prod, команда reth і Base, Nethermind, a16z crypto і Кай Чен і команда Hildr), які використовуються як критично важливі залежності в стеку OP, в даний час команди над альтернативними доказами помилок працюють команда State Channels, RISCZero, O(1) Labs, AltLayer, Protolambda (в OP Labs), а також інженери Віллем Олдінг та Ерік Ту, а також geohotz та його початкова робота над Cannon.

Ось як це виглядатиме:

Стек OP є потрійною загрозою. Він є модульним і має відкритий вихідний код, що означає, що вся міць стека може потрапити до рук третьої «загрози» — надзвичайно творчої та блискучої спільноти розробників. Інженерам OP Labs знадобляться роки, щоб розробити, протестувати та реалізувати численні схеми перевірки, необхідні для децентралізації другого етапу. Надаючи найкращі інструменти в руки провідних розробників та інженерів ядра нашої екосистеми, будь-хто, хто зацікавлений в успіху Optimism, може розробити компоненти, які допоможуть досягти нашої мети.

Щоб досягти етапу децентралізації 1 і перейти на етап 2, мережам необхідно щось на кшталт поради безпеки — мультипідпис, за допомогою якого можна керувати оновленнями протоколу, який обслуговують щонайменше 8 незалежних осіб із порогом підпису 75% або вище.

Восени 2023 року розпочалася серйозна робота з створення першої заради безпеки екосистеми Оптимізму, що складається з людей, які не входять до Фонду. Перші 14 членів заради безпеки екосистеми Оптимізму були ратифіковані голосуванням керівництва у грудні 2023 року, а ще одне голосування - це питання про те, чи слід ділитися ключами оновлення з Радою безпеки під час проміжної «Фазі 0», також було успішним.

Одна з цінностей Optimism – технології з відкритим вихідним кодом. Подібно до того, як інженери екосистеми створюють відкритий стек OP з відкритим вихідним кодом, ліцензований MIT, так і рада безпеки буде створюватися відкрито, наприклад публічна хартія, відкритий вихідний код виконання, та прозорі операції. Це відповідає двом із трьох керівних принципів, які лягли в основу структури Ради безпеки: прозорість та спільність.

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

От і все. Це мем.

L2 недостатньо досягти Стадії 1 і обмежити використання тренувальних коліс, як і раніше покладаючись на єдиний механізм перевірки для забезпечення системи захисту від збоїв, що зароджується. Крім того, ефективність єдиної системи захисту від збоїв залежить від сили Ради безпеки, яка може нею керувати. На першому етапі Рада безпеки з 14 осіб була ратифікована Управлінням Оптимізму для управління безпекою Суперчейна, і ключовою метою у 2024 році є те, щоб ця рада безпеки керувала ключами оновлення екосистеми під керівництвом Управління Оптимізму. та незалежно від Фонду Оптимізму.

Більша частина планування та розвитку OP Labs за останні півтора роки була спрямована на те, щоб поставити всю екосистему Optimism у таке становище, коли досягнення децентралізації другого етапу не тільки реалістичне, а й досяжне. Ми раді здійснити цю подорож наступного року разом з усіма іншими членами колективу!

Посилання на оригінальну статтю:

https://blog.oplabs.co/endgame-is-stage-2/