Dash

Защита от атак 51%. А как у других?

owner

3 нояб. 2021 г. • 6 min read

Ранее в цикле статей "Безопасность, как сервис" мы рассказывали об уникальной технологии dPoW (delayed Proof of Work) с помощью которой Komodo защищает не только свой блокчейн, но и также помогает защитить сторонние блокчейны. На данный момент под защитой dPoW от Komodo находятся AYA (Aryacoin), CHIPS, GleecBTC, Einsteinium (EMC2), SFUSD и некоторые другие монеты. Но как обстоят дела у других блокчейнов? Используют ли другие блокчейны какие-то уникальные механизмы защиты от атак 51% или решение от Komodo является единственным?

Поиском ответа на этот вопрос мы и займемся в данной статье. Т.е. постараемся рассмотреть варианты, используемые в плане защиты от атак 51%, используемые другими поставщиками блокчейн. При этом основной упор мы постараемся сделать на UTXO-based блокчейны, т.е. на монеты, которые так или иначе являются форками Bitcoin, временно оставив платформу Ethereum за бортом обсуждения.

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

Для начала давайте познакомимся со следующими статьями:

Или их русскоязычными вариантами:

Как следует из приведенных материалов, LLMQ (Long Living Masternode Quorums) кворумы могут использоваться мастернодами для достижения решения в самых разнообразных вопросах. Общая суть процесса состоит в том, что мастерноды в рамках кворума обмениваются между собой информацией об их индивидуальных голосах по рассматриваемому вопросу и закрепляют свое решение с помощью BLS (Boneh-Lynn-Shacham) подписей. Итоговый результат кворума представляет собой всего лишь одну итоговую BLS подпись, которая и распространяется по сети. Т.к. BLS подписи обладают свойством детерминированности и уникальности - для каждой комбинации ключей и сообщения, подписанного ими, существует только одна верная подпись, все остальные участники сети могут легко проверить результат достигнутого консенсуса и доверять ему. В отличие от ECDSA подписей, в которых мультиподпись M-из-N не может быть проверена без верификации подписи каждого из участников в отдельности, BLS предоставляет возможность создания итоговой "короткой подписи", которая аутентифицирует всю коллекцию подписей. И именно этот замечательный факт и использует DASH в LLMQ, распространение и проверка всего лишь одной подписи не требует больших вычислительных ресурсов или большой пропускной способности сети.

Так как же LLMQ кворумы решают задачу защиты от атаки 51%? Для того чтобы разобраться в этом - давайте обратимся к DIP: 0008 - ChainLocks.

Идея ChainLock'ов на основе LLMQ

DIP 0008 представляет ChainLocks, технологию для почти мгновенного подтверждения блоков и нахождения почти мгновенного консенсуса по самой длинной действительной / принятой цепи блоков.

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

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

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

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

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

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

DIP 0008 предлагает новый метод, называемый ChainLocks, для уменьшения неопределенности при получении средств и устранения возможности атак майнинга 51%.

Общая идея ChainLock состоит в том, что мастерноды пытаются "подписать текущий блок" с помощью LLMQ кворума. В случае если в сети присутствует несколько различных вариантов блока с одной и той же высотой, т.е. несколько вариантов цепи, то подписанным окажется тот блок, который пришел к большинству участников кворума первым, поскольку только один из них может достичь большего количества участников LLMQ быстрее, чем другой, и, таким образом, получить большинство в запросе подписи. После того как консенсус найден - участники кворума создают специальное p2p сообщение (CLSIG) и распространяют его в сети. Сообщение включает в себя высоту (height) и hash подписанного блока, а также BLS подпись:

После получения сообщения CLSIG каждый узел в сети, перед тем как разослать его остальным известным узлам, выполняет базовые проверки полученного сообщения, а именно, на основе детерминированного списка мастернод для данной высоты блока узел находит кворум, который был активен на момент добычи этого блока и на основании данных этого кворума (подробнее с данными кворума и запросами / сессиями подписания можно познакомиться в DIP-0007: LLMQ Signing Requests / Sessions) проверяет подпись BLSSig.

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

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

Если блок был получен локально, а CLSIG еще не получено, его следует обрабатывать так же, как и до введения ChainLocks. Это означает, что должны применяться правила самой длинной цепочки и правило "первого увиденного", т.е. когда локально активным становится тот блок, который данный узел увидел первым. Когда CLSIG сообщение для этого блока получено позже - должна применяться вышеуказанная логика.

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

Как видно, реализация защиты от атак 51% используемая в DASH логически в чем-то сходна с реализацией dPoW от Komodo, в том плане что и там, и там определенная группа выделенных узлов, наделенных специальными полномочиями (мастерноды в случае DASH и нотариальные ноды в случае Komodo) пытаются найти консенсус для подписания блока на текущей высоте. После чего подписанный с помощью CLSIG блок в DASH или нотариально заверенный блок в Komodo не может быть отвергнут сетью при попытке реорганизации. Другими словами подписанный или нотариально заверенный блок не удастся отсоединить от текущей активной цепочки. Однако, в случае с DASH сообщения о подписанных блоках MSG_CLSIG ретраслируются узлами в сеть, как и другие inventory сообщения, например MSG_TX или MSG_BLOCK и нигде не сохраняются, а в случае с Komodo информация о нотариально заверенном блоке записывается на блокчейн в специально сформированной транзакции, содержащей все необходимые данные в OP_RETURN.

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