MMS

В этом посте рассматриваются определения и общие идеи децентрализации свертки. В нем не рассматриваются глубокие технические детали децентрализованных реализаций объединения.

Мы идентифицируем Taiko как децентрализованный ZK-накопитель, эквивалентный Ethereum. Ethereum-эквивалент — прозвище ZK-EVM типа 1 — это техническое дизайнерское решение, которое мы описываем  здесь .

В этом посте мы хотели бы поговорить о другом дескрипторе в этом заявлении:  децентрализованном . Мы изучим:

  • Каково определение децентрализованного объединения?
  • Как вы децентрализуете накопительный пакет?
  • Каковы компромиссы децентрализованного объединения?
  • Подход Тайко: прогрессивная эффективность
  • Децентрализованное внедрение и децентрализованное управление
  • Как децентрализация является частью эквивалентности Ethereum

Каково определение децентрализованного объединения?

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

Децентрализованный накопительный пакет — это такой, при котором  любой пользователь может быть уверен, что его транзакция будет выполнена .

Мы должны воспользоваться моментом, чтобы спросить, почему кого-то вообще может волновать, децентрализован ли накопительный пакет или нет. Учитывая, что накопительные пакеты полагаются на L1 для гарантий безопасности (в основном Ethereum в наши дни для ведущих накопительных пакетов), разве пользователи не защищены, несмотря ни на что?

Свертки гарантируют, что, пока существует L1 (уровень доступности данных), пользователи могут восстановить состояние L2 и  выйти из свертки, инициировав транзакцию на L1.  Если система не удовлетворяет этому ограничению, то мы бы сказали, что она не представляет собой свертки; это другой тип L2 или боковая цепь. Это должно прояснить, что выбор сильно децентрализованного (всегда живого, устойчивого к цензуре) L1 имеет решающее значение. Еще один нюанс заключается в том, что для универсального свертывания, в отличие от свертывания для конкретного приложения, пользователи должны иметь возможность  принудительно включить любую произвольную транзакцию, а не только «выходные» транзакции .

Установив, что мы говорим о свертывании, мы заявили, что различие, которое определяет объединение как децентрализованное или нет, заключается в  том, насколько сложно или реалистично для пользователя иметь возможность принудительно включить свою транзакцию . Например,  нужны ли им очень мощные вычислительные ресурсы для создания доказательства ZK? Или они могут использовать потребительское оборудование или арендовать дешевый сервер на короткое время? Есть ли какой-то привилегированный участник, который имеет полную свободу действий в течение длительного периода, снижая возможность попытаться быть включенным, чтобы его отложили на 30 дней? Чем менее запретительно, тем более децентрализовано.

Между этими крайностями существует спектр.  «Менее децентрализовано» — это вещь.
Между этими крайностями существует спектр. «Менее децентрализовано» — это вещь.

На самом деле обычный пользователь, скорее всего, не захочет запускать полный узел свертки, а в случае ZK-Rollup — надстройку для проверки. Они хотели бы знать, что накопительный пакет, с которым они работают, или, может быть, даже накопительный пакет, который они называют домом, способствует тому, чтобы  широкий и разнообразный набор участников выполнял необходимые функции . И что новые участники могут присоединиться к сети для выполнения этих функций без разрешения — включая самих себя, если они того пожелают.

Имея в виду вышеизложенное, давайте закончим этот раздел другим определением децентрализованного объединения, которое поможет нам лучше понять:

Децентрализованный накопительный пакет — это тот, в котором  несколько сторон могут участвовать в каждой сетевой позиции  , то есть в качестве предлагающих, подтверждающих и исполняющих узлы.

Это приводит нас к следующему разделу.

Как вы децентрализуете накопительный пакет?

Учитывая приведенные выше определения, особенно второе, вы можете увидеть, что мы можем  децентрализовать объединение, обеспечив выполнение всех ролей несколькими сторонами — в идеале обширным и географически разнообразным набором. Эти роли:

  • Предлагающие
  • пруверы
  • Бегуны узлов

Прежде чем мы рассмотрим каждую роль, давайте просто рассмотрим вопрос, затронутый в предыдущем разделе: накопительные пакеты, как решение L2, решают, какой L1 они хотят масштабировать, или, точнее, какой L1 они будут использовать для гарантий безопасности. «Гарантии безопасности» здесь означают использование L1 для обеспечения консенсуса и доступности данных (DA). Хотя это не то, что сам накопительный пакет может настроить на децентрализацию,  выбор достаточно децентрализованного L1 является критическим решением , и Тайко выбирает Ethereum из-за самых надежных гарантий безопасности.

К ролям.

Предлагающие

Предлагающие создают блоки свертки из пользовательских транзакций L2 и предлагают их L1. Иногда их называют  секвенсорами  в других системах объединения.

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

Как мы установили —> децентрализованный накопительный пакет должен позволить пользователям ожидать  включения  всех их действительных транзакций.

пруверы

Доказывающие генерируют доказательства SNARK, подтверждающие достоверность транзакций и блоков L2 из вышеупомянутых предложенных блоков.

Доказывающие решают  , какие предложенные блоки превратить в   блоки , проверенные в цепочке . Эта позиция определяет, когда блок может достичь своего состояния проверки в цепочке, но не определяет, какие транзакции идут в блоке или как они упорядочены. До этого состояния проверки в цепочке доказывающая сторона может оставлять зависшими определенные транзакции, которые зависят от подтверждения достоверности, или оставлять зависшие определенные  блоки, которые могут быть  проверены в цепочке, ожидающие проверки своего родительского блока в цепочке.

Как мы установили —> децентрализованный накопительный пакет должен позволить пользователям ожидать  проверки  всех своих действительных транзакций.

Бегуны узлов

Node runners  выполняют транзакции из данных в цепочке (L1),  чтобы синхронизироваться с состоянием свертки.

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

Как мы установили —> децентрализованный накопительный пакет должен позволить пользователям ожидать  выполнения  всех их действительных транзакций.

Примечание: в то время как децентрализация проверщиков/проверщиков является явным решением протокола объединения (например, смарт-контракты могут быть настроены на прием блоков или подтверждений только с разрешенных адресов), запуск узла в основном зависит от ресурсов, которые зависят от роста состояния, требований к оборудованию и т. д. ., и не является прямым протокольным решением. Удовлетворение разумного роста состояния имеет решающее значение, но не обсуждается в этом посте.

Каковы компромиссы децентрализованного объединения?

Переход от централизации к децентрализации открывает пространство для компромиссов.

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

В контексте инициаторов/проверщиков объединения мы рассматриваем следующее:

Подход Тайко: прогрессивная эффективность

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

Источник: L2beat.com.  Отображает различные риски сверток.  Для тем, которые мы обсуждаем, накопительный пакет с децентрализованными предложениями и пруверами будет иметь «блоки предложений» в столбцах «Отказ секвенсора» и «Сбой валидатора» (и пользователям будет очень легко работать с ними).  Как видите, ни один из вышеперечисленных в настоящее время не удовлетворяет обоим.
Источник: L2beat.com. Отображает различные риски сверток. Для тем, которые мы обсуждаем, накопительный пакет с децентрализованными предложениями и пруверами будет иметь «блоки предложений» в столбцах «Отказ секвенсора» и «Сбой валидатора» (и пользователям будет очень легко работать с ними). Как видите, ни один из вышеперечисленных в настоящее время не удовлетворяет обоим.

Taiko, с другой стороны, стремится запустить  полностью децентрализованный (и не требующий разрешений) набор предложений и доказательств . Протокол не будет закреплять или разрешать какие-либо стороны; любой сможет выполнять эти обязанности. Кроме того, Taiko планирует иметь минимальную схему координации, определяемую протоколом, для инициаторов/проверщиков. Текущий план состоит в том, чтобы он был без лидера.

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

В этом смысле подход Тайко можно рассматривать  как прогрессивную эффективность , а не прогрессивную децентрализацию; переходя от полностью децентрализованной и неструктурированной крайности к середине, если это необходимо.

Это не означает, что Тайко с самого начала будет полностью « без тренировочного колеса ». Некоторые меры, такие как возможность обновления смарт-контрактов, останутся в силе до тех пор, пока все не будет проверено в бою. Это обусловлено подходом, ориентированным на безопасность: без возможности обновления на основе прокси активы пользователей могут столкнуться со значительным риском ошибок. Управляемая возможность обновления — это один из рычагов, который в какой-то момент будет передан DAO.

Децентрализованное внедрение и децентрализованное управление

Недавно Виталик  написал  , что «децентрализованная структура управления защищает от злоумышленников изнутри, а децентрализованная реализация защищает от мощных злоумышленников снаружи». Это было сказано в контексте DAO, то есть как структура управления, так  и  реализация относились к DAO. В частности, это было сказано об одной цели децентрализации DAO: надежности.

Мы думаем, что очень полезно использовать эту структуру для накопительных пакетов в целом и разделить «структуру управления» на значение DAO накопительного пакета, точку (принимая как должное, что реализация управления основана на смарт-контракте) и «реализацию» на значение архитектуры накопительного пакета. сам.

Источник: https://vitalik.ca/general/2022/12/05/excited.html
Источник: https://vitalik.ca/general/2022/12/05/excited.html

В этом свете мы до сих пор обсуждали, как накопительный пакет может защитить себя от внешних угроз (цензура, сбои живости) с децентрализованной реализацией. Мы не должны пренебрегать тем, как накопительный пакет может защитить себя от внутренних угроз  — от организации и сообщества, которым было поручено изначально создать и поддерживать его. Инструментом в распоряжении накопительного пакета здесь является управление или, упрощенно, его DAO.

Когда дело доходит до управления, Taiko использует подход, аналогичный другим накопительным пакетам и большинству протоколов Ethereum в целом, от DeFi до инфраструктуры. Этот подход действительно представляет собой прогрессивную децентрализацию: контроль над протоколом будет постепенно передаваться сообществу, в частности Taiko DAO. Пока еще слишком рано описывать детали DAO и какие механизмы управления мы хотели бы предложить, но это будет предметом будущих публикаций.

В качестве заключительной мысли по этой теме: мы считаем, что  реализация предлагает анализ свойств агрегации на определенный момент времени, в то время как управление может описать, как реализация может меняться с течением времени и какие стороны могут принимать эти решения.

Как децентрализация является частью эквивалентности Ethereum

В своем стремлении к чистому эквиваленту Ethereum Taiko высоко ценит приоритетность децентрализации. Было бы странно, если бы эквивалентность в качестве цели включала EVM, хеш-функции, деревья состояний и транзакций и т. д., не принимая также во внимание эквивалентность в составе сети.

Эмуляция Ethereum для Taiko означает, что все соответствует Ethereum: ZK-EVM, другая архитектура базового уровня Ethereum, философские соображения, сообщество и ~ флюиды ~. Это распространяется на децентрализацию сети и основные свойства, которые она предоставляет разработчикам и их пользователям: устойчивость к цензуре и живучесть.

Спасибо за чтение.

Присоединяйтесь к нам

Изучите открытые вакансии на нашей  доске объявлений .

Подписывайтесь на нас

Чтобы быть в курсе последних новостей от Taiko:

Способствовать

Внесите свой вклад в Taiko и заработайте GitPOAP! Вы также будете отмечены как участник нашего README. Начните работу с помощью  руководства по внесению вклада .

Tags:

Leave a Reply

Your email address will not be published. Required fields are marked *