Ограничения масштабируемости блокчейна

Автор: Vitalik Buterin

Исходное название: 《Пределы масштабируемости блокчейна》

Дата публикации: 23 мая 2021 года

Насколько мы можем повысить масштабируемость блокчейна? Можем ли мы действительно, как говорит Илон Маск, "ускорить время блока в десять раз, увеличить размер блока в десять раз и снизить комиссии в сто раз", не приводя к крайней централизации и не нарушая основные свойства блокчейна? Если ответ отрицательный, то до какого уровня мы можем дойти? Что произойдет, если изменить алгоритм формулы? Более того, что произойдет, если мы введем функции, подобные ZK-SNARK или шардированию? Может ли шардированный блокчейн теоретически постоянно добавлять шард, и действительно ли это возможно?

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

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

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

Представьте, что в два часа ночи вы получили срочный звонок от человека с другого конца света, который помогает вам управлять майнинг-пулом (пулом стейкинга). Примерно 14 минут назад ваш пул и еще несколько человек отделились от цепочки, в то время как сеть все еще поддерживает 79% хешрейта. Согласно вашему узлу, большинство блоков цепи недействительны. В это время возникает ошибка баланса: блок, похоже, ошибочно распределил 4,5 миллиона дополнительных токенов на неизвестный адрес.

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

К утру обсуждение широко распространяется в Twitter и на одном нецензурируемом форуме сообщества. Но к тому времени большая часть из 4,5 миллиона токенов уже была обменена на другие активы в цепочке и проведены десятки миллиардов долларов в сделках DeFi. 79% узлов консенсуса, а также все основные блокчейн-эксплореры и конечные точки легких кошельков следовали за этой новой цепочкой. Возможно, новый фонд разработчиков будет финансировать некоторые разработки, или, возможно, все это будет поглощено ведущими пулами, биржами и их связями. Но как бы то ни было, фонд фактически стал фактом, с которым обычные пользователи не могут бороться.

Возможно, есть даже фильм на эту тему. Возможно, его профинансирует MolochDAO или другая организация.

Случится ли это в вашем блокчейне? Элитные участники вашего блокчейн-сообщества, включая пулы, блокчейн-эксплореры и хостинг-узлы, могут хорошо координироваться, и они, вероятно, все находятся в одном телеграм-канале и WeChat-группе. Если они действительно захотят внезапно изменить правила протокола ради своей выгоды, то они могут иметь такую возможность. Блокчейн Ethereum полностью решил проблему консенсуса за десять часов, и если это блокчейн с единственной реализацией клиента, и нужно только развернуть изменения кода на десятках узлов, то можно быстрее координировать изменения клиентского кода. Единственный надежный способ противостоять такой атаке социальной кооперации — это "пассивная защита", а эта сила исходит от децентрализованной группы: пользователей.

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

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

Мнение Hasu по этому поводу:

"Давайте проясним одну вещь: мы можем противостоять злонамеренным изменениям протокола благодаря культуре верификации блокчейна пользователями, а не благодаря PoW или PoS."

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

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

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

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

• Вычислительная мощность: сколько ЦПУ мы можем выделить для запуска узлов, сохраняя безопасность?
• Пропускная способность: сколько байт может содержать один блок на основе текущего сетевого соединения?
• Хранение: сколько пространства мы можем требовать от пользователей для хранения? Кроме того, какая должна быть скорость чтения? (т.е. достаточно ли HDD? Или нам нужны SSD?)

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

Вычислительная мощность

• Ошибочный ответ: 100% ЦПУ должно использоваться для верификации блоков
• Правильный ответ: около 5-10% ЦПУ может использоваться для верификации блоков

Четыре основных причины, по которым это ограничение так низко:

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

Обратите внимание, что до недавнего времени большинство объяснений по вопросу "почему только 5-10%?" сосредоточивались на другом, отличном вопросе: поскольку время создания блоков в PoW непостоянно, верификация блоков занимает много времени, что увеличивает риск одновременного создания нескольких блоков. У этой проблемы много решений, таких как Bitcoin NG или использование PoS. Но они не решают другие четыре проблемы, поэтому они не достигли значительного прогресса в масштабируемости, как многие ожидали.

Параллелизм также не является панацеей. Обычно даже клиенты блокчейна, которые кажутся однопоточными, уже параллелизованы: подписи могут проверяться одним потоком, а выполнение — другими потоками, и есть отдельный поток, который обрабатывает логику пула транзакций в фоновом режиме. И чем ближе использование всех потоков к 100%, тем больше потребление энергии для запуска узлов, тем ниже коэффициент безопасности против DoS.

Пропускная способность

• Ошибочный ответ: если блоки размером 10 МБ создаются каждые 2-3 секунды, то у большинства пользователей сеть больше 10 МБ/с, и они, конечно, могут обрабатывать эти блоки
• Правильный ответ: возможно, мы можем обрабатывать блоки размером 1-5 МБ каждые 12 секунд, но это все еще сложно

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

1. "Мбит/с" означает "миллионы бит в секунду"; один бит — это 1/8 байта, поэтому нам нужно разделить заявленное количество бит на 8, чтобы получить количество байт.
2. Провайдеры сетевых услуг, как и другие компании, часто лгут.
3. Всегда есть несколько приложений, использующих одно и то же сетевое соединение, поэтому узлы не могут полностью использовать всю пропускную способность.
4. P2P сети неизбежно вводят накладные расходы: узлы обычно в конечном итоге многократно загружают и повторно загружают один и тот же блок (не говоря уже о том, что транзакции должны быть сначала распространены через мемпул перед упаковкой в блок).

Когда Starkware проводила эксперимент в 2019 году, они впервые выпустили блок размером 500 кБ после снижения стоимости газа для транзакционных данных, и некоторые узлы фактически не могли обработать блоки такого размера. Способность обрабатывать большие блоки уже улучшалась и будет продолжать улучшаться. Но что бы мы ни делали, мы все равно не можем получить среднюю пропускную способность в МБ/с, убеждая себя, что можем принять задержку в 1 секунду и способны обрабатывать блоки такого размера.

Хранение

• Ошибочный ответ: 10 ТБ
• Правильный ответ: 512 ГБ

Как вы, возможно, догадались, здесь основной аргумент такой же, как и в других местах: разница между теорией и практикой. Теоретически мы можем купить 8 ТБ твердотельного накопителя на Amazon (действительно, нужны SSD или NVME; HDD слишком медленны для хранения состояния блокчейна). На практике мой ноутбук, на котором я пишу этот блог, имеет 512 ГБ, и если вы предложите людям купить оборудование, многие станут ленивыми (или не смогут позволить себе 800 долларов за 8 ТБ SSD) и будут использовать централизованные услуги. Даже если можно будет установить блокчейн на какое-то устройство хранения, большое количество активности может быстро исчерпать диск и заставить вас купить новый диск.

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

Кроме того, размер хранения определяет время, необходимое для того, чтобы новые узлы могли выйти в сеть и начать участвовать в ней. Любые данные, которые должны хранить существующие узлы, являются данными, которые новые узлы должны загрузить. Это время начальной синхронизации (и пропускная способность) также является основным препятствием для пользователей, способных запускать узлы. Когда я писал этот блог, синхронизация нового узла geth заняла у меня около 15 часов. Если использование Ethereum увеличится в 10 раз, то синхронизация нового узла geth займет как минимум неделю, и это, скорее всего, приведет к ограничению интернет-соединения узла. Это особенно важно во время атак, когда пользователям, которые ранее не запускали узлы, необходимо включить новые узлы, чтобы успешно ответить на атаку.

Взаимодействие эффектов

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

Не воспринимайте этот график буквально, разные базы данных работают по-разному, и обычно часть в памяти — это просто один отдельный (но большой) уровень (см. LSM-деревья, используемые в leveldb). Но основная идея остается той же.

Например, если кэш составляет 4 ГБ, и мы предполагаем, что каждый уровень базы данных больше предыдущего в 4 раза, то текущее состояние Ethereum ~64 ГБ потребует ~2 доступа. Но если размер состояния увеличится в 4 раза до ~256 ГБ, это увеличится до ~3 доступов. Таким образом, увеличение предела газа в 4 раза на самом деле может привести к увеличению времени верификации блоков примерно в 6 раз. Это влияние может быть еще больше: жесткий диск требует больше времени для чтения и записи, когда он заполнен, чем когда он пуст.

Что это значит для Ethereum?

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

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

Еще одно возможное среднесрочное решение — использование ZK-SNARK для верификации транзакций. ZK-SNARK могут гарантировать, что обычные пользователи не нуждаются в личном хранении состояния или верификации блоков, даже если им все еще нужно загрузить все данные из блоков, чтобы противостоять атакам на недоступность данных. Кроме того, даже если атакующие не могут принудительно отправить недействительные блоки, если сложность запуска узла консенсуса слишком высока, все равно существует риск координационных атак. Таким образом, ZK-SNARK не могут бесконечно увеличивать возможности узлов, но все же могут значительно их улучшить (возможно, на 1-2 порядка). Некоторые блокчейны исследуют эту форму на уровне 1, в то время как Ethereum извлекает выгоду из протоколов уровня 2 (также называемых ZK rollups), таких как zksync, Loopring и Starknet.

Что будет после шардирования?

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

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

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

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

Так какие же эти риски?

Минимальное количество пользователей

Можно представить, что не шардированный блокчейн может работать, если есть хотя бы один пользователь, готовый участвовать. Но шардированный блокчейн не таков: отдельный узел не может обрабатывать всю цепь, поэтому требуется достаточное количество узлов для совместной обработки блокчейна. Если каждый узел может обрабатывать 50 TPS, а цепь может обрабатывать 10,000 TPS, то цепи нужно как минимум 200 узлов, чтобы существовать. Если в любой момент времени в цепи будет менее 200 узлов, это может привести к тому, что узлы не смогут оставаться синхронизированными, или узлы перестанут обнаруживать недействительные блоки, или могут произойти многие другие плохие вещи, в зависимости от настроек программного обеспечения узлов.

На практике, из-за необходимости избыточности (включая выборку доступности данных), безопасное минимальное количество будет в несколько раз выше, чем простое "TPS цепи делить на TPS узлов", для приведенного выше примера мы установим его на 1000 узлов.

Если емкость шардированного блокчейна увеличивается в 10 раз, то минимальное количество пользователей также увеличивается в 10 раз. Теперь все могут задаться вопросом: почему бы нам не начать с более низкой емкости и не увеличивать ее, когда пользователей много, поскольку это наша реальная потребность, а затем снижать емкость, когда количество пользователей снижается?

Здесь есть несколько проблем:

1. Блокчейн сам по себе не может надежно обнаружить, сколько уникальных пользователей на нем, поэтому требуется какое-то управление для обнаружения и установки количества шард. Управление ограничениями по емкости легко может стать источником раскола и конфликтов.
2. Что делать, если много пользователей внезапно одновременно отключатся?
3. Увеличение минимального количества пользователей, необходимого для запуска форка, делает защиту от злонамеренного контроля более сложной.

Минимальное количество пользователей в 1000, можно сказать, почти не проблема. С другой стороны, минимальное количество пользователей в 1,000,000 определенно не подходит. Даже минимальное количество в 10,000 можно считать рискованным. Таким образом, кажется, что трудно доказать, что шардированный блокчейн с более чем несколькими сотнями шардов является разумным.

Историческая проверяемость

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

Да, в 2372 году люди все еще смогут загружать и просматривать ваших крипто-котов.

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

Легко количественно оценить этот риск. Умножив емкость данных блокчейна (MB/сек) на ~30, мы получаем объем данных, хранящихся в год (TB). Текущая емкость данных в плане шардирования составляет около 1.3 MB/сек, что составляет около 40 TB в год. Если увеличить в 10 раз, то это будет 400 TB в год. Если мы хотим не только иметь доступ к данным, но и делать это удобным способом, нам также нужны метаданные (например, для распаковки сводных транзакций), поэтому это может достигнуть 4 PB в год, или 40 PB через десять лет. Internet Archive использует 50 PB. Таким образом, можно сказать, что это верхний предел безопасного размера для шардированного блокчейна.

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

Заключение

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

Компьютеры, запускающие узлы блокчейна, не могут использовать 100% ЦПУ для верификации блоков; им нужно большое запасное пространство для защиты от неожиданных атак DoS, им нужно резервное пространство для выполнения таких задач, как обработка транзакций в мемпуле, и пользователи не хотят, чтобы их компьютеры не могли одновременно использоваться для других приложений, когда они запускают узлы. Пропускная способность также ограничена: соединение 10 МБ/с не означает, что можно обрабатывать блоки размером 10 МБ в секунду! Возможно, мы можем обрабатывать блоки размером 1-5 МБ каждые 12 секунд. Хранение тоже самое: повышение требований к аппаратному обеспечению для запуска узлов и ограничение специализированных операторов узлов не является решением. Для децентрализованного блокчейна критически важно, чтобы обычные пользователи могли запускать узлы и формировать культуру, в которой запуск узлов является общепринятой практикой.

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