Проблема разнообразия клиентов Ethereum

Дата запуска «слияния» (объединение Beacon Chain с основной сетью Ethereum) быстро приближается. Согласно последней [статистике] (https://beaconcha.in/), в Beacon Chain насчитывается более 300 000 валидаторов и более 10 миллионов эфиров (ETH) в стейках валидаторов.

Переход Эфириума от механизма консенсуса «доказательство работы» к механизму консенсуса «доказательство доли» имеет несколько последствий для его будущего. С Beacon Chain в качестве уровня консенсуса Ethereum PoS обещает лучшую сетевую безопасность, энергоэффективность, масштабируемость и децентрализацию.

Однако это также создает новые проблемы, которые могут угрожать функциональности Ethereum.

Одной из таких задач является достижение идеального разнообразия клиентов. В децентрализованной сети, такой как Ethereum, разнообразие клиентского программного обеспечения необходимо для повышения сетевой безопасности, функциональности и устойчивости к цензуре.

Тем не менее, текущая статистика показывает, что уровень консенсуса PoS Ethereum (цепочка маяков) не хватает в отделе разнообразия клиентов. Как мы узнаем из этой статьи, централизация реализации программного обеспечения имеет критические последствия для экосистемы Ethereum.

ELI5: Что означает разнообразие клиентов?

Ethereum — это децентрализованная одноранговая сеть, поддерживаемая глобально распределенным набором узлов (то есть компьютеров). На каждом узле работает «клиент» — это программное обеспечение, которое помогает узлам взаимодействовать с блокчейном Ethereum. Без клиентов узлы не могут транслировать и проверять транзакции, выполнять смарт-контракты или достигать консенсуса по состоянию блокчейна.

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

Разнообразие клиентов просто означает справедливое распределение клиентского программного обеспечения на сетевых узлах. В идеале ни один клиент не должен питать более 33% узлов в децентрализованной системе, такой как Ethereum. Или же могут начать происходить несколько плохих вещей (которые мы рассмотрим позже).

В настоящее время Beacon Chain Ethereum не имеет справедливого распределения клиентского программного обеспечения между узлами, на которых работает сеть. Как показано на диаграмме ниже, большинство клиентов контролируют > 68% валидаторов, что может подвергнуть систему риску по разным причинам.

[Источник изображения]

Разнообразие клиентов — горячо обсуждаемая тема в сообществе Ethereum. И это связано с его важностью для производительности Ethereum, особенно в контексте слияния. Дебаты также существуют из-за [разногласий по поводу того, как должно быть реализовано разнообразие клиентов] (https://medium.com/prysmatic-labs/prysmatic-labs-statement-on-client-diversity-c0e3c2f05671).

Итак, почему разнообразие клиентов так важно? Это то, что мы собираемся выяснить.

Важность разнообразия клиентов

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

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

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

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

Ограничения на завершение транзакции

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

Завершенность — это то, что придает Ethereum и другим сетям блокчейна их «неизменное» качество. Любой может использовать Ethereum, зная, что транзакции будут постоянно записываться в цепочке и не могут быть подделаны.

Как правило, блокчейн-сети требуют, чтобы большинство узлов достигли консенсуса, прежде чем транзакция будет завершена. В Beacon Chain для завершения цепочки требуется не менее 2/3 поставленных ETH. Что-нибудь ниже, чем это, и цепочка не может быть завершена, что ставит систему под угрозу.

Итак, как это связано с дефектным клиентским программным обеспечением? Ну, вы должны рассмотреть, что может вызвать ситуацию, когда узлы не могут достичь консенсуса.

Мы могли бы придумать разные причины, но самая реальная из них проста: проверяющие узлы работают со сбоями. Если 1/3 валидаторов неактивны, то для окончательности Beacon Chain не потребуется квалифицированного большинства в 2/3.

Чтобы решить эту проблему, Beacon Chain активирует механизм утечки бездействия. Этот механизм предназначен для постепенного снижения ставок автономных валидаторов, позволяя оставшимся узлам вновь сформировать большинство в две трети.

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

Разделение сети

В предыдущем разделе было рассмотрено, что может произойти, если неисправный клиент питает более 1/3 проверяющих узлов. Но это только начало — могут случиться и худшие вещи, особенно если > 1/2 валидаторов используют плохое клиентское ПО.

В этом случае сеть Beacon Chain может быть разделена на две отдельные цепочки. Обе цепочки не смогут завершиться, потому что половина их валидаторов отсутствует; следовательно, активируется механизм утечки бездействия.

Депозиты, принадлежащие затронутым валидаторам, будут уничтожены через некоторое время — скажем, через три-четыре недели — до тех пор, пока они не будут контролировать менее 1/3 поставленных ETH. В результате старая и новая цепочки будут завершены независимо друг от друга, что затруднит их последующее объединение.

Чтобы объединить обе цепочки, сообществу необходимо согласовать каноническую цепочку — процесс, который, вероятно, будет чреват политикой. Причина проста: если попросить валидаторов присоединиться к другой цепочке, они потеряют все свои доли.

Разделение сети заставит более половины сообщества понести огромные экономические потери. Чтобы избежать этой участи, валидаторы в отброшенной цепочке могут решить продолжить работу с разветвленной цепочкой, разделив сообщество Ethereum.

Это напоминает события, связанные со взломом DAO в 2016 году, когда фракция, недовольная ситуацией, [разветвила сеть] (https://www.gemini.com/cryptopedia/ethereum-classic-etc-vs- eth) и создал Ethereum Classic. Разделение не только ослабит Ethereum, но и может снизить цену эфира на рынке.

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

Отмена транзакций

Если неисправный клиент, на котором работает > 1/2 валидаторов Beacon Chain, является катастрофой, то ситуация, когда > 2/3 узлов используют одно и то же уязвимое программное обеспечение, — это армагеддон. Новая цепочка, состоящая из узлов с затронутым клиентом, будет отделена от цепочки маяков и, поскольку она имеет квалифицированное большинство в 2/3, будет завершена независимо. В лучшем случае у разработчиков будет \~ 13 минут, чтобы исправить программное обеспечение, прежде чем разделенная цепочка станет окончательной.

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

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

Исправить №1

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

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

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

Исправить №2

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

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

Теперь, это тот момент, когда я говорю: «Но подождите, есть еще!». Давайте представим, что затронутые валидаторы успешно выходят из плохой цепочки и пытаются присоединиться к правильной цепочке. Поскольку они уже подтвердили одну цепочку, любая попытка подтвердить другую незавершенную цепочку приведет к сокращению их ставок ETH.

Другими словами, перед нами стоит дилемма:

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

В конце концов, никто не выигрывает от возникновения этой проблемы. Вот почему клиент, контролирующий более 2/3 проверяющих узлов, вызывает тревогу.

Можно ли улучшить разнообразие клиентов Ethereum?

К настоящему времени важность разнообразия для здоровья сети Ethereum должна быть очевидной, особенно если мы хотим сохранить децентрализованность Ethereum. Но, если судить по цифрам, Beacon Chain Ethereum еще не добилась справедливого распределения клиентов.

Доминирующий клиент, Prysm, контролирует > 68% узлов в сети Beacon Chain, что прочно ставит нас на территорию Армагеддона. Выражение беспокойства по поводу того, что один клиент имеет квалифицированное большинство, может показаться паникерством, но эти проблемы не являются гипотетическими.

В августе 2020 года Medalla (теснет Beacon Chain) потерпела серьезный сбой. Причина? Узлы с программным обеспечением Prysm вышли из строя из-за ошибки часов в клиенте. В результате узлы Prysm отключились, и цепочка не смогла завершить работу.

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

История также показывает, почему разнообразие клиентов важно. Например, в 2016 году хакеры нацелились на Ethereum с помощью распределенной атаки типа «отказ в обслуживании» (DDoS), используя уязвимости в клиенте Go Ethereum (Geth). Сеть выжила, потому что узлы могли переключиться на клиент Parity, который был защищен от атаки.

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

Тем не менее, существуют различные возможные решения для повышения разнообразия программного обеспечения:

Поощрения протокола

Механизм Casper PoS в Ethereum, который контролирует Beacon Chain, предназначен для того, чтобы препятствовать использованию конкретного клиента большинством. Это стимулирует разнообразие клиентов за счет антикорреляционных штрафов и квадратичных сборов за утечку бездействия.

Квадратичная утечка бездействия

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

Стандартные штрафы за бездействие низкие (около 1 ETH), и валидаторы по-прежнему сохранят большую часть своей ставки. Однако, если > 1/3 валидаторов неактивны, все начинает выглядеть иначе. Цепочка не может завершиться в этой ситуации, что угрожает живучести — обязательному качеству для всех распределенных системы, а не только блокчейны.

В сценарии квадратичной утечки плата за бездействие будет увеличиваться квадратично до тех пор, пока офлайн-валидаторы не сократят свои доли до менее чем 1/3 сети. Обоснование заключается в том, что если что-то отключит большое количество валидаторов, цепочка все еще может достичь окончательности.

Помните, что нам нужно 2/3 стейкеров, чтобы достичь консенсуса для завершения Beacon Chain? Механизм утечки бездействия гарантирует, что офлайн-узлы будут удерживать менее 1/3 ставок, позволяя оставшимся валидаторам создать требуемое квалифицированное большинство в две трети.

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

Антикорреляционные штрафы

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

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

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

Если недопустимый блок зафиксирован в цепочке маяка, другие узлы отклонят его и сформируют новую цепочку, в которой нет этого блока. Единственный вариант для узлов в действительной цепочке — переключиться на правильную цепочку; однако это влечет за собой штраф, поскольку значительный процент ставок ETH сокращается.

Эти стимулы созданы для продвижения мультиклиентской культуры в Ethereum. Таким образом, валидаторам рекомендуется запускать миноритарных клиентов.

Запуск миноритарных клиентов

Более очевидный шаг к достижению лучшего разнообразия клиентов — заставить узлы работать с разными клиентами. Запуская различное программное обеспечение, валидаторы могут гарантировать, что Ethereum останется надежным, безопасным и функциональным.

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

Вот некоторые согласованные клиенты меньшинства, которые вы можете запустить:

• путеводная звезда

• Теку

• Нимб

• Маяк

В этой статье мы сосредоточились исключительно на согласованных клиентах, то есть на узлах Beacon Chain. Однако у Ethereum Mainnet есть аналогичная проблема. Согласно статистике, Go Ethereum (Geth) контролирует более 80% узлов, а Nethermind, OpenEthereum и Erigon отстают с низкими показателями.

[Источник изображения]

Поскольку уровень выполнения так же важен, как и уровень консенсуса, он также нуждается в разнообразии клиентов. Чтобы решить эту проблему, узлы в основной сети Ethereum могут запускать следующие клиенты исполнения:

• Hyperledger Besu

• Нижний разум

• Erigon

• CoreGeth

Последние мысли

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

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

Рекомендации

1. [Подтверждено, ставка на eth2: #1 — Стимулы] (https://blog.ethereum.org/2020/01/13/validated-staking-on-eth2-1-incentives/)

1. Ethereum Merge: запускайте большинство клиентов на свой страх и риск!

1. [Eth2book: Уровень стимулирования] (https://eth2book.info/altair/part2/incentives/diversity#diversity)

Обложка предоставлена ​​Getty Images

Также опубликовано в Business Tech Guides