1. Інтернет договорів - нова реальність на базі смарт-контрактів? Олексій Благірев, керівник з розвитку...
2. Інтернет договорів - нова реальність на базі смарт-контрактів?

Інтернет договорів - нова реальність на базі смарт-контрактів?

Наша взаимовыгодная связь https://banwar.org/

Олексій Благірев, керівник з розвитку 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 )

Інтернет договорів - нова реальність на базі смарт-контрактів?

Олексій Благірев, керівник з розвитку 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 )

Інтернет договорів - нова реальність на базі смарт-контрактів?

Олексій Благірев, керівник з розвитку 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 )