Углубленный взгляд на валидацию блокчейна

Смотрите также:

• [Инженерная безопасность через проблемы координации] (https://hackernoon.com/engineering-security-through-coordinate-problems-tq9pa3p2q)

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

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

Зачем проверять?

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

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

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

Представление определения по сравнению с представлением координации

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

Вот один из примеров точки зрения «по определению» [от Гэвина Андресена] (http://gavinandresen.ninja/a-definition-of-bitcoin):

Вот еще один из [кошелька Wasabi] (https://docs.wasabiwallet.io/using-wasabi/BitcoinFullNode.html#the-importance-of-running-a-full-node); это еще более прямолинейно с точки зрения объяснения того, почему полные узлы ценны:

Обратите внимание на два основных компонента этого представления:

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

1. Важно, чтобы вы оставались в цепочке с правилами, которые вы считаете приемлемыми.

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

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

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

Обычно проблемы с координацией в мире — это плохо: тогда как для большинства людей было бы лучше, если бы английский язык избавился от своей очень сложной и нерегулярной системы правописания и сделал ее фонетической, или если бы Соединенные Штаты перешли на метрическую систему, или если бы мы могли немедленно [понизить все цены и заработную плату на десять процентов в случае рецессии] (http://www.interfluidity.com/v2/6088.html), на практике это требует, чтобы все договорились о переходе на в то же время, и это часто очень и очень трудно.

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

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

Углубление проверки

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

по умолчанию провал > по умолчанию хаос > по умолчанию победа

«>» здесь, конечно, означает «лучше, чем». Лучше всего, если атака полностью проваливается; второй вариант — если атака приводит к путанице, когда все расходятся во мнениях относительно того, какая цепочка правильна, и худший — если атака удалась. Почему хаос намного лучше победы? Это вопрос стимулов: хаос увеличивает затраты для атакующего и лишает его уверенности в том, что он даже выиграет, в первую очередь отбивая охоту к попыткам атак. Среда «по умолчанию к хаосу» означает, что злоумышленнику необходимо выиграть и войну блокчейнов, чтобы совершить атаку 51%, и* «социальную войну», чтобы убедить сообщество следовать за ним. Это гораздо сложнее и гораздо менее привлекательно, чем просто начать атаку 51% и тут же заявить о своей победе.

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

Легкие клиенты и доказательства мошенничества

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

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

![Один блок в цепочке блоков касается только нескольких учетных записей. Доказательство мошенничества будет содержать данные в этих учетных записях вместе с доказательствами Меркла, доказывающими, что эти данные верны.

Этот метод также иногда называют * [проверка без сохранения состояния] (https://ethresear.ch/t/the-stateless-client-concept/172)*: вместо того, чтобы хранить полную базу данных о состоянии блокчейна, клиенты могут хранить только заголовки блоков, и они могут проверить любой блок в режиме реального времени, запросив у других узлов доказательство Меркла для любых желаемых записей состояния, к которым обращается проверка блока.

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

Шардинг

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

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

Вот что обычно означает аудируемость в реальном мире: не то, что все постоянно все проверяют, а то, что (i) на каждой конкретной части достаточно глаз, чтобы, если есть ошибка, она была обнаружена, и (ii) когда обнаружена ошибка, которая должна быть сделана ясной и видимой для всех.

Тем не менее, в долгосрочной перспективе блокчейны, безусловно, могут улучшить это. Одним из конкретных источников улучшений являются ZK-SNARK (или «доказательства достоверности»): эффективно проверяемые криптографические доказательства, которые позволяют производителям блоков доказывать клиентам, что блоки удовлетворяют некоторым произвольно сложным условиям достоверности. Доказательства достоверности более надежны, чем доказательства мошенничества, потому что они не зависят от интерактивной игры для обнаружения мошенничества. Еще одной важной технологией является [проверка доступности данных] (https://arxiv.org/pdf/1809.09044.pdf), которая может защитить от блоков, данные которых опубликованы не полностью. Проверки доступности данных основаны на очень консервативном предположении, что где-то в сети существует хотя бы небольшое количество честных узлов, хотя хорошая новость заключается в том, что этот минимальный порог честности низок и не растет, даже если есть очень большое количество нападающих.

Тайминг и атаки 51%

Теперь давайте перейдем к самому мощному последствию мышления «по умолчанию к хаосу»: 51% нападают на себя. Текущая норма во многих сообществах заключается в том, что если атака 51% побеждает, то эта атака 51% обязательно является действительной цепочкой. Эта норма часто соблюдается довольно строго; и недавняя [атака 51% на Ethereum Classic] (https://blog.bitquery.io/attacker-stole-807k-etc-in-ethereum-classic-51-attack) хорошо иллюстрирует это. Злоумышленник отменил более 3000 блоков (похитив 807 260 ETC при двойной трате в процессе), что отодвинуло цепочку дальше в истории, чем один из двух клиентов ETC (OpenEthereum) технически мог откатить; в результате узлы Geth присоединились к цепочке злоумышленника, а узлы OpenEthereum остались с исходной цепочкой.

Можно сказать, что атака действительно привела к хаосу по умолчанию, хотя это была случайность, а не преднамеренное проектное решение сообщества ETC. К сожалению, затем сообщество решило принять (более длинную) цепочку атак как каноническую, шаг [описанный в твиттере eth_classic] (https://twitter.com/eth_classic/status/1289637659351031809) как «следующий Proof-of-Work, как и предполагалось». . Следовательно, нормы сообщества активно помогли злоумышленнику победить.

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

![5 предел возврата блока только для иллюстрации; на самом деле ограничение может быть больше, например, 100-1000 блоков.

Чтобы было ясно, это вносит существенное изменение в то, как определяется каноничность: вместо того, чтобы клиенты просто смотрели на данные, которые они получают сами по себе, клиенты также смотрят на когда эти данные были получены. Это приводит к возможности того, что из-за задержки в сети клиенты расходятся во мнениях: что, если из-за массированной атаки два конфликтующих блока A и B завершатся одновременно, и некоторые клиенты сначала увидят A, а некоторые — B? Но я бы сказал, что это хорошо: это означает, что вместо победы по умолчанию даже атаки 51%, которые просто пытаются вернуть транзакции, по умолчанию приводят к хаосу, а внеполосное экстренное реагирование может выбрать, какой из двух блоки, с которых продолжается цепочка. Если протокол хорошо разработан, форсирование эскалации до внеполосного экстренного реагирования должно быть очень дорогим: в доказательстве доли такая вещь потребует, чтобы 1/3 валидаторов пожертвовали своими депозитами и были сокращены.

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

Для блокчейн-сообщества, которое ценит неизменность, введение ограничений на возврат такого рода, возможно, является лучшим путем. Трудно честно заявить, что блокчейн неизменен, когда независимо от того, как долго транзакция была принята в цепочке, всегда существует вероятность того, что какие-то неожиданные действия могущественных субъектов могут отменить ее. Конечно, я бы сказал, что даже BTC и ETC уже имеют крайний предел возврата; если бы произошла атака, которая вернула вспять несколько недель активности, сообщество, скорее всего, приняло бы софтфорк, активируемый пользователем, чтобы отвергнуть цепочку злоумышленников. Но более окончательное согласование и официальное оформление этого кажется шагом вперед.

Вывод

Здесь есть несколько «моралей истории». Во-первых, если мы признаем легитимность социальной координации и легитимность косвенной валидации с использованием моделей доверия «1 из N» (то есть, если предположить, что где-то в сети существует один честный человек; НЕ то же самое, что предположить, что что одна конкретная сторона, например Infura, честна), то мы можем создавать гораздо более масштабируемые блокчейны.

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

В-третьих, если мы допустим, что определение каноничности включает время, то мы открываем много дверей для улучшения нашей способности отклонять атаки 51%. Легче всего получить свойство [слабая субъективность] (https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/): идея о том, что если клиенты должны регистрировать по крайней мере один раз каждый например. 3 месяца, и отказаться от возврата дольше, тогда мы можем добавить слэш к доказательству доли и сделать атаки очень дорогими. Но мы можем пойти дальше: мы можем отклонить цепочки, возвращающие финализированные блоки, и тем самым защитить неизменяемость и даже защитить от цензуры. Поскольку сеть непредсказуема, зависимость от времени действительно подразумевает атаки, «по умолчанию приводящие к хаосу» в некоторых случаях, но преимущества того стоят.

Имея в виду все эти идеи, мы можем избежать ловушек (i) чрезмерной централизации, (ii) чрезмерной избыточной проверки, ведущей к неэффективности и (iii) ошибочных норм, случайно упрощающих атаки, и лучше работать над созданием более устойчивых , производительные и безопасные блокчейны.

• Первоначально опубликовано как «[Философия проверки блокчейна] (https://vitalik.ca/general/2020/08/17/philosophy.html)»*