Размер блокчейна Эфириума превысил 1ТБ, и да, это проблема (Часть 1)

1_ZBwgMHuXDCzIc-2ZMacbEQ (1)

Это мой непрямой ответ на статью, которую меньше года назад написал Афри Шёдон, разработчик Ethereum-клиента Parity. Должен подчеркнуть, что я с уважением отношусь к большинству разработчиков в этой сфере, и это не попытка атаковать кого-либо из них. В этой статье я лишь хочу рассмотреть актуальные проблемы и показать, что Шёдон в своей статье упускает их из виду.

И скажу сразу: ограниченный объём хранения данных здесь ни при чём.

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

1_LjiNX7_XcHu-YgNh-JxOzg

«Warp-sync работает и отлично подходит для любой сети, кроме Ethereum. Текущий размер состояния в Ethereum – серьёзная проблема, и дело вовсе не в Parity».
https://github.com/paritytech/parity/issues/6372

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

Содержание статьи:

  • Мнение: размер директории с данными Эфириума неуклонно растёт, и это лишь вершина айсберга
  • Предсказание: всё будет работать, пока рано или поздно не сломается
  • Совет: эвакуация

Мнение: больший размер блоков приводит к централизации подтверждающих узлов

Это довольно простая идея, но все обсуждения масштабирования в криптокомьюнити сводятся именно к ней. И почти все, кто знаком с блокчейн-протоколами, с ней согласны. Приведу отрывок из статьи, в которой, на мой взгляд, очень хорошо описаны различные решения «второго слоя» для масштабирования сети (из которых, единственное реально работающее уже воплощено в сети Биткойна):

1. Проблемы масштабирования публичных блокчейнов

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

Наиболее обсуждаемый из этих вопросов — это пропускная способность сети. На данный момент Ethereum может обрабатывать до 15 транзакций в секунду, в то время как Visa обрабатывает около 45 000 транзакций в секунду. В прошлом году популярность таких приложений, как Cryptokitties, или некоторых ICO становилась причиной замедления работы всей сети и роста стоимости газа.

Главное ограничение публичных блокчейнов заключается в том, что каждая транзакция должна быть обработана каждым узлом сети. Любая операция в блокчейне Ethereum — платёж, рождение криптокошечки, запуск нового контракта ERC20 — должна быть проведена параллельно каждым узлом сети. Это заложено в системе, и отчасти благодаря этому публичные блокчейны так надёжны. Узлам не приходится полагаться на кого бы то ни было, чтобы определить текущее состояние блокчейна — они вычисляют его самостоятельно.

Это накладывает фундаментальное ограничение на пропускную способность сети Ethereum: она не может быть выше пропускной способности отдельного узла.

Автор этой статьи — Джош Старк. Он знает, о чём говорит. Его компания даже анонсировала проект по созданию подобия Lightning Network в сети Ethereum (что любопытно, в разработке Lightning Network участвует компания его однофамилицы, Элизабет Старк).

В чём же проблема? Если не вдаваться в рассуждения о Proof-of-Stake, система стимулов на базовом уровне протокола совершенно неработоспособна, так как в сети Эфириума нет ограничения размера блока. Если бы оно и существовало, оно должно было бы быть «разумным», однако это так или иначе помешало бы работе Dapp, которые едва ли справляются со своими задачами даже сейчас, когда размер блока неограничен. Каким бы ни был его предел, он не имеет значения, ведь данный аргумент остаётся в силе даже при отсутствии ограничения.

Давайте вернёмся немного назад. Я приведу краткое определение блокчейна и разочарую некоторых читателей.

Вот что предоставляет блокчейн:

  • неизменяемый децентрализованный реестр,
  • и ничего больше.

Вот что требуется блокчейну для поддержания этих характеристик:

Децентрализованная сеть со следующими возможностями:

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

Вот что смертельно опасно для блокчейна:

  • Любые встроенные в него функции, которые не соответствуют задачам сети.

Блокчейн – всего лишь инструмент, используемый сетью. И это инструмент довольно узкого применения, который подходит только для сети определённого типа. Блокчейн и сеть, в которой он используется, связаны настолько неразрывно, что со временем приходят в упадок, если не могут эффективно взаимодействовать друг с другом. Над сетью можно создавать надстройки, однако любые нововведения на базовом уровне протокола, так или иначе затрудняющие работу сети, рано или поздно приведут к её полному краху.

Некоторые функции первого уровня не вредят сети в целом – например, мультиподписи.

Обработка транзакций с мультиподписью накладывает на узлы некоторую дополнительную нагрузку, но ею можно пренебречь. Важно понимать, что такие сети спроектированы вполне разумно, и узким местом в них является не оборудование, а латентность. Простой перевод средств на кошелёк с мультиподписью не загрузит сеть сильнее, чем перевод на обычный кошелёк, так как каждая транзакция оплачивается в зависимости от объёма данных в байтах. Эта функция блокчейна не вредит работоспособности сети, так как (1) пользователи платят за каждый байт, и (2) объём данных регулируется через ограничение размера блока. Регулируется, а не сдерживается искусственным образом. Размер блоков не сдерживает поток транзакций, а контролирует объём данных, передаваемых всем участникам сети. Здесь-то и кроется проблема.

Говоря о размере директории с данными, мы подразумеваем размер всей цепочки блоков начиная с генезисного, и, не задумываясь, приводим стандартные доводы:

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

Однако эти доводы никак не учитывают поток данных, который узлы должны обрабатывать каждую секунду.

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

  1. Закон Мура оценивает рост производительности интегрированных микросхем, в среднем, в 60% в год. Но он ничего не говорит о средней пропускной способности (более важном показателе).
  2. Пропускная способность соединения растёт медленнее (см. закон Нильсена). Если изначально соотнести её с производительностью процессоров как 1:1 (то есть пропускная способность не отстаёт от производительности), то при ежегодном росте на 50% через 10 лет их соотношение достигнет 1:2. Другими словами, через 10 лет пропускная способность сети будет масштабироваться в 2 раза медленнее, чем производительность процессоров, через 20 лет – в 4 раза, через 40 лет – в 8 раз медленнее и т. д. На самом деле, рост пропускной способности замедляется ещё раньше, но даже упрощённые вычисления приводят к неутешительному прогнозу.
  3. Латентность сети изменяется ещё медленнее, чем пропускная способность. Это значит, что, по мере того, как увеличивается скорость соединения между узлами, скорость передачи блоков и данных не успевает расти так же быстро.
  4. Для обработки блоков большего размера необходимо обеспечить более быструю передачу данных (или меньшую латентность), чтобы избежать централизации узлов.

В случае Эфириума, учитывая, что после введения Proof-of-Stake сеть будет состоять исключительно из узлов, не стоит оставлять без внимания проблему их централизации. В сети Биткойна узким местом является размер блока (что вполне естественно), так как он сдерживает рост вычислительных потребностей, которые должны соответствовать таким внешним и не всегда предсказуемым ограничениям, как производительность оборудования и сети. Размер блока в Эфириуме растёт экспоненциально и в сети нет узкого места, которое сдерживало бы его рост в соответствии с внешними факторами. Это приводит к снижению числа узлов и к централизации сети, так как её потребности всё в большей степени превосходят возможности оборудования и соединения среднего пользователя.

1_E-p9wQ1L7oPTNexh6N3cew

«По-моему, люди беспокоятся не столько о пространстве на диске, сколько о трафике. Какой минимальной скоростью соединения должны обладать полные узлы, чтобы обеспечить безопасность сети? Пример анализа: []»
(нет ответа)

SPV-узлы (легкие клиенты) в Биткойне — не настоящие узлы. Они не участвуют в передаче блоков или транзакций по сети, а паразитируют, считывая только заголовки блоков.

Замечание, важное для дальнейшего понимания статьи:

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

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

Например, этот узел был частью сети, пока не был вынужден прекратить работу из-за растущих требований к соединению:

1_6XGgs3_KkCEf_McaTkjxgQ

«Не знаю, что произошло, и появились ли у Geth минимальные системные требования.
Раньше мой клиент Geth работал на компьютере с Core i3 и 8Гб оперативной памяти. Быстрая синхронизация занимала менее 2 часов с настройкой –cache=1024.
После того, как произошли атаки, я больше не мог синхронизировать или даже запустить Geth.
Теперь, уже после форка, синхронизация Geth останавливается на 99% (примерно через 6 часов), запускает импорт блоков, не успевает завершиться, и я постоянно отстаю от блокчейна на 5-7 часов.
Я протестирую клиент на виртуальной машине с SSD-дисками, но пока я лишь могу предположить, что требования Geth слишком высоки для моего компьютера».

«У меня та же проблема. Клиент синхронизируется уже 1,5 дня и до сих пор запаздывает».
https://www.reddit.com/r/ethereum/comments/58ectw/geth_super_fast/d908tik/

Это происходит до сих пор, и довольно часто:

1_Ck76HcvJT2ELelzP4obKjw

«Вот что я понял из этой истории с ускоренным режимом Geth:
Нужен четырёхъядерный процессор и, по крайней мере, 4 Гб оперативной памяти.
Необходимо использовать SSD, а не HDD.
Интернет-соединение должно быть стабильным, и его скорость должна быть не ниже 2 Мбит/с.
Если все эти условия выполняются, то можно попробовать Geth. Если использовать клиент в полном режиме, синхронизация должна занять не более 1–2 недель. В быстром режиме всё зависит от удачи, но, скорее всего, синхронизация либо завершится через 2–3 дня, либо не завершится никогда».

1_r7HrvZt_H_QD0b0s96ZuTA

«Geth 1.8.
До сих пор сталкиваюсь с этой проблемой.
После перезагрузки появляется ошибка.
Сейчас быстрый режим разрывает соединение с пирами и не синхронизируется. До конца синхронизации остаётся около 100 блоков, но она так и не завершается.
Такова природа p2p-сетей: всё зависит от работы пиров и состояния соединения. Обычно, если подождать достаточно долго, синхронизация сработает. Также может помочь Ctrl+C и перезагрузка (возможно, после этого вам попадётся более надёжный пир). Ещё один вариант – найти хорошего пира и установить соединение с ним вручную».
https://github.com/ethereum/go-ethereum/issues/14647

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

То, что я описал, представляет собой классический сценарий централизации, к которой приводит неограниченный размер блока. Большой (но ограниченный) размер блока – вариант чуть лучше, однако его введение создаёт прецедент для того, чтобы увеличивать его каждый раз, когда наступают «трудные времена». А это постепенно приведёт к тем же последствиям, что и нерегулируемый размер блока. Поэтому рассуждения о размере блока Биткойна здесь излишни.

Я несколько раз писал на эту тему в твиттере, но, судя по всему, и этого оказалось недостаточно. Среди моих подписчиков в твиттере не так много участников Ethereum-комьюнити.

chrome_2018-06-17_04-58-26

«Объяснить подробнее?
Допустим, что вашему Geth-узлу нужно обработать 100 условных «единиц» данных, чтобы синхронизироваться.
Ваш компьютер способен обработать всего 150 единиц. Завтра требования сети возрастут до 101 единицы. В следующем месяце – до 125. 
Отставание неизбежно».

Это схематичный график. На нём не изображены конкретные цифры – он лишь помогает визуально передать мысль этой статьи. Зелёная линия обозначает кумулятивный средний показатель требований сети Эфириума. Из-за его роста, ваш узел со временем рассинхронизируется, если не будет введено ограничение размера блока. Его могут ввести уже сейчас, через 10 или даже через 50 лет, но даже при его наличии такие темпы роста рано или поздно приведут к рассинхронизации. Этого никогда не произойдёт в сети Биткойн. Легко отрицать это предсказание сейчас, но, если через какое-то время они сбудутся, вспомните эту статью. Тогда глупым приложениям вроде CryptoKitties, Shrimp Farm, Pepe Farm и их будущим аналогам придёт конец. Такая судьба уже постигла сервис Райана Чарлза Yours.org, построенный на базе Биткойна. Он отличается лишь тем, что на момент его запуска размер блока Биткойна уже был ограничен, и Райан либо недостаточно разобрался в ситуации, либо ожидал, что размер блока продолжит увеличиваться. Вместо того чтобы сменить курс, он сделал ставку на Bitcoin Cash. А тем временем Yalls.org воплотил ту же самую идею на базе Lightning Network в сети Биткойна.

Продолжение следует…

Источник



Рубрики:Анализ, Важное, Мнение, ETH, Ethereum, эфир

Метки: , , , ,

4 replies

Trackbacks

  1. В погоне за ростом спроса: ответ на критику в связи ростом размера блокчейна Ethereum (часть 1) — EthereumClassic
  2. В погоне за ростом спроса: ответ на критику в связи ростом размера блокчейна Ethereum (часть 2) — EthereumClassic
  3. Шардинг Эфириума: централизация вместо масштабирования (часть 1) — EthereumClassic
  4. Шардинг Эфириума: централизация вместо масштабирования (часть 4) — EthereumClassic

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

Connecting to %s