WikiDer > Рикардианский договор - Википедия

Ricardian contract - Wikipedia

В Рикардианский контракт, изобретенный Яном Григгом в 1996 году, представляет собой метод записи документа как договор в соответствии с законом и надежно связывая его с другими системами, такими как бухгалтерский учет, для контракта как выдачи стоимости.[1][2] Он надежен благодаря использованию идентификации криптографическая хеш-функция, прозрачный за счет использования читаемого текста для юридической прозы и эффективный язык разметки для извлечения важной информации.

Рикардианский контракт помещает определяющие элементы юридического соглашения в формат, который может быть выражен и реализован в программном обеспечении.[3] Ключ состоит в том, чтобы сделать формат как машиночитаемым, чтобы их можно было легко извлечь для вычислительных целей, так и читаемым как обычный текстовый документ, чтобы юристы и договаривающиеся стороны могли удобно читать основные положения контракта.[4]

С юридической точки зрения использование язык разметки встроенный в прозаический документ, в основном, юридический, приводит к снижению транзакционных издержек, более быстрому разрешению споров, лучшему исполнению и большей прозрачности.[4][5] С вычислительной точки зрения рикардианский контракт - это шаблон разработки программного обеспечения оцифровать документы и обеспечить их участие в финансовых транзакциях, таких как платежи, без потери богатства традиций заключения договоров. Публикация контента и ссылка на него уникальным криптографический дайджест сообщения исключает мошенничество на основе нескольких презентаций.[5]

Этот метод возник из работы Яна Григга, завершенной в середине 1990-х годов над Рикардо.[6] система переводов активов, которая была построена в 1995-1996 гг. компанией Systemics и включала в себя шаблон. Система и образец дизайна были названы в честь Давид Рикардо в честь его плодотворного вклада в теория международной торговли.

Определение

Рикардианский контракт можно определить как единый документ,[1]

а) договор, предлагаемый эмитентом держателям,
б) для ценных прав, принадлежащих держателям и управляемых эмитентом,
в) легко читаемый (как договор на бумаге),
г) читается программами (анализируется как база данных),
д) с цифровой подписью,
f) перенос ключей и информации о сервере, и

g) связаны с уникальным и безопасным идентификатором

Диаграмма

Рикардианский контракт разделяет соглашение сторон во времени и в пространстве. Слева от изображения "Галстук-бабочка"[требуется разъяснение] переговоры и заключение юридически обязывающего контракта приводят к единому родительскому документу, который определяет все намерения этого соглашения. Справа выполнение этого соглашения может включать в себя множество транзакций, которые необходимо учитывать, логически отделенные от смысла проблемы.[7] Соединение между юридическим миром и миром бухгалтерского учета формируется хешем - каждая транзакция фиксирует условия конкретной сделки сторон путем включения хеш-кода контракта в каждую соответствующую запись транзакции, но при этом операция транзакций и выдача контрактов четко отделены, и, таким образом, устранены порочные стимулы.[8]

Схема BowTie рикардианских контрактных элементов и генеративов

Правовые отношения

Роль рикардианского контракта состоит в том, чтобы зафиксировать договорные отношения между договаривающимися сторонами, чтобы способствовать последующему выполнению этого контракта программами.[9] По своей договорной форме это запись предложения эмитента держателю. Предложение подписывается в цифровом формате в формате оферентом, обычно с использованием цифровой подписи в виде открытого текста, например, предоставленной OpenPGP.

Принятие договор обычно формируется путем подписания / согласия на транзакцию, которая относится к хешу этого контракта. В контексте высокопроизводительной платежной системы безопасный платеж будет ссылаться на хэш контракта по инструменту, по которому производится оплата, а также стороны плательщика и получателя, а также количество единиц.[10] В смарт-контракты системы, принятие будет осуществляться путем использования кода контракта, чтобы продвинуть состояние соглашения вперед.

Подписание и намерение

Обычно подписание контракта любой стороной открыто выполняется с использованием закрытого ключа. Подпись исходного оферента обычно находится над исходным документом, а затем добавляется, чтобы сформировать полностью связывающее, читаемое предложение для активов, описанных в документе.[11]

Последующее участие сторон в контракте, такое как платежи или выполнение смарт-контракта, обычно подписывается хеш-идентификатором (генерируемым криптографическая хеш-функция) поверх подписанного оригинала документа. В отличие от первоначальной подписи, использование хеш-кода контракта в последующих транзакциях также сигнализирует о намерениях и формирует скрытую подпись над контрактом. Хотя подписи с закрытым ключом хорошо изучены и подпадают под действие правовых рамок, таких как Европейская директива о цифровой подписи, Григг предполагает, что след хэшей - запутанность - формирует более эффективное свидетельство намерения.[1] чем подпись закрытого ключа.

Шаблон программирования

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

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

Вариации

Если соглашение является более сложным, чем может описать один документ, документы можно связать в цепочку: акцепт предложения может быть рикардианским договором, который включает хэш предложения, или акцепт может включать все содержимое более ранней фазы, узор, известный как русские куклы[12] используется как OpenTransactions, так и OpenBazaar. Эти шаблоны перехода можно использовать несколько раз для создания цепочки или иерархии элементов.

Форматы

Соответствующее решение - выбрать такое представление текста, чтобы разметка может быть включен для помощи программному агенту при сохранении читабельности.[13] Чтобы быть рикардианским контрактом, он должен анализироваться как программой, так и читателем-человеком.[14]

«Читаемость» обязательно определяется относительно некоторого интерфейса просмотра. Встроенные системы разметки, такие как XML, обычно рассматриваются не как «необработанный источник», а с гораздо более богатым форматированием. Юристам не нужно просматривать «сырые» файлы JSON, LaTeX или XML, так же как веб-пользователям необходимо просматривать необработанные изображения HTML или шестнадцатеричные PNG. Некоторые читатели с ослабленным зрением обязательно используют очень разные интерфейсы. Даже редакторы «обычного текста» различаются обработкой [наборов символов] и [кодировок символов], специфичных для ОС концов строк, шрифтов, табуляций, переноса длинных строк и т. Д. Даже простой текстовый редактор можно взломать, чтобы он ошибся. отображать текст желаемым образом, как и любое другое программное обеспечение. Но со стандартными, небинарными представлениями данных внизу пользователи могут сравнивать несколько решений для просмотра, а с текстовыми представлениями, а не с двоичные файлы практично проверять исходный документ напрямую, когда это необходимо (или, как это обычно делается, для одновременного просмотра полностью отформатированного и необработанного представления).

Идеальный формат документа также должен поддерживать каноническая форма хэш (криптографическая хеш-функция), то есть иметь способ доставки хеширования содержимого, которое не изменяется из-за общих сериализация и артефакты передачи. Латекс и XML подходят, потому что их исходный код обычно читается людьми, и у них есть широко доступные средства визуализации. XML также имеет стандартизованный Канонический XML форма, которая специально разработана для облегчения криптографического хеширования и нейтрализует незначительные синтаксические вариации, такие как незначительные пробелы, зависящие от платформы концы строк, порядок атрибутов и т. д.

Популярные форматы, такие как JSON и Семантическая сеть форматы часто, хотя и не всегда, гораздо менее удобочитаемы в необработанном виде для непрограммистов, таких как юристы, и гораздо более подвержены неограниченным синтаксическим, но не семантическим вариациям.[15][9]

Отношение к смарт-контрактам

Смарт-контракты, как это определено в работе Ник Сабо являются абстрактным понятием, относящимся к автоматизированному выполнению уже согласованного контракта,[16] в то время как рикардианский контракт - это шаблон проектирования, отражающий намерения сторон до его исполнения.[17]

С помощью хэшей внутри в качестве ссылок или ссылок на внешние документы, описанная выше, рикардианская форма контракта легко расширяется для ссылки на код.[3][18] Явная ссылка на код может передать легитимность всеобъемлющей юридической прозы коду, тем самым реализуя концепцию смарт-контракта.[19]

Рефакторинг для описания блокчейнов и интеграции ссылок на логику смарт-контрактов создал гибридную версию рикардианского контракта.[18][20] Эта форма предлагает кортеж {проза, параметры, код}, где параметры могут конкретизировать или специализировать юридическую прозу и компьютерный код для создания единой сделки из шаблона или библиотеки компонентов.[3] Также известный как рикардианская тройка, он может описывать блокчейны, смарт-контракты, устройства Интернета вещей и людей.

Реализации

Есть несколько явных существующих реализаций рикардианского шаблона проектирования контрактов, и есть некоторые проекты, которые делают это неявно, а другие движутся в этом направлении.[15]Среди тех, кто явно использует этот шаблон:

ПроектКомментарийРуководитель проекта
РикардоРанняя платежная система, использующая криптографически подписанное дерево транзакций, которая была первой реализацией «тройного учета».[нужна цитата]Ян Григг
Открытые транзакции«Open-Transactions реализует финансовые инструменты в виде рикардианских контрактов, то есть контрактов, которые могут быть поняты людьми, а также ими можно манипулировать с помощью программного обеспечения».[21][неосновной источник необходим]Крис Одом
OpenBazaar"Рикардианский контракт - это средство отслеживания обязанность одной стороны к другой при продаже товаров друг другу в OpenBazaar. По сути, контракт представляет собой отдельную единицу товара или услуги. В OpenBazaar следует использовать рикардианские контракты, поскольку они являются средством эффективного отслеживания законно подписанных соглашений между двумя сторонами, которые нельзя подделать после подписания контракта. В рикардианских контрактах используется цепочка контрактов с цифровой подписью и хэшированием контрольной суммы для создания неизменяемой записи соглашения для обмена в одноранговой сети ».[22] "Сделки в сети OpenBazaar основаны на рикардианских контрактах,[23][24] то есть электронный документ, определяющий условия торговли таким образом, чтобы он был доступен для чтения компьютерам и людям и был подписан криптографически. Помимо продажи физических и цифровых продуктов, OpenBazaar также может использоваться для торговли спекулятивными контрактами, которые легко могут быть представлены рикардианскими контрактами "[14]Вашингтон Санчес
Уценка Monax LegalПозволяет двойную интеграцию смарт-контракт код и прозаический контрактный язык.[нужна цитата]Нина Килбрайд, Кейси Кульман
АскемосРикардианские контракты описываются как овеществление класса Аскемос.[25][неосновной источник необходим]Йорг Виттенбергер
Barclays'Шаблоны смарт-контрактовРикардианские контракты описываются как основа «соглашения, исполнение которого можно автоматизировать и обеспечить принудительное исполнение».[26][неосновной источник необходим]
Более подробная информация в шаблонах смарт-контрактов: основы, ландшафт дизайна и направления исследований[3]		Д-р Ли Брэйн
Корда из R3«в системе, которая, возможно, имела явную цель проектирования - преобладание кода, необходимо иметь более широкий контракт, объясняющий, что происходит в случае, если что-то пойдет не так»[27]Ричард Джендал Браун
LegalThings

Живые контракты

Живой контракт имеет текстовое представление и машинно-интерпретируемое представление в виде конечного автомата. Каждый переход между состояниями должен быть подписан цифровой подписью и впоследствии храниться в контракте, образуя частный блокчейн. Привязка к глобальной цепочке блоков используется для отметки времени и подтверждения существования.[28]Арнольд Дэниэлс
Маттереум«Рикардианский контракт решает вышеупомянутые проблемы. Он берет юридическую прозу юристов или юридически опытного делового человека, включает подпись, а затем хеширует согласованный документ».[29][неосновной источник необходим]Винай Гупта
ChamapesaРасширяет рикардианский контракт до варианта использования, называемого «распределенный рикардианский контракт».[нужна цитата]Ян Григг

Интеллектуальная собственность

Рикардианский контракт свободен от каких-либо ограничений интеллектуальной собственности, кроме требования, чтобы любые реализации цитировали автора и ссылались на статью.[30] Он был полностью опубликован как проект и реализация в 1996 году и был описан в академической статье, представленной в 2004 году. Ни его изобретатель, Ян Григг, ни Systemics никогда не заявляли о патентах или других механизмах интеллектуальной собственности.

Рекомендации

  1. ^ а б c Григг, Ян (2004). «Рикардианский контракт». Материалы первого международного семинара IEEE по электронному контракту. IEEE: 25–31. Дои:10.1109 / WEC.2004.1319505. ISBN 0-7695-2184-3.
  2. ^ "Что такое рикардианский контракт?". Электронный журнал о законе о киберпространстве. Сеть исследований в области социальных наук. 11 декабря 2017. SSRN 3085682.
  3. ^ а б c d Клак, Кристофер Д .; Бакши, Викрам А .; Брейн, Ли (2016). Шаблоны смарт-контрактов: основы, ландшафт дизайна и направления исследований. arXiv:1608.00771.
  4. ^ а б Nagy, Daniel A .; Шакель, Надзея В. (2008). Цудик, Джин (ред.). Финансовые инструменты на основе OpenPGP и арбитраж споров (PDF). Финансовая криптография и безопасность данных. Конспект лекций по информатике. 5 143. Косумель, Мексика: Springer. С. 267–271. Дои:10.1007/978-3-540-85230-8_24. ISBN 978-3-540-85229-2.
  5. ^ а б Надь, Дэниел А. (2006). «О цифровых платежных системах, подобных наличным деньгам». Материалы Международной конференции по электронному бизнесу и телекоммуникациям. Коммуникации в компьютерных и информационных науках. 3: 26–38. Дои:10.1007/978-3-540-75993-5_3. ISBN 978-3-540-75992-8.
  6. ^ Григг, Ян (февраль 2000 г.). Финансовая криптография на 7 уровнях. Труды конференции по финансовой криптографии 2000. LNCS. 1,962. Ангилья, Британская Вест-Индия: Springer Verlag.
  7. ^ Fujimura, Ko; Терада, Масаюки (2002). «Торговля между ненадежными сторонами через систему купонов». В Schmid, Beat; Станоевская-Слабева, Катарина; Tschammer, Volke (ред.). К электронному обществу. Международная федерация обработки информации. 74. Бостон: Спрингер. С. 445–457. Дои:10.1007/0-306-47009-8_32. ISBN 978-0-7923-7529-6.
  8. ^ Франко, Педро (2014). «14.5 Открытые транзакции». Понимание Биткойн: криптография, инженерия и экономика. Джон Вили и сыновья. С. 240–241. ISBN 978-1-119-01916-9.
  9. ^ а б Батлин, Алекс (2016). «Crypto 2.0 Musings - сочетание рикардианских и смарт-контрактов». LinkedIn.
  10. ^ Хауленд, Гэри (1996). «Развитие открытой и гибкой платежной системы». Системность.
  11. ^ Дорье, Николя (10 декабря 2014 г.). «Цветные монеты и рикардианские контракты». Архивировано из оригинал 16 февраля 2015 г.
  12. ^ Одом, Крис (2013). «Образец валютного контракта».
  13. ^ Виттенбергер, Йорг Ф. «Контракты в кошельках A-Coin». МЯЧ. Аскемос.
  14. ^ а б Вернер, Доминик; фон Бомхард, Томас; Шрайер, Ян-Петер; Билджери, Доминик (2016). «Экосистема Биткойн - нарушение, выходящее за рамки финансовых услуг?».
  15. ^ а б «Рикардианские реализации». Webfunds. 2016.
  16. ^ Сабо, Ник (1994). «Смарт-контракты». Архивировано из оригинал 6 марта 2016 г.. Получено 13 июн 2016.
  17. ^ Брандгаард, Пелле (29 июня 2016 г.). «Простое соглашение для понятных человеку терминов для смарт-контрактов». StakeVentures.
  18. ^ а б Григг, Ян (2015). «Сумма всех цепочек - давайте сойдемся». Coinscrum.
  19. ^ Браун, Ричард Джендал; Карлайл, Джеймс; Григг, Ян; Хирн, Майк (2016). "Корда: Введение" (PDF). Архивировано из оригинал (PDF) 6 июня 2017 г.
  20. ^ Григг, Ян (2015). «На пересечении рикардианских и смарт-контрактов».
  21. ^ Одом, Крис (2015). «Открытые транзакции: защищенные контракты между ненадежными сторонами» (PDF).
  22. ^ Санчес, Вашингтон (2014). «Рикардианские контракты на OpenBazaar».
  23. ^ «Ян - Рикардианский контракт». iang.org. Получено 6 июн 2017.
  24. ^ «Рикардианский контракт». iang.org. Получено 6 июн 2017.
  25. ^ «Аскемос».
  26. ^ "Саммит шаблонов смарт-контрактов" (PDF). R3 CEV. 29 июня 2016.
  27. ^ Эллисон, Ян (13 июля 2016 г.). «R3 расширяет сотрудничество с Саммитом шаблонов смарт-контрактов». International Business Times.
  28. ^ Кардон, Дидерик (30 ноября 2017 г.). «Рикардианские контракты - юридически обязывающие соглашения о блокчейне». Середина. Получено 7 января 2018.
  29. ^ Гупта, Винай; Рыцарь, Роб; Бьюкенен, Аэрон; Рэй, Кристофер; Григг, Ян; Кульман, Кейси; Кимпоесу, Михай; Майнелли, Майкл; Фридман, Клайв. «Смарт-контракты, недвижимость» (PDF). Маттереум.
  30. ^ Григг, Ян (2016). «Обеспокоенность ИС по поводу рикардианских контрактов». Финансовая криптография.