Внутри смарт-контракта Universa

На прошлых неделях вы могли прочитать вступительные статьи о некоторых аспектах внутренней архитектуры блокчейна Universa и ревизиях смарт-контрактов. Как вы теперь знаете, транзакции не добавляются к линейным блокам в цепочке, но каждая транзакция представляет собой ревизию «умного контракта» в наборе направленных ациклических графов (DAG).

Но что такое смарт-контракт на самом деле, и как выглядит его архитектура?

Внутри смарт-контракта

Прежде всего, термин «умный контракт», или «смарт-контракт», используется довольно часто, но при этом не применяется надлежащим образом. Речь идет о сложном контракте, который исполняется в блокчейне каким-то умным способом.

В блокчейне Universa каждая транзакция является (новым) «умным контрактом». И это может быть на самом деле контракт, но это также может быть документ, цифровой процесс или какое-то ещё соглашение. Мы можем назвать все эти операции «умными документами», «умными процессами», как угодно.

Если мы подробнее рассмотрим умный контракт в блокчейне Universa, то увидим, что он состоит из трех разделов:

  1. definition: «определение»
  2. state: «состояние»
  3. transactional: «транзакционные данные»

definition: «определение»

Первая часть структуры содержит данные, которые должны быть неизменными в любой ревизии этого контракта. Если транзакция выполняется, эти данные должны быть не тронутыми. Изменить это невозможно.

Если данные в секции definition изменяются, узлы Universa запрещают регистрацию такой транзакции. При этом, узлы сравнивают эти данные новой ревизии с предыдущей.

state: «состояние»

Секция state содержит данные, которые могут быть изменены в ревизиях этого контракта. Конкретные детали того, что и как это может быть изменено, могут быть указаны в definition.permissions. Параметры, которые задаются в секциях definition или state – это такие вещи, как «создатель», «эмитент» или «владелец».

transactional: «транзакционные данные»

Третья часть структуры содержит данные, которые (не обязательно) будут храниться в договоре, но привязаны только к конкретной транзакции. Например: если вы платите продавцу, вы можете поместить запись о причине платежа / код счета в секцию transactional.

Это три раздела в смарт-контракте, которые содержат все данные, касающиеся конкретной транзакции. Мы называем все это «просто данными», но о чем могут быть эти данные?

Контракт Universa Token (UTN)

Давайте возьмем в качестве примера «корневой» (origin) контракт Universa Token (UTN). Вы можете найти его самостоятельно на universaexplorer. Он показывает общие данные / информацию о ролях и владельце.

Вы также можете прочитать данные секции definition (которые должны остаться неизменными во всех ревизиях). Независимо от того, какой редакцией контракта вы обязаны, вы всегда увидите следующие данные:

Второй раздел – это данные о состоянии, которые содержат поле amount – количество UTN. Это может сбить с толку, так как вы ожидаете, что выпущенное количество токенов будет фиксированным или неизменным.

Однако транзакция с токенами (то есть, ревизия этого корневого контракта) использует функции split-join (разделение-объединение). Это один из вариантов использования умного контракта. Операция Split-join с контрактом в основном используется для «монетообразных» контрактов.

Проще говоря, корневой контракт токена UTN состоит из 4 997 891 952 токенов.

Из-за динамической и гибкой природы свапов UTN-UTNP, Universa не имеет точных данных об остатках и количестве UTNP в обращении. Однако это можно отследить, но такой инструмент еще не создан.

Если из этого контракта будет выполнен платеж, эта сумма будет разделена, скажем, на 1 997 891 952 и 3 000 000 000. Это возможно, поскольку эти данные – в секции state контракта (следовательно, их можно менять).

После этого у нас есть два контракта (ревизии) одного и того же корневого контракта, оба из которых имеют (или являются) собственным количеством токенов. Для каждого платежа или транзакции с этим токеном сумма будет разделена, отправлена, а затем объединена (или присоединена) на стороне получателя. Вы можете прочитать больше об этом случае в КБ.

Кстати, Origin ID (идентификатор корневого контракта для токена) – наиболее идеологически важный элемент для токенов с фиксированной эмиссией.

Как вы знаете, в мире блокчейна очень важны термины «изменчивый» (mutable) и «неизменный» (immutable). Задумайтесь, например, о максимальной эмиссии, о владельце или эмитенте контракта. При наличии и секций definition и state это можно гарантировать для каждого конкретного случая использования.

Разрешения (Permissions) и роли (Roles)

Существуют также методы, позволяющие указать, кому именно принадлежат какие-то разрешения контракта. Это может быть SimpleRole («простая роль», в которой указывается только один приватный ключ), RoleLink (ссылка на другую роль, например, «текущий владелец») или ListRole (ссылающийся на список из нескольких других ролей).

Это на самом деле очень интересно. Потому что благодаря такому можно составить такую ​​роль, как «список из 5 человек, и ВСЕ они должны подписать документ». Или сделать роль вроде «Список из 6 человек, и ЛЮБОЙ из них должен подписать документ». Можно даже создать конструкцию вида «15 из 16». Это добавляет дополнительную безопасность для операций, например, возможности холодного хранения, или принятие решений большинством голосов.

На практике, помимо простого определения роли, любая роль может даже содержать некоторые дополнительные проверяемые ссылки (references), в которых можно добавить дополнительную пользовательскую логику проверки. Такие ссылки могут быть определены в секциях definition, state или transactional. Это может быть, например, ссылка на name, transactional_id, fields или signed_by.

Есть много способов указать данные, роли и разрешения умного контракта / документа. После регистрации смарт-контракт можно использовать / проверять / выполнять, и у него создаётся новая ревизия для каждой транзакции. Это приводит к различным «состояниям элементов» (Item States) для каждой ревизии, которая будет добавлена ​​в DAG.

Item State – «статус» контракта

Давайте вернемся к смарт-контракту UTN, который мы используем в качестве примера. Статус этого элемента – Item State – помечен как UNDEFINED («не определён»).

Важно: это потому, что сработала операция split-join, а не потому, что токен UTN «не работает или больше не существует».

Есть несколько состояний для умных контрактов, определяемых консенсусом сети.

  1. APPROVED – ПОДТВЕРЖДЕНО, основное «успешное» состояние контракта
  2. LOCKED – ЗАБЛОКИРОВАНО, консенсус о состоянии еще положительный, но контракт уже заблокирован во время подготовки к его архивированию.

Также возможно, что возник «негативный консенсус» между узлами:

  1. DECLINED
  2. REVOKED

Наконец, есть четыре варианта состояния смарт-контрактов (или транзакций), в которых консенсус не определён:

  1. UNDEFINED – НЕ УКАЗАН, потому что, например, он уже давно отменен (или никогда не был зарегистрирован).
  2. PENDING – ОЖИДАНИЕ
  3. DISCARDED – ОТВЕРГНУТ
  4. LOCKED_FOR_CREATION

Вы можете прочитать больше об этих статусах в нашей Knowledge Base. В следующей статье мы подробнее рассмотрим варианты использования этих умных документов. Следите за обновлениями.

Help translating this post to Английский Немецкий Французский Голландский Итальянский Испанский Хорватский. Contact @starnold to participate!

Related posts

Суть смарт-контрактов Universa

Arnold

Направленный ациклический граф (DAG) Universa – внутреннее содержание

Arnold

Что делает блокчейн Universa безопасным? HashID

Arnold

Leave a Comment