Ознакомительная версия. Доступно 16 страниц из 76
подавляющее большинство приложений будут слишком маленькими, чтобы заручиться собственными блокчейнами. Также стоит отметить, что существуют большие классы децентрализованных приложений, в частности децентрализованных автономных организаций, которые должны взаимодействовать друг с другом.
В свою очередь, у создания протокола поверх 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.
◊ ОТСУТСТВИЕ ПРОМЕЖУТОЧНЫХ СОСТОЯНИЙ. UTXO можно либо потратить, либо не потратить; невозможно создать контракт или скрипт для какого-то промежуточного состояния. Это затрудняет заключение многоуровневых контрактов с опциями, создание предложений децентрализованного обмена или двухэтапных протоколов криптографического соглашения (необходимых для безопасности вознаграждений за решение той или иной вычислительной задачи). Также это значит, что UTXO может использоваться для простых моментально исполняющихся контрактов, но никак не для более сложных контрактов «с отслеживанием состояния» вроде децентрализованных организаций. По этой же причине становится трудно внедрять метапротоколы. Бинарность состояния в сочетании с финансовой слепотой также приводит к невозможности задать предельное значение суммы, которую можно снять с кошелька.
◊ БЛОКЧЕЙН-СЛЕПОТА. UTXO не видит информацию блокчейна о временной метке, одноразовом коде и хеше предыдущего блока. Это сильно ограничивает его применение в азартных играх и некоторых других категориях, лишая скриптовый язык потенциально ценного источника случайных величин.
Таким образом, мы видим три подхода к разработке более продвинутых приложений на базе криптовалюты: создать новый блокчейн, использовать скриптовый язык поверх Bitcoin и создать метапротокол поверх Bitcoin. Создание нового блокчейна предоставляет неограниченную свободу творчества, но ради этого придется потратить очень много времени на разработку, бутстрэппинг и безопасность. Вариант со скриптовым языком намного проще внедрить и стандартизировать, но он крайне ограничен в возможностях. В свою очередь метапротоколы, хоть и тоже простые, трудно масштабировать. В Ethereum мы хотим создать альтернативный фреймворк, который еще эффективней использует простоту разработки, а также усилит свойства легкого клиента и в то же время позволит приложениям пользоваться экономической средой и безопасностью блокчейна.
ETHEREUM
Цель Ethereum – представить альтернативный протокол для создания децентрализованных приложений, обеспечив компромиссы, которые, как нам кажется, будут очень полезны для большого класса децентрализованных приложений, с особым акцентом на обстоятельства, где важны быстрая разработка, безопасность для маленьких и редко используемых приложений и возможность эффективного взаимодействия разных приложений. Для этого Ethereum создает предельно базовую платформу – блокчейн со встроенным полным по Тьюрингу языком программирования, позволяющим любому желающему писать смарт-контракты и децентрализованные приложения, где каждый может создавать собственные произвольные правила владения, форматы транзакций и произвольные функции изменения состояния. В простейшей форме реализация идеи известной криптовалюты Namecoin на этом языке занимает две строки кода, а протоколы валют и систем репутации можно реализовать менее чем в двадцать строк. Смарт-контракты – криптографические «коробки», содержащие значение и открывающиеся только при определенных условиях, – также могут быть построены поверх платформы Ethereum, причем со значительно большей функциональностью, чем в скриптовом языке Bitcoin. Это возможно благодаря полному по Тьюрингу языку Ethereum, его финансовой «зрячести», блокчейн-«зрячести» и наличию промежуточных состояний.
АККАУНТЫ ETHEREUM
В Ethereum состояние состоит из объектов под названием «аккаунты»; каждому аккаунту соответствует 20-байтовый адрес. Функции изменения состояния – переводы валюты или информации между аккаунтами. Ethereum-аккаунт содержит четыре поля:
◊ ОДНОРАЗОВЫЙ КОД – счетчик, необходимый для того, чтобы каждая транзакция произошла ровно один раз;
◊ текущий БАЛАНС ЭФИРА, принадлежащего аккаунту;
◊ КОД КОНТРАКТА, связанного с аккаунтом, если контракт есть;
◊ ХРАНИЛИЩЕ аккаунта (пустое по умолчанию).
Эфир – главное внутреннее «криптотопливо» Ethereum, он же используется для уплаты комиссий. Возможны
Ознакомительная версия. Доступно 16 страниц из 76
