В предыдущем посте я описал то, что требуется для создания документа, который бы являлся одинаково удобным для чтения как людьми, так и машинами, мог выступить в качестве юридического контракта и также был достаточно подходящим для поддержки криптовалютной финансовой модели. Теперь, когда у нас есть контракт, который могут прочитать и согласовать как компьютер, так и человек, нам остается лишь научить его взаимодействию.
Большинство текстовых контрактов пишутся, отправляются по электронной почте, обсуждаются, корректируются и искажаются, чтобы, наконец, быть подписанными и потом лечь на дальнюю полку, чтобы стать забытыми. Все это, возможно, является странным отношением к предмету столь близкому к самой сути бизнеса и деловых соглашений.
Но с цифровым контрактом все иначе! Поскольку мы добавили в контракт ключевые параметры, делающие его специальным, теперь он может использоваться в качестве транзакции: чтобы сообщать, что является предметом платежа, обмена или другого вида сделки.
Для этого мы используем криптографический трюк с хешированием. Мы берем хеш (“криптографический профиль сообщения”) вышеупомянутого документа и вставляем его во все транзакции, которые ссылаются на этот контракт. Это означает, что транзакции в некотором смысле “знают” о контракте.
К примеру, если транзакция была долларовым платежом Алисы Бобу, то в контракте будут описаны доллары. Чтобы понять, как это работает, взгляните на данный платеж:
{Alice, Bob, 100, dollars}
Быть может, эта запись способна описать транзакцию в ряде контекстов, но в реальном мире она недостаточно хороша – я могу отправить вам гонконгские доллары, а вы, возможно, ожидаете сингапурские доллары. Упс! Кроме того, означает ли эта цифра 100 в записи 100 долларов или 1,00 доллар, который равен 100 центам, или же 100 сатоши, которые могут стоить около 0,000001 доллара каждый?
Компьютер не может этого знать, а уж если компьютер, являющийся вашим цифровым ангелом, не может знать, то и вы не можете знать тоже. Ну да, базы данных и всё такое, но они являются приманками для инсайдерских махинаций, вирусов и прочих ужасов. Если бы базы данных умели осуществлять платежи, блокчейн не был бы изобретен.
А теперь давайте посмотрим, как это делается на рикардианский манер. Я плачу вам:
{Alice, Bob, 10000, ABC1234IANG66DOLLAR911911HASH}
На самом деле, этот пример еще менее понятен, чем предыдущий. И это в своем роде преимущество, поскольку теперь вашему клиентскому ПО придется разрешить для вас эту проблему дефицита информации.
Получается вот что. Ваше клиентское ПО, ваш цифровой ангел, должно произвести это монструозное хеширование ABC1234IANG66DOLLAR911911HASH и найти документ, соответствующий данному хешу.
Там где есть один хеш – есть только один документ, и этот документ самостоятельно доказывает, что он является соответствующим хешу, так что никакого скама! И если предположить, что документ является контрактом, как описано в предыдущем посте на эту тему, то мы можем извлечь из него ряд простых параметров. Благодаря тому, что эти параметры легко восстанавливаются с помощью описанных выше методов разметки, ваш цифровой ангел теперь может сказать вам примерно следующее:
Боб, Алиса заплатила тебе 100.00 Iang-баксов. Нам известна эта валюта, она нам и раньше нравилась. Теперь твой баланс составляет $120.00 и план твоих сбережений в норме!
Весь контекст контракта теперь находится в руках клиентского ПО, попадая туда сразу и без путаницы.
Почему контракты необходимо оцифровывать
Это становится очевидным в любой крупномасштабной структуре. Контракт свопа от ISDA (Международной ассоциации свопов и деривативов) может насчитывать до 300 страниц, он способен забить полки и убить часы времени. Однако оцифровка позволяет полкам оставаться свободными, а нам дает быстрый и стабильный доступ ко всем данным контракта с повторяющимися значениями!
Перманентность также является большой победой – если вы знакомы с теми, кому больше 70 лет, спросите их, какой валютный контракт был их любимым, и они начнут рассказывать истории о чем-нибудь вроде золотого окна или о том, как банк обещал заплатить предъявителю 1 фунт стерлингового серебра. К несчастью для Банка Англии и Федеральной резервной системы, в те времена криптография была для них недоступна, и они не могли зафиксировать свои контракты с помощью хеширования. Без такой опции контракты неизбежно ускользнули в небытие, оставив нам только легенды.
Что такое контракт для доллара США сегодня? Если бы он имел рикардианскую форму, то вы бы могли сказать точно. Но поскольку это не так, “контракт” является немногим более, чем обычный маркетинговый слоган, который меняется каждый раз, когда ФРС нужно освежить бренд.
Бренды полезны, а государство может выйти сухим из воды с одним только брендом. Но в открытом контрактном пространстве блокчейна нам нужна контрактная определенность для цифровых эмиссий, и не в последнюю очередь потому, что их существует так много – ERC-20! ICO! И это всё мягкие условия, поскольку в наши дни трудно сказать, что каждое из них означает в точности. Используя же упомянутый в предыдущем посте подход, мы достигаем значительной точности, будь то текст для юридических контрактов, параметры для варьируемости или хеш для фиксирования точности в системе учета.
(Маленькое примечание – концепция {текст, параметры и код} дополнительно описана в статье Sum of all Chains, но это слишком много для одного поста.)
Рикардианская Конституция
Если контракт станет конституцией блокчейна, это будет полезно тем, что код блокчейна сможет извлекать параметры напрямую. Чейн может следить за уровнем инфляции, просто читая то, о чем пользователи договорились в конституции. Затем код будет следовать примеру из конституции и извлекать число напрямую – и никакого хардкодинга, никакой дубликации, никакого громоздкого выравнивания кода с текстом.
Хеш Конституции может также фигурировать в ключевых инструкциях и таким образом означать – в силу обычая – что инициатор этой сделки соглашается с Конституцией. Например, если инструкция CREATE-NEW-ACCOUNT включает в себя хеш, то он приписывает этот аккаунт к Конституции, что, в свою очередь, определяет Сообщество: это все те, чьи аккаунты связаны одной Конституцией и состоят в едином Сообществе.
В итоге использование рикардианской формы дает блокчейн-сообществу ряд определенных преимуществ:
1 Хеш-механизм исключает неопределенность относительно того, о каком документе мы говорим, и устраняет большое количество путаницы:
- При выборе своей конституции сообщество голосует за хеш этой конституции, указывающий на точный документ
- Транзакции в блокчейне хешируются, поэтому они привязаны к правильному и действующему документу
2 Текст контракта означает, что мы можем использовать все устоявшиеся традиции права для выражения желаемого соглашения и в случае необходимости объяснить и интерпретировать его. Все это устраняет множество неопределенностей и делает наш бизнес намного прозрачнее.
- Обратите внимание, способ создания документа не меняется – вы можете использовать юристов для подготовки контракта, а можете написать его самостоятельно.
- Вне зависимости от выбранного метода предпочтение отдается простому письму!
3 Параметры означают, что мы можем не только разметить ключевые пункты для читателя, но также сообщить о них компьютеру.
- Название, начальное количество и инфляция теперь являются параметрами нашего контракта, который выделяет их цветом, делая доступными для прочтения человеком, а также снабжает ими программу для прочтения компьютером.
- Параметры отображения позволяют программе обрабатывать символы и десятичные знаки всех форм.
4 Теперь альтернативным чейнам относительно легко создать новое деловое предложение. Параметры указывают на изменения, которые необходимо произвести при запуске собственного чейна.
5 Только один документ является истинным
- Больше никаких отдельных файлов с параметрами и никакой дискоординации
- И больше никакого хардкодинга!
Оригинал поста: ЗДЕСЬ
Если вам нравится то, что мы делаем - поддержите witness blockchained на Steem!
