Глазами инженера: Фундаментальные проблемы блокчейна и как их решить

Блокчейн-инженер Притхи Касиредди (Preethi Kasireddy) делится своим взглядом на существующие проблемы этой технологии и методы их решения. Оригинал материала опубликован в ее блоге на Medium. Представляем вашему вниманию перевод.

Ни у кого не вызывает сомнений тот факт, что технология блокчейн обладает гигантским потенциалом.

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

Действительно, кампании ICO, в ходе которых были собраны миллиарды, и стремительный рост цен на протяжении 2017-го — всё это достаточно увлекательно. Хайп реален.

Поймите меня правильно. Мне нравится то обстоятельство, что хайп в связи с блокчейном помогает популяризировать его среди обычных пользователей. Я наконец-то перестала встречать непонимающие взгляды, произнося такие слова, как «биткоин» или «эфир».

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

К числу технических барьеров относятся (список не исчерпывающий):

• ограниченная масштабируемость;
• ограниченная конфиденциальность;
• отсутствие формальной верификации контрактов;
• необходимость хранить большие объёмы данных;
• ненадёжность механизмов достижения консенсуса;
• отсутствие управления и стандартов;
• недостаточный инструментарий;
• угроза со стороны квантовых вычислений.

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

Я считаю, что нам, разработчикам, критически важно отвлечь своё внимание от новых «лучезарных» ICO и направить его на реальные технологические вызовы на нашем пути.

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

Ограниченная масштабируемость

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

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

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

Из этого вытекают два практических следствия:

1. Низкая пропускная способность: блокчейны способны обрабатывать только ограниченное число транзакций.
2. Медленный темп транзакций: на обработку одного блока транзакций уходит слишком много времени. Например, время обработки блока биткоина составляет 10 минут, в то время как обработка блока эфира занимает 14 секунд. Сейчас, в периоды максимальной нагрузки на сеть, требуется даже больше времени. Сравните это с практически мгновенными подтверждениями у таких сервисов, как Square или Visa.

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

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

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

Решения проблемы масштабируемости

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

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

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

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

Примерами сетей каналов микроплатежей являются Raiden Network и Lightning Network.

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

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

Направленные ациклические графы. Направленный ациклический граф, или НАГ (Directed Acyclic Graph, DAG), представляет собой графическую структуру данных, имеющую рёбра и вершины. Вершина — это точка на графе, а ребро — путь от одной вершины к другой. НАГ гарантирует невозможность начать движение в любой вершине и следовать череде рёбер, которая в итоге возвращается к этой вершине (то есть невозможны замкнутые циклы). Это позволяет нам иметь последовательность узлов (или вершин) в топологическом порядке.

Предпосылка разработки протоколов на основе направленных ациклических графов, таких как IOTA’s Tangle, состоит в том, чтобы полностью избавиться от глобальной линейной структуры блокчейна в пользу структур данных НАГ, что позволит лучше поддерживать состояние системы. Безопасность сети достигается благодаря тому, что эти протоколы полагаются на собственные новаторские подходы, в рамках которых от каждого узла не требуется линейно обрабатывать каждую транзакцию.

Другой подход, в основе которого лежит НАГ, известен как протокол SPECTRE. В нём направленные ациклические графы используются для блоков и параллельно ведётся майнинг блоков НАГ, что позволяет обрабатывать большее количество транзакций с меньшими временными затратами.

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

Ограниченная конфиденциальность

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

Но не всё так просто.

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

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

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

Как это случилось?

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

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

Загрузка ключевых бизнес-данных в блокчейн, где хакеры, конкуренты или другие неавторизованные стороны могут их увидеть, просто немыслима для большинства компаний. Речь идёт об информации такого рода:

• Электронная медицинская документация, представляющая собой в высшей степени приватную информацию. Недопустимо, чтобы она была доступна для обозрения в публичном блокчейне, поскольку нарушается конфиденциальность пациента.
• Данные удостоверений личности, такие как номера социального страхования, не могут открыто храниться в публичных смарт-контрактах.
• Управлению учётными данными — например, паролям и ключам — нет места в открытых и совершенно незащищённых смарт-контрактах.
• Финансовые документы, такие как таблицы капитализации или данные о зарплатах сотрудников, никогда не должны быть публично связаны с легко отслеживаемыми адресами.

Список можно продолжить.

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

Решения проблемы

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

Адреса на протоколе Диффи — Хеллмана — Меркля на эллиптических кривых (ECDHM). Чтобы понять адреса ECDHM, необходимо разобраться, как работает обмен ключами Диффи — Хеллмана. Идея, лежащая в его основе, состоит в том, что две стороны совместно используют секретный ключ. С помощью этого ключа происходит конфиденциальный обмен сообщениями в публичной сети.

Каким образом?

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

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

Примерами адресов на протоколе Диффи — Хеллмана — Меркля на эллиптических кривых служат Stealth Addresses Питера Тодда, платёжные коды многократного использования BIP47 Джастеса Ранвьера, общий адрес BIP75 Out of Band Джастина Ньютона и другие. Однако случаи фактического использования таких схем редки.

Миксеры. Идея миксера состоит в том, что группа людей может объединить свои платежи в один пул, отслеживая, кто кому сколько должен, в приватном реестре. Затем, когда средства пула израсходованы, источники оригинальных платежей скрываются. Любой, наблюдающий блокчейн, способен видеть объёмы платежей, а также получателей, но при этом (в теории) невозможно установить, кто авторизовал платёж. Примером миксера является CoinJoin.

К сожалению, миксеры зарекомендовали себя ненадёжным решением. Например, исследователи легко смогли идентифицировать транзакции CoinJoin и доказали, что, потратив лишь $32 000, атакующий способен деанонимизировать транзакции с вероятностью успеха в 90%. Более того, исследователи также доказали, что миксеры слабо защищают от атак Сивиллы и DDoS-атак.

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

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

Другим примером такого решения является CoinShuffle, децентрализованный миксинг-протокол, разработанный группой исследователей из Саарского Университета в Германии. CoinShuffle — попытка улучшить CoinJoin посредством отказа от доверенной третьей стороны, собирающей смешанные транзакции.

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

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

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

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

Пример 1: Игра «вызов-ответ» (challenge/response)

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

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

Давайте рассмотрим схему на примере.

У Боба есть исключительное право доступа к некому ресурсу (например, его машине). Элис тоже хочет получить доступ к машине, чтобы ездить на ней в магазин. Боб «бросает вызов» — например, это «52w72y2». Элис должна ответить одной строкой букв, соответствующей «вызову», «брошенному» Бобом. Единственный способ найти ответ — использовать алгоритм, известный только Бобу и Элис. Больее того, Боб всякий раз «бросает» новый «вызов». Таким образом, знание предыдущего правильного ответа не даёт Элис никаких преимуществ.

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

Пример 2: zkSNARK

Что это такое? Давайте расшифруем эту аббревиатуру.

В данном случае zk — это нулевое разглашение (метод доказательства без раскрытия секретной информации). Он требует знания информации, чтобы доказать её существование.

SNARK (Succinct Non-interactive Adaptive ARgument of Knowledge) — это сжатое неинтерактивное адаптивное доказательство знания.

«Сжатое» или «лаконичное» означает, что доказательство является кратким и его можно верифицировать в сжатые сроки.

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

«Адаптивное доказательство» указывает на знание принципа неких вычислений.

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

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

Пример 3: zkSNARK + Zcash

Zcash представляет собой обеспечивающую конфиденциальность криптовалюту на базе zk-SNARK.

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

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

Пример 4: zkSNARKs + эфириум

В рамках очередного апгрейда эфириума под названием Metropolis разработчики смогут эффективным образом использовать верификацию zk-SNARK в рамках блокчейна.

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

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

Пример 5: zkSTARK

У zkSNARK есть более молодой и эффективный «двоюродный брат» zkSTARK, где «T» означает «транспарентный», то есть «прозрачный». zkSTARK позволяет избавиться от одного из основных слабых мест zkSNARK: зависимости от предварительной «установки доверия».

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

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

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

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

Определение обфускатора («запутывателя») неразличимости O таково: если взять две эквивалентные программы A и B (то есть одни вводные данные для A и B генерируют те же самые выходные данные) и рассчитать O(A) = P и O(B) = Q, то не существует способа для кого-то, кто не имеет доступа к A или B, сказать, что P произошло от A или B.

Недавно исследователи Крейг Джентри, Амит Сахаи и другие смогли создать код для неразличимого запутывания. Однако алгоритму сопутствует масса дополнительных расчётов.

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

Например, можно представить себе эфириум-контракт, содержащий пароль пользователя от Coinbase. Можно написать программу так, что если определённые условия контракта соблюдаются, то контракт инициирует HTTPS-сеанс с Coinbase, используя некий промежуточный узел, и позволяет авторизоваться с помощью пользовательского пароля и осуществлять трейдинг.

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

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

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

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

Отсутствие формальной верификации контрактов

Формальная верификация смарт-контрактов остаётся СЕРЬЁЗНОЙ проблемой. Прежде всего давайте выясним, что вообще представляет собой формальная верификация контракта. Для этого необходимо понять, что такое формальное доказательство. В математике это математическое доказательство, которое было проверено компьютером с помощью фундаментальных математических аксиом и примитивных правил вывода.

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

Примером языка спецификаций является Isabelle — система автоматического доказательства теорем общего назначения, позволяющая передавать математические формулы формальным языком и обеспечивающая инструменты для доказательства этих формул посредством логического исчисления. Альтернатива — Coq, формальный язык, используемый для создания математических определений, выполняемых алгоритмов и теорем.

Так почему же важно формально верифицировать программы, зашифрованные в смарт-контрактах?

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

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

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

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

Решения для формальной верификации. Мне хотелось бы продемонстрировать в этом разделе больше публично доступных решений, но, к сожалению, они немногочисленны. Я обнаружила набор инструментов, созданный Ёити Хираи, инженером по формальной верификации Ethereum foundation. Он находится ещё на очень ранней стадии. Ёити сумел добиться первых результатов в верификации нескольких смарт-контрактов, включая маленький формальный договор. Это первый на моей памяти реальный контракт, проанализированный в среде доказательства теорем.

Сам Ёити говорит:

Полученные результаты далеки от совершенства. Я по-прежнему нахожу больше изъянов в настройках верификации, чем в верифицированных контрактах. Я уже говорю об этом публично, поскольку данный проект — хороший пример того, какой объём работы (и насколько кропотливой) необходим, чтобы верифицировать смарт-контракт с помощью логического умозаключения, полученного благодаря машине. На данный момент, если бы мне предложили внедрить смарт-контракт стоимостью более $100 000 и доверили составить график, я бы рассмотрел возможность взяться за это (другой вариант — сперва попробовать сначала внедрить контракт с меньшими значениями).

Есть и другие команды (например, Tezos), которые полностью отказываются от использования Solidity в качестве языка, а EVM — в качестве виртуальной машины. Вместо этого они создают собственные языки программирования смарт-контрактов и виртуальные машины, осуществляющие формальную верификацию.

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

Необходимость хранить большие объёмы данных

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

Однако хранение информации в публичном блокчейне означает, что данные:

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

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

Решения для хранения данных

В нескольких молодых проектах используются различные стратегии разделения данных на сегменты и хранения распределённым образом на участвующих в обработке данных узлах (то есть распределённого хранения).

Базовый принцип состоит в том, что каждый узел не хранит всё: наборы узлов расщепляют или «распределяют» данные в своей среде. Приведу несколько примеров таких проектов.

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

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

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

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

Ненадёжность механизмов достижения консенсуса

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

Механизм, в течение долгого времени использовавшийся в не требующем доверия блокчейне и способный достаточно эффективно противостоять атакам, называется протоколом консенсуса. Протоколы консенсуса не являются новой функцией, возникшей вместе с блокчейном и биткоином. Например, в 1992 году Дворк и Наор создали одну из первых систем Proof-of-Work (PoW, доказательства выполнения работы), в рамках которой можно создавать криптографическое доказательство вычислительных затрат, чтобы получить доступ к ресурсу без необходимости полагаться на доверие. Эту систему использовали для борьбы со спамом. Позже, в 1997-м, Адам Бэк создал схожую систему под названием Hashcash. Затем, в 2003 году, Вишнумурти и другие впервые использовали Proof-of-Work с целью обезопасить валюту. В том случае токен использовался не в качестве общей валюты, а с целью поддержать p2p-систему обмена файлами.

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

Консенсус Proof-of-Work

Proof-of-Work — это схема, состоящая из решения проблем, которые трудно решить, но легко верифицировать. Майнеры выполняют сложные ресурсоёмкие расчёты, используя свои вычислительные мощности, а система биткоина награждает их новыми биткоинами и комиссиями за транзакции. Чем больше у майнера вычислительных мощностей, тем большим «весом» он обладает в деле принятия решения по консенсусу.

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

Слабые места протокола Proof-of-Work

Специальному оборудованию отдаётся преимущество. К недостаткам консенсуса Proof-of-Work относится необходимость использовать специальное аппаратное оборудование. В 2013 году появились устройства, называемые интегральными схемами прикладной ориентации (микросхемы ASIC). Они были разработаны исключительно для майнинга биткоина, увеличив его эффективность в 10-50 раз.

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

Чтобы уменьшить масштабы этой проблемы, эфириум предпочёл сделать свой алгоритм PoW (Ethhash) последовательно требовательным к объёму памяти. Алгоритм спроектирован таким образом, что вычисления требуют больших объёмов памяти и большой пропускной способности одновременно. Такие требования не позволяют даже сверхбыстрому одновременно решать множество задач. Благодаря этому уменьшается риск централизации и создаётся более однородная конкурентная среда для узлов, осуществляющих верификацию.

Конечно, это не означает, что в будущем не появится ASIC для эфириума. Специализированное оборудование остаётся источником серьёзного риска для алгоритмов PoW.

Централизация майнинговых пулов. Концепция майнинг-пула состоит в том, что пользователи, вместо того чтобы майнить для себя с крошечными шансами получить награду за создание блока, майнят для пула. Пул бесперебойно посылает им их часть награды пропорционально их вкладу. Проблема майнинг-пулов заключается в том, что, поскольку они больше «весят» в сети, их прибыль стабильнее, чем у отдельных пользователей. Со временем несколько пулов начинают контролировать большую часть сети. В настоящее время, например, пяти ведущим майнинговым пулам принадлежит до 70% всего объёма хеша. Это, мягко говоря, пугает.

Энергозатраты. Майнеры задействуют компьютеры огромной мощности, осуществляя вычисления в рамках алгоритма Proof-of-Work, но, к несчастью, вся эта вычислительная работа не представляет для общества ценности.

Согласно индексу потребления энергии биткоином, опубликованному сайтом Digiconomist, сейчас расчётное годовое потребление электроэнергии составляет 29,05 ТВт·ч, что представляет 0,13% глобального расхода электроэнергии. Чтобы дать вам представление о том, насколько это много, скажу, что майнинг биткоина тратит больше электричества, чем 159 отдельно взятых стран мира.

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

Решения проблемы консенсуса

«Полезное» доказательство выполнения работы. Один из способов решения проблемы «пустых» трат энергии состоит в том, чтобы сделать функцию Proof-of-Work средством одновременного решения некоей полезной задачи. Например, представьте сценарий, в рамках которого майнеры тратят свои вычислительные мощности на решение сложных алгоритмов искусственного интеллекта вместо того, чтобы решать случайную SHA256-задачу, требуемую протоколом.

Переход на Proof-of-Stake (доказательство доли владения). Один из способов решить проблему централизации майнинга состоит в том, чтобы полностью отказаться от майнинга и перейти к другому механизму расчёта «веса» каждого узла в консенсусе. Эту цель преследует протокол Proof-of-Stake (PoS, доказательство доли владения).

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

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

Однако, как и в случае любой технологии, есть свои проблемы. Алгоритм PoS сталкивается с фундаментальными вызовами.

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

Атака дальнего действия (Long-range attack). Когда происходит форк блокчейна с PoW, майнер начинает новую цепочку за несколько блоков позади нынешней «головы» основной цепи, иначе потребуются нереальные вычислительное мощности. В случае PoS майнер может начать форк с любого места, поскольку единственное, что для этого требуется, — доля, то есть деньги. Это означает, что майнер может получить валидаторы предыдущих участников и создать миллионы блоков в новом блокчейне, мешая пользователям понять, какой из блокчейнов является «правильным».

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

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

Чтобы более эффективным образом заменить Proof-of-Work на Proof-of-Stake, мы нуждаемся в алгоритме, который решит проблему «ничего на кону» и устранит возможность атаки дальнего действия, не создавая новые риски тайных соглашений.

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

В отличие от Proof-of-Work, Proof-of-Stake имеет меньше обоснований и сложнее для понимания. Осознание различных преимуществ и недостатков различных проектных решений требует дальнейших исследований и экспериментов. Таким образом, присутствует настоятельная потребность в сотрудничестве ради создания более эффективных, быстрых и надёжных систем консенсуса, основанных на том, что уже сделано.

Отсутствие управления и стандартов

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

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

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

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

Должен существовать лучший путь.

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

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

Недостаточный инструментарий

Адекватный инструментарий существенен для активной и эффективной деятельности разработчиков. Скверный инструментарий — сюжет для фильмов ужасов.

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

Будучи разработчиком Solidity и блокчейна, я сформулировала, чего прежде всего не хватает в экосистеме инструментария. Это:

• IDE (интегрированная проектная среда), которая обладает инструментами статического анализа кода и всеми необходимыми плагинами для эффективного развития смарт-контрактов и анализа блокчейна.
• Система сборки кода и компилирующая программа — хорошо задокументированные и лёгкие в использовании.
• Эффективное средство развёртывания.
• Техническая документация для различных интерфейсов прикладных программ и комплексов программ, которая реально существует и не является совершенно устаревшей.
• Тестовая среда, не наводящая тоску. Существуют более-менее приемлемые инструменты для эфириума, такие как Truffle, но необходимы дополнительные опции и возможности экспериментировать в связи с тестированием. Недостаток тестирования неприемлем в любом случае, но особенно неприемлем, когда вовлечены такие гигантские суммы. Например, смарт-контракты продажи токена BAT не имеют набора тестов, однако с помощью этих контрактов $36 млн. было собрано за 24 секунды. Любой здравомыслящий человек понимает, что если контракт способен приводить в движение такие денежные потоки, то рискует стать объектом атак.
• Инструменты отладки программы. Чёрт. Поиск багов в коде Solidity — это всё равно что поиск золота в тёмном тоннеле с повязкой на глазах. В прошлом я занималась разработкой веб-приложений, и возможность пошагово пройти код строка за строкой с помощью программы отладки была поистине палочкой-выручалочкой. Не иметь подобного инструмента или даже отдалённо его напоминающего в высшей степени печально и непродуктивно, когда ведётся разработка в Solidity. Мы отчаянно нуждаемся в инструментах, облегчающих задачу по поиску проблем для последующего устранения.
• Инструменты логирования (см. описанное выше).
• Аудит безопасности. Это очень важно. Я слышала лишь об одной достойной внимания системе аудита безопасности для эфириума — Open Zepplin. Хотя эта система вносит значительный вклад в проверку безопасности, индустрия, зарабатывающая миллиарды долларов с помощью смарт-контрактов, нуждается в чём-то большем, чем одинокий стартап. Компаниям и инженерам нужно создавать более продвинутые инструменты и сервисы. Должно увеличиться число экспертов по безопасности, помогающих всесторонним образом проводить аудит смарт-контрактов. Пока же внимание безопасности смарт-контрактов уделяется лишь постфактум, после того, как происходят атаки, подобные взломам Parity и DAO. Затем, конечно, вину возлагают на разработчиков, написавших смарт-контракты, или, что ещё хуже, на основную команду эфириума. Я думаю, что это несправедливо. Разработчики не должны отвечать за аудит безопасности их собственного кода. Это всё равно, что просить баскетболиста Стефена Карри самостоятельно вести счёт. Это так не работает. Нам жизненно необходимы помощь и экспертный потенциал специалистов по защите информации и исследователей. Нам нужны инвесторы, действующие, а не просто говорящие. Нам необходимы усилия, направленные на финансирование проектов по развитию защиты смарт-контрактов и блокчейнов.
• Блоки-проводники и инструменты аналитики. У эфириума есть блок-проводник, именуемый Etherscan. В случае биткоина есть Blockchain.info, Blockexplorer и Blockcypher. Все они представляют собой замечательные плоды совместной работы. Я много и часто пользуюсь Etherscan. Но для осуществления любой серьёзной аналитики блокчейна этого инструмента явно недостаточно. Существуют весьма интересные данные о публичном блокчейне, которые можно и нужно анализировать.

Угроза со стороны квантовых вычислений

Одной из потенциальных угроз криптовалютам и криптографии являются квантовые вычисления.

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

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

Устойчивость к квантовым атакам

Хотя я ни в коей мере не являюсь специалистом в этой области, моё очень ограниченное понимание таково, что разработка постквантовой криптографии сейчас идёт в шести направлениях: криптография на основе решёток, многовариантная криптография, криптография на основе хеша, криптография на основе кода, криптография на основе изогении суперсингулярных эллиптических кривых и системы на основе симметричных ключей — AES и SNOW 3G.

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

Прочие вызовы, приходящие на ум

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

Заключение

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

В наступившем году я намерена продолжать:

• привлекать внимание специалистов и энтузиастов к этим вопросам;
• уделять максимум времени поиску решений;
• помогать другим исследователям и разработчикам делать то же самое.

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

Хотите больше новостей? Facebook. Быстрее всех? Telegram и Twitter. Подписывайтесь!