Глубокое погружение: модель безопасности Биткойна

Глубокое погружение: модель безопасности Биткойна
В процессе обсуждения механизма консенсуса для различных криптовалют возникает одна проблема, вызывающая ряд вопросов. Это нехватка понимания (и определений) относительно модели безопасности, обеспечивающей сохранность исторических данных в реестре. Несмотря на то, что каждая модель консенсуса теоретически нацелена предотвращать различные атаки, весьма важно понимать цели преследуемые отдельно взятой моделью.
У каждой модели безопасности есть две главные части: предположения и гарантии. Если предполагаемые входные данные являются верными, то должны обеспечиваться и гарантии на выходе из модели.

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

В поисках истины
«Одна из сильных сторон Биткойна — даже одна из самых главных, по моему мнению — это ваша возможность низкой степени доверия к другим». — Питер Уилл

Цель распределённых реестров — обеспечивать упорядоченную историю событий, потому что в распределённых системах вы не можете просто доверять временным меткам.

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

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

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

• Никто не увеличивал денежную массу кроме майнеров и в соответствии со строго установленным графиком;
• Никто не потратил деньги без владения соответствущим приватным ключом;
• Никто не потратил те же самые деньги дважды.

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

• Любой блок в цепи был создан в течение двухчасового промежутка относительно временной метки самого блока;
• Они синхронизируют подлинную версию истории блокчейна.

На техническом уровне это потребует множества проверок.

Все блоки следуют правилам консенсуса:

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

Все транзакции следуют правилам консенсуса:

• Входные и выходные значения являются допустимыми;
• Транзакции тратят только неистраченные выходы;
• Все потраченные входы имеют действительные подписи;
• Ни один из выходов Coinbase транзакций не был истрачен ранее 100 блоков, найденных с момента их создания (созревание полученных майнерами монет);
• Ни одна из транзакций не истратила входы в неподтверждённом состоянии, т.е до включения её в блок.

Есть также множество других правил, обсуждение которых здесь займёт слишком много времени.

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

Источник: “Bitcoin’s Security Model Revisited” by Yonatan Sompolinsky1 and Aviv Zohar
Пока никто из атакующих не обладает вычислительной мощностью, превышающей мощность сети на 50% и честные узлы могут быстро связываться между собой, вероятность отмены транзакции уменьшается по экспоненте вместе с ростом количества подтверждений этой транзакции. Есть другие типы атак, например эгоистичный майнинг, которые могут снизить необходимое количество мощности, однако, они довольно сложны в реализации.

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

Источник: http://bitcoin.sipa.be
Разберём некоторые ценовые показатели такой атаки:

Antminer S9 требует 0.1 джоулей на Гх/с(109 хэшей)
1026 хэшей * 0.1 Дж / 109 хэшей = 1015 джоулей
1015 джоулей = 2,777,777,778 кв/ч * $0.10 кв/ч = $277,777,778 будет стоимость электроэнергии для перезаписи всего блокчейна.

На момент написания статьи, сложность отдельно взятого блока стремится к 253,618,246,641, что потребует примерно:
253,618,246,641 * 248 / 65535 = 1.09 * 1021 хэшей.
1.09 * 1021 хэшей * 0.1 J / 109 хэшей = 1.09 * 1011 джоулей
1.09 * 1011 джоулей = 30,278 кВт/час * $0.10 кВт/час = $3,028 стоимость электроэнергии для перезаписи одного блока.

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

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

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

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

Это также известно как «Sybil сопротивление», означающее, что невозможно атаковать узел, создавая много нечестных пиров, выдающих ложную информацию.



На рисунке представлен наихудший сценарий, в котором ваш узел подвергается массированной Sybil атаке, но всё ещё имеет одно соединение с честным узлом, который подключен к истинной Биткойн-сети. До тех пор, пока один честный пир передает истинные блокчейн-данные на ваш полный узел, будет совершенно ясно, что какие-то Sybil злоумышленники пытаются обмануть вас, и ваш узел будет игнорировать их.

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

Авторы “Research Perspectives and Challenges for Bitcoin and Cryptocurrencies” отмечают следующие свойства, которые важны для стабильности криптовалюты:

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

Экспоненциальное сближение. Вероятность ответвления для глубины n равна O(2−n). Это дает пользователям высокую уверенность, что простое правило “k подтверждений” обеспечит неизменяемость состоявшихся транзакций.

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

Правильность. Все блоки в цепи с наибольшим доказательством объёма работы будут включать только действительные транзакции.

Справедливость. Майнер, владеющий X% от общей вычислительной мощности сети будет добывать приблизительно X% блоков.

Авторы статьи отмечают, что Биткойн, по-видимому, обладает этими свойствами, по крайней мере, в предположении, что большинство майнеров остаются честными, а стимулировать их будет вознаграждение за найденный блок, полученный при предоставлении доказательства выполненного объема работы (Proof of Work).

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

• Доказательство владения;
• Доказательство возраста монеты;
• Доказательство депозита;
• Доказательство уничтожения;
• Доказательство деятельности;
• Доказательство затрат прошедшего времени;
• Федеративный Консенсус;
• Практическая Византийская Отказоустойчивость.

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

Недопонимание модели безопасности
Есть распространенное ошибочное предположение, что у Биткойна существует чётко определённая модель безопасности.

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

Тем не менее, есть несколько свойств Биткойн-протокола, которые часто анализируются неправильно.

Некоторые блокчейны достаточно сильно пострадали от атак, когда разработчики добавляли централизованно транслируемые подписанные контрольные точки в программное обеспечение узла, по сути утверждая, что “блок X был проверен разработчиками как находящийся в правильной исторической цепочке.” Это является моделью абсолютной централизации.

Стоит отметить, что биткойн имеет 13 жестко закодированных контрольных точек, но они не меняют модель безопасности так, как это делают централизованно транслируемые контрольные точки. Последняя контрольная точка была добавлена в Bitcoin Core 0.9.3 и находится на блоке 295000, который был создан 9 апреля 2014 года. Этот блок имел сложность 6,119,726,089, которая потребует приблизительно:

6,119,726,089 * 248 / 65535 = 2.62 * 1019 хэшей
2.62 * 1019 хэшей * 0.1 J / 109 хэшей = 2.62 * 109 джоулей
2.62 * 109 джоулей = 728 кВт/час * $0.10 кВт/час = $73 сумму для генерации блока.

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

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

Грег Максвелл и Питер Уилл вдвоём заявили, что они надеются когда-нибудь полностью удалить контрольные точки. Ведущий специалист по сопровождению Bitcoin Core Владимир ван дер Лаан отметил, что контрольные точки являются постоянным источником путаницы для людей, которые стремятся понять модель безопасности Биткойна.

Можно привести аргумент, означающий, что полный узел “доверяет” разработчикам Bitcoin Core относительно действительности истории блокчейна до 9 апреля 2014 года, но узел по-прежнему проверяет Merkle-хэши в заголовке каждого блока, а это означает, что надежность истории транзакций по-прежнему обеспечивается доказательством произведённой работы. Эти старые контрольные точки позволяют увеличить производительность (пропуская проверку подписи) при первоначальной синхронизации блокчейна, хотя введение libsecp256k1 сделало разницу в производительности менее значительной.

Контрольные точки остаются задействованными для трех целей:

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

Пока писалась эта статья, Грег Максвелл предложил заменить контрольные точки кумулятивной проверкой работы. Как только узел настраивается на цепь, которая содержит больше чем 5.4 * 1024хэша, цепи с меньшим количеством кумулятивной работы будут считаться недействительными. Это примерно совпадает с объемом выполненных работ до блока 320,000 в сентябре 2014 года, и на тот момент сложность отдельных блоков была примерно 27,000,000,000.

Источник: Blockchain.info
Добыча блоков на сложности 27,000,000,000 потребует примерно
27,000,000,000 * 248 / 65535 = 1.16 * 1020 хэшей
1.16 * 1020 хэшей * 0.1 дж / 109 хэшей = 1.16 * 1010 джоулей
1.16 * 1010 джоулей = 3,222 кВт/час * $0.10 кВт/час = $322 за блок

Таким образом, учитывая предложенное изменение, если Sybil-атакующий полностью окружил новый узел, который синхронизировался с нуля, он смог бы выдавать ему ложные блоки, начиная с любого блока после genesis блока, почти не затрачивая средств. Если Sybil злоумышленник полностью окружил узел, который синхронизировался примерно с блока 320 000, он может начать выдавать ему ложную цепь с этой точки по цене 322 доллара за блок.

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

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

В дополнение к контрольным точкам существует также вопрос о том, как узел загружает сам себя. Текущий процесс для Биткойн-узлов заключается в том, чтобы проверить, есть ли у него локальная база данных пиров, о которых он знал ранее. Если нет, то он запросит набор “семян DNS”, которые жестко закодированы в программное обеспечение. Эти семена содержат список адресов хорошо связанных Биткойн-узлов, загружаемых на ваш узел.

Как мы видим из кода Bitcoin Core 0.13, активные на сегодня DNS семена поддерживают Питер Уилл, Мэтт Коралло, Люк Дашр, Кристиан Декер, Джефф Гарзик и Джонас Шнелли. Любой может поддерживать в сети DNS семена, используя ПО Питера Уила bitcoin-seeder или ПО Мэтта Коралло, хотя для принятия новыми узлами, вам нужно убедить разработчиков одной из полных реализаций узла добавить свой DNS-хост в их программное обеспечение.

Это может ещё раз показаться точкой абсолютной централизации, когда процесс начальной загрузки для нового узла зависит от всего лишь шести семян DNS. Напомним, что модель безопасности Биткойна требует подключения только к одному честному пиру, для противодействия Sybil атакам.

Таким образом, новый узел должен быть в состоянии только соединиться с одним семенем DNS, которое не скомпрометировано и возвращает IP-адреса честных узлов. Однако существует резервный вариант, если по какой-то причине все семена DNS недоступны – это жестко закодированный список надежных IP-адресов узлов, который обновляется для каждого релиза.

Модель безопасности для различных параметров инициализации заключается не в том, что оператор полного узла доверяет ДНС семенам от Х или разработчикам ядра от Y чтобы выдавать им честные данные, а в том, что по крайней мере 1/х ДНС семян не скомпрометировано или 1/y Core разработчиков честны относительно рассмотрения утверждённых изменений списка жёстко запрограммированных пиров.

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

Существуют методы проверки программного обеспечения путем сопоставления цифровых подписей вашего двоичного файла с подписями van der Laan, но маловероятно, что многие люди озаботятся прохождением такой проверки. Что касается надежного оборудования, это сложная проблема. Скорее всего вы будете использовать безопасное аппаратное решение наподобие ORWL, которое гарантированно “самоуничтожится”, при попытке вмешательства извне.

Однако, учитывая, что аппаратные архитектуры для процессоров, оперативной памяти и другого важного оборудования, как правило, являются проприетарными, вы никогда не можете быть на 100% уверены, что они не скомпрометированы.

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

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

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



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

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

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

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

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

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

Клиент, использующий упрощенную проверку платежей (SPV), загружает полную копию заголовков для всех блоков во всей цепи. Это означает, что требования к загрузке и хранению масштабируются линейно с количеством времени с момента изобретения Биткойна. Это описано в разделе 8 whitepaper Биткойна.



Сатоши писал, что SPV клиент “не может проверить транзакцию самостоятельно, но связав её с определённым местом в цепи, он может увидеть, что сетевой узел принял её, и блоки, добавленные после неё, в дальнейшем лишь подтверждают принятие транзакции сетью”. SPV предполагает, что дальнейшее блокирование транзакции X будет стоить дорого.

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

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

SPV клиенты могут сделать запрос, чтобы узнать информацию о транзакциях, затрагивающих определенные адреса. Несмотря на то, что для пиров было бы довольно дорого лгать о существовании поддельных подтвержденных транзакций (потребуется майнинг блока с достаточным количеством PoW), они могут лгать, утверждая, что результаты для bloom фильтра, использованного для запроса информации о транзакциях, отсутствуют. Также стоит отметить, что SPV серьёзно уязвима с точки зрения кофиденциальности по причине дефектов в bloom фильтрах.

BitcoinJ имеет отличное описание модели безопасности SPV. Касаемо неподтвержденных транзакций отмечено:

“В режиме SPV, единственная причина, по которой вы можете доверять подлинности транзакции, это факт трансляции транзакции узлами к которым вы подключены. Если злоумышленник смог бы убедить вас, что вы подключены к его узлам, это означало, что он смог бы заставить вас принять полностью недействительную транзакцию (потраченные несуществующие деньги), и она все равно была бы принята, как если бы она была настоящей”.

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

Там нет такого места, как Локалхост
Если вы не оперируете полным узлом (и фактически не используете его для проверки транзакций), вы передаете на аутсорсинг по крайней мере некоторый уровень доверия третьим лицам, что приводит к иной модели безопасности для вашего использования Биткойна. Обратите внимание, что это не обязательно требует, чтобы все пользователи и компании создавали свое ПО непосредственно поверх RPC API Bitcoin Core.

Некоторые альтернативные конфигурации инфраструктуры могут использовать следующие варианты, но не ограничиваться только ими:

1) Использование мобильного кошелька, такого как Bitcoin Wallet для Android, GreenAddress или Stash, которые позволяют настроить кошелек для выполнения запросов только с вашего собственного полного узла.

2) Создание приложений на основе библиотек узлов SPV, таких как BitcoinJ, и настройка их для подключения только к вашим собственным полным узлам. В BitcoinJ это можно сделать, определив собственные SeedPeers, которые вы передаете вашей группе пиров во время инициализации. С помощью libbitcoin вы можете настроить сетевое подключение к определенному узлу, используя этот пример.

3) Создание прокси-сервера, совместимого с API JSON-RPC Bitcoin Core, который отправляет некоторые вызовы сторонним сервисам, но также автоматически проверяет возвращаемые ими данные, делая запросы к локальному полному узлу. Для примера см. BitGo’s BitGoD software. Эта гибридная модель способна предоставить лучшее из обоих миров: вы можете использовать расширенные функции, предоставляемые третьими сторонами, сохраняя свой финансовый суверенитет.

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