Глава 6. Адаптивные контракты

Адаптивные контракты впервые на теоретическом уровне были предложены Ником Сабо в конце 1990- х, однако прошло почти 20 лет, прежде чем их истинный потенциал и выгоды были оценены по достоинству. Адаптивные контракты описываются Сабо следующим образом:

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

Главная мысль адаптивного контракта была реализована неким ограниченным образом биткойном в 2009 году, когда транзакции биткойна были применены для обмена определёнными ценностями между пользователями поверх одноранговой сетевой среды, в которой пользователям не нужно было доверять друг другу в полном объёме и где не было нужды в доверенном посреднике.

Не существует какого бы то ни было согласия относительно стандартного определения адаптивного контракта (smart contract). Тем не менее существенно определить чем является адаптивный контракт и ниже приводится попытка данного автора предоставить обобщённое определение адаптивного контракта.

Дальнейший разбор этого определения показывает, что адаптивный контракт на самом деле является вычислительной программой, написанной на некотором языке, который может понимать этот компьютер или целевая машина. Кроме того, оно содержит соглашения между сторонами в форме бизнес- логики. Другая ключевая идея состоит в том, что адаптивные контракты автоматически выполняются при осуществлении определённых условий. Они подлежат исполнению, что означает, что все договорные условия выполняются как определённые, причём даже при наличии злоумышленников. Принудительное обеспечение соблюдения (enforcement) - это более широкий термин, который охватывает традиционное правоприменение в форме закона, совместно с осуществлением определённых мероприятий и мер контроля, которые позволяют выполнить условия контракта без каких либо посредников. Следует отметить, что настоящие адаптивные контракты не должны основываться на традиционных методах обеспечения их выполнения. Вместо этого они должны работать на основании концепции, согласно которой законом является данный код, а это означает, что нет необходимости в том, чтобы некий арбитр или какое- то третье лицо контролировали данный адаптивный контракт или оказывали воздействие на его исполнение. Адаптивные контракты являются самостоятельно поддерживающимися в противовес закреплённым юридически. Это можно рассматривать как мечты либертарианца, однако это полностью возможно и соответствует истинному духу адаптивных контрактов.

Помимо этого, они являются безопасными и непреклонными, что означает, что такие вычислительные программы необходимо разрабатывать таким образом, чтобы они были устойчивы к отказам и исполнялись в разумные сроки. Эти программы должны иметь возможность исполняться и сопровождаться с жизнеспособным внутренним состоянием даже в том случае, когда этому не благоприятствуют внешние факторы. Например, представим себе, что обычная вычислительная программа, которая закодирована на некоторую логику и исполняется в соответствии с закодированными в ней инструкциями, однако, если та среда, в которой она вынуждена исполняться, или некие внешние факторы, от которых она зависит, отклоняются от обычного или ожидаемого состояния, данная программа может реагировать на это произвольным образом или просто прервать своё исполнение. Важно чтобы данный адаптивный контракт был не восприимчив к таким проблемам.

Безопасность и непреклонность вполне могут рассматриваться как требования или желателная функциональность, однако в долгосрочной перспективе это принесёт большие преимущества, если безопасность и непреклонность с самого начала включены в определение самого адаптивного контракта. Это позволит исследователям с самого начала сосредоточиться на этих сторонах и поможет заложить прочную основу, на которой впоследствии могут базироваться дальнейшие исследования. Со стороны некоторых исследователей также имеется предположение, что адаптивным контрактам не следует исполняться автоматически, а вместо этого они бы могли бы быть тем, что имеет наименование автоматизируемых (automatable), благодаря ручному вводу человеком, требуемым в определённых сценариях. Хотя это и верно, что в некоторых ситуациях желателен контроль со стороны человека, однако это не является абсолютно необходимым; и, чтобы контракт был действительно адаптивным (smart), по мнению данного автора, он должен быть автоматизирован полностью. Определённый ввод, который необходимо производить со стороны человека, может и должен быть также автоматизирован посредством применения Оракулов (Oracles). Более подробно Оракулы будут обсуждены далее в этой главе.

Адаптивные контракты обычно работают посредством управления их внутреннего состояния с использованием некоторой модели машины состояний. Это позволяет разрабатывать некую действенную инфраструктуру для программирования адаптивных контрактов, в которой определённое состояние контракта продвигается далее на основании некоторых предварительно определённых критериев и условий.

Также продолжается обсуждение по вопросу того, является ли код приемлемым в качестве некоего контракта в судебном разбирательстве. Это совершенно отличается представлением от обыкновенного изложения, хотя они на самом деле представляют и обеспечивают соблюдение всех положений договора, однако судебное разбирательство не понимает код. Это порождает ряд вопросов о том, как адаптивный договор может быть юридически обязательным: можно ли разработать его таким образом, чтобы он был приемлем и понятен в судебном разбирательстве? Как можно реализовать оспаривание решения в рамках данного кода и возможно ли это? Более того, регулирующие и соблюдаемые требования являются ещё одним вопросом, который необходимо решить прежде чем адаптивные контракты можно будет применять настолько же действенно, как и обычные юридические документы.

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

Адаптивные контракты в соответствии со своей сущностью должны быть детерминированными от природы. Это свойство позволит адаптивному контракту запускаться любым узлом в сетевой среде и достигать одного и того же результата. Если получаемый результат отличается даже немного, консенсус в этом случае не может быть достигнут и вся парадигма распределённого согласования в блокчейне может претерпеть отказ. Более того, также желательно чтобы сам язык контракта был детерминированным, что обеспечивало бы целостность и стабильность рассматриваемых адаптивных контрактов. Под этим я подразумеваю детерминированность в том смысле, что в данном языке не применяются недетерминированные функции, которые могут приводить к различным результатам на различных узлах. Например, различные операции с плавающей точкой, рассчитываемые различными функциями на разных языках программирования могут приводить к отличающимся результатам в разных средах исполнения. Другой пример заключается в некоторых математических функциях в JavaScript, которые могут производить различные результаты для одного и того же входа в разных браузерах и которые, в свою очередь, могут приводить к разнообразным ошибкам. Это крайне не желательно в адаптивных контрактах, потому что если результаты не согласуются между узлами, то консенсус никогда не будет достигнут. Детерминированная функция гарантирует, что адаптивные контракты всегда выдают одинаковый результат для конкретных входных данных. Другими словами, те программы, которые были скомпилированы, создают прочную и точную бизнес- логику, которая полностью соответствует требованиям, которые запрограммированы в коде высокого уровня.

В сумме адаптивный контракт имеет четыре таких свойства:

Первые два свойства необходимы в качестве какого- то минимума, в то время как последние два могут не требоваться или реализовываться при определённых сценариях и могут быть ослаблены. Например, некий производный контракт, возможно, не должен иметь полную семантическую согласованность и непреклонность, однако должен по крайней мере иметь автоматическую исполняемость и подлежать обязательному исполнению на некотором основном уровне. С другой стороны, некий свод законов должен быть полностью семантически согласованным и завершённым, следовательно, чтобы он был реализован в виде адаптивного контракта, его язык должен пониматься как компьютерами, так и людьми. Этот вопрос интерпретации был рассмотрен Яном Григгом в его изобретении Рикардианских контрактов, которые мы рассмотрим более подробно в следующем разделе.

Рикардианские контракты первоначально были предложены в статье Яна Григга Financial Cryptography in 7 Layers в конце 1990-х. Эти контракты изначально были применены для торговли облигациями и платёжная система имела название Ricardo. Основная мысль состояла в написании некоего документа, который был бы понятен обоим направлениям, и судебному разбирательству, и программному обеспечению. Рикардианские контракты призваны решить вызов публикации стоимости в Итернете. Они идентифицируют эмитента и фиксируют все условия и положения контракта в некотором документе чтобы сделать его приемлемым в качечестве непреложного юридического договора.

Отталкиваясь от первоначального определения Яна Григга в http://iang.org/papers/ricardian_contract.html, Рикардианский контракт является документом, который имеет ряд следующих свойств:

На практике контракты реализуются путём создания единого документа, который содержит условия контракта в виде юридического текста и необходимых читаемых компьютером тегов. Этот документ подписывается цифровой подписью эмитентом с имползованием его частного (закрытого, private) ключа. Этот документ затем хэшируется с помощью сообщения функции свёртки для создания некоего хэша, с помощью которого можно идентифицировать этот документ. Данный хэш затем использутся сторонами и подписывается ими во время исполнения данного контракта чтобы связать каждую транзакцию с определённым хэш- идентификатором, который, тем самым, служит доказательством намерений. Это показывается на схеме ниже, обечно именуемой моделью bowtie (узла с двумя петлями).

Приводимая ниже схема отображает с левой стороны Мир закона (World of Law), из которого и происходит данный документ. Он после этого хэшируется и полученные в результате цифровые сообщения используются как некий идентификатор в имеющемся Мире бухгалтерского учёта (World of Accountancy). Такой Мир бухгалтерского учёта может быть в основном представлен любыми, причём разнообразными системами ведения учётных записей, торговли и информации, которые применяются в делах для выполнения разнообразных бизнес операций. Основная идея данного потока состоит в том, что такие создаваемые хэшированием документа сообщения сёрток вначале применяются в так называемой порождающей транзакции (genesis transaction), а затем используются во всех тразакциях как идентификаторы во время конкретного очередного исполнения транзакции.

Тем самым между таким первоначально подписанным контрактом и всеми транзакциями в имеющемся Мире бухгалтерского учёта создаётся некая безопасная связь.

Рикардианские контракты отличаются от адаптивных контрактов в том смысле, что некий адаптивный контракт не содержит какого либо смыслового документа и полностью сосредоточены на самом исполнении данного контракта. Некий Рикардианский контракт с другой стороны, более сосредоточен на имеющемся семантическом богатстве и выработке некего документа, который содержит юридический текст контракта. Такое смысловое содержание некоторого контракта может быть разделено на два типа: семантику операции и денотационную семантику. Первый тип определяет реальное исполнение, верность и безопасность данного контракта, а вторая сосредоточена вокруг понятий реального мира всего рассматриваемого контракта. Некоторые исследователи различают код адаптивного контракта и адаптивный юридический контракт, заключающееся в том, что некий адаптивный контракт состоит только в самом исполнении данного контракта, а второй тип содержит как само содержание условий, так и семантику исполнения некоторого юридического соглашения. Возможно, имеется некий смысл классифицировать адаптивные контракты (smart contracts) на основе разницы между семантиками, однако лучше рассматривать адаптивные контракты как некие автономные объекты, которые способны кодировать в нём юридический текст и код (бизнес логику).

В случае биткойна может быть рассматрена очень простая реализация адаптивного контракта, которая полностью ориентирована на само исполнение рассматриваемого контракта, в то время как Рикардианский контракт более сцеплен с созданием некоторого понимаемого человеком документа с какими- то частями, которые может понимать вычислительная программа. Это можно рассматривать как сопоставление юридической семантики с выполнением операций (семантика против выполнения), что отображается на приводимой далее схеме. Она первоначально была предложена Яном Григгом в его статье On the intersection of Ricardian and smart contracts.

Некий адаптивный контракт создаётся для того чтобы иметь оба этих элемента (исполнение и смысловую часть) встроенными совместно, что составляет идеальную модель адаптивного контракта.

Какой- то Рикардианский контракт может быть представлен в качествые кортежа из трёх объектов, а именно, Текста (Italic), параметров и кода. Текст представляет собой сам юридический контракт на обычном языке; код выступает в роли определённой программы, которая имеет понимаемое компьютером представление юридического текста; а параметры соединяют все соответствующие части имеющегося юридического контракта с его эквивалентами кода.

Рикардианские контракты были раелизованы во множестве систем, например, CommonAccord, OpenBazaar, OpenAssets и Askemos.

Адаптивные контракты можно реализовать во всех отраслях в которых они нужны, однако самые последние варианты применения связаны с финансовой сферой. Псоледние работы в пространстве адаптивных контрактов, относящихся к финансовой отрасли предложили понятие шаблонов адаптивных контрактов. Основная идея состоит в построении стандартных шаблонов, которые предоставляют некую инфраструкутуру для поддержки юридической аргументации финансовых инструментов. Именно это было предложено Кларком с соавторами в их статье Smart Contract Templates: Foundations, design landscape and research directions. Эта работа также предложила необходимость построения соответствующих этой области языков для поддержки проектирования и реализации шаблонов адаптивных контрактов. Был предложен и начал разрабатываться язык с названием CLACK, некий язык для расширенных знаний о контрактах. Представляется, что этот язык должен быть очень насыщенным и предоставлять широкое разнообразие диапазона функций для поддержки юридических текстов чтобы иметь возможность исполняться на различных платформах, а также функций криптографии.

Контракты в существующей финансовой сфере теперь не являются каким- то новым понятием и доступны различные предметно- ориентированные языки DSL (domain-specific language), которые поддерживают разработку продуктов страхования, представляют собой энергетические деривиативы или применяются для построения рыночных стратегий. Этот перечень можно продолжить, а исчерпывающий список предметных языков финансовой сферы можно найти по ссылке http://www.dslfin.org/resources.html.

Важно осознать основное понятие предметно- ориентированных языков. Эти языки разрабатываются с ограниченной выразительностью для определённой области интересов. Предметно- ориентированные языки (DSL, Domain-specific languages), отличаются от Языков программирования общего назначения (GPL general-purpose programming languages): DSL имеют ограниченную функциональность, которая является достаточной и оптимизированы для той отрасли, для применения в которой они и предназначены. и, в отличии от GPL, обычно не предназначаются для построения больших прикладных программ общего назначения. Отталкиваясь от такой философии проектирования DSL можно рассчитывать, что такие языки могут быть специально разработаны для написания адаптивных контрактов. Определённая работа уже проделана и Solidity является одним из подобных языков, разработанных блокчейном Эфириум для написания адаптивных контрактов. Serpent является ещё одним языком, введённым Эфириумом, хотя он и применяется не столь интенсивно как Solidity.

Данная концепция предметно- ориентированных языков для адаптивных контрактов может быть дополнительно расширена до графического предметно- ориентироанного языка, некоторой платформы моделирования адаптивных контрактов, в еоторой эксперты некоторой предметной отрасли (не программисты) могут применять какой- то графический интерфейс и полотно для определения и отражения необходимых семантических правил и исполнения финансового контракта. После того как данный поток отображён и завершён, он может быть смоделирован вначале для тестирования, а затем и для развёртывания в той же системе, что и целевая платформа, которая может бвть неким блокчейном. Это также не является неким новым подходом и аналогичный подход применяется в продукте на основе потоков Tibco, который является системой на основе Java, применяемой для построения управляемых высокочастотными событиями торговых систем.

Предполагается, что следует также проводить исследования в области разработки DSL высокого уровня, которые смогут применяться для программирования адаптивного контракта с удобным для пользователя графическим интерфейсом, что позволит разрабатывать адаптивный контракт не программистам.

Оракулы являются некоторой важной составляющей во всей экосистеме адаптивных контрактов. Основное ограничение для адаптивных контрактов состоит в том, что они не могут иметь доступа к внешним данным, которые могут быть необходимы для управленимя их исполнением в данной бизнес логике; например, конкретная рыночная стоимость ценной бумаги, которая необходима по данному контракту для выпуска определённых выплат дивидендов. Для предоставления внешних данных в адаптивные контракты могут применяться Оракулы. Некий Оракул является каким- то интерфейсом, который доставляет данные из внешнего источника в адаптивные контракты. В зависимости от рассматриваемой отрасли и необходимых требований Оракулы могут доставлять различные типы данных в диапазоне из сводок о погоде, новостей реального мира, а также корпоративных акций вплоть до данных, поступающих от устройств IoT (Internet of Things, Интернета вещей). Оракулы являются облечёнными доверием сущностями, которые применяют какой- то безопасный канал для обмена данными с неким адаптивным контрактом.

Оракулы также обладают способностью осуществления цифровой подписи тех данных, которые являются аутентичными для источника их информации. Адаптивные контракты могут затем осуществлять подписку на таких Оракулов и эти адаптивные контракты могут либо сами осуществлять активную доставку необходимых данных (pull), либо её выполняют Оракулы (push) в эти адаптивные контракты. Также необходимо, чтобы такие Оракулы не имели возможности манипулировать теми данными, которые они предоставляют и должны быть способны предоставлять аутентичные данные. Даже хотя Оракулы являются обличёнными доверием, может так случаться, что всё ещё имеется возможность в некоторых случаях что их данные являются ошибочными из- за операций. Следовательно, необходимо чтобы Оракулы были не в состоянии изменять эти данные. Проверка этого может быть предоставлена с применением различных схем заверения, обсуждаемых далее в этой главе. При таком подходе можно обнаружить некую проблему, наличие которай, скорее всего, нежелательно в ряде случаев, а именно, проблема доверия. Насколько вы доверяете третьей стороне относительно качества и подлинности тех данных, которые они предоставляют? Это в особенности справедливо в финансовом мире, в котором данные рынка должны быть точными и надёжными. Для проектировщика адаптивного контракта может быть приемлемым принимать данные какого- то Оракуоа, которые предоставляются третьей стороной с большой положительной репутацией, однако основная проблема централизации всё ещё остаётся. Эти виды оракулов именуются стандартными или простыми Оракулами.

Другой вид оракулов, который в сущности и появился из- за требований децентрализации, можно называть распределёнными (децентрализованными) Оракулами. Такие виды Оракулов могут строиться на основании некоторого механизма распределения. Можно также предусмотреть, чтобы Оракулы сами имели возможность получать в качестве источника данные от другого блокчейна, который определяется распределённым согласованием, что тем самым обеспечит необходимую достоверность данных. Например, одно учреждение, в котором действует свой собственный частный блокчейн, может публиковать свои поставки (feed) данных через какого- то Оракула, который затем может потребляться другими блокчейнами.

Другой подход аппаратных Оракулов также вводится исследователями, которым требуются данные реального мира от физических устройств. Например, это может применяться в телеметрии и IoT. Однако такой подход требует некоего механизма, при котором аппаратные устройства не могут быть повреждены. Этого можно достичь применяя защищённые от внешнего воздействия устройствва.

Сейчас существуют платформы, которые позволяют некому адаптивному контракту получать внешние данные с применением Оракула. Имеются различные методы, применяемые неким Оракулом для записи данных в имеющийся блокчейн в зависимости от применяемого вида блокчейна. Например, в блокчейне Биткойн некий Оракул может записывать данные в определённую транзакцию с помощью кода операции OP_RETURN и какой- то Оракул может отслеживать такую транзакцию и считывать получаемые данные. Доступны различные Интернет- службы, ьтакие как http://www.oraclize.it/ и https://www.realitykeys.com/, которые предоставляют службы оракулов. Кроме того, доступна другая служба, https://smartcontract.com/, которая предоставляет внешние данные и наличие возможности оплаты при помощи адаптивных контрактов. Основная цель всех этих служб состоит в том чтобы сделать возможным для определённых адаптивных контрактов получать те данные, которы им требуются для исполнения и принятия решений. Чтобы подтверждать достоверность тех данных, которые извлекаются конкретным Оракулом из внешних источников, может применяться механизм такой как TLSnotary, который предоставляет доказательство взаимодействия между определённым источником и данным Оракулом. Это гарантирует, что те данные, которые будут возвращены в рассматриваемый адаптивный контракт несомненно получены из необходимого источника. Дополнительные подробности о TLSnotary можно найти на https://tlsnotary.org/.

Приводимая далее схема отображает некую общую модель экосистемы каких- то Оракула и адаптивного контракта:

Помимо всего прочего, Codius была предложена идея Адаптивного Оракула (Smart Oracle). Адаптивные Оракулы в основном являются сущностями, во многом схожими с Оракулами, однако с добавлением возможности исполнения кода контракта. Предлагаемые Codius Адаптивные Оракулы исполняются с примененем Google Native Client, который является средой песочницы для исполнения естественного кода x86 без наличия удостоверения. Codius доступен на https://www.codius.org/.

Адаптивные контракты могут быть развёрнуты в некий блокчейн, а могут быть развёрнуты и без него, однако имеет смысл развёртывать их именно в некоем блокчейне из- за определённого механизма распределённого согласия, который предоставляется блокчейном. Эфириум является примером блокчейна, который естественным образомподдерживает саму разработку и разработку адаптивных контрактов. Адаптивные контракты в блокчейне Эфириум обычно являются частью юолее крупного приложения, такого как DAO (Decentralized Autonomous organization, Децентрализованная автономная организация).

В качестве сравнения, в блокчейне Биткойн имеющееся поле lock_time может рассматриваться как некий разрешающий параметр какой- то базовой версии адаптивного контракта. Данное поле lock_time делает возможной блокировку какой- то транзакции до тех пор, пока не истечёт предписанное время, либо после некоторого числа блокирований, что тем самым допуская принудительное выполнение удаления такой блокировки определённой транзакции основного контракта при определённых обстоятельствах (истечение времени или превышение числа блокировок). Однако это очень ограничивает его поведение и должно рассматриваться только как некий пример какого- то базового адаптивного контракта. Помимо упомянутого выше примера, язык сценариев Биткойн, хотя и ограниченно, может применяться для построения базовых адаптивных контрактов. Одна из возможностей состоит в том, чтобы поддерживать некий адрес биткойна, который может расходоваться любым, кто демонстрирует атаки хэш конфликта. Данная идея была представлена на Форуме Биткойна и дополнительную информацию можно отыскать на https://bitcointalk.org/index.php?topic=293382.0. Это также можно рассматривать как некий базовый вид адаптивного контракта.

DAO является одним из самых крупных краудфандинговых проектов, который был запущен в Апреле 2016. Он был в основном набором адаптивных контрактов, написанных чтобы предоставить неую платформу для инвестиций. Из- за ошибки в коде он был взломан в июне 2016 и эквивалент в 50 миллионов долларов был откачан из этого DAO в другую учётную запись. Это в результате привело к некой жёсткой развилке в Эфириуме с тем, чтобы выполнить восстановление поле данной атаки. Следует отметить, что такое понятие как код является законом, или непреклонные адаптивные контракты, должны рассматриваться с некоторой долей скептицизма, поскольку реализация этих концепций пока ещё недостаточно зрелая, чтобы обеспечить полное и несомненное доверие. Это очевидно из последних событий, когда фонд Эфириум оказался способным остановить и изменить исполнение The DAO введя некую жёсткую развилку. Хотя эта жёсткая развилка и была введена из- за естественной потребности, она идёт вразрез с истинным духом децентрализации и понятию код является законом. С другой стороны, противостояние этой жёсткой развилке и некоторые майнеры, которые приняли решение оставаться добытчиками в их первоначальной цепочке привели к созданию Классического Эфириума. Именно он является тем первоначальным, не ответвишимся блокчейном Эфириум, в котором код всё ещё является законом.

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

Дананая глава началась с истории адаптивных контрактов, и проследовала скозь подробное обсуждение самого определения адаптивного контракта. Поскольку не существует какого- то согласия о стандартном определении адаптивного контракта, мы попытались ввести некое определение, которое вберёт в себя всю соль адаптивных контрактов. Также было предоставлено введение в Рекардианские контракты, а также была объяснена разница между Рекардианскими контрактами и адаптивными контрактами, причём с упором на тот факт, что Рекардианские контракты сосредотачиваются на сомом определении данного контракта, в то время как адаптивные контракты редуцируют с имеющимся реальным выполнением такого контракта. Бало обсуждено понятие шаблонов адаптивного контракта, согласно которой в настоящее время в академических кругах и в промышленности в настоящее время ведутся высококлассные исследования. Также обсуждались некоторые соображения о возможности создания проблемно- ориентированных языков высокого уровня для создания адаптивных контрактов или шаблонов адаптивных контрактов. В последних разделах данной главы было введено понятие Оракулов с последующим кратким обсуждением проблем DAO и безопасности в DAO и адаптивных контрактах.