Вступление
Перед вами разделенный на несколько частей мысленный эксперимент, призванный выяснить, как Блокчейн-конституцию наподобие предложения EOS можно сделать полноценным Рикардианским Контрактом. Это не так сложно, как кажется, и к тому же может принести неожиданную пользу.
В качестве краткого введения поясню: Рикардианский контракт – это текстовой или юридический контракт, содержащий распознаваемую компьютером разметку. В первую очередь это документ, предназначенный для чтения людьми, и только потом это машиночитаемый документ.
Акцент сделан на людей, поскольку с ними возникает больше сложностей. Контракт становится таковым благодаря наличию намерения, о котором люди должны не просто знать, но и понимать его, чтобы иметь возможность заключить юридическое соглашение, которое любой (управляемый людьми) суд примет в качестве законного контракта. Установление конкретного намерения настолько важно, что зачастую мы устраиваем вокруг него церемонию, хорошо известную людям и судам как подписание.
Этот человеческий фактор оказывается очень большой проблемой для цифровой обработки, в то время как заставить компьютер понимать документ не составляет труда – всего лишь надо добавить разметку. По мере чтения помните о порядке – сначала люди, потом компьютеры.
Часть 1. Рикардианская разбивка
Что ж, давайте начнем! Возьмем текст Конституции и добавим разметку. В качестве образца берем пункт из примерной версии Конституции, которая может быть или не быть полезной для EOS:
СТАТЬЯ 3 - Валюта
Настоящим Сообщество создает валюту, известную как EXAMPLE, владение которой является свидетельством внесения вклада в сообщество. Количество EXAMPLE должно увеличиваться не более чем на 5% в год после распространения первого 1 млрд EXAMPLE.
Обратите внимание, что автор этой статьи (@dantheman) рассчитывает, что другие будут использовать этот экземпляр, намекая, что можно заменить EXAMPLE на МойКоин, или ТвойКоин, или БобКоин, или нечто подобное. Несмотря на трудоемкость, крайне важно сделать эту статью адаптированной к разным контекстам – и здесь сокрыт самый спорный момент: мы намерены сохранить точность соответствующего контракта, но хотели бы, чтобы работу по редактированию и презентации выполнил компьютер, который учел бы приведенные выше шаблоны и превратил его в финализированный контракт, пригодный для использования в том или ином конкретном контексте блокчейна.
А также мы хотим дать людям (и компьютеру) возможность без труда интерпретировать результаты.
Формальный контракт
Чтобы создать и исполнить наш формальный контракт, давайте добавим некоторую разметку и некоторые параметры в те места, которые могут различаться в разном контексте. Мы уже видели, что одним из таких параметров является название монеты, и мы можем также добавить к нему общую сумму начальной эмиссии, а также скорость и уровень инфляции после первоначального выпуска; все это в значительной степени зависит от контекста, в котором заключается контракт:
Статья 3 – Валюта
ИМЯМОНЕТЫ = IangBux
ИНФЛЯЦИЯ = 5%
НАЧАЛЬНАЯЭМИССИЯ = 1 000 000 000
Сообщество настоящим создает валюту, известную как ИМЯМОНЕТЫ, владение которой является свидетельством внесенного в сообщество вклада. Количество ИМЯМОНЕТЫ должно увеличиваться не более, чем на ИНФЛЯЦИЯ в год после распределения первой НАЧАЛЬНОЙЭМИССИИ ИМЯМОНЕТЫ.
В графическом редакторе контрактов мы можем обработать этот сухой документ так, чтобы в итоге отображался текст контракта, выведенный из вышеуказанной информации.
Вы можете себе представить, как при наведении курсора на эти выделенные цветом части высвечивается оригинальное название, которое было заменено. Или мы можем иметь режим для отслеживания переменных при помощи цветов и выделения, как в используемой программистами интегрированной среде разработки (IDE):
Часы веселья!
Но здесь очень важно осознавать один момент. Мы не хотим слишком много веселья. Дело в том, что слишком много веселья с графикой и фокусов с инструментами, FLASH и всплывающими окнами, а также специальные предложения и прочие мерзопакости делают все труднее и труднее жизнь главных действующих лиц этой системы – пользователей. Как сказал Эйнштейн, система должна быть настолько простой, насколько это возможно, но не проще!
Задавайте свои переменные во имя победы контракта!
Выше мы отделили параметры от текста. Примечательно, что эта идея является выигрышной как в виде правового изложения, так и в компьютерном коде. В сфере юриспруденции она известна как шаблонизация контракта и позволяет использовать один шаблон контракта для множества участвующих сторон – большая экономия на юридических сборах. Больше информации о шаблонизации вы сможете найти здесь.
Кодеры, предварительное описание ваших переменных помогает программисту предельно ясно понимать намерение. А также оно позволяет компилятору оказывать вам помощь в следовании этому намерению, например, путем идентификации того, что все параметры назначены верно. В обоих случаях это делает продукт более легким для прочтения другими профессионалами, а поддержание его в рабочем состоянии становится проще и дешевле.
Чуть более продвинутая Разметка
Тем не менее, вышеприведенный пример несколько труден для кодинга – что будет, если мы захотим написать такой акроним, как ИМЯМОНЕТЫ или СТАТЬЯ? И что делать, если мы захотим выделить жирным шрифтом (верхним регистром) предупреждение об инфляции?
Обычно в таком случае мы рекомендуем использовать в тексте простую разметку. Вот пример, где JSON-подобный формат используется для установки параметров, а гибрид – для распределения значений.
Статья 3 – Валюта
{
“ИМЯМОНЕТЫ”: “IangBux”,
“ИНФЛЯЦИЯ”: “5%”,
“НАЧАЛЬНАЯЭМИССИЯ”: “1 000 000 000”
“СИМВОЛ”: “$”
“ДРОБНОСТЬ”: “2”
}
Сообщество настоящим создает валюту, известную как {ИМЯМОНЕТЫ}, владение которой является свидетельством внесенного в сообщество вклада. Количество {ИМЯМОНЕТЫ} должно увеличиваться не более, чем на {ИНФЛЯЦИЯ} в год после распределения первой {НАЧАЛЬНОЙЭМИССИИ} {ИМЯМОНЕТЫ}.
Это исходный текст, которому требуется небольшое дополнение. Теперь синтаксический разбор этого фрагмента довольно прост:
- Просканируйте и извлеките все части JSON, чтобы установить внутренние переменные. Проще говоря, блоки JSON должны быть обозначены фигурными скобками, каждое открытие и закрытие на одной строке, как обычно.
- Останется текст, который нужно проверить на наличие парных фигурных скобок, удерживая параметры для замены. В данном контексте фигурные скобки надежны, потому что текстовому контракту нет нужды их использовать (я надеюсь!), что делает их доступными для простого разбора.
- Можете свободно добавить цвет или мягкое форматирование для подчеркивания смарт-активности.
Это довольно просто, но не так просто, как предыдущие способы организации данных. JSON хорош для параметров, но плох для читабельного текста; текстовые описания безнадежны для параметров, хотя и обладают хорошей читабельностью.
Как можно проще, но не более того
Комбинирование текстовой информации и параметров создает простой, читаемый и компьютером, и человеком контракт, который теперь можно изменять и использовать в разных контекстах. Наша основная цель остается прежней – контракт не более сложен для прочтения человеком, чем оригинальный текст; остальные случаи нечитабельности возникают, по всей видимости, из оригинального текста, но юристы должны помочь нам корректно составить контракты на доступном языке (пожалуйста!).
Финальным проектом для учебной группы по защите сделал упражнение “построй/сломай/почини”. Урок: парсинг гораздо сложнее, чем вы думаете, даже если вы уже в курсе, что парсинг – это гораздо сложнее, чем вы думаете.
Безусловно, мы могли бы использовать любое количество форматов. В прошлом я использовал формат INI. Вы можете использовать и LaTeX или XML, но в этом посте я не стану так над вами издеваться! Смысл в том, чтобы помнить: а) цель этого – во-первых, прежде всего и всегда – сделать текст читабельным для людей, особенно для тех, кто не сильно разбирается в коде и технике, и б) сохранить его как можно более простым, но не более того ;-)
После изложения основной идеи о том как, мой следующий пост будет кратким рассуждением на тему почему закрепление документа столь важно в контексте серьезных цифровых транзакций, а уже затем я вернусь к Конституции.
Заключительные слова: в качестве материала для дальнейшего чтения обратите внимание на оригинальный документ Рикардианского контракта. Документ Кристофера Клэка Smart Contract Templates: foundations, design landscape and research directions наглядно отображает текущий вектор мысли. Самые передовые мысли на тему замечены мной здесь – Common Accord. Чтобы узнать больше о смарт-контрактах и объективизации блокчейн-контрактов смотрите The Sum of all Chains, однако эти материалы отправят вас вслед за Алисой вниз по кроличьей норе.
Оригинал поста: ЗДЕСЬ
Если вам нравится то, что мы делаем - поддержите witness blockchained на Steem!
Nic post.
Автор рассказал про JSON и его парсинг. Как-то непонятно, что он хотел этим сказать. Что контракты в блокчейне не могут хранится в виде привычного текста и должны как-то быть отформатированы понятным компьютерам образом? Вроде это итак очевидно.
Ссылка "Рикардианские контракты" ( http://iang.org/papers/ricardian_contract.htm - 404 Not Found) не работает. В оригинале тоже.
http://iang.org/ricardian/