Умные контракты и чейнкод¶
Целевая аудитория: архитекторы, разработчики приложений и умных контрактов, администраторы
С точки зрения разработчика приложений умные контракт вместе с реестром являются основой блокчейн-сети Hyperledger Fabric. В то время как реестр хранит факты о текущем и прошлых состояниях набора бизнес-объектов, умный контракт определяет исполняемую логику, согласно которой генерируются новые факты для добавления в реестр. Чейнкод обычно используется администраторами для объединения связанных смарт-контрактов перед развертыванием, но также может использоваться для низкоуровневого системного программирования сети Fabric. В этом разделе рассматривается важность умных контрактов и чейнкода, а также случаи и способы их применения.
В этой статье:
Умные контракты¶
Для возможности совершения транзакций, организации сперва должны определить общий набор контрактов, охватывающих общие условия, данные, правила, определения концепций и процессы. В совокупности эти контракты определяют бизнес-модель, которая регулирует все взаимодействия между сторонами.
В исполняемом коде умного контракта содержатся правила взаимодействия различных организаций. Приложения вызывают умные контракты для создания транзакций, которые далее записываются в реестр.
В блокчейн-сети эти контракты превращаются в исполняемые программы, известные как умные контракты, которые открывают широкий спектр новых возможностей. Так, умные контракты могут реализовывать правила управления любым типом бизнес-объектов, которые автоматически применятся при выполнении умного контракта. Например, умный контракт может гарантировать, что доставка нового автомобиля будет произведена в указанные сроки или что средства будут высвобождены в соответствии с заранее оговоренными условиями, улучшая потоки товаров или капитала. Однако наиболее важно то, что выполнение умного контракта намного эффективнее, чем бизнес-процесс, осуществляемый человеком вручную.
На схеме выше две организации ORG1
и ORG2
определили умный контракт car
для запроса (query
),
передачи (transfer
) и обновления (update
) автомобилей. Приложения организаций вызывают этот умный контракт для
выполнения согласованного действия в бизнес-процессе, например, для передачи права собственности на конкретный
автомобиль от организации ORG1
к организации ORG2
.
Терминология¶
Пользователи Hyperledger Fabric часто используют термины умный контракт и чейнкод как синонимы. В целом, умный контракт определяет логику транзакции, которая управляет жизненным циклом бизнес-объекта, хранящегося в глобальном состоянии. Далее он упаковывается в чейнкод, который затем развертывается в блокчейн-сети. Можно рассматривать умные контракты как механизм управления транзакциями. Чейнкод в свою очередь определяет, каким образом умные контракты упаковываются для развертывания.
Умный контракт определен в чейнкоде. Один чейнкод может содержать определения нескольких умных контрактов. При развертывании чейнкода все содержащиеся в нем умные контракты становятся доступными для приложений.
На схеме изображен чейнкод vehicle
, который содержит три умных контракта: car
, boat
и truck
. Также изображен
чейнкод insurance
, который содержит четыре умных контракта: policy
, liability
, syndication
и securitization
.
В обоих случаях эти контракты охватывают ключевые аспекты бизнес-процесса, касающиеся транспортных средств и
страхования. В этом разделе в качестве примера будем использовать контракт car
. Таким образом, умный контракт — это
программа для конкретной сферы применения и конкретных бизнес-процессов. А чейнкод — это контейнер для группы связанных
умных контрактов.
Реестр¶
Объясняя простым языком — для обновления состояний в реестре в блокчейн записываются транзакции без возможности внесения изменений. Умный контракт программно получает доступ к двум отдельным частям реестра — блокчейну, хранящему историю всех транзакций без возможности внесения изменений, и глобальному состоянию, хранящему кэш текущих значений этих состояний, и именно эти значения обычно требуются при обращении к объектам.
Умные контракты в основном записывают (put), запрашивают (get) и удаляют (delete) состояния в глобальной базе состояний, а также могут запрашивать запись транзакций в блокчейн без возможности дальнейших изменений.
- get обычно используется для получения информации о текущем состоянии бизнес-объекта.
- put обычно создает новый бизнес-объект или изменяет существующий в глобальном состоянии реестра.
- delete обычно удаляет бизнес-объект из текущего состояния реестра, однако история остается неизменной.
Умные контракты имеют множество доступных API. Важно заметить, что во всех случаях создания, считывания, обновления или удаления бизнес-объектов транзакциями в глобальном состоянии чейнкод содержит неизменяемую историю записей этих изменений.
Разработка¶
При разработке приложений на умные контракты нацелен основной фокус внимания, и, как было показано, один чейнкод может содержать любое количество умных контрактов. При развертывании чейнкода в сети все умные контракты чейкнода становятся доступными для организаций этой сети. Это означает, что работа с чейнкодом лежит в ответственности исключительно администраторов. Всем остальным пользователям достаточно концепции умных контрактов.
В основе умного контракта лежит набор определений транзакций
. Например, рассмотрим файл
fabcar.js,
содержащий пример транзакции умного контракта, которая создает новый автомобиль:
async createCar(ctx, carNumber, make, model, color, owner) {
const car = {
color,
docType: 'car',
make,
model,
owner,
};
await ctx.stub.putState(carNumber, Buffer.from(JSON.stringify(car)));
}
Подробное рассмотрение примера умного контракта Fabcar приводится в статье о создании первого приложения.
С помощью умного контракта можно описать почти бесконечное количество вариантов бизнес-процессов, связанных с неизменностью данных при принятии решений несколькими организациями. Используя языки программирования JavaScript, Go или Java, разработчики умных контрактов выражают существующий бизнес-процесс, в ходе которого определяются цены или условия поставки, в виде умного контракта. Для преобразования многовекового юридического опыта в код с помощью языка программирования все чаще нужны аудиторы умных контрактов, обладающие соответствующими юридическими и техническими знаниями. Подробная информация о проектировании и разработке умных контрактов приводится в статье о разработке приложений.
Одобрение¶
Для каждого чейнкода предусмотрена политика одобрения, которая применяется ко всем определенным в нем умным контрактам. Политика одобрения очень важна — она определяет, какие организации в блокчейн-сети должны подписать транзакцию, созданную определенным умным контрактом, чтобы эта транзакция была объявлена подтвержденной.
Каждый умный контракт имеет связанную с ним политику одобрения. Политика одобрения определяет организации, которые должны одобрить транзакцию, сгенерированную умным контрактом, прежде чем транзакция может быть идентифицирована как подтвержденная.
Например, политика одобрения может определять, что три из четырех организаций блокчейн-сети должны подписать транзакцию, прежде чем она будет рассматриваться как подтвержденная. Все подтвержденные или неподтвержденные транзакции добавляются в распределенный реестр, однако только подтвержденные транзакции обновляют глобальное состояние.
Если в политике одобрения указано, что транзакция должна быть подписана несколькими организации, то для получения
подтвержденной транзакции умный контракт должен быть выполнен достаточным количеством организаций. В примере выше
транзакция умного контракта для передачи (transfer
) автомобиля должна быть выполнена и подписана организациями ORG1
и ORG2
, чтобы считаться подтвержденной.
Политика обновления отличает сеть Hyperledger Fabric от других блокчейнов, таких как Ethereum или Bitcoin. В этих
системах любой узел сети может создавать транзакции, которые будут считаться подтвержденными. Сеть Hyperledger Fabric
более точно моделирует реальный мир — транзакции должны подтверждаться доверенными организациями в сети. Например,
руководящая организация должна подписать транзакцию выдачи идентификатора (issueIdentity
), или покупатель (buyer
)
и продавец (seller
) автомобиля должны подписать транзакцию передачи автомобиля (car
). Политика одобрения
предусмотрена для более точного моделирования подобных реальных взаимодействий.
В заключение, политика одобрения — это лишь один из примеров политик в Hyperledger Fabric. Также можно использовать другие политики для определения субъектов, которые могут запрашивать или обновлять реестр, и добавлять или удалять участников из сети. Обычно правила заранее согласуются консорциумом организаций в блокчейн-сети и могут быть изменены позже. Для этого в самих правилах определены дополнительные правила, согласно которым они могут быть изменены. И хотя эта тема требует углубленного рассмотрения, стоит отметить, что также возможно задавать пользовательские политики помимо стандартных, предоставляемых Fabric.
Подтвержденные транзакции¶
В случае обращения к умному контракту, он выполняется на одноранговом узле, который принадлежит определенной организации в блокчейн-сети. Контракт принимает набор входных параметров, называемых предложением транзакции, и использует их согласно внутренней программной логике для чтения и обновления реестра. Изменения глобального состояния записываются в виде ответа на предложение транзакцию (или просто ответ на транзакцию), содержащий набор чтения-записи с прочитанными состояниями и новыми состояниями, которые должны быть записаны в реестр, если транзакция будет подтверждена. Обратите внимание, что глобальное состояние не обновляется при выполнении умного контракта.
Все транзакции имеют идентификатор, а также запрос и ответ, подписанные некоторым количеством организаций. Все транзакции, подтвержденные или неподтвержденные, записываются в блокчейн, но только подтвержденные транзакции изменяют глобальное состояние.
Рассмотрим транзакцию передачи автомобиля car transfer
. Транзакция t3
используется для передачи автомобиля
организацией ORG1
организации ORG2
. Обратите внимание, что транзакция имеет входные данные {CAR1, ORG1, ORG2}
и
выходные данные {CAR1.owner = ORG1, CAR1.owner = ORG2}
, которые указывают на смену владельца с ORG1
на ORG2
. Также
входные данные подписываются организацией-владельцем приложения ORG1
, а выходные данные подписываются обеими
организациями ORG1
и ORG2
, указанными в политике одобрения. Подписи генерируются с помощью закрытых ключей каждого
из участников. Это означает, что любой участник сети может проверить, что все соответствующие субъекты в сети согласны
с содержанием транзакции.
Транзакции распределяются по всем одноранговым узлам в сети, и проверяются каждым одноранговым узлом в два этапа. Сперва транзакция проверяется на наличие достаточного количества подписей от организаций в соответствии с политикой одобрения. Затем проверяется, чтобы текущее значение глобального состояния совпадало с набором чтения транзакции, которое было при подписании транзакции одобряющими узлами. Это необходимо, чтобы проверить отсутствие промежуточных обновлений. Транзакция считается подтвержденной в случае успешного прохождения двух этапов проверки. В блокчейн добавляются все транзакции независимо от того, являются ли они подтвержденными или неподтвержденными, однако только подтвержденные транзакции обновляют глобальное состояние.
В нашем примере t3
является подтвержденной транзакцией, поэтому владельцем автомобиля CAR1
становится организация
ORG2
. Однако t4
(не показана) является неподтвержденной транзакцией, поэтому, хотя она была записана в реестр,
глобальное состояние не было обновлено, и владельцем автомобиля CAR2
остается организация ORG2
.
Наконец, чтобы разобраться в принципах взаимодействия умных контрактов или чейнкода с глобальным состоянием, рекомендуем ознакомится со статьей о пространстве имен чейнкода.
Каналы¶
Hyperledger Fabric позволяет организациям одновременно быть участниками нескольких независимых блокчейн-сетей благодаря каналам. Присоединяясь к нескольким каналам, организация может участвовать в так называемой сети из сетей. Каналы позволяют эффективно совместно использовать инфраструктуру при сохранении конфиденциальности связи и обмена данными. Каналы достаточно независимы, чтобы помочь организациям разделять свой рабочий трафик при работе с разными контрагентами, а также достаточно интегрированы, позволяя организациями производить любую другую деятельность при необходимости.
Канал предоставляют полностью независимый механизм связи для набора организаций. При записи определения чейнкода в канал, все умные контракты этого чейнкода становятся доступными для приложений в канале.
Несмотря на то, что программный код умного контракта устанавливается в пакете чейнкода на одноранговых узлах организации, участники канала могут выполнять умный контракт только после записи определения чейнкода в канале. Определение чейнкода — это структура, которая содержит параметры управления работой чейнкода. Эти параметры включают имя, версию и политику одобрения чейнкода. Каждый участник канала подтверждает параметры чейнкода, соглашаясь с определением чейнкода от имени своей организации. При одобрении конкретного определения чейнкода достаточным количеством организаций (по умолчанию большинством), такое определение может быть записано в канал. Затем участники канала могут использовать умные контракты из чейнкода в соответствии с политикой одобрения, указанной в определении чейнкода. Политика одобрения применяется в равной степени ко всем умным контрактам, определенным в одном чейнкоде.
В примере выше контракт car
определен в канале VEHICLE
, а договор insurance
— в канале INSURANCE
.
Определение car
в чейнкоде содержит политику одобрения, согласно которой организации ORG1
и ORG2
должны подписать
транзакции, прежде чем их можно будет считать подтвержденными. В определении чейнкода для контракта insurance
указывается, что подтверждение транзакции может осуществлять только организация ORG3
. Организация ORG1
является
участником сразу двух сетей — канала VEHICLE
и сети INSURANCE
, и может взаимодействовать с организациями ORG2
и
ORG3
в этих двух сетях.
Определение чейнкода предоставляет участникам канала возможность согласовать управление чейнкодом перед использованием
умных контрактов для проведения транзакций в канале. Согласно примеру выше, организации ORG1
и ORG2
намереваются
одобрить транзакции, которые вызывают контракт car
. Поскольку политика по умолчанию требует, чтобы определение
чейнкода было подтверждено большинством организаций, обе организации должны согласиться с политикой одобрения
AND {ORG1, ORG2}
. В противном случае организации ORG1
и ORG2
одобрят разные определения чейнкода и в результате не
смогут записать определение чейнкода в канал. Благодаря такому процессу гарантируется, что транзакция умного контракта
car
должна быть одобрена обеими организациями.
Взаимодействие¶
Умный контракт может вызывать другие контракты в канале, в котором он установлен, а также в других каналах. Таким образом, умные контракты могут читать и обновлять данные глобального состояния, к которым в противном случае у них не было бы доступа из-за ограничений пространств имен.
Для такого межконтрактного взаимодействия предусмотрены ограничения, которые подробно описаны в статье о пространстве имен чейнкода.
Системный чейнкод¶
Определенные в чейнкоде умные контракты содержат правила для проведения соответствующих бизнес-процессов, согласованные набором организаций в блокчейн-сети. Однако в чейнкоде также может быть определен низкоуровневый программный код, который применяется к любым системным взаимодействиям, не связанным с умными контрактами для конкретных бизнес-процессов.
Ниже приведены различные типы системных чейнкодов и связанных с ними сокращений:
_lifecycle
выполняется на всех одноранговых узлах и контролирует установку чейнкода на одноранговых узлах, утверждение определений чейнкодов организациями и запись определений чейнкодов в каналах. Описание реализации процесса жизненного цикла чейнкода Fabric в_lifecycle
приведено в этой статье.- Системный чейнкод жизненного цикла (LSCC) управляет жизненным циклом чейнкода в сетях Fabric версий 1.x. В этих версиях требовалось, чтобы чейнкод создавался или обновлялся в каналах. LSCC можно по-прежнему использовать для управления чейнкодом, если уровень функциональных возможностей приложений канала имеют версию V1_4_x или ниже.
- Системный чейнкод конфигурации (CSCC) выполняется на всех одноранговых узлах для обработки изменений, вносимых в конфигурацию канала, например, при обновлении политик. Более подробно об этом процессе рассказано в этом разделе, посвященном чейнкоду.
- Системный чейнкод запросов (QSCC) выполняется на всех одноранговых узлах и предоставляет API для доступа к реестру, включая такие команды, как запрос блока, запрос транзакции и другие. Описание этих API в контексте транзакций приведено в этом разделе.
- Системный чейнкод одобрения (ESCC) выполняется на одобряющих узлах при создании криптографической подписи ответа на транзакцию. Подробное описание реализации этого процесса системой ESCC приведено в этом разделе.
- Системный чейнкод валидации (VSCC) проверяет транзакцию, осуществляя проверку выполнения требований политик одобрения и соответствие версии набора чтения-записи. Больше информации о реализации этого процесса системой VSCC приведено в этом разделе.
Разработчики и администраторы сетей Fabric могут изменять системные чейнкоды для собственных целей с помощью низкоуровневого программирования. Однако разработка и управление системными чейнкодами является особым направлением, не связанным с разработкой умных контрактов, и обычно не требуется для успешного функционирования сети. Системные чейнкоды следует изменять с особой осторожностью, поскольку они имеют фундаментальное значение для правильного функционирования сети Hyperledger Fabric. Например, при ошибочной реализации системного чейнкода разные одноранговые узлы могут обновлять свои копии глобального состояния или блокчейна по-разному. Отсутствие консенсуса является одной из форм разветвления реестра. Такая ситуация — очень нежелательна в блокчейн-сети.