Алексей Благирев, глава по развитию R3 в СНГ, о мире недалекого будущего, в котором нет ни одного документа, а все взаимоотношения определяются контрактами, какие Вы сами конфигурируете, и которые доступны в специальной Сети – новоиспеченном Интернете договоров.
Более 30 лет назад Интернет начинался как мена информацией – торговля в нем не существовала, поэтому все правила, протоколы и интерфейсы запросто не были предназначены для совершения транзакций передачи ценности от одного субъекта к иному субъекту.
Потом появился SSL и HTTPS, создав защищенный слой, какой мог использовать данные банковской карты и гарантировал бы, что эти не попадут в третьи руки при совершении операций оплаты в Сети.
Но соглашение более сложное понятие, чем платеж, в котором существующий комплект параметров конечен и смысл однозначно интерпретируется любым участником Сети.
В соглашениях появляется много дополнительных параметров – они могут быть с участием массы контрагентов, различного срока и описания или встроенных опционов, или прочих деривативов. Вероятно ли создать аналогичную инфраструктуру, подобную инфраструктуре проведения платежей, но для уже проведения немало сложных операций с использованием более сложных соглашений?
Существующие законодательные практики и основы настолько сложные, что требуются специально обученные люд, чтобы подготовить и выверить тот или иной контракт. А если контракт исполняется на территории нескольких стран, то это потребует погружения в их предметную область и существующее законодательство.
Разбор описания всех практик и законов вылит на исследование кода, давно написанной программы, когда утеряна нотация и непонятно зачем это было сделано. Остается лишь учить кейс за кейсом и наблюдать, как система будет реагировать на обстоятельства, какие однозначно в контракте не указаны. Так сегодня устроено дефиниция и построение взаимоотношений на уровне компаний.
Есть ли альтернатива?
На заре создания Интернета, ученый и исследователь Ян Григ (Ian Grigg) сформулировал концепцию рикардианского контракта – особой формы электронной записи для документа, которая позволяла легковесно прочитать контракт как пользователю, так и распознать машине.
Впоследствии рикардианская логика контрактов улеглась в основу нескольких известных платформ, работающих на распределенных реестрах таких как Corda, EoS, Mattereum и иные.
Это создало возможность перенести договор в электронный формат, при этом сохранив его юридическую значимость. Само по себе распознавание машиной электронного документа не столь мощно изменит окружающую действительность, сколько на нее повлияет встроенный в рикардианский контракт так именуемый «умный контракт» (smart contract), который будет выполнять заложенную логику, не опираясь на посредника или человечий фактор.
Такая конструкция позволяет с одной сторонки организовать прозрачную систему взаимодействия и расчетов, с иной стороны эта самая простота и прозрачность позволяет упростить процедуру арбитража, и, при наступлении тех или других проблем, понять возникшую проблему.
Каждый рикардианский контракт подписывается электронной цифровой подписью любого из участников, так, что подписывается каждый параметр контракта, какой был выделен. А номер контракта задается алгоритмом таким манером, что сочетает внутри, как закодированное значение всех параметров, так и факт, что они бывальщины подписаны участниками.
Когда стороны выполняют транзакцию по этому контракту, в описании транзакции передается тот самый номер, и программа соображает, что конкретная транзакция выполняется в соответствии с контрактом. Таким манером можно на шаг ближе стать к Цифровой Конституции, про какую писал Ян Григ. С другой стороны, гораздо несложнее становится проектировать финансовые инструменты, используя для этого аналогичную SWIFT – систему распределенных извещений, где можно закрепить подписью достигнутые договоренности.
Этакий чатик, в каком Вы переписывается и закрепляете договоренности, а из них уже платформа или система строит электронный документ, какой отражает суть Ваших достигнутых ожиданий по коммерческим касательствам.
Если мы добавим в систему расчетов эквивалент передачи ценности, какой будут использовать контракты – допустим какой-то вид токенов, то мы получим распределенную систему учета ценности, основанную на контрактных условиях и обязательствах, закрепленных участниками своими электронными подписями.
Такие токены вполне могут быть отчуждаемыми, как это мастерят проекты Zcash, DigiCash и другие.
В этом случае невозможно проследить откуда они пришли, но можно проконтролировать, что одинешенек и тот же токен не выпущен дважды по одному и тому же контракту, чтобы его невозможно было дважды использовать.
Это гарантируется за счет использования особой парадигмы 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, демонстрируя тем самым наличие средств для покрытия издержек на срок выполнения трудов, если Бэлла выполняет работы, то ей перечисляется депозит. Стоит отметить, что, когда оружия депонируются в смарт-контракт, то никто не имеет права их использовать, если другое не предусмотрено смарт-контрактом (например, смарт-контракт может допустить использование этих оружий для пассивного трейдинга на криптовалютной бирже, чтобы снизить издержки Обри при отвлечении оружий).
Рассматривая экосистемы существующих технологических решений на распределенных реестрах уже можно отыскать отдельный компоненты, которые позволяют технически скопить часть необходимой инфраструктуры, но чтобы перейти к глобальному мене без использования документов, необходимо интегрировать семантический слой (описания бизнес логики, правил и резонов) в существующий компьютерный код, а это два разных направления для работ, какие требуют навыков и соответствующих усилий со стороны профессионального сообщества.
Типизация трудов по отношению к смарт-контрактам – по данным исследований Smart Contract Templates 2016 (https://arxiv.org/pdf/1608.00771.pdf)
