# Обзор протокола Taiko

**Published by:** [クゼヒデオ](https://paragraph.com/@rulos-2/)
**Published on:** 2023-05-07
**URL:** https://paragraph.com/@rulos-2/taiko

## Content

Отказ от ответственности: разработка протокола Taiko все еще находится в стадии разработки. Ниже приведена его новейшая версия, однако все еще может измениться. Тайко придерживается подхода «децентрализовано с 1 дня». Ниже приведено описание протокола. Протокол Taiko состоит из трех этапов: предложение блока , валидация и проверка . TLDR: Taiko — это ZK-EVM типа 1, что означает, что он эквивалентен Ethereum. То есть он реализует спецификации Ethereum Yellow Paper; Выполнение блока является детерминированным, как только блок добавляется в предлагаемый список блоков. То есть с этого момента все его свойства неизменны; И предлагающие, и доказывающие не имеют разрешения. Любой может запускать и прекращать работу узла предложения и проверки в любое время; Метаданные блока проверяются при предложении блока. Доказательство не влияет на то, как выполняется блок и каково состояние после блока; Доказательство может быть сгенерировано после того, как блок проверен на достоверность и известно состояние его родительского блока. Этап 1: Заблокировать предложение Любой может управлять Тайко-предлагателем. Клиент Taiko (предлагающий) отслеживает сетевой мемпул Taiko на наличие подписанных и отправленных транзакций. Плата за транзакцию L2 = базовая комиссия L2 EIP-1559* + комиссия за транзакцию L1 + комиссия за проверку + плата за предлагающего ** * Под комиссией EIP-1559 мы подразумеваем, что плата за транзакцию L2 делится на (i) сетевую плату L2 (базовая плата) и (ii) оплату за выполненную работу (доказывающим, предлагающим, L1). Плата L2 EIP-1559 = чаевые L2 EIP-1559 (переходит предлагающему) + базовая плата L2 EIP-1559 (передается Taiko DAO). ** Работа предлагающего – включение и упорядочивание транзакций в блок. С этой целью сборы L2 (за исключением базовой платы L2 EIP-1559) взимаются на счет предлагающего на L2. Плата за транзакцию L1 и плата за проверку оплачиваются со своего счета на L1. Таким образом, плата предлагающего = плата за подсказку L2 EIP-1559 - плата за транзакцию L1 - плата за проверку. Предлагающий может потерять деньги, если плата за подсказку L2 EIP-1559 недостаточна для платы за транзакцию L1 и платы за проверку. Как только предлагающий собрал достаточно транзакций, предположительно включив и упорядочив их с намерением получить (максимальную) прибыль, он создает блок. Прибыль означает, что для предлагающего сумма комиссий за транзакцию (комиссия за транзакцию L2) от блока больше, чем комиссия за транзакцию L1 + комиссия за проверку + базовая комиссия EIP-1559. Предлагающий определяет последовательность транзакций в блоке. Когда блок построен, предлагающий отправляет транзакцию offerBlock (блок = список транзакций + метаданные) непосредственно в Ethereum через контракт TaikoL1. Между узлами L2 нет консенсуса, но между узлами L2 существует некоторая сеть (синхронизация, обмен транзакциями и т. д.). Однако порядок блоков Taiko в Ethereum (L1) определяется узлом Ethereum. Все другие предлагающие также могут отслеживать мемпул транзакций L2 и идентифицировать предлагаемые блоки Taiko в ожидающих транзакциях L2 offerBlock . Многие блоки предлагаются параллельно и становятся ожидающими в мемпуле Ethereum. Тем не менее, Taiko поддерживает только ограниченное количество слотов (скажем, 10 240) для непроверенных блоков (как предложенных, но не проверенных, так и проверенных, но не проверенных) на уровне выполнения Ethereum и повторно использует их, чтобы минимизировать комиссию за предложение блока. Выполнение блока является детерминированным. Когда блок предлагается, данные блока публикуются в Ethereum, и блок добавляется в предлагаемый список блоков, хранящийся в контракте TaikoL1. После этого все свойства блока неизменяемы. Все узлы Taiko подключаются к узлам Ethereum и подписываются на события блоков Ethereum. Когда предложение блока Taiko подтверждается, блок добавляется в очередь на L1 в контракте TaikoL1. Затем узлы Taiko могут загружать эти блоки и выполнять действительные транзакции в каждом блоке. Узлы Taiko отслеживают, какие блоки L2 проверены , подписавшись на другое событие TaikoL1 в Ethereum. Этап 2: Проверка блока Блок состоит из списка транзакций (txList) и метаданных. Список txList блока L2 в конечном итоге (когда EIP-4844 будет запущен) станет частью большого двоичного объекта на уровне консенсуса L1 (CL). Однако txList не доступен напрямую для контрактов L1. Следовательно, ZKP должен доказать, что выбранный txList является срезом заданных данных большого двоичного объекта. Блок считается действительным, если он соответствует нескольким критериям: Имеет размер в байтах меньше K_maxBobSize(также применяется в контрактах); Может быть RLP-декодирован в список транзакций без пробела в конце; Содержит не больше транзакций (действительных и недействительных), чем константа протокола K_BlockMaxTxs; Имеет общий лимит газа для всех действительных транзакций, не превышающий константу протокола K_BlockMaxGasLimitплюс config.anchorTxGasLimit. Как только блок предлагается, клиент Taiko проверяет, декодирован ли блок в список транзакций; если txList не декодируется, то блок является пустым блоком только с привязкой tx. Клиент Taiko проверяет каждую вложенную транзакцию и создает журнал трассировки для каждой транзакции, чтобы доказывающая сторона использовала его в качестве данных-свидетелей. Если TX недействителен, он будет удален. Сделка считается недействительной , если: Имеет недопустимую подпись транзакции; Имеет недопустимый одноразовый номер транзакции (отличный от текущего одноразового номера учетной записи отправителя); На счету недостаточно ETH для оплаты eth_value + tx_gaslimit * tx_gas_price; В учетной записи отправителя развернут некоторый код контракта (EIP-3607); Имеет лимит газа меньше собственного газа, g0используемого транзакцией. Блок taiko L2 Первая транзакция в блоке Taiko L2 всегда является якорной транзакцией. Транзакция привязки содержит некоторые дополнительные данные, недоступные непосредственно самому ZK-EVM. A ZK-EVM covers Доказательство транзакции для каждой транзакции (так же, как в Ethereum); State Proof == MPT state trie (полное доказательство всех обновлений состояния в блоке); Доказательство выполнения == байт-код EVM (при правильных входных данных каждый получит правильные выходные данные). Таким образом, якорная транзакция проверяет 256 хэшей последних блоков (которые не являются частью Merkle Tree); Идентификатор цепочки L2 и базовая плата EIP-1559. Этап 3: Проверка блока Блок может быть доказан, как только Все заключенные допустимые транзакции в этом блоке выполнены (сформирована необходимая трасса выполнения для вычисления ZKP); Состояние его родительского блока известно. Доказательство доказывает переход из состояния родительского блока в состояние нового блока. Блок проверяется, когда Его родительский блок проверен; Существует действительный ZKP, подтверждающий переход из родительского состояния в текущее состояние блока. Любой может провести прувер. Поскольку выполнение блока является детерминированным, все клиенты Taiko могут вычислять состояние после блока. И никто не знает о последнем состоянии больше, чем кто-либо другой. Кроме того, для пользователей L2 транзакция подтверждается после предложения блока. То есть ЗКП ждать не надо. Доказывающие могут отправлять доказательства для любого блока, который им нравится. Несколько пруверов могут работать параллельно для создания ZKP для одного или нескольких блоков Taiko, но только первое доказательство будет принято для любого заданного перехода блока (выбор вилки). Адрес для получения вознаграждения связан с доказательством, что предотвращает его кражу другими доказывающими. Oracle Prover (временно для тестовой сети альфа-3) Чтобы гарантировать, что все пользовательские активы безопасны, а все транзакции блоков действительны, даже если есть ошибки в генерации доказательств, протокол Taiko на данный момент вводит средство проверки оракула. Средство проверки оракула проверяет все переходы состояний (путем запуска узла для выполнения всех транзакций в блоке) и может переопределять существующие переходы состояний (выборы ответвления), которые доказали обычные средства проверки. Окно охлаждения составляет 5 минут (время запланировано для следующей тестовой сети). Представьте себе хэш родительского блока A. Тогда хеш нового блока должен быть B. И выбор ветвления должен быть A → B. Но если в системе проверки есть ошибка, может быть возможно сгенерировать действительное доказательство для A → С. В этом случае доказывающий оракул видит, что A→C неверно, и сообщает протоколу, что A должен перейти в B, а не в C. Затем обычный доказывающий генерирует новое доказательство для A → B. Примечание: средство проверки оракула не может напрямую проверять/проверять блоки и, следовательно, не может изменять состояние цепочки. Следовательно, настоящий ZKP по-прежнему требуется для подтверждения выбора переопределенной вилки. Subscribe

## Publication Information

- [クゼヒデオ](https://paragraph.com/@rulos-2/): Publication homepage
- [All Posts](https://paragraph.com/@rulos-2/): More posts from this publication
- [RSS Feed](https://api.paragraph.com/blogs/rss/@rulos-2): Subscribe to updates
- [Twitter](https://twitter.com/Liana00964264): Follow on Twitter