16 марта 2018 Криптовалюта.Tech
В этой статье специалист по программному обеспечению Притхи Касиредди (Preethi Kasireddy) делится своими взглядами на проблемы технологии блокчейн и способы их решения.
Безусловно, технология блокчейн обладает огромным потенциалом.
Разработчики блокчейнов исследуют впечатляющие возможности применения этой технологии, такие как децентрализованные биржи, рынки предсказаний и платформы для управления активами (и это лишь малая часть того, что уже придумано).
Впечатляющие настолько, что в 2017 году общая сумма средств, собранных на ICO, составила более миллиарда долларов, а стоимость многих криптовалют выросла в разы. Это уже настоящая мания.
Поймите меня правильно: я рада тому, что все это подстегивает интерес широкой публики к блокчейн-технологиям. У людей наконец перестали стекленеть глаза, когда они слышат от меня слова «биткойн» или «эфириум».
Но ложка дегтя тоже имеется, хоть об этом особо и не говорят: у блокчейнов есть недостатки, которые на сегодняшний день существенно ограничивают возможности их широкого применения.
Я уверена, что все эти недостатки преодолимы, но разработчикам и инвесторам важно видеть реальную картину. А она такова, что может пройти много лет, прежде чем пока еще ненадежные системы станут готовы к использованию в требуемом масштабе.
В число этих недостатков входят:
Ограничения масштабируемости
Ограничения конфиденциальности
Отсутствие формальной верификации контрактов
Требования к размеру хранилища данных
Ненадежные механизмы достижения консенсуса
Отсутствие регулирования и единых стандартов
Недостаток средств разработки
Угроза квантовых компьютеров
…и так далее.
В этой серии статей я рассмотрю перечисленные выше недостатки и приведу примеры решений, которые могли бы помочь их преодолеть.
Как разработчик, я считаю важным сместить фокус внимания с этих модных ICO на стоящие перед нами реальные технологические проблемы.
Замечу, что невозможно рассказать здесь обо всех недостатках технологии и способах их обхода. В этой серии статей я рассмотрю те из них, в которых достаточно хорошо разбираюсь.
1. Ограничения масштабируемости
Сейчас все открытые консенсус-протоколы для блокчейнов имеют одно и то же узкое место: каждый полный сетевой узел (полная нода) должен обрабатывать каждую транзакцию.
Почему? Вспомним, что одна из основных характеристик блокчейнов — децентрализация, то есть в них нет единого Центра, ответственного за поддержку работоспособности и безопасность системы. Вместо этого, каждый узел вносит вклад в общую безопасность сети тем, что подтверждает каждую транзакцию и хранит полную копию состояния сети.
Такой метод децентрализации обеспечивает основные преимущества блокчейна, которые важны для всех нас — гарантии безопасности, политическую нейтральность, устойчивость к цензуре, — но за это приходится платить масштабируемостью, так как количество транзакций, которое способен обработать блокчейн, равно пропускной способности одного сетевого узла.
Из этого следует два практических вывода:
Низкая пропускная способность. Блокчейн может обработать только ограниченное число транзакций.
Низкая скорость выполнения транзакций. Обработка блока транзакций занимает существенное время. Например, в сети Биткойн интервал между блоками составляет 10 минут, в сети Ethereum — примерно 14 секунд, а в периоды пиковой нагрузки на это уходит еще больше времени. Для сравнения, в таких сервисах, как Square и Visa, транзакции подтверждаются практически мгновенно.
Поэтому разработчики публичных блокчейнов вынуждены искать компромисс между низкой пропускной способностью сетей и высокой степенью централизации.
Другими словами, по мере роста размера блокчейна растут и требования к размеру хранилища, пропускной способности и вычислительной мощности каждого узла сети. Может наступить момент, когда на обработку блоков потребуется столько ресурсов, что останется слишком мало узлов, способных справляться с этой нагрузкой, и тогда сеть рискует стать централизованной.
То есть мы сделаем полный круг и вернемся к централизованным системам, которые требуют доверия к нескольким крупным участникам, хотя на самом деле нам нужна система, способная обрабатывать тысячи транзакций в секунду и сохранять ту же степень децентрализации, какая была обещана изначально.
Решения проблемы масштабируемости
В идеале нам нужен блокчейн, не менее безопасный, чем Биткойн или Ethereum, и при этом не требующий, чтобы каждый узел обрабатывал как минимум определенную долю всех транзакций сети. Другими словами, нужен механизм, который ограничивал бы количество узлов, необходимых для подтверждения транзакций, но без потери уверенности участников сети в правильности и подлинности каждой транзакции. Звучит просто, но реализовать это очень сложно.
Масштабируемость — это серьезное препятствие на пути к будущему успеху платформы. Есть несколько вариантов решения проблемы, которыми уже занимаются различные команды разработчиков.
Платежные каналы офчейн
Суть этого решения заключается в создании дополнительного слоя с сетью каналов для микроплатежей, которая позволит проводить большинство транзакций вне блокчейна, то есть вынести за пределы основного блокчейна действия, которые обычно записываются в него напрямую. В этой модели блокчейн используется как расчетный слой, в котором обрабатывается только последняя транзакция из серии взаимодействий между аккаунтами и фиксируется конечное состояние счетов. Таким образом, появляется возможность разгрузить блокчейн.
Это решает обозначенную выше проблему с пропускной способностью, так как в этой модели блокчейн масштабируется до значительно больших объемов транзакций. Более того, поскольку транзакция считается совершенной, как только ее обработал платежный канал, а не после подтверждения включающего ее блока, каналы микроплатежей решают проблему скорости обработки транзакций, уменьшая период ожидания.
В качестве примеров сетей микроплатежных каналов можно привести Raiden Network и Lightning Network.
Шардирование (sharding)
Идея шардирования состоит в том, что полная информация о состоянии блокчейна делится на сегменты (shards), и обработка разных частей этого состояния происходит одновременно в разных узлах сети. При этом каждый сегмент обрабатывает небольшую часть данных. В целом шардирование блокчейна похоже на шардирование базы данных, но в блокчейне, с его децентрализованным набором узлов, значительно сложнее обеспечить безопасность и проверку подлинности данных.
Вычисления офчейн
Это похоже на обработку состояния в нескольких каналах, только в еще большем масштабе. Идея этого метода состоит в том, что вне блокчейна происходит не только передача токенов, но и те вычисления, которые требуют слишком больших затрат ресурсов при их выполнении в блокчейне. Способ проведения этих вычислений гарантирует их безопасность и подлинность. Использование отдельного протокола для проведения вычислений и проверок вне блокчейна способствует увеличению пропускной способности сети. Пример применения этой модели для Ethereum — TrueBit.
Направленный ациклический граф
Направленный ациклический граф (DAG, от directed acyclic graph) состоит из вершин (точек) и ребер (соединительных линий между точками). В направленном ациклическом графе не существует пути обхода, возвращающегося к начальной точке (невозможны замкнутые циклы). Это позволяет установить топологический порядок для вершин и ребер.
Основанные на DAG протоколы (например, Tangle в IOTA) позволяют полностью отойти от глобальных линейных блокчейнов, потому что в них состояние системы задано структурой, имеющей вид такого графа. Для обеспечения сетевой безопасности эти протоколы используют новаторские технологии, которые не требуют линейным образом обрабатывать каждую транзакцию в каждом узле.
Протокол SPECTRE — еще решение, основанное на DAG — соединяет в DAG блоки и поддерживает параллельный майнинг блоков для повышения пропускной способности и производительности системы.
Впрочем, на текущий момент крупномасштабных решений, реализующих такие протоколы, не существует. Это связано с наличием серьезных ограничений и уязвимостей, и надежные масштабируемые решения появятся только тогда, когда будут найдены способы исправить эти недостатки.
2. Ограничения конфиденциальности
Ваши транзакции в блокчейне не имеют прямой привязки лично к вам, и потому они могут казаться конфиденциальными, ведь кто угодно может создать анонимный кошелек и совершать транзакции через него.
Но не все так просто.
С одной стороны, использование псевдонимов составляет сильную сторону этой технологии. Хоть история транзакций и хранится в открытом реестре, эти данные привязаны к учетным записям, состоящим только из букв и цифр. Кроме того, к учетным записям не привязаны никакие реальные данные, и отыскать человека, который совершил транзакцию, кажется невозможным.
Но на самом деле это только создает видимость безопасности. Человек действительно может сохранять анонимность, пока его псевдоним в сети не связан с его реальным именем, но достаточно одной утечки информации, чтобы это перестало быть тайной. Один такой случай уже произошел: правоохранительные органы подтвердили, что в ходе расследования узнали имена людей, переводивших биткоины, и тем самым опровергли предположение о полной конфиденциальности подобных транзакций.
Как они смогли это сделать?
Информация из cookie-файла или из программы, которая анализирует поведение пользователя на веб-сайте, может попасть в сеть и стать доступной для кого угодно — и для правительств, и для правоохранительных органов, и для злоумышленников.
Более того, в таких блокчейн-платформах, как Ethereum, пользователи создают смарт-контракты, которые могут оперировать самыми разными данными. В блокчейне Ethereum все данные из смарт-контрактов, включая отправителя, получателя, переданные в транзакции данные, выполненный код и состояние, записанное в контракте, находятся в открытом доступе.
Для большинства компаний неприемлемо записывать важные данные в блокчейн, где их может увидеть кто угодно, включая и хакеров, и конкурентов. Примерами таких данных могут служить:
Электронные медицинские карты. Публикация этих данных в блокчейне недопустима, потому что нарушает право пациента на конфиденциальность.
Данные из удостоверений личности – например, номер паспорта.
Данные для авторизации, такие как пароли и ключи.
Финансовые документы – например, таблицы капитализации или данные о зарплате сотрудников.
И многое другое.
Конфиденциальность остается серьезным препятствием для физических лиц и организаций, а также в отраслях, где важна сохранность личных данных. Многие из тех, кто возлагает большие надежды на криптовалюты, заинтересованы в создании системы, которая предоставляет новые финансовые возможности и при этом не требует доверия к другим участникам и устойчива к цензуре. Как ни парадоксально, сейчас для этих целей используется открытый и легко отслеживаемый реестр!
Решения проблемы конфиденциальности
Вот примеры решений, над которыми сейчас работают разные команды разработчиков.
Адреса на эллиптической кривой Диффи-Хеллмана-Меркле (ECDHM, от Elliptic Curve Diffie-Hellman-Merkle)
Концепция ECDHM-адресов основана на протоколе Диффи-Хеллмана. Он позволяет двум сторонам получить общий секретный ключ, с помощью которого они в дальнейшем смогут обмениваться закрытыми сообщениями в открытой сети.
Каким образом?
Отправитель и получатель могут публично обменяться ECDHM-адресами, а затем использовать общий секретный ключ для генерации анонимных адресов в сети Биткоин. Эти Биткоин-адреса могут быть открыты только тому, кому известен секретный ключ, а в открытом доступе остаются только ECDHM-адреса многоразового использования. Поэтому участники могут не переживать за конфиденциальность своих транзакций.
Концептуальная схема идеи обмена ключами, которая использует разные цвета вместо очень больших чисел (Источник)
Примеры схем, основанных на ECDHM-адресах, включают Stealth-адреса Питера Тодда (Peter Todd), платежные коды многоразового использования из BIP47 Юстуса Ранвье (Justus Ranvier) и обмен адресами по внешнему каналу из BIP75 Джастина Ньютона (Justin Newton). Однако рабочие реализации таких схем встречаются крайне редко.
Миксеры
Идея миксера заключается в том, что несколько пользователей объединяют свои платежи в общий пул и хранят записи о том, кто кому сколько должен, в закрытом реестре. После того как средства из общего пула потрачены, нельзя определить источники отдельных платежей. Наблюдатель может видеть, кому и сколько было передано средств, но вычислить человека, который совершил тот или иной платеж, в теории, нельзя. Пример такого миксера — CoinJoin.
К сожалению, на практике миксеры оказались ненадежным решением. Например, эксперты смогли легко установить источник транзакций, совершенных с помощью CoinJoin, и доказали, что злонамеренному пользователю достаточно потратить 32 000 долларов, чтобы с вероятностью 90% лишить участников транзакции анонимности. Более того, оказалось, что миксеры слабо устойчивы к атакам Сивиллы и DoS-атакам.
Еще более разочаровывает то, что якобы защищенный реестр миксера требует администрирования третьей стороной, которой должны доверять участники пула миксера.
Поскольку CoinJoin не является сервисом, предоставляемым по умолчанию, его используют не так много людей, то есть количество участников в пуле миксера невелико. Поэтому несложно определить, что конкретную транзакцию совершил один из нескольких возможных участников.
Другой пример такого решения – CoinShuffle, децентрализованный миксер-протокол, разработанный группой исследователей из Саарского университета в Германии. Они попытались улучшить CoinJoin, исключив необходимость наличия доверенной третьей стороны для компоновки объединенных транзакций.
Monero
Другой способ решения проблемы конфиденциальности — это создание криптовалюты, анонимной по умолчанию, такой как Monero. В отличие от многих альткоинов, Monero – не форк Биткоина. В основе Monero лежит альтернативный протокол CryptoNote.
Главное отличие Monero от других криптовалют — использование схемы кольцевой подписи.
Это вариант групповой подписи, где каждый участник, имеющий право поставить подпись, имеет открытый и закрытый ключи. В отличие от обычной криптографической подписи, которая показывает, что транзакция подтверждена одним участником, групповая подпись означает, что транзакция подтверждена одним из участников группы, но неизвестно, каким именно.
Доказательство с нулевым разглашением
Этот криптографический протокол позволяет проверяющей сторонеубедиться, что доказывающая сторона обладает неким секретным знанием, без необходимости раскрытия информации о нем проверяющей стороне. Другими словами, программа может предусматривать ввод секретных данных, но доказывающая сторона не предоставляет эти данные проверяющей. Доказательство с нулевым разглашением предоставляет основные элементы для реализации механизмов обеспечения конфиденциальности. Рассмотрим несколько примеров.
Пример 1: игры «вызов — ответ»
В сфере компьютерной безопасности аутентификация типа «вызов — ответ» описывает класс протоколов, в которых одна сторона должна задать вопрос («вызов»), а другая — предоставить верный ответ. Такую «игру» можно использовать для подтверждения транзакций в блокчейне. Если транзакция оказалась недействительной, другой узел может «привлечь внимание» к этому факту. Для подтверждения того, что транзакция недействительна, требуется доказательство, которое можно проверить. Если такого доказательства нет, источник транзакции получает «вызов», и для подтверждения подлинности транзакции он должен отправить верный ответ.
Рассмотрим пример. Боб имеет эксклюзивный доступ к некоему ресурсу (например, к своему автомобилю). Алиса хочет получить доступ к этому автомобилю, потому что ей нужно ехать в магазин. Боб отправляет ей вызов, например, «52w72y». Алиса должна отправить Бобу символьную строку, которая будет верным ответом на его вызов. Единственный способ сформировать такую строку — использовать алгоритм, который известен и Бобу, и Алисе. Кроме того, Боб каждый раз присылает новый вызов. Таким образом, если Алиса знает правильные ответы на прошлые вызовы, это не дает ей никакого преимущества.
Игры «вызов — ответ» уже используются в некоторых блокчейнах, например, в Ethereum. Однако пока нам не хватает библиотек и инструментов, которые могли бы серьезно упростить использование таких схем аутентификации.
Пример 2: zk-SNARK
Что такое zk-SNARK? Давайте разбираться.
zk = zero-knowledge (дословно — нулевое знание, здесь — нулевое разглашение). Это значит, что для доказательства существования информации необязательно делиться этой информацией.
SNARK: Succinct Non-interactive Adaptive ARgument of Knowledge (сжатое неинтерактивное адаптивное доказательство знания).
«Сжатое» означает, что доказательство может быть предоставлено в короткий срок.
«Неинтерактивное» означает, что проверяющей стороне не нужно напрямую взаимодействовать с доказывающей стороной. Вместо этого, доказывающая сторона может заранее опубликовать доказательство, которое потребуется проверяющей стороне.
«Адаптивное доказательство знания» означает доказательство знания о некоем вычислении.
zk-SNARK — это перспективная и впечатляющая технология обеспечения конфиденциальности, однако у нее есть узкие места:
SNARK требует больших вычислительных мощностей.
SNARK позволяет пользователю доказать, что тот обладает доступом к секрету, однако на этого пользователя ложится ответственность за сохранение секрета и предоставление этих данных по необходимости.
SNARK требует предварительной фазы настройки, во время которой фиксируется подлинность вычисления (circuit). В этой фазе участники закрытой группы людей, доверяющих друг другу, должны выполнить определенные действия. То есть это не только требует от участников доверия к людям, проводящим необходимую настройку, но также делает SNARK не лучшим выбором для выполнения произвольных вычислений по причине необходимости предварительной настройки.
Пример 3: zk-SNARK + Zcash
Zcash — анонимная криптовалюта, основанная на zk-SNARK. В Zcash есть так называемые защищенные транзакции, свойства которых распространяются на каждый из передаваемых коинов. Защищенные транзакции используют защищенные адреса, которые требуют от отправителя или получателя сгенерировать доказательство с нулевым разглашением, позволяющее другим участникам сети верифицировать зашифрованные данные транзакции без доступа к ним.
Схема транзакций Zcash
Несомненно, такой проект, как Zcash, заслуживает особого внимания.
Пример 4: zk-SNARK + Ethereum
В Metropolis, следующем обновлении протокола Ethereum, разработчики получат возможность эффективно и ончейн верифицировать доказательства zk-SNARK.
Какие возможности откроет использование технологии zk-SNARK в Ethereum? Некоторые параметры контрактов можно будет сделать конфиденциальными. Вместо того чтобы хранить информацию о секрете в блокчейне, ее можно хранить на стороне пользователей, которые будут подтверждать выполнение условий контракта с помощью SNARK. Каждый из этих пользователей должен заранее пройти фазу настройки. Но как только вычисление зафиксировано, его можно использовать для проверки сколь угодно большого числа транзакций.
Однако SNARK не сможет обеспечить для Ethereum конфиденциальность без участия пользователя. Ведь в этом случае SNARK полагается на пользователя, который хранит секрет вне блокчейна, и поэтому проверка секрета без участия этого пользователя невозможна.
Пример 5: zk-STARK
У zk-SNARK есть «преемник» — zk-STARK. Здесь буква T означает «Transparent» (прозрачный). zk-STARK исправляет одну из основных уязвимостей zk-SNARK — необходимость предварительной настройки. Кроме того, эта технология проще, потому что она основана только на хешировании и теории передачи информации, и еще она лучше защищена от взлома с помощью квантовых компьютеров, так как не использует эллиптические кривые и экспоненциальные допущения.
В целом, несмотря на большой прогресс в улучшении перечисленных выше схем обеспечения конфиденциальности с помощью доказательств с нулевым разглашением, они еще нуждаются в серьезных доработках. Библиотеки, реализующие доказательство с нулевым разглашением, требуют всестороннего анализа, проверок в полевых условиях и дополнительного развития. Также нужны проверки технологий zk-SNARK и zk-STARK в различных публичных блокчейнах. И мы еще посмотрим, как заложенные в Zcash сценарии использования покажут себя в большем масштабе и в реальных условиях. Для всего этого нужно время.
Обфускация кода
Еще один механизм обеспечения конфиденциальности – обфускация (запутывание) кода. Предположим, у нас есть программа P. Применив к ней обфускатор, мы получим программу O(P) = Q. При одинаковых входных данных обе программы возвращают одинаковые результаты, но с помощью анализа программы Q невозможно получить информацию о внутреннем устройстве P. Таким образом можно скрыть конфиденциальные данные (пароли, номера документов и т. п.) внутри Q, и при этом они будут оставаться доступными для использования.
Эксперты считают, что полная обфускация, которая превратила бы программу в «черный ящик», невозможна. Зато возможен более слабый вариант этого преобразования, который называется «обфускация неразличимости» (indistinguishability obfuscation). Возьмем две программы A и B, которые при одинаковых входных данных возвращают одинаковые результаты. После применения к ним обфускатора неразличимости получаются программы O(A) = P и O(B) = Q, и если у вас нет доступа к программам A и B, то вы не сможете определить, какая из них была исходной для программы P.
Эксперты Крейг Джентри (Craig Gentry), Амит Сахай (Amit Sahai) и др.описали реализацию обфускации неразличимого кода. Разработанный ими алгоритм очень требователен к вычислительным ресурсам, но если получится его улучшить, это решит многие проблемы. Самая интересная возможность в мире криптовалют — это идея публикации в блокчейне контрактов, содержащих закрытые данные.
Например, представим себе контракт на платформе Ethereum, который содержит пользовательский пароль для Coinbase. Можно написать программу, которая при выполнении определенных условий контракта открывает HTTPS-соединение с Coinbase через какой-нибудь промежуточный узел, авторизуется с этим паролем и совершает сделку. Если данные, которые хранятся в контракте, будут скрыты с помощью обфускатора, ни промежуточный узел, ни любой другой пользователь блокчейна не смогут изменить передаваемый запрос или узнать пароль.
Оракулы
Применительно к блокчейнам, оракул — это сторона, которая выполняет обмен данными между смарт-контрактами и внешними источниками данных. Фактически это носитель информации, передаваемой между смарт-контрактами, которые находятся в блокчейне, и внешними источниками данных, которые находятся вне блокчейна. Один из способов сохранения конфиденциальности данных — это использование оракулов для получения закрытых данных из внешних источников.
Безопасная среда исполнения
Безопасная среда исполнения (Trusted Execution Environment, TEE) представляет собой защищенную область в главном процессоре. Код и данные, загруженные в эту область, защищены с точки зрения целостности и конфиденциальности. Безопасная среда существует параллельно с операционной системой, в которой работает пользователь, но по сравнению с последней, она должна иметь более высокую степень конфиденциальности и защищенности.
Уже сейчас проводятся исследования возможностей использования безопасной среды исполнения для обеспечении конфиденциальности в блокчейне. Приятно, что многие эксперты работают в этом направлении, но хотелось бы, чтобы их стало еще больше.
3. Отсутствие формальной верификации контрактов
Формальная верификация смарт-контрактов остается СЕРЬЕЗНОЙ проблемой. Прежде всего давайте выясним, что вообще представляет собой формальная верификация контракта. Для этого необходимо понять, что такое формальное доказательство. В математике это математическое доказательство, которое было проверено компьютером с помощью фундаментальных математических аксиом и примитивных правил вывода.
Если брать более широко, то формальная верификация по отношению к программному продукту — это методология, позволяющая определить, ведет ли себя программа согласно спецификации. В целом это делается посредством конкретного языка спецификации, используемого для описания того, как должны соотноситься вводы и выводы функций. Иначе говоря, сначала мы должны установить касающиеся программы неизменяемые величины, а затем обязаны доказать утверждение.
Примером языка спецификаций является Isabelle — система автоматического доказательства теорем общего назначения, позволяющая передавать математические формулы формальным языком и обеспечивающая инструменты для доказательства этих формул посредством логического исчисления. Альтернатива — Coq, формальный язык, используемый для создания математических определений, выполняемых алгоритмов и теорем.
Так почему же важно формально верифицировать программы, зашифрованные в смарт-контрактах?
Во-первых, смарт-контракты неизменяемы: невозможно обновить или исправить их после того, как они развернуты в основной сети эфириума. Это означает, что нам необходимо довести их до ума в доверенной среде, прежде чем мы сумеем использовать эти контракты в реально работающих приложениях.
Более того, смарт-контракты публично доступны, и все, что хранится в них, открыто для всеобщего обозрения. Эта характеристика обеспечивает прозрачность, но она также делает смарт-контракты крайне привлекательной мишенью для хакеров.
Реальность такова, что создать заслуживающие доверия смарт-контракты, свободные от серьезных программных ошибок, нелегко, независимо от того, какие меры предосторожности принимаются. В случае эфириума, например, верифицировать код децентрализованной виртуальной машины эфириума (EVM) очень непросто, что объясняется устройством EVM. Таким образом, создание решений формальной верификации для эфириума — это еще более сложная задача.
Формальная верификация — это эффективное средство решения такой проблемы, как риск заражения вирусами и хакерских атак. Она гарантирует безошибочность в большей мере, чем традиционные подходы (например, тестирование, независимая экспертиза и т. д.), а нам жизненно необходимы лучшие решения.
Решения проблемы формальной верификации
Мне хотелось бы продемонстрировать в этом разделе больше публично доступных решений, но, к сожалению, они немногочисленны. Я обнаружила набор инструментов, созданный Ёити Хираи, инженером по формальной верификации Ethereum foundation. Он находится еще на очень ранней стадии. Ёити сумел добиться первых результатов в верификации нескольких смарт-контрактов, включая маленький формальный договор. Это первый на моей памяти реальный контракт, проанализированный в среде доказательства теорем.
Сам Ёити говорит:
«Полученные результаты далеки от совершенства. Я по-прежнему нахожу больше изъянов в настройках верификации, чем в верифицированных контрактах. Я уже говорю об этом публично, поскольку данный проект — хороший пример того, какой объем работы (и насколько кропотливой) необходим, чтобы верифицировать смарт-контракт с помощью логического умозаключения, полученного благодаря машине. На данный момент, если бы мне предложили внедрить смарт-контракт стоимостью более $100 000 и доверили составить график, я бы рассмотрел возможность взяться за это (другой вариант — сперва попробовать внедрить контракт с меньшими значениями)».
Есть и другие команды (например, Tezos), которые полностью отказываются от использования Solidity в качестве языка, а EVM — в качестве виртуальной машины. Вместо этого они создают собственные языки программирования смарт-контрактов и виртуальные машины, осуществляющие формальную верификацию.
Какой бы подход ни был правильным: изменение EVM с целью облегчить процесс формальной верификации или создание совершенно нового языка, который изначально легче верифицировать, — мы должны приложить максимум усилий. Нам нужно больше исследователей и разработчиков, работающих над формальной верификацией. Нам необходимы библиотеки формальной верификации и стандарты на всех возможных языках программирования.
4. Требования к размеру хранилища данных
В большинстве своем приложения, построенные на публичном блокчейне, требуют того или иного решения для хранения данных (идентификационной информации пользователей, финансовой информации и т. д.).
Однако хранение информации в публичном блокчейне означает, что данные:
хранятся каждым полным узлом в сети;
хранятся неопределенно долго, поскольку база данных блокчейна предназначена лишь для добавления и неизменяема.
Таким образом, хранение данных предполагает высокую стоимость децентрализованной сети, в которой каждый полный узел бесконечно хранит все больше и больше информации. В результате хранение становится серьезным препятствием для любого «настоящего» приложения, которое выстраивается на блокчейне.
Решения проблемы хранения данных
В нескольких молодых проектах используются различные стратегии разделения данных на сегменты и хранения их распределенным образом на участвующих в обработке данных узлах (то есть распределенного хранения). Базовый принцип состоит в том, что каждый узел не хранит все: наборы узлов расщепляют или «распределяют» данные в своей среде. Приведу несколько примеров таких проектов.
Swarm: представляет собой p2p-протокол совместного использования файлов для эфириума, позволяющий хранить код приложения и данные вне основного блокчейна в комплексе узлов, которые связаны с блокчейном эфириума. Позднее этими данными можно обмениваться внутри блокчейна.
Storj: решение, в котором файлы и данные вначале сегментируются, зашифровываются, а затем распределяются по многочисленным узлам таким образом, что каждый узел хранит лишь малую часть данных, то есть происходит распределенное хранение. Storj Coin (SCJX) используется для оплаты хранения и действует в качестве вознаграждения для узлов, хранящих часть пользовательских файлов или данных.
IPFS: альтернативный p2p-протокол гиперсреды, обеспечивающий высокую пропускную способность, с моделью хранения данных в виде блоков с гиперссылками к содержимому. По существу, этот протокол позволяет хранить файлы постоянно и децентрализованно, сохраняя предыдущие версии и устраняя дубли.
Decent: децентрализованная платформа совместного использования контента, позволяющая пользователям загружать, монетизировать и совместно использовать свои работы (видео, музыку, электронные книги и т. д.), не полагаясь на централизованную третью сторону. Пользователям облегчается доступ к контенту, поскольку промежуточные стороны отсутствуют, а узлы, хранящие контент, награждаются комиссиями.
5. Ненадежные механизмы достижения консенсуса
Пользователям, осуществляющим транзакции в блокчейне, не нужно доверять третьей стороне. Благодаря этому достигается анонимность, возможность сопротивления ограничениям и осуществления инноваций без чьего-либо одобрения.
Механизм, в течение долгого времени использовавшийся в не требующем доверия блокчейне и способный достаточно эффективно противостоять атакам, называется протоколом консенсуса. Протоколы консенсуса не являются новой функцией, возникшей вместе с блокчейном и биткоином. Например, в 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 имеет меньше обоснований и сложнее для понимания. Осознание различных преимуществ и недостатков различных проектных решений требует дальнейших исследований и экспериментов. Таким образом, присутствует настоятельная потребность в сотрудничестве ради создания более эффективных, быстрых и надежных систем консенсуса, основанных на том, что уже сделано.
6. Отсутствие регулирования и единых стандартов
Нет нужды говорить, что у публичного децентрализованного блокчейна нет центрального ответственного лица или организации, принимающей решения. С одной стороны, благодаря этому мы обретаем то, к чему стремимся: совершенно не требующую доверия, открытую и свободную от ограничений систему. С другой стороны, не существует безопасного пути обновления протокола, и никто не ответственен за установление и поддержание стандартов.
Хотя мы однозначно хотим, насколько это возможно, сохранять децентрализованный характер развития технологии блокчейн, нам по-прежнему нужно координировать деятельность разработчиков и других представителей экосистемы, чтобы приходить к согласию по вопросам новых стандартов, функций и обновлений. Неясно, как можно этого достичь в отсутствие хотя бы толики централизации (например, без 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. Некоторые исследователи и разработчики отчаянно пытаются решить вышеуказанные проблемы, но им недостает ресурсов. К несчастью, соображения выгоды подталкивают многих, включая разработчиков и лидеров сектора, игнорировать существующие проблемы.
В наступившем году я намерена продолжать:
привлекать внимание специалистов и энтузиастов к этим вопросам;
уделять максимум времени поиску решений;
помогать другим исследователям и разработчикам делать то же самое.
Независимо от того, имеем ли мы сейчас дело с пузырем, я убеждена, что блокчейн задержится надолго. Нам, разработчикам, просто нужно приложить максимум усилий к тому, чтобы снести барьеры, стоящие на пути широкомасштабного внедрения блокчейна. И нам нужны инвесторы, финансирующие эти усилия.
https://cryptocurrency.tech/ (C)
Не является индивидуальной инвестиционной рекомендацией
При копировании ссылка обязательна Нашли ошибку: выделить и нажать Ctrl+Enter
Безусловно, технология блокчейн обладает огромным потенциалом.
Разработчики блокчейнов исследуют впечатляющие возможности применения этой технологии, такие как децентрализованные биржи, рынки предсказаний и платформы для управления активами (и это лишь малая часть того, что уже придумано).
Впечатляющие настолько, что в 2017 году общая сумма средств, собранных на ICO, составила более миллиарда долларов, а стоимость многих криптовалют выросла в разы. Это уже настоящая мания.
Поймите меня правильно: я рада тому, что все это подстегивает интерес широкой публики к блокчейн-технологиям. У людей наконец перестали стекленеть глаза, когда они слышат от меня слова «биткойн» или «эфириум».
Но ложка дегтя тоже имеется, хоть об этом особо и не говорят: у блокчейнов есть недостатки, которые на сегодняшний день существенно ограничивают возможности их широкого применения.
Я уверена, что все эти недостатки преодолимы, но разработчикам и инвесторам важно видеть реальную картину. А она такова, что может пройти много лет, прежде чем пока еще ненадежные системы станут готовы к использованию в требуемом масштабе.
В число этих недостатков входят:
Ограничения масштабируемости
Ограничения конфиденциальности
Отсутствие формальной верификации контрактов
Требования к размеру хранилища данных
Ненадежные механизмы достижения консенсуса
Отсутствие регулирования и единых стандартов
Недостаток средств разработки
Угроза квантовых компьютеров
…и так далее.
В этой серии статей я рассмотрю перечисленные выше недостатки и приведу примеры решений, которые могли бы помочь их преодолеть.
Как разработчик, я считаю важным сместить фокус внимания с этих модных ICO на стоящие перед нами реальные технологические проблемы.
Замечу, что невозможно рассказать здесь обо всех недостатках технологии и способах их обхода. В этой серии статей я рассмотрю те из них, в которых достаточно хорошо разбираюсь.
1. Ограничения масштабируемости
Сейчас все открытые консенсус-протоколы для блокчейнов имеют одно и то же узкое место: каждый полный сетевой узел (полная нода) должен обрабатывать каждую транзакцию.
Почему? Вспомним, что одна из основных характеристик блокчейнов — децентрализация, то есть в них нет единого Центра, ответственного за поддержку работоспособности и безопасность системы. Вместо этого, каждый узел вносит вклад в общую безопасность сети тем, что подтверждает каждую транзакцию и хранит полную копию состояния сети.
Такой метод децентрализации обеспечивает основные преимущества блокчейна, которые важны для всех нас — гарантии безопасности, политическую нейтральность, устойчивость к цензуре, — но за это приходится платить масштабируемостью, так как количество транзакций, которое способен обработать блокчейн, равно пропускной способности одного сетевого узла.
Из этого следует два практических вывода:
Низкая пропускная способность. Блокчейн может обработать только ограниченное число транзакций.
Низкая скорость выполнения транзакций. Обработка блока транзакций занимает существенное время. Например, в сети Биткойн интервал между блоками составляет 10 минут, в сети Ethereum — примерно 14 секунд, а в периоды пиковой нагрузки на это уходит еще больше времени. Для сравнения, в таких сервисах, как Square и Visa, транзакции подтверждаются практически мгновенно.
Поэтому разработчики публичных блокчейнов вынуждены искать компромисс между низкой пропускной способностью сетей и высокой степенью централизации.
Другими словами, по мере роста размера блокчейна растут и требования к размеру хранилища, пропускной способности и вычислительной мощности каждого узла сети. Может наступить момент, когда на обработку блоков потребуется столько ресурсов, что останется слишком мало узлов, способных справляться с этой нагрузкой, и тогда сеть рискует стать централизованной.
То есть мы сделаем полный круг и вернемся к централизованным системам, которые требуют доверия к нескольким крупным участникам, хотя на самом деле нам нужна система, способная обрабатывать тысячи транзакций в секунду и сохранять ту же степень децентрализации, какая была обещана изначально.
Решения проблемы масштабируемости
В идеале нам нужен блокчейн, не менее безопасный, чем Биткойн или Ethereum, и при этом не требующий, чтобы каждый узел обрабатывал как минимум определенную долю всех транзакций сети. Другими словами, нужен механизм, который ограничивал бы количество узлов, необходимых для подтверждения транзакций, но без потери уверенности участников сети в правильности и подлинности каждой транзакции. Звучит просто, но реализовать это очень сложно.
Масштабируемость — это серьезное препятствие на пути к будущему успеху платформы. Есть несколько вариантов решения проблемы, которыми уже занимаются различные команды разработчиков.
Платежные каналы офчейн
Суть этого решения заключается в создании дополнительного слоя с сетью каналов для микроплатежей, которая позволит проводить большинство транзакций вне блокчейна, то есть вынести за пределы основного блокчейна действия, которые обычно записываются в него напрямую. В этой модели блокчейн используется как расчетный слой, в котором обрабатывается только последняя транзакция из серии взаимодействий между аккаунтами и фиксируется конечное состояние счетов. Таким образом, появляется возможность разгрузить блокчейн.
Это решает обозначенную выше проблему с пропускной способностью, так как в этой модели блокчейн масштабируется до значительно больших объемов транзакций. Более того, поскольку транзакция считается совершенной, как только ее обработал платежный канал, а не после подтверждения включающего ее блока, каналы микроплатежей решают проблему скорости обработки транзакций, уменьшая период ожидания.
В качестве примеров сетей микроплатежных каналов можно привести Raiden Network и Lightning Network.
Шардирование (sharding)
Идея шардирования состоит в том, что полная информация о состоянии блокчейна делится на сегменты (shards), и обработка разных частей этого состояния происходит одновременно в разных узлах сети. При этом каждый сегмент обрабатывает небольшую часть данных. В целом шардирование блокчейна похоже на шардирование базы данных, но в блокчейне, с его децентрализованным набором узлов, значительно сложнее обеспечить безопасность и проверку подлинности данных.
Вычисления офчейн
Это похоже на обработку состояния в нескольких каналах, только в еще большем масштабе. Идея этого метода состоит в том, что вне блокчейна происходит не только передача токенов, но и те вычисления, которые требуют слишком больших затрат ресурсов при их выполнении в блокчейне. Способ проведения этих вычислений гарантирует их безопасность и подлинность. Использование отдельного протокола для проведения вычислений и проверок вне блокчейна способствует увеличению пропускной способности сети. Пример применения этой модели для Ethereum — TrueBit.
Направленный ациклический граф
Направленный ациклический граф (DAG, от directed acyclic graph) состоит из вершин (точек) и ребер (соединительных линий между точками). В направленном ациклическом графе не существует пути обхода, возвращающегося к начальной точке (невозможны замкнутые циклы). Это позволяет установить топологический порядок для вершин и ребер.
Основанные на DAG протоколы (например, Tangle в IOTA) позволяют полностью отойти от глобальных линейных блокчейнов, потому что в них состояние системы задано структурой, имеющей вид такого графа. Для обеспечения сетевой безопасности эти протоколы используют новаторские технологии, которые не требуют линейным образом обрабатывать каждую транзакцию в каждом узле.
Протокол SPECTRE — еще решение, основанное на DAG — соединяет в DAG блоки и поддерживает параллельный майнинг блоков для повышения пропускной способности и производительности системы.
Впрочем, на текущий момент крупномасштабных решений, реализующих такие протоколы, не существует. Это связано с наличием серьезных ограничений и уязвимостей, и надежные масштабируемые решения появятся только тогда, когда будут найдены способы исправить эти недостатки.
2. Ограничения конфиденциальности
Ваши транзакции в блокчейне не имеют прямой привязки лично к вам, и потому они могут казаться конфиденциальными, ведь кто угодно может создать анонимный кошелек и совершать транзакции через него.
Но не все так просто.
С одной стороны, использование псевдонимов составляет сильную сторону этой технологии. Хоть история транзакций и хранится в открытом реестре, эти данные привязаны к учетным записям, состоящим только из букв и цифр. Кроме того, к учетным записям не привязаны никакие реальные данные, и отыскать человека, который совершил транзакцию, кажется невозможным.
Но на самом деле это только создает видимость безопасности. Человек действительно может сохранять анонимность, пока его псевдоним в сети не связан с его реальным именем, но достаточно одной утечки информации, чтобы это перестало быть тайной. Один такой случай уже произошел: правоохранительные органы подтвердили, что в ходе расследования узнали имена людей, переводивших биткоины, и тем самым опровергли предположение о полной конфиденциальности подобных транзакций.
Как они смогли это сделать?
Информация из cookie-файла или из программы, которая анализирует поведение пользователя на веб-сайте, может попасть в сеть и стать доступной для кого угодно — и для правительств, и для правоохранительных органов, и для злоумышленников.
Более того, в таких блокчейн-платформах, как Ethereum, пользователи создают смарт-контракты, которые могут оперировать самыми разными данными. В блокчейне Ethereum все данные из смарт-контрактов, включая отправителя, получателя, переданные в транзакции данные, выполненный код и состояние, записанное в контракте, находятся в открытом доступе.
Для большинства компаний неприемлемо записывать важные данные в блокчейн, где их может увидеть кто угодно, включая и хакеров, и конкурентов. Примерами таких данных могут служить:
Электронные медицинские карты. Публикация этих данных в блокчейне недопустима, потому что нарушает право пациента на конфиденциальность.
Данные из удостоверений личности – например, номер паспорта.
Данные для авторизации, такие как пароли и ключи.
Финансовые документы – например, таблицы капитализации или данные о зарплате сотрудников.
И многое другое.
Конфиденциальность остается серьезным препятствием для физических лиц и организаций, а также в отраслях, где важна сохранность личных данных. Многие из тех, кто возлагает большие надежды на криптовалюты, заинтересованы в создании системы, которая предоставляет новые финансовые возможности и при этом не требует доверия к другим участникам и устойчива к цензуре. Как ни парадоксально, сейчас для этих целей используется открытый и легко отслеживаемый реестр!
Решения проблемы конфиденциальности
Вот примеры решений, над которыми сейчас работают разные команды разработчиков.
Адреса на эллиптической кривой Диффи-Хеллмана-Меркле (ECDHM, от Elliptic Curve Diffie-Hellman-Merkle)
Концепция ECDHM-адресов основана на протоколе Диффи-Хеллмана. Он позволяет двум сторонам получить общий секретный ключ, с помощью которого они в дальнейшем смогут обмениваться закрытыми сообщениями в открытой сети.
Каким образом?
Отправитель и получатель могут публично обменяться ECDHM-адресами, а затем использовать общий секретный ключ для генерации анонимных адресов в сети Биткоин. Эти Биткоин-адреса могут быть открыты только тому, кому известен секретный ключ, а в открытом доступе остаются только ECDHM-адреса многоразового использования. Поэтому участники могут не переживать за конфиденциальность своих транзакций.
Концептуальная схема идеи обмена ключами, которая использует разные цвета вместо очень больших чисел (Источник)
Примеры схем, основанных на ECDHM-адресах, включают Stealth-адреса Питера Тодда (Peter Todd), платежные коды многоразового использования из BIP47 Юстуса Ранвье (Justus Ranvier) и обмен адресами по внешнему каналу из BIP75 Джастина Ньютона (Justin Newton). Однако рабочие реализации таких схем встречаются крайне редко.
Миксеры
Идея миксера заключается в том, что несколько пользователей объединяют свои платежи в общий пул и хранят записи о том, кто кому сколько должен, в закрытом реестре. После того как средства из общего пула потрачены, нельзя определить источники отдельных платежей. Наблюдатель может видеть, кому и сколько было передано средств, но вычислить человека, который совершил тот или иной платеж, в теории, нельзя. Пример такого миксера — CoinJoin.
К сожалению, на практике миксеры оказались ненадежным решением. Например, эксперты смогли легко установить источник транзакций, совершенных с помощью CoinJoin, и доказали, что злонамеренному пользователю достаточно потратить 32 000 долларов, чтобы с вероятностью 90% лишить участников транзакции анонимности. Более того, оказалось, что миксеры слабо устойчивы к атакам Сивиллы и DoS-атакам.
Еще более разочаровывает то, что якобы защищенный реестр миксера требует администрирования третьей стороной, которой должны доверять участники пула миксера.
Поскольку CoinJoin не является сервисом, предоставляемым по умолчанию, его используют не так много людей, то есть количество участников в пуле миксера невелико. Поэтому несложно определить, что конкретную транзакцию совершил один из нескольких возможных участников.
Другой пример такого решения – CoinShuffle, децентрализованный миксер-протокол, разработанный группой исследователей из Саарского университета в Германии. Они попытались улучшить CoinJoin, исключив необходимость наличия доверенной третьей стороны для компоновки объединенных транзакций.
Monero
Другой способ решения проблемы конфиденциальности — это создание криптовалюты, анонимной по умолчанию, такой как Monero. В отличие от многих альткоинов, Monero – не форк Биткоина. В основе Monero лежит альтернативный протокол CryptoNote.
Главное отличие Monero от других криптовалют — использование схемы кольцевой подписи.
Это вариант групповой подписи, где каждый участник, имеющий право поставить подпись, имеет открытый и закрытый ключи. В отличие от обычной криптографической подписи, которая показывает, что транзакция подтверждена одним участником, групповая подпись означает, что транзакция подтверждена одним из участников группы, но неизвестно, каким именно.
Доказательство с нулевым разглашением
Этот криптографический протокол позволяет проверяющей сторонеубедиться, что доказывающая сторона обладает неким секретным знанием, без необходимости раскрытия информации о нем проверяющей стороне. Другими словами, программа может предусматривать ввод секретных данных, но доказывающая сторона не предоставляет эти данные проверяющей. Доказательство с нулевым разглашением предоставляет основные элементы для реализации механизмов обеспечения конфиденциальности. Рассмотрим несколько примеров.
Пример 1: игры «вызов — ответ»
В сфере компьютерной безопасности аутентификация типа «вызов — ответ» описывает класс протоколов, в которых одна сторона должна задать вопрос («вызов»), а другая — предоставить верный ответ. Такую «игру» можно использовать для подтверждения транзакций в блокчейне. Если транзакция оказалась недействительной, другой узел может «привлечь внимание» к этому факту. Для подтверждения того, что транзакция недействительна, требуется доказательство, которое можно проверить. Если такого доказательства нет, источник транзакции получает «вызов», и для подтверждения подлинности транзакции он должен отправить верный ответ.
Рассмотрим пример. Боб имеет эксклюзивный доступ к некоему ресурсу (например, к своему автомобилю). Алиса хочет получить доступ к этому автомобилю, потому что ей нужно ехать в магазин. Боб отправляет ей вызов, например, «52w72y». Алиса должна отправить Бобу символьную строку, которая будет верным ответом на его вызов. Единственный способ сформировать такую строку — использовать алгоритм, который известен и Бобу, и Алисе. Кроме того, Боб каждый раз присылает новый вызов. Таким образом, если Алиса знает правильные ответы на прошлые вызовы, это не дает ей никакого преимущества.
Игры «вызов — ответ» уже используются в некоторых блокчейнах, например, в Ethereum. Однако пока нам не хватает библиотек и инструментов, которые могли бы серьезно упростить использование таких схем аутентификации.
Пример 2: zk-SNARK
Что такое zk-SNARK? Давайте разбираться.
zk = zero-knowledge (дословно — нулевое знание, здесь — нулевое разглашение). Это значит, что для доказательства существования информации необязательно делиться этой информацией.
SNARK: Succinct Non-interactive Adaptive ARgument of Knowledge (сжатое неинтерактивное адаптивное доказательство знания).
«Сжатое» означает, что доказательство может быть предоставлено в короткий срок.
«Неинтерактивное» означает, что проверяющей стороне не нужно напрямую взаимодействовать с доказывающей стороной. Вместо этого, доказывающая сторона может заранее опубликовать доказательство, которое потребуется проверяющей стороне.
«Адаптивное доказательство знания» означает доказательство знания о некоем вычислении.
zk-SNARK — это перспективная и впечатляющая технология обеспечения конфиденциальности, однако у нее есть узкие места:
SNARK требует больших вычислительных мощностей.
SNARK позволяет пользователю доказать, что тот обладает доступом к секрету, однако на этого пользователя ложится ответственность за сохранение секрета и предоставление этих данных по необходимости.
SNARK требует предварительной фазы настройки, во время которой фиксируется подлинность вычисления (circuit). В этой фазе участники закрытой группы людей, доверяющих друг другу, должны выполнить определенные действия. То есть это не только требует от участников доверия к людям, проводящим необходимую настройку, но также делает SNARK не лучшим выбором для выполнения произвольных вычислений по причине необходимости предварительной настройки.
Пример 3: zk-SNARK + Zcash
Zcash — анонимная криптовалюта, основанная на zk-SNARK. В Zcash есть так называемые защищенные транзакции, свойства которых распространяются на каждый из передаваемых коинов. Защищенные транзакции используют защищенные адреса, которые требуют от отправителя или получателя сгенерировать доказательство с нулевым разглашением, позволяющее другим участникам сети верифицировать зашифрованные данные транзакции без доступа к ним.
Схема транзакций Zcash
Несомненно, такой проект, как Zcash, заслуживает особого внимания.
Пример 4: zk-SNARK + Ethereum
В Metropolis, следующем обновлении протокола Ethereum, разработчики получат возможность эффективно и ончейн верифицировать доказательства zk-SNARK.
Какие возможности откроет использование технологии zk-SNARK в Ethereum? Некоторые параметры контрактов можно будет сделать конфиденциальными. Вместо того чтобы хранить информацию о секрете в блокчейне, ее можно хранить на стороне пользователей, которые будут подтверждать выполнение условий контракта с помощью SNARK. Каждый из этих пользователей должен заранее пройти фазу настройки. Но как только вычисление зафиксировано, его можно использовать для проверки сколь угодно большого числа транзакций.
Однако SNARK не сможет обеспечить для Ethereum конфиденциальность без участия пользователя. Ведь в этом случае SNARK полагается на пользователя, который хранит секрет вне блокчейна, и поэтому проверка секрета без участия этого пользователя невозможна.
Пример 5: zk-STARK
У zk-SNARK есть «преемник» — zk-STARK. Здесь буква T означает «Transparent» (прозрачный). zk-STARK исправляет одну из основных уязвимостей zk-SNARK — необходимость предварительной настройки. Кроме того, эта технология проще, потому что она основана только на хешировании и теории передачи информации, и еще она лучше защищена от взлома с помощью квантовых компьютеров, так как не использует эллиптические кривые и экспоненциальные допущения.
В целом, несмотря на большой прогресс в улучшении перечисленных выше схем обеспечения конфиденциальности с помощью доказательств с нулевым разглашением, они еще нуждаются в серьезных доработках. Библиотеки, реализующие доказательство с нулевым разглашением, требуют всестороннего анализа, проверок в полевых условиях и дополнительного развития. Также нужны проверки технологий zk-SNARK и zk-STARK в различных публичных блокчейнах. И мы еще посмотрим, как заложенные в Zcash сценарии использования покажут себя в большем масштабе и в реальных условиях. Для всего этого нужно время.
Обфускация кода
Еще один механизм обеспечения конфиденциальности – обфускация (запутывание) кода. Предположим, у нас есть программа P. Применив к ней обфускатор, мы получим программу O(P) = Q. При одинаковых входных данных обе программы возвращают одинаковые результаты, но с помощью анализа программы Q невозможно получить информацию о внутреннем устройстве P. Таким образом можно скрыть конфиденциальные данные (пароли, номера документов и т. п.) внутри Q, и при этом они будут оставаться доступными для использования.
Эксперты считают, что полная обфускация, которая превратила бы программу в «черный ящик», невозможна. Зато возможен более слабый вариант этого преобразования, который называется «обфускация неразличимости» (indistinguishability obfuscation). Возьмем две программы A и B, которые при одинаковых входных данных возвращают одинаковые результаты. После применения к ним обфускатора неразличимости получаются программы O(A) = P и O(B) = Q, и если у вас нет доступа к программам A и B, то вы не сможете определить, какая из них была исходной для программы P.
Эксперты Крейг Джентри (Craig Gentry), Амит Сахай (Amit Sahai) и др.описали реализацию обфускации неразличимого кода. Разработанный ими алгоритм очень требователен к вычислительным ресурсам, но если получится его улучшить, это решит многие проблемы. Самая интересная возможность в мире криптовалют — это идея публикации в блокчейне контрактов, содержащих закрытые данные.
Например, представим себе контракт на платформе Ethereum, который содержит пользовательский пароль для Coinbase. Можно написать программу, которая при выполнении определенных условий контракта открывает HTTPS-соединение с Coinbase через какой-нибудь промежуточный узел, авторизуется с этим паролем и совершает сделку. Если данные, которые хранятся в контракте, будут скрыты с помощью обфускатора, ни промежуточный узел, ни любой другой пользователь блокчейна не смогут изменить передаваемый запрос или узнать пароль.
Оракулы
Применительно к блокчейнам, оракул — это сторона, которая выполняет обмен данными между смарт-контрактами и внешними источниками данных. Фактически это носитель информации, передаваемой между смарт-контрактами, которые находятся в блокчейне, и внешними источниками данных, которые находятся вне блокчейна. Один из способов сохранения конфиденциальности данных — это использование оракулов для получения закрытых данных из внешних источников.
Безопасная среда исполнения
Безопасная среда исполнения (Trusted Execution Environment, TEE) представляет собой защищенную область в главном процессоре. Код и данные, загруженные в эту область, защищены с точки зрения целостности и конфиденциальности. Безопасная среда существует параллельно с операционной системой, в которой работает пользователь, но по сравнению с последней, она должна иметь более высокую степень конфиденциальности и защищенности.
Уже сейчас проводятся исследования возможностей использования безопасной среды исполнения для обеспечении конфиденциальности в блокчейне. Приятно, что многие эксперты работают в этом направлении, но хотелось бы, чтобы их стало еще больше.
3. Отсутствие формальной верификации контрактов
Формальная верификация смарт-контрактов остается СЕРЬЕЗНОЙ проблемой. Прежде всего давайте выясним, что вообще представляет собой формальная верификация контракта. Для этого необходимо понять, что такое формальное доказательство. В математике это математическое доказательство, которое было проверено компьютером с помощью фундаментальных математических аксиом и примитивных правил вывода.
Если брать более широко, то формальная верификация по отношению к программному продукту — это методология, позволяющая определить, ведет ли себя программа согласно спецификации. В целом это делается посредством конкретного языка спецификации, используемого для описания того, как должны соотноситься вводы и выводы функций. Иначе говоря, сначала мы должны установить касающиеся программы неизменяемые величины, а затем обязаны доказать утверждение.
Примером языка спецификаций является Isabelle — система автоматического доказательства теорем общего назначения, позволяющая передавать математические формулы формальным языком и обеспечивающая инструменты для доказательства этих формул посредством логического исчисления. Альтернатива — Coq, формальный язык, используемый для создания математических определений, выполняемых алгоритмов и теорем.
Так почему же важно формально верифицировать программы, зашифрованные в смарт-контрактах?
Во-первых, смарт-контракты неизменяемы: невозможно обновить или исправить их после того, как они развернуты в основной сети эфириума. Это означает, что нам необходимо довести их до ума в доверенной среде, прежде чем мы сумеем использовать эти контракты в реально работающих приложениях.
Более того, смарт-контракты публично доступны, и все, что хранится в них, открыто для всеобщего обозрения. Эта характеристика обеспечивает прозрачность, но она также делает смарт-контракты крайне привлекательной мишенью для хакеров.
Реальность такова, что создать заслуживающие доверия смарт-контракты, свободные от серьезных программных ошибок, нелегко, независимо от того, какие меры предосторожности принимаются. В случае эфириума, например, верифицировать код децентрализованной виртуальной машины эфириума (EVM) очень непросто, что объясняется устройством EVM. Таким образом, создание решений формальной верификации для эфириума — это еще более сложная задача.
Формальная верификация — это эффективное средство решения такой проблемы, как риск заражения вирусами и хакерских атак. Она гарантирует безошибочность в большей мере, чем традиционные подходы (например, тестирование, независимая экспертиза и т. д.), а нам жизненно необходимы лучшие решения.
Решения проблемы формальной верификации
Мне хотелось бы продемонстрировать в этом разделе больше публично доступных решений, но, к сожалению, они немногочисленны. Я обнаружила набор инструментов, созданный Ёити Хираи, инженером по формальной верификации Ethereum foundation. Он находится еще на очень ранней стадии. Ёити сумел добиться первых результатов в верификации нескольких смарт-контрактов, включая маленький формальный договор. Это первый на моей памяти реальный контракт, проанализированный в среде доказательства теорем.
Сам Ёити говорит:
«Полученные результаты далеки от совершенства. Я по-прежнему нахожу больше изъянов в настройках верификации, чем в верифицированных контрактах. Я уже говорю об этом публично, поскольку данный проект — хороший пример того, какой объем работы (и насколько кропотливой) необходим, чтобы верифицировать смарт-контракт с помощью логического умозаключения, полученного благодаря машине. На данный момент, если бы мне предложили внедрить смарт-контракт стоимостью более $100 000 и доверили составить график, я бы рассмотрел возможность взяться за это (другой вариант — сперва попробовать внедрить контракт с меньшими значениями)».
Есть и другие команды (например, Tezos), которые полностью отказываются от использования Solidity в качестве языка, а EVM — в качестве виртуальной машины. Вместо этого они создают собственные языки программирования смарт-контрактов и виртуальные машины, осуществляющие формальную верификацию.
Какой бы подход ни был правильным: изменение EVM с целью облегчить процесс формальной верификации или создание совершенно нового языка, который изначально легче верифицировать, — мы должны приложить максимум усилий. Нам нужно больше исследователей и разработчиков, работающих над формальной верификацией. Нам необходимы библиотеки формальной верификации и стандарты на всех возможных языках программирования.
4. Требования к размеру хранилища данных
В большинстве своем приложения, построенные на публичном блокчейне, требуют того или иного решения для хранения данных (идентификационной информации пользователей, финансовой информации и т. д.).
Однако хранение информации в публичном блокчейне означает, что данные:
хранятся каждым полным узлом в сети;
хранятся неопределенно долго, поскольку база данных блокчейна предназначена лишь для добавления и неизменяема.
Таким образом, хранение данных предполагает высокую стоимость децентрализованной сети, в которой каждый полный узел бесконечно хранит все больше и больше информации. В результате хранение становится серьезным препятствием для любого «настоящего» приложения, которое выстраивается на блокчейне.
Решения проблемы хранения данных
В нескольких молодых проектах используются различные стратегии разделения данных на сегменты и хранения их распределенным образом на участвующих в обработке данных узлах (то есть распределенного хранения). Базовый принцип состоит в том, что каждый узел не хранит все: наборы узлов расщепляют или «распределяют» данные в своей среде. Приведу несколько примеров таких проектов.
Swarm: представляет собой p2p-протокол совместного использования файлов для эфириума, позволяющий хранить код приложения и данные вне основного блокчейна в комплексе узлов, которые связаны с блокчейном эфириума. Позднее этими данными можно обмениваться внутри блокчейна.
Storj: решение, в котором файлы и данные вначале сегментируются, зашифровываются, а затем распределяются по многочисленным узлам таким образом, что каждый узел хранит лишь малую часть данных, то есть происходит распределенное хранение. Storj Coin (SCJX) используется для оплаты хранения и действует в качестве вознаграждения для узлов, хранящих часть пользовательских файлов или данных.
IPFS: альтернативный p2p-протокол гиперсреды, обеспечивающий высокую пропускную способность, с моделью хранения данных в виде блоков с гиперссылками к содержимому. По существу, этот протокол позволяет хранить файлы постоянно и децентрализованно, сохраняя предыдущие версии и устраняя дубли.
Decent: децентрализованная платформа совместного использования контента, позволяющая пользователям загружать, монетизировать и совместно использовать свои работы (видео, музыку, электронные книги и т. д.), не полагаясь на централизованную третью сторону. Пользователям облегчается доступ к контенту, поскольку промежуточные стороны отсутствуют, а узлы, хранящие контент, награждаются комиссиями.
5. Ненадежные механизмы достижения консенсуса
Пользователям, осуществляющим транзакции в блокчейне, не нужно доверять третьей стороне. Благодаря этому достигается анонимность, возможность сопротивления ограничениям и осуществления инноваций без чьего-либо одобрения.
Механизм, в течение долгого времени использовавшийся в не требующем доверия блокчейне и способный достаточно эффективно противостоять атакам, называется протоколом консенсуса. Протоколы консенсуса не являются новой функцией, возникшей вместе с блокчейном и биткоином. Например, в 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 имеет меньше обоснований и сложнее для понимания. Осознание различных преимуществ и недостатков различных проектных решений требует дальнейших исследований и экспериментов. Таким образом, присутствует настоятельная потребность в сотрудничестве ради создания более эффективных, быстрых и надежных систем консенсуса, основанных на том, что уже сделано.
6. Отсутствие регулирования и единых стандартов
Нет нужды говорить, что у публичного децентрализованного блокчейна нет центрального ответственного лица или организации, принимающей решения. С одной стороны, благодаря этому мы обретаем то, к чему стремимся: совершенно не требующую доверия, открытую и свободную от ограничений систему. С другой стороны, не существует безопасного пути обновления протокола, и никто не ответственен за установление и поддержание стандартов.
Хотя мы однозначно хотим, насколько это возможно, сохранять децентрализованный характер развития технологии блокчейн, нам по-прежнему нужно координировать деятельность разработчиков и других представителей экосистемы, чтобы приходить к согласию по вопросам новых стандартов, функций и обновлений. Неясно, как можно этого достичь в отсутствие хотя бы толики централизации (например, без 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. Некоторые исследователи и разработчики отчаянно пытаются решить вышеуказанные проблемы, но им недостает ресурсов. К несчастью, соображения выгоды подталкивают многих, включая разработчиков и лидеров сектора, игнорировать существующие проблемы.
В наступившем году я намерена продолжать:
привлекать внимание специалистов и энтузиастов к этим вопросам;
уделять максимум времени поиску решений;
помогать другим исследователям и разработчикам делать то же самое.
Независимо от того, имеем ли мы сейчас дело с пузырем, я убеждена, что блокчейн задержится надолго. Нам, разработчикам, просто нужно приложить максимум усилий к тому, чтобы снести барьеры, стоящие на пути широкомасштабного внедрения блокчейна. И нам нужны инвесторы, финансирующие эти усилия.
https://cryptocurrency.tech/ (C)
Не является индивидуальной инвестиционной рекомендацией
При копировании ссылка обязательна Нашли ошибку: выделить и нажать Ctrl+Enter