👾 Ethereum 2.0: The Merge, PoS, Sharding
На конференции Ethereum в Париже, команда Ethereum представила роадмап с шагами на ближайшие несколько лет. Самый ближний этап — the Merge, который назначен на 15–16 сентября. Еще одно важное изменение произойдет на этапе the Surge — это внедрение шардинга. Сеть Ethereum перейдет на Proof-of-Stake. Но как это коснется разработчиков и что изменится в консенсусе?
Доклад с митапа Cyber Academy в Тбилиси от Эльшана Джафарова, который последние пять лет работает блокчейн-инженером, сейчас в проекте Fluence Lab (об этом проекте можно посмотреть доклад прошлого митапа Cyber Academy).
Философия дизайна Ethereum
Существуют разные блокчейн-философии и подходы к разработке. Команда Ethereum ставит на первое место безопасность и живучесть протокола. Среди других пунктов:
- надейтесь на лучшее, но ожидайте худшего — можно подкупить валидаторов и атаковать сеть, ⅔ сети могут отключиться из-за землетрясения и т.д. — каждый протокол должен иметь способы выхода из кризисных ситуаций;
- простота — чтобы пользователи могли легко контрибьютить;
- децентрализация — нормальное количество нод и валидаторов;
- ожидайте неожиданного — это про квантовый апокалипсис или другие невозможные ситуации, но Ethereum уже имеет некоторые квантово-устойчивые элементы;
- от людей для людей — чтобы сеть можно было запустить на обычном пользовательском устройстве.
Что такое The Merge
На самом деле Beacon Chain запущен уже где-то год и работает как отдельная сеть. Там есть валидаторы и залоченные ETH. The Merge «вмерджит» Beacon Chain с той сетью Ethereum, к которой мы привыкли пользоваться. (Читайте лонгрид Cyber Academy про мердж).
Что поменяется на Application Layer
Application Layer — слой, с которым девелоперы взаимодействуют во время разработки dApps, смарт-контрактов и сетей на базе Ethereum. После мерджа будет разделение слоев на консенсусный слой (Beacon Chain c PoS) и уровень исполнения (execution layer, бывший майннет Ethereum, та же структура блоков).
При переходе с PoW на PoS исчезнут несколько полей. Начнем с difficulty и nonce. Первый обозначает сложность майнинга, которая теперь будет высчитываться динамически. Nonce — при майнинге блоков в PoW он перебирает nonce, чтобы получить уникальный хеш и найти таргет-хеш для валидации блока. Остальные два поля — ommers-блоки.
Что такое ommers-блоки
Во время форка часть блоков являются «отмершими», их еще называют uncle-блоками. В PoS они тоже есть, но в PoW на такие блоки потрачена часть энергии, то есть они имеют некоторую ценность. Майнеры находятся в убытке из-за того, что их цепочка не стала доминирующей.
В Ethereum есть такая фича — привязать ommers-блоки к новой цепочке, хотя она тоже не будет валидной и отпадет, но майнеры получат вознаграждения с основного блокчейна все равно. Это стимулирует валидаторов стремиться к одной цепи, а не разветвляться на форки.
Другие изменения post-merge
В EVM поменяется команда difficulty, она будет указывать не на сложность блока, а на предыдущие результаты Random DAO. А само значение будет лежать в слоте, который назывался mixHash.
В сети появится абсолютная финальность блоков. Это значит, что мы можем гарантировать, что нет параллельной цепочки, которая потенциально может стать длиннее. Это вероятностность PoW. В PoS ⅔ стейка валидаторов на конкретном чейне достаточно, чтобы цепочка считалась завершенной.
Изменится время блока. Было около 13 секунд, а станет ровно 12 секунд. Добавится понятие «безопасной головы». Это блок за которым мы можем следовать, но он не является финальным, в нем нет ⅔ стейка. Вероятность того, что эта цепочка форкнется — минимальная. Можно следовать ей, когда мы хотим синхронизировать какой-то merge-стейт. Но точно не в случае, когда мы хотим подтвердить платежную транзакцию.
Что поменяется на Engine Layer
Ноды. Ethereum-клиент будет состоять из двух компонентов: Beacon-ноды и execution engine. Это те ноды, которые работают сейчас в Ethereum. После морджа ноды текущего майннета не отвалятся, а продолжат работать. Хотя они не смогут валидировать всю цепочку, но лишь ее часть на execution layer. Для пользователей будут два разны API. Данные можно будет получить из web3 library по двум источникам: web3.beacon и web3.eth.
У одного пользователя появятся несколько валидаторов. 32 ETH — 1 валидатор. Если пользователь положил 64 ETH — получил двух валидаторов. Достаточно запустить одну Beacon-ноду и можно запустить n-ое количество клиентов для валдиации чейна.
Что поменяется на consensus layer
Beacon chain — координационный уровень для шардов, на котором все менеджерится и синхронизируется.
В Ethereum2.0 к привычному пониманию блоков добавляется понятие слотов. Слот — потенциальное место для блока. 32 слота — одна эпоха. В слоте может быть блок, или он может быть пропущен. Эпохи нужны, чтобы знать границы финализации цепочки. Это позволяет нам делать менее избыточные голосования. И за определенное количество блоков определять, какая эпоха финализирована. Например, у нас есть эпоха #0, и в эпохе #1 мы будем голосовать за эпоху #0 и тогда она будет финализирована, если получит ⅔ стейка.
Как изменится производство блоков
В Ethereum2.0 случайным образом выбирается блок-продьюсер, который должен будет агрегировать транзакции из мем-пула в блок, который он же и создаст. Также есть понятие комитетов — это остальные валидаторы, которые случайным образом раскинуты по разным группам. В одном комитете может быть минимум 128 валидаторов. В каждом комитете выбирается 16 агрегаторов. На каждый блок выбирается случайный блок-продьюсер и несколько комитетов, которые должны подписать блок в рамках слота.
Это позволяет все время ротировать валидаторов и не давать им сговориться. Таким образом создается рандом с возможностью верификации стейков других валидаторов внутри одного слота. Агрегаторы собирают подписи комитетов и передают их блок-продьюсеру, чтоб он мог финализировать блок.
Сейчас в сети Ethereum около 400 000 валидаторов. Нам нужен эффективный способ сжатия подписей в блок. Мы можем при помощи BLS-подписи делать бесконечное число подписей, передавать агрегатору и он объединяет их в одну, чтобы сделать хранение, верифицирование и использование более эффективным.
Голосование валидаторами за блок в Ethereum2.0 называется аттестацией.
Изменения в протоколе GHOST
В Биткоине мы выбираем самую длинную цепочку по простому принципу — какая цепочка длиннее. В Ethereum доминирует цепочка, у которой больше всего форков создано в этом дереве. Мы оцениваем value всего дерева — сколько на него потрачено ресурсов майнинга, чем больше форков — тем больше ресурсов потрачено на вычисления.
В Ethereum2.0 доминирующая цепочка будет выбираться, исходя из голосов валидаторов. Чем больше в поддереве аттестаций — тем более этот чейн доминирующий.
Как стать валидатором
Нужно сделать депозит 32 ETH и подождать какое-то время. За неправильное поведение мы можем быть заслешены — нас могут отключить или оштрафовать.
Вознаграждения валидаторам начисляются за аттестацию, а блок-продьюсерам за финализацию блоков. Также блок-продьюсерам начисляется награда за то, что они кладут аттестацию в блок. Также есть награда за то, что кто-то прислал fraud-proof валидатора.
Как изменится слешинг
Сейчас есть два вида слешинга — двойное голосование и бездействие. Бездействие самый легкий слешинг — в долгосрочной перспективе не снижает депозит сильно. Что значит бездействие? Это нода, которая отключилась и пока она не включится, с ее баланса будут сниматься ETH, пока баланс не станет меньше 16 ETH. Это сделано, чтобы чейн финализировался в любом случае, даже если меньше ⅓ активного стейка осталось в сети.
Двойное голосование — намеренное действие для атаки на сеть. Злоумышленник голосует за две конфликтующие эпохи параллельно друг другу. При голосовании мы обязаны указать, за какую именно эпоху мы голосуем, но наш голос может попасть в другую таргет-эпоху. Когда мы проголосовали в эпоху 2 за 3, а потом в эпоху 1 за 4 — это запрещенное голосование.
Как образуется RANDAO
В блокчейне с рандомом все плохо обычно, в Ethereum каждый валидатор в комитете блока выбирает и хеширует случайное число из которого потом образуется хеш блока. Это псевдо-рандом, потому что на него могут повлиять валидаторы.
Особенности шардинга в Ethereum2.0
Комитеты получают различные задания для обработки отдельных шардчейнов. Даже если у нас в сети много злонамеренных валидаторов, они окажутся обезврежены за счет постоянной перетасовки. Вероятность того, что много плохих валидаторов попадет в один шардчейн — низкая.
Но есть проблема из-за того, что когда валидаторы получают в шардчейне состояние блокчейна, остальные валидаторы не могут верифицировать ссылку на меркл-три шардчейна. Но мы не можем проверить доступность данных и доказать, что данные для хеша были доставлены валидатором. Поэтому в шардах эфира есть механизм Blob, который диктует каждому валидатору предоставить фрагменты информации о блоке, по которым он верифицирует всю эпоху. Вторая часть фрагментов (осколков информации) проверяется при помощи кодирования и стирания. Если можно получить 50% осколков, то можно восстановить и вторую часть. То есть ⅔ валидаторов должны получить 50% информации о блоке.
