Ник Сабо: смарт-контракты до появления Ethereum

У торгового автомата можно купить напиток без переговоров с продавцом: выбрать товар, внести монеты, получить бутылку и сдачу. Правило простое, но оно уже напоминает небольшой договор: условие проверяется механизмом, а исполнение происходит автоматически. Именно такой пример Ник Сабо использовал, когда в 1994 году описывал смарт-контракты. В его ранней идее речь шла не только о программах в блокчейне, а о способе встроить некоторые условия сделки в программное обеспечение, устройства и цифровые права.

Содержание

1. Контракт в раннем интернете
2. Почему Сабо выбрал торговый автомат
3. От короткого определения к большой теме
4. Bit gold и цифровая редкость
5. Что изменил Ethereum
6. Где заканчивается код

Контракт в раннем интернете

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

В его авторском определении смарт-контракт — это компьютеризированный протокол транзакции, который исполняет условия контракта. Важны два слова: «протокол» и «условия». Код задаёт последовательность действий и проверки, но не обязательно заменяет весь документ, закон или суд. Он может принять подпись, проверить доступный баланс, передать цифровой объект или заблокировать действие до наступления срока. Но он исполняет только те условия, которые можно формализовать и к которым система имеет доступ.

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

Это объясняет, почему выражение «смарт-контракт» иногда сбивает с толку. В бытовом юридическом смысле контракт — это соглашение людей, которое интерпретируется и при необходимости обеспечивается правовой системой. В блокчейн-разработке смарт-контрактом часто называют программу, которая хранится и исполняется на сети. Между понятиями есть связь, но они не тождественны. Программа может автоматизировать часть сделки, не становясь сама по себе полным юридическим договором.

Почему Сабо выбрал торговый автомат

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

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

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

В тексте Сабо о смарт-контрактах 1997 года приводится последовательное уточнение: от простого замка — к системе с доступом владельца, отдельным доступом кредитора, условиями его включения и снятием залога после последнего платежа. «Умность» здесь — не в том, что программа сама знает справедливость. Она в том, что устройство может автоматически выполнять больше заранее оговорённых правил и делать некоторые нарушения дороже.

От короткого определения к большой теме

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

В 1997 году журнал First Monday опубликовал его статью «Formalizing and Securing Relationships on Public Networks». Сабо рассматривал смарт-контракты как сочетание протоколов и пользовательских интерфейсов, которые формализуют отношения в компьютерных сетях. Он связывал дизайн с правовыми принципами, экономической теорией и надёжностью протоколов. Среди применений упоминались кредит, права на контент, платежи и сделки с предъявителем.

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

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

Bit gold и цифровая редкость

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

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

История публикаций требует аккуратности. Текущая копия поста Bit gold в блоге Unenumerated показывает дату 27 декабря 2008 года. В начале автор пишет, что идея пришла ему значительно раньше, но эта фраза не устанавливает точную дату первого текста. Поэтому здесь мы не подменяем доступную страницу неподтверждённым годом первой публикации и не называем bit gold сетью, которая уже работала в 1990-х.

Bit gold часто называют предшественником Bitcoin, но сходство идей не означает, что один проект был запущенным прототипом другого или что Сабо создал Bitcoin. В собственном описании bit gold есть proof of work, временные отметки и реестр титулов; в Bitcoin Сатоши Накамото предложил свою работающую систему, в которой блоки и консенсус решают проблему двойного расходования. Можно сопоставлять решения и исторический контекст, не приписывая авторство без подтверждения.

Что изменил Ethereum

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

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

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

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

Где заканчивается код

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

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

Поэтому проверка смарт-контракта состоит не только в поиске ошибок кода. Нужно спросить: кто написал условия и кто может их менять? Что видит пользователь до подписания? Кто хранит управляющие ключи? Какие данные поступают извне? Есть ли процедура исправления и что происходит с пользователями в аварии? Кому принадлежит цифровой объект по договору и кому — по записи сети? В зависимости от ответов система может быть распределённой в одном слое и централизованной в другом.

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

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

Источники и дальнейшее чтение

1. Nick Szabo, “Smart Contracts”, copyright 1994; авторский текст.
2. Nick Szabo, “Formalizing and Securing Relationships on Public Networks”, First Monday 2(9), опубликовано 1 сентября 1997.
3. Nick Szabo, “The Idea of Smart Contracts”, текст автора, впервые опубликован в 1997 году, архивная копия.
4. Nick Szabo, “Bit gold”, страница Unenumerated; текущая копия показывает дату 27 декабря 2008 года. Ранее датированные архивные версии требуют отдельной сверки.
5. Vitalik Buterin, Ethereum Whitepaper, опубликовано в 2014 году; историческая версия, не описание актуального Ethereum.
6. Vitalik Buterin, “DAOs Are Not Scary, Part 1: Self-Enforcing Contracts And Factum Law”, Ethereum Foundation, 24 февраля 2014.