◊ МЕТАКОЙН. Идея следующая: протокол метакойна располагается поверх сети 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 повторяющихся операций умножения.