АЛЬТЕРНАТИВНЫЕ ПРИЛОЖЕНИЯ БЛОКЧЕЙНА

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

◊ NAMECOIN. Созданный в 2010 году Namecoin можно описать как децентрализованную базу данных зарегистрированных имен. Децентрализованным протоколам вроде Tor, Bitcoin и BitMessage нужен какой-то способ идентификации учетных записей, чтобы другие люди могли с ними взаимодействовать, но во всех существующих возможен лишь один вид идентификации – псевдослучайный хеш вроде 1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy. В идеале пользователям хотелось бы иметь возможность создавать аккаунты с именами вроде «george». Но проблема в том, что если кто-то может создать аккаунт «george», то другой пользователь сможет таким же образом зарегистрировать аккаунт с тем же именем и выдавать себя за первого человека. Единственное решение здесь – парадигма «первого заявителя», где второй заявитель не сможет претендовать на уже занятое имя. Такой подход прекрасно сочетается с протоколом консенсуса Bitcoin. Namecoin – первый и самый успешный пример такой системы регистрации имен.

◊ ЦВЕТНЫЕ МОНЕТЫ. Цель цветных монет – позволить людям создавать собственные цифровые валюты (или, что тоже важно, валюты с одной единицей – цифровые токены) на блокчейне Bitcoin. В протоколе цветных монет любой может «выпустить» новую валюту, публично перекрасив свои UTXO из Bitcoin. Протокол рекурсивно окрашивает UTXO в цвет монет на входе создавших их транзакций (в случаях, когда на входе присутствует несколько цветов, применяются особые правила). Это позволяет пользователям поддерживать кошельки, содержащие только UTXO определенного цвета, и отправлять их так же, как обычные биткойны, отслеживая в истории цвет любого полученного UTXO.

◊ МЕТАКОЙН. Идея следующая: протокол метакойна располагается поверх сети Bitcoin, в ней же хранятся метакойн-транзакции, но при этом используется другая функция изменения состояния – APPLY’. Поскольку метакойн-протокол не может предотвратить появление невалидных метакойн-транзакций в блокчейне Bitcoin, в протокол добавляется правило: если APPLY’ (S, TX) выдает ошибку, применить APPLY’ (S, TX) = S. Это обеспечивает простой механизм для создания произвольного протокола криптовалюты с расширенным функционалом, невозможным внутри самого Bitcoin, но с очень низкой стоимостью разработки, поскольку сложности майнинга и сетевого взаимодействия уже обрабатываются протоколом Bitcoin. Метакойны используют для реализации некоторых классов финансовых контрактов, регистрации имен и децентрализованных бирж.

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

В свою очередь, у создания протокола поверх Bitcoin тоже есть свой недостаток: он не наследует у Bitcoin систему упрощенной верификации платежей. SPV работает в Bitcoin, потому что он может использовать глубину блокчейна в качестве прокси для валидности: если давние предшественники транзакции находятся достаточно глубоко в блокчейне, можно с уверенностью сказать, что они легитимны. С другой стороны, основанные на Bitcoin метапротоколы не могут требовать от блокчейна не включать транзакции, невалидные с точки зрения этого самого метапротокола. Следовательно, внедрение полностью безопасного SPV-метапротокола потребовало бы пробегать по всему блокчейну вплоть до самого начала, чтобы проверить валидность той или иной транзакции. На сегодня «легкие» внедрения основанных на блокчейне Bitcoin метапротоколов полагаются на предоставление данных сервером, которому необходимо доверять, что крайне неприемлемо в свете одной из главных целей криптовалют – избавиться от необходимости кому-либо доверять.

НАПИСАНИЕ СКРИПТОВ

На самом деле даже без каких-либо расширений протокол Bitcoin поддерживает примитивную версию «смарт-контрактов». Владение UTXO в Bitcoin можно подтверждать не только публичным ключом, но и скриптом, написанным на простом языке программирования, основанном на стеке. В этой парадигме транзакция, тратящая эти UTXO, должна предоставить данные, которые удовлетворят этот скрипт. На самом деле даже стандартный, использующий публичный ключ механизм владения реализован как скрипт: «на входе» он берет цифровую подпись на основе эллиптических кривых, сопоставляет ее с транзакцией и адресом, который владеет UTXO, и возвращает 1 в случае успешной верификации и 0 – в случае неуспешной. В различных дополнительных кейсах возможны более замысловатые скрипты. К примеру, возможен скрипт, согласно которому для валидации необходимо предоставить две из трех цифровых подписей (так называемая мультиподпись). Это может быть полезно для корпоративных аккаунтов, аккаунтов безопасного хранения и торговли с эскроу-счетами. Скрипты также можно использовать для выплат наград за решение важных вычислительных задач; можно даже создать скрипт, говорящий что-то вроде «эти UTXO биткойна будут ваши, если вы предоставите SPV-доказательство того, что переслали мне столько-то дожкойнов». По сути, получится почти децентрализованная биржа криптовалют.

Однако у встроенного в Bitcoin языка скриптов есть ряд серьезных ограничений.

◊ ОТСУТСТВИЕ ПОЛНОТЫ ПО ТЬЮРИНГУ. Скриптовый язык Bitcoin поддерживает большое подмножество вычислений, но далеко не все. Прежде всего не хватает циклов. Это сделано для того, чтобы избежать длинных циклов во время верификации транзакций; теоретически это – преодолимое препятствие для авторов скриптов, поскольку любой цикл можно симулировать простым повторением кода через оператора «if», но из-за этого скрипт может попросту раздуться. К примеру, для внедрения алгоритма цифровой подписи на основе эллиптической кривой, по-видимому, придется вручную прописать 256 повторяющихся операций умножения.

◊ ФИНАНСОВАЯ СЛЕПОТА. Скрипт UTXO не может тщательно контролировать, сколько денег может быть снято со счета. Например, возьмем кейс с хедж-контрактом, где A и B закладывают эквивалент $1000 в биткойнах и спустя 30 дней скрипт пересылает стороне A эквивалент $1000 в биткойнах по новому курсу, а остальное – стороне B. Для определения стоимости 1 BTC в долларах США потребуется оракул, но даже так по сравнению существующими сейчас полностью централизованными решениями такой вариант – серьезный прогресс с точки зрения доверия и инфраструктуры. Однако поскольку UTXO нельзя использовать частично, единственный способ достичь этого – использовать очень неэффективный хак, суть которого в обладании множеством UTXO разного номинала (например, один UTXO 2k для каждого k до 30), и сделать 0 попыток подобрать, какой UTXO отправлять A, а какой – B.