Дэвид Розенталь: Мой доклад на конференции «Блокчейн для бизнеса»

Данный пост д-ра Дэвида Розенталя (David Rosenthal – на фото) была опубликован на его блоге (DSHR's Blog) 8 октября 2021 года.

Меня вместе с Джоном Райаном (John Ryan) и Дэном Гиром (Dan Geer) пригласили принять участие в круглом столе, проводившемся в рамках организованной Университетом Арканзаса конференции «Блокчейн для бизнеса» (Blockchain for Business) ( https://blockchain.uark.edu/conference-2021/ ). Ниже приведены мои вступительные замечания.

Мой комментарий: Конференция проводилась в дистанционном режиме 8 октября 2021 года. Программа конференции доступна по адресу https://cpb-us-e1.wpmucdn.com/wordpressua.uark.edu/dist/5/444/files/2018/01/2021-Conference-Agenda-1-2.pdf . Круглый стол, о котором идёт речь, назывался «Безопасность и смягчение рисков в блокчейн-системах» (Blockchain Security & Risk Mitigation).

Я хотел бы поблагодарить Дэна Конвея (Dan Conway) за приглашение поговорить о безопасности блокчейнов. Вам не нужно конспектировать; текст моего выступления со ссылками на источники выложен на моём блоге, см. на https://blog.dshr.org .

К сожалению, термин «блокчейн» (blockchain) используется для описания двух совершенно разных технологий, у которых общим является лишь то, что они обе используют структуру данных, называемую деревом Меркла (Merkle Tree, см. http://www.merkle.com/papers/Protocols.pdf ; см. также https://ru.wikipedia.org/wiki/Дерево_хешей - Н.Х.), обычно в виде, запатентованном Стюартом Хабером (Stuart Haber) и Скоттом Сторнеттой (Scott Stornetta) в 1991 году, см. https://doi.org/10.1007/3-540-38424-3_32 . Блокчейн - это линейная цепочка блоков, каждый из которых включает хеш предыдущего блока. Ещё печальнее то, что более безопасный способ (см. https://blog.dshr.org/2018/11/certificate-transparency.html ) реализации заслуживающих доверия публичных баз данных с использованием деревьев Меркла блокчейном не называется, и, соответственно,  не получает никаких дивидендов от волны шумихи, поднятой вокруг этого термина.

В случае блокчейна с ограниченным доступом (permissioned blockchains) существует центральный орган, контролирующий, какие сетевые узлы могут добавлять блоки в блокчейн-цепочку; в то время, как в блокчейнах без ограничения доступа (permissionless blockchains), таких как Биткойн, этого не делается. Данное различие является принципиальным:

• Блокчейны с ограниченным доступом могут использовать хорошо зарекомендовавшие себя и относительно эффективные методы, такие, как «Византийская отказоустойчивость» (Byzantine Fault Tolerance, см. https://doi.org/10.1145/357172.357176 - также часто используется термин «проблема византийских генералов» - Н.Х.), для обеспечения того, что бы каждый узел в сети выполнил одинаковые вычисления над одними и теми же данными для получения такого же состояния для следующего блока в цепочке. Это механизм консенсуса (consensus mechanism).
  
  
• В принципе, каждый узел в сети блокчейна без ограничения доступа может выполнять разные вычисления над разными данными, и получить отличающееся состояние для следующего блока в цепочке. Какой из всех этих блоков попадёт в блокчейн-цепочку, определяется рандомизированным и предвзятым механизмом голосования (election mechanism). Например, в блокчейнах на основе доказательства выполнения работы (Proof-of-Work), таких, как Биткойн, узел побеждает в голосовании, если первым решит вычислительную задачу. Время, необходимое для решения этой задачи, является случайным, но вероятность оказаться первым у участников неодинаковая, поскольку она пропорциональна вычислительной мощности, которую использует узел.

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

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

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

• Отсутствует центральный орган для сбора средств на оплату голосующих (избирателей), поэтому их расходы должны возмещаться самой системой - либо посредством инфляции криптовалюты, либо посредством уплаты комиссии за транзакцию, либо и того, и другого вместе. В настоящее время доход «майнеров» биткойнов на 90% состоит из вознаграждения (т.е. инфляции). Исследование (см. https://www.bis.org/publ/work765.pdf ) показывает, что система только с оплатой комиссионных (см. http://randomwalker.info/publications/mining_CCS.pdf ), которой стремится стать Биткойн, является небезопасной.
  
  
• Возложение затрат с помощью алгоритма доказательства выполнения работы (Proof-of-Work), как это делает большинство криптовалют, приводит к катастрофически большому «углеродному следу» (см. https://blog.dshr.org/2021/10/cryptocurrencys-carbon-footprint.html ). Альтернативы этому алгоритмы (см. https://blog.dshr.org/2021/07/alternatives-to-proof-of-work.html ) являются куда более сложными, и их чрезвычайно сложно сделать правильно. Тот же Ethereum уже лет семь пытается внедрить «доказательство доли» (Proof-of-Stake).
  
  
• Для информационных технологий характерна большая экономия при увеличении масштабов. Чем больше ресурсов имеется у избирателя, тем выше его маржа. В результате этого успешные блокчейны без ограничения доступа фактически централизованы; 3-4 майнинговых пула контролируют большую часть мощности майнинга биткойнов в течение уже как минимум 7 лет.

Утверждается, что преимуществом блокчейнов без ограничения доступа над блокчейнами с ограничение доступа является децентрализация. Однако на практике - это иллюзия, и огромные затраты на попытки избежать централизации тратятся впустую (см. https://arxiv.org/pdf/1801.03998.pdf ):

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

Ethereum всегда был даже более централизованным, чем Биткойн, и, поскольку это среда программирования, то его поверхность для атак экспоненциально больше. В частности, как мы видим в недавней атаке на сеть Poly Network с ущербом в 600 миллионов долларов (см. https://www.lawfareblog.com/disrupting-cryptocurrencies-2-lessons-poly-hack ), Ethereum гораздо более уязвим для атак на цепочку поставок такого типа, от которых Мунин (Munin) предостерегает в других средах.

На самом деле, централизация - это часто хорошая вещь. Ошибки неизбежны, как мы видим на примере недавнего «прокола» на 90 миллионов долларов в Compound ( https://www.bleepingcomputer.com/news/security/crypto-platform-mistakenly-gives-90m-to-users-asks-for-refund ) и последующего «прокола» на 67 миллионов долларов (https://www.cnbc.com/2021/10/03/162-million-up-for-grabs-after-bug-in-defi-protocol-compound-.html ); или на примере комиссионных в размере 23 миллионов долларов, которые Bitfinex заплатила за транзакцию в 100 тысяч долларов ( https://cryptocat.news/2021/09/27/bitfinex-paid-a-colossal-23m-fee-to-send-100k-of-usdt/ ). Централизация Ethereum позволила Poly Network убедить майнеров максимально затруднить распоряжение добычей в размере 600 миллионов долларов и заставить вора вернуть большую часть этой добычи. Неизменяемость (immutability) звучит отлично – но лишь до тех пор, пока Вы не станете жертвой кражи.

Менее уязвимый способ реализации надежной децентрализованной базы данных продемонстрирован системой «Прозрачность сертификатов» (Certificate Transparency system, https://www.certificate-transparency.org/ ), описанной в спецификациях RFC 6962 (  https://tools.ietf.org/html/rfc6962 ). Эта система, построенная на принципе «доверяй, но проверяй» является, как правило, гораздо более подходящей моделью для деловой деятельности, чем обеспечение неизменности. Данный подход позволяет в режиме реального времени проверять, что сертификаты, защищающие протокол HTTPS, были выпущены соответствующим удостоверяющим центром (Certificate Authority, CA) и являются действующими. По сути, это сеть с узлами трёх типов:

• Журналы аудита (logs), в которые удостоверяющие центры предоставляют сведения о своих текущих сертификатах и из которых они получают подтверждения, называемые «отметками времени подписанных сертификатов» (Signed Certificate Timestamps, SCT) - их владельцы могут прикреплять к своим сертификатам. Клиенты могут проверить подпись на SCT-квитанции, а затем убедиться, что хеш, который содержит данная квитанция, соответствует сертификату. Если такое соответствие имеет место, то сертификат был именно тем сертификатом, который удостоверяющий центр представил в журнал аудита, и который был проверен его владельцем. Каждый журнал аудита поддерживает структуру данных дерева Меркла ( https://en.wikipedia.org/wiki/Merkle_tree ) сертификатов, для которых он выдал SCT-квитанции.
  
  
• Контролёры (monitors), которые периодически скачивают все вновь добавленные записи из журналов аудита, за которыми они наблюдают, и проверяют, действительно ли они были добавлены в журнал аудита, а также выполняют серию проверок их достоверности. Такие узлы также выполняют функции резервных копий отслеживаемых ими журналов аудита.
  
  
• Аудиторы, которые используют дерево Меркла проверяемых ими журналов аудита для контроля того, что сертификаты были правильно добавлены в журналы аудита, и что не было никаких позднейших вставок, удалений или модификаций сертификатов в журнале. Клиенты могут использовать аудиторов для того, чтобы определить, появился ли сертификат в журнале аудита. Если это не так, они могут использовать SCT-квитанцию, чтобы доказать, что журнал аудита ведёт себя некорректно.

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

Обратите внимание на то, что в отличие от блокчейна, это не механизм консенсуса или выборов / голосования. Это механизм для обеспечения того, что ни один из участников сети не сможет избежать ответственности за свои действия, - что во многих случаях как раз то, что необходимо. Например, Хоф (Hof) и Карл (Carle) – см. https://arxiv.org/pdf/1711.07278.pdf - показывают, как такой же механизм можно применить для защиты цепочки поставок программного обеспечения ( https://blog.dshr.org/2018/12/securing-software-supply-chain.html ).

Дэвид Розенталь (David Rosenthal)

Мой комментарий: С моей точки зрения, Дэвид Розенталь правильно обращает внимание на то, что блокчейны и распределенные реестры невозможно рассматривать и регламентировать как некую однородную массу, и что между системами «с ограничением доступа» и «без ограничения доступа» существуют принципиальные различия, которые абсолютно необходимо принимать во внимание. Я постоянно сталкиваюсь с этим упрямым фактом при работе в профильном техническом комитете ИСО – равно как и с упорным нежеланием коллег открыто его признать :)

Источник: DSHR's Blog
https://blog.dshr.org/2021/10/talk-at-blockchain-for-business.html