Пределы масштабируемости блокчейна

Оригинал: https://vitalik.ca/general/2021/05/23/scaling.html
Перевели: t.me/notothemoon

Особая благодарность Феликсу Ланге, Мартину Свенде, Мариусу ван дер Вейдену и Марку Тайнвею за фидбек и обзор.

Как далеко вы сможете масштабировать блокчейн? Сможете ли вы на самом деле, как того желает Илон Маск, "ускорить время блока в 10 раз, увеличить размер блока в 10 раз и снизить комиссии в 100 раз", не придя к крайней централизации и угрозе фундаментальных свойств, которые делают блокчейн тем, чем он является? Если нет, то как далеко вы способны зайти? А если поменять алгоритм консенсуса? Еще более важно, что, если вы измените технологию, введя такие функции, как ZK-SNARK или сегментирование? В теории, сегментированный блокчейн может просто добавлять новые участки; однако присутствует ли здесь фактор избыточности?

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

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

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

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

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

Может ли это произойти на вашем блокчейне? Элита вашего блокчейн-сообщества, включая пулы, эксплореры блоков и размещенные ноды, скорее всего довольно хорошо скоординированы; вполне вероятно, что все они переписываются в одних telegram каналах и группах wechat. Если они действительно захотят организовать внезапное изменение правил протокола в своих собственных интересах, то они это смогут. Блокчейн Ethereum сумел полностью исправить ошибки консенсуса за десять часов; если ваш блокчейн имеет только одну реализацию клиента, и есть необходимость развернуть изменение в коде только для пары десятков нод, координирование внесения этих изменений в код клиента можно осуществить намного быстрее. Единственный точный способ сделать такую скоординированную социальную атаку неэффективной - это пассивная защита от одного субъекта, который на самом деле децентрализован: пользователи.  

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

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

Итак, каковы пределы нагрузки полных нод?

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

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

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

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

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

• Неверный ответ: 100% мощности ЦП может быть потрачено на проверку блока
• Правильный ответ: ~5-10% мощности ЦП может быть потрачено на проверку блока 

Существует четыре основных причины, по которым лимит настолько низок:

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

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

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

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

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

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

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

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

Хранение

• Неверный ответ: 10 терабайт
• Правильный ответ: 512 гигабайт

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

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

Эффекты взаимодействия 

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

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

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

Так что же это означает для Ethereum?

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

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

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

Что произойдет после сегментирования? 

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

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

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

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

Так каковы эти риски? 

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

Блокчейн без сегментирования может работать до тех пор, пока есть хотя бы один пользователь, который хочет им пользоваться. Сегментированные блокчейны отличаются: ни одна нода не сможет обработать всю цепочку, и поэтому необходимо иметь достаточно нод, чтобы они могли, по крайней мере, обработать ее вместе. Если каждая нода может обрабатывать 50 TPS, а сам чейн способен обработать 10000 TPS, то необходимо как минимум 200 нод для его выживания. Если в какой-то момент нод оказывается меньше 200, то либо все они перестают поддерживать цепочку, либо они не способны обнаруживать недопустимые блоки, либо происходит еще что-нибудь плохое (зависит от настройки ПО нод).

На практике, безопасное минимальное количество в несколько раз больше, чем наивный расчет вроде “ TPS чейна поделить на TPS нод”, из-за необходимости избытка (в том числе для выборки данных); для нашего вышеописанного примера, скажем, этот минимум составляет 1000 нод. 

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

С этим возникают некоторые проблемы: 

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

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

Восстановление истории

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

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

Количественно оценить этот риск несложно. Возьмите емкость данных блокчейна в МБ/сек и умножьте на ~30, чтобы получить объем данных, хранящихся в терабайтах ежегодно. Текущий план сегментирования предусматривает пропускную способность данных ~1.3 МБ/с, то есть около 40 ТБ/год. Если это увеличится в 10 раз, получаем 400 ТБ/год. И если мы хотим, чтобы данные были не просто доступными, но и удобно доступными, нам также понадобятся метаданные (например, декомпрессия роллапов транзакций), поэтому показатели растут до 4 петабайтов в год или 40 петабайт через десятилетие. Интернет-архив использует 50 петабайт. Это разумный потолок того, насколько большим может безопасно стать сегментированный блокчейн.

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

Заключение 

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

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