Блокчейн-интернет
Меня зовут Анна. Я — блокчейн-журналист. Довольно часто я беру интервью у экспертов. Темы разные, но обычно довольно сложные для понимания читателей, отдаленно представляющих себе, что такое смарт-контракты и технология распределенных реестров. Однако недавно мне довелось поговорить с Алексеем Благиревым — лектором МГИМО в области блокчейн. Специально для читателей BitJournal Алексей провел мини-лекцию, после которой многие из вас смогут более детально разобраться в этой теме. Все материалы представлены вашему вниманию ниже. Приятного чтения!
Представьте себе мир, в котором нет ни одного документа, а все взаимоотношения определяются контрактами, которые вы сами конфигурируете, и которые доступны в специальной сети – новом Интернете-договоров.
Более 30 лет назад Интернет начинался как обмен информацией – торговля в нем не существовала, поэтому все правила, протоколы и интерфейсы попросту не были предназначены для совершения транзакций, передачи ценности от одного объекта к другому объекту.
Потом появился SSL и HTTPS, создав защищенный слой, который мог использовать данные банковской карты и создавал надежность того, что данные не попадут в третьи руки при совершении операций оплаты в Сети.
Но договор более сложное понятие, чем платеж, в котором существующий набор параметров конечен и смысл однозначно интерпретируется любым участником Сети.
В договорах появляется много дополнительных параметров – они могут быть с участием множества контрагентов, различного срока и описания или встроенных опционов, или прочих деривативов. Возможно ли создать аналогичную инфраструктуру, подобную инфраструктуре проведения платежей, но для уже проведения более сложных операций с использованием более сложных договоров?
Существующие законодательные практики и основы настолько многогранны, что требуются специально обученные люди, чтобы подготовить и выверить тот или иной контракт. А если контракт исполняется на территории нескольких государств, это потребует погружения в их предметную область и существующее законодательство.
Разбор описания всех практик и законов похож на исследование кода, давно написанной программы, когда потеряна нотация и непонятно зачем это было сделано. Остается лишь изучать кейс за кейсом и наблюдать, как система будет реагировать на обстоятельства, которые однозначно в контракте не указаны. Так сегодня устроено определение и построение взаимоотношений на уровне компаний.
Есть ли альтернатива?
На заре создания Интернета ученый и исследователь Ян Григ (Ian Grigg) сформулировал концепцию рикардианского контракта – специальной формы электронной записи для документа, которая позволяла легко прочитать контракт как пользователю, так и распознать машине.
Впоследствии рикардианская логика контрактов легла в основу нескольких известных платформ, работающих на распределенных реестрах таких как Corda, EoS, Mattereum и другие.
Это создало возможность перенести договор в электронный формат, при этом сохранив его юридическую значимость. Само по себе распознавание машиной электронного документа не столь сильно изменит окружающую действительность, сколько на нее повлияет встроенный в рикардианский контракт так называемый «умный контракт» (smart contract), который будет выполнять заложенную логику, не опираясь на посредника или человеческий фактор.
Такая конструкция позволяет с одной стороны организовать прозрачную систему взаимодействия и расчетов, с другой стороны эта самая простота и прозрачность позволяет упростить процедуру арбитража и, при наступлении тех или иных проблем, понять причину, которая их породила.
Каждый рикардианский контракт подписывается электронной цифровой подписью каждого из участников, так, что подписывается каждый параметр контракта, который был выделен. А номер контракта задается алгоритмом таким образом, что сочетает внутри, как закодированное значение всех параметров, так и факт, что они были подписаны участниками.
Когда стороны выполняют транзакцию по этому контракту, в описании транзакции передается тот самый номер, и программа понимает, что конкретная транзакция выполняется в соответствии с контрактом. Таким образом можно на шаг ближе стать к Цифровой Конституции, про которую писал Ян Григ. С другой стороны, гораздо проще становится проектировать финансовые инструменты, используя для этого аналогичную SWIFT — систему распределенных сообщений, где можно закрепить подписью достигнутые договоренности.
Этакий чатик, в котором вы переписываетесь и закрепляете договоренности, а из них уже платформа или система строит электронный документ, который отражает суть ваших достигнутых ожиданий по коммерческим отношениям.
Если мы добавим в систему расчетов эквивалент передачи ценности, который будут использовать контракты – допустим какой-то вид токенов, то мы получим распределенную систему учета ценности, основанную на контрактных условиях и обязательствах, закрепленных участниками своими электронными подписями.
Такие токены вполне могут быть отчуждаемыми, как это делают проекты Zcash, DigiCash и другие.
Unspent Transaction Output
В этом случае нельзя проследить откуда они пришли, но можно проконтролировать, что один и тот же токен не выпущен дважды по одному и тому же контракту, чтобы его нельзя было дважды использовать.
Это гарантируется за счет использования специальной парадигмы UTXO, с которой начался Bitcoin. UTXO (Unspent Transaction Output) – модель отслеживания двойных транзакций, которая представляет из себя метод соблюдения бухгалтерского баланса – сколько прибыло, столько и убыло. Дебет есть дебет, кредит есть кредит. Кто-то называет UTXO тупиком в развитии, кто-то считает правильной защитой от дублирования транзакций, которая действует везде, за исключением форка.
Отчуждаемость токена гарантирует возможность для токена быть расчетной единицей для передачи ценности. Это означает, что если стороны договорились создать нечто ценное в рамках договора, то размер этой ценности определяется и может быть передан третьей стороне, что создает возможность для поддержки торговых операций.
Возможны ли такие интерфейсы и такой Интернет, который избавит от необходимости заполнять и передавать друг другу документы?
Разбирая основы коммерческих взаимоотношений, можно выделить общие компоненты, одинаково важные как для B2C, так и B2B:
- Terms and Conditions (далее T&C) – основные параметры договоров, которые указываются как в номинальных договорах. Например, при посещении того или иного сайта, предлагается согласиться с политикой обработки персональных данных, или при установке программного обеспечения предлагается прочитать и согласиться с договором по использованию программного обеспечения.
Большинство T&C являются базовыми, т.е. шаблонными, куда проще, если их все заменить на предопределенные шаблоны, которые будут храниться в распределенном реестре, при этом компании будут менять только определенные параметры, явно их обозначая. Выделяя базовые учетные единицы юридического пространства и унифицируя их использование, можно спроектировать пространство взаимодействия как это будет удобно.
- Know Your Customer (далее KYC) – для того, чтобы вступить в те или иные взаимоотношения или транзакцию, сегодня необходимо предъявить документы, удостоверяющие личность или подтверждающие тот или иной статус компании.
Соответственно область трансформации должна включать в себя изменение этого процесса. В качестве одного из шагов, необходимо разработать и создать единую базу досье как физических, так и юридических лиц. Звучит это, как недостижимая утопия, но, если рассмотреть этот вопрос детальнее, то «единая» для большинства означает централизованная, хотя на деле мы говорим о децентрализованной модели обмена ключевой информацией, необходимой для идентификации, обладающей рядом важных характеристик:
-
- Конфиденциальность – информацию получают только те, кому пользователь или компания дала доступ к ней.
- Непротиворечивость – вся информация имеет возможность быть подтвержденной или нет через соответствующую статусную модель.
- Принадлежность – информацией владеет именно пользователь или компания, и он несет за нее ответственность при предоставлении поддельных данных.
Стоит отметить, что консорциум R3 реализовал проект информационного досье для юридических лиц и провел более 300 успешных транзакций с участием 39 банков на Corda. Взаимодействие в таком распределенном реестре происходит через связи, которые подтверждены участниками. Например, значение того или иного параметра, являющего частью общего досье, допустим имя «Алексей», подтверждается каждым участником, который участвует в транзакции. Таким образом не важно само название или значение того или иного параметра, сколько сам факт, что участники его подтвердили и верифицировали.
- Арбитраж – процесс арбитража в случае спора, конфликта или возникновения неразрешимой ситуации, должен быт прозрачным и возникать только в тех случаях, которые не покрываются правилами и параметрами, указанными в контракте.
Например, договор на copyright, когда автор выполнил заказ, но по какой-то причине заказ не был оплачен. Это наиболее сложная часть, которая затрагивает взаимодействие в различных юрисдикциях. Ян Григ указывает на четыре ключевых актива, которые должны быть соблюдены для того, чтобы арбитраж стал возможен с использованием рикардианских контрактов:
- Основа арбитража и процедуры — в смарт-контракте необходимо описать ключевые процедуры, по которым будет происходить резолюция возникшего инцидента. В данном конкретном случае, помимо этого, процедура должна иметь возможность допускать к участию различные арбитражные организации.
- Портфолио шаблонов контрактов — портфолио представляет из себя набор типовых контрактов, подготовленных и описанных на понятном пользователю языке, сохранив при этом необходимую разметку, которую может распознать алгоритм.
- Парадигма проектирования — методология проектирования смарт-контрактов с сохранением и нормализацией контекста, т.е. выделение атомарных уникальных свойств контракта, которые параметризируют каждый тип транзакции.
- Экосистема развития технологий — пользователями контрактов будет в первую очередь выступать малый и средний бизнес, а также технологические предприниматели, именно они будут двигателями изменений по созданию новых продуктов в цифровой экономики.
Пример исполнения рикардианского контракта при совершении покупки вина – на основании материалов WhitePaper платформы Mattereum. В этом случае арбитражная организация представлена независимой нодой, которая получает вознаграждение за выполнение операции подтверждения, если подтверждение об оплате не последует, именно арбитражная организация на основании описанных процедур проведет резолюцию инцидента в пользу Боба.
Следующий пример использования рикардианского контракта для трудоустройства (взят из описания платформы Mattereum). Бэлла, веб-разработчик, получает задание от Обри разработать прототип в обмен на оплату за 5 ETH в день. Но она сомневается, что Бэлла сможет закончить работу в срок за 5 дней, поэтому этому добавляет дополнительное время, но по сниженной уже ставке 2.5 ETH в день. При этом Обри депонирует 25 ETH, показывая тем самым наличие средств для покрытия издержек на срок выполнения работ, если Бэлла выполняет работы, то ей перечисляется депозит.
Стоит отметить, что когда средства депонируются в смарт-контракт, то никто не имеет права их использовать, если иное не предусмотрено смарт-контрактом (например, смарт-контракт может допустить использование этих средств для пассивного трейдинга на криптовалютной бирже, чтобы снизить издержки Обри при отвлечении средств).
Рассматривая экосистемы существующих технологических решений на распределенных реестрах уже можно найти отдельный компоненты, которые позволяют технически собрать часть необходимой инфраструктуры, но чтобы перейти к глобальному обмену без использования документов, необходимо интегрировать семантический слой (описания бизнес-логики, правил и смыслов) в существующий компьютерный код, а это два разных направления для работ, которые требуют навыков и соответствующих усилий со стороны профессионального сообщества.
BitJournal
Автор: Анна Окружко
