Общая информация

Отличительные особенности

Блокчейн-платформа Apla разработанна для построения цифровых экосистем на базе интегрированной среды разработки приложений с многоуровневой системой управления правами доступа к данным, интерфейсам и смарт-контрактам. Платформа построена на базе программного продукта разработанного компанией EGAAS S.A.

Apla по своей структуре и функционированию принципиально отличается от большинства существующих блокчейн-сетей.

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

Архитектура блокчейн-платформы Apla

Сеть

Apla построена на базе одноранговой сети. Полные узлы сети содержат актуальную версию блокчейна и базу данных, в которой фиксируется текущее состояние платформы. Пользователи сети получают данные обращаясь к базам данных полных узлов с помощью программного клиента (или команд REST AP). Новые данные отправляют в сеть в виде подписанных пользователем транзакций, которые по сути являются командами модификации базы данных. Из транзакций формируются блоки, которые присоединяются к блокчейнам на узлах сети, и одновременно с этим происходит отработка транзакции - изменение состояния базы данных.

Валидирующие узлы

Полные узлы сети, имеющие право формировать блоки, называются валидирующими. Число валидирующих узлов ограничено и задается параметром count_of_nodes в настройках платформы.

Список валидирующих узлов хранится в параметре full_nodes в формате

[["host1:port","-1222","nodepub1"], ["host2:ip","-1222", "nodepub2"]], где
  • host1:port - это адрес хоста, на который пересылаются транзакции и новые блоки, также с этого адреса можно получить всю цепочку блоков начиная с 1-го;
  • -1222 - номер виртуального аккаунта, на который нода получает комиссию; если кошелек не существует, то комиссия не снимается.
  • nodepub1 - публичный ключ узла, необходимый для проверки подписей блоков, созданных им.

Транзакции

Транзакция формируется программным клиентом (или командой contract REST API) и содержит данные для выполнения специального программного контролера - контракта («смарт-контракта»), вызываемого пользователем. Транзакция имеет следующий формат:

  • Type - ID вызываемого контракта,
  • Data - параметры, передаваемые контракту,
  • KeyID - идентификатор пользователя отправившего транзакцию,
  • PublicKey - публичный ключ пользователя (опционно),
  • BinSignatures - подпись транзакции,
  • Time - время отправления транзакции,
  • EcosystemID - номер экосистемы, из которой отправлена транзакция,
  • ТokenEcosystem - номер экосистемы, в токенах которой оплачивается транзакция,
  • MaxSum - максимальная комиссия за транзакцию,
  • PayOver - дополнительная плата за ускорение в очереди.

Транзакция подписывается приватным ключом владельца аккаунта. Ключ вместе с функцией подписания может храниться: в браузере, в программном клиенте, на сим-карте, на специальном физическом устройстве. В текущей реализации приватный ключ хранится в программном клиенте Molis в зашифрованном алгоритмом AES виде. Транзакции подписываются с помощью алгоритма ECDSA.

Сетевой протокол

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

Узел, имеющий в данный момент право генерировать блок (согласно параметру full_nodes), извлекает транзакции из очереди и посылает в блок-генератор. Параллельно с формированием блока происходит отработка транзакций: транзакция посылается в виртуальную машину, где происходит выполнение контракта с параметрами, переданными транзакцией, в результате чего происходит модификация состояния базы данных.

Новый блок проверяется на наличие ошибок, и если он признается валидным, то рассылается другим валидирующим узлам.

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

Проверка блока и транзакций

Проверка блока, проводимая валидирующим узлом после его формирования, а также на всех других валидирующих узлах после его получения, содержит следующие тесты:

  • равен ли первый байт 0, если нет, то полученные данные не являются блоком,
  • время генерации блока не больше текущего,
  • имел ли право узел подписавший блок сделать это в указанное в блоке время,
  • номер блока больше последнего блока в имеющейся цепочке,
  • не превышен ли общий лимит на оплату транзакций блока,
  • проверка правильности подписи блока ключом создавшего блок узла; подписываются BlockID, Hash предыдущего блока, Time, Position в full_nodes, MrklRoot от всех транзакций блока,
  • проверка правильности всех транзакций блока:
    • уникальность хеша транзакции,
    • не превышен ли лимит транзакций подписанных одним ключом (max_block_user_tx),
    • не превышен размер транзакции (max_tx_size),
    • время посылки не больше времени формирования блока и не меньше времени формирования блока минус 86400 сек,
    • правильность подписи транзакции,
    • существуют ли токены, в которых происходит оплата ресурсов в списке sys_currencies,
    • достаточно ли токенов на виртуальном аккаунте пользователя для оплаты необходимых для выполнения транзакции ресурсов.

База данных платформы

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

На данный момент на платформе используется СУБД PostgreSQL.

Экосистемы платформы

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

Программно экосистема представляет собой совокупность приложений - систем интерфейсов, контрактов, таблиц базы данных. На принадлежность элементов приложений к конкретной экосистеме указывает префикс в их имени, например, @1name, в котором после знака «@» указывается ID экосистемы. При обращении к элементам приложений внутри одной экосистемы префикс можно опустить.

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

Пользователем платформы можно стать только получив приватный ключ для доступа в одну из экосистем (традиционно в экосистему №1). Пользователь может быть членом любого количества экосистем. Переход между экосистемами осуществляется при помощи специального меню программного клиента.

Интегрированная среда разработки

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

  • таблица параметров экосистемы,
  • редактор контрактов,
  • инструменты для администрирования таблиц базы данных,
  • редактор интерфейсов и визуальный конструктор интерфейсов,
  • редактор языковых ресурсов,
  • сервис экспорта/импорта приложений.

Приложения Apla

Приложение на платформе Apla - это система таблиц, контрактов, интерфейсов с настроенными правами доступа выполняющая некоторую функцию или реализующая отдельный сервис.

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

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

Таблицы экосистемы

В каждой экосистеме возможно создание неограниченного числа таблиц в базе данных платформы. Как уже отмечалось, таблицы экосистемы идентифицируются по префиксу, содержащему номер экосистемы, который не отражается в программном клиенте при работе «внутри» экосистемы. Запись в таблицы других экосистем возможна, если позволяют настройки прав доступа.

Инструменты для администрирования таблиц

Инструменты управление таблицами экосистемы доступны в разделе Tables административной секции программного клиента Molis, где реализованы следующие функции:

  • просмотр списка таблиц и их содержимого,
  • создание новых таблиц,
  • добавление в таблицы новых колонок с выбором типовых форматов данных: Text, Date/Time, Varchar, Character, JSON, Number, Money, Double, Binary,
  • установление правами доступа на запись данных и изменение структуры таблиц.

Операции с данными таблиц

Для работы с базой данных язык контрактов Simvolio и язык шаблонизатора Protypo содержат функции DBFind, обеспечивающие получение из таблиц как отдельных значений, так и массивов. Язык контрактов содержит функции добавления строк в таблицы DBInsert и изменения значений в существующих записях DBUpdate (при изменении значения переписываются только данные в таблице базы данных, в блокчейн же добавляется новая транзакция с сохранением всех предыдущих транзакций). Данные в таблицах не удаляются.

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

Параметры экосистем

В разделе Ecosystem parameters административной секции программного клиента Molis доступны для просмотра и редактирования параметры экосистемы, которые можно разделить на несколько групп:

  • общие параметры: название экосистемы (ecosystem_name), описание (ecosystem_description), аккаунт основателя (founder_account) и некоторые другие,
  • параметры доступа, которые определяют исключительные права доступа к элементам приложений (changing_tables, changing_contracts, changing_page, changing_menu, changing_signature, changing_language),
  • технические параметры: например, пользовательские стили (stylesheet),
  • пользовательские параметры экосистемы, в которых хранятся константы или списки (через запятую), необходимые для работы приложений.

Для каждого параметра экосистема указываются права на его изменения.

Для получения значений отдельных параметров экосистемы и в языке контрактов Simvolio, и в языке шаблонизатора Protypo имеется функция EcosysParam, в которой в качестве аргумента указывается имя параметра. Для возврата элемента списка (записанных в параметр экосистемы через запятую) необходимо вторым параметром функции указать его порядковый номер.

Параметры платформенной экосистемы

Все параметры платформы хранятся в таблице параметров платформенной экосистемы. Это такие параметры как:

  • промежуток времени, отведенный на создание блока валидирующим узлом,
  • код исходных страниц, контрактов, таблиц, меню новых экосистем,
  • список валидирующих узлов,
  • максимальные размеры транзакции, блока, максимальное число транзакций в блоке,
  • максимальное количество транзакций от одного аккаунта в блоке,
  • максимальное количество Fuel расходуемое на одну транзакцию, один блок,
  • курс Fuel к APL и другие.

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

Список параметров платформенной экосистемы
  • default_ecosystem_page - какой код по умолчанию вставить в первую страницу только что созданной экосистемы.
  • default_ecosystem_menu - какой под по умолчанию вставить в первое меню только что созданной экосистемы.
  • gap_between_blocks - множитель, на который умножается количество секунд, которые нода ждет, пока не получает право сгенерить следующий блок. 0 < gap_between_blocks < 86400.
  • rb_blocks_1 - максимальное количество блоков, на которое можно откатиться. Влияет на количество блоков которое можно за раз скачать. 0 < rb_blocks1 < 10000.
  • new_version_url - хост для проверки доступности новых версий (апдейт сервера).
  • number_of_nodes - максимальное количество полных нод. 0 < number_of_nodes < 1000.
  • max_block_size - максимальный размер блока в байтах. max_block_size > 0.
  • max_tx_size - максимальный размер транзакции в байтах. max_tx_size > 0.
  • max_tx_count - максимальное количество транзакции в блоке. max_tx_count > 0.
  • max_columns - максимальное количество колонок в созданном пользователем реестре. max_columns > 0.
  • max_indexes - максимальное количество индексов в созданном пользователем реестре. max_indexes > 0.
  • max_block_user_tx - максимальное количество транзакции в блоке от одного пользователя. max_block_user_tx > 0.
  • max_block_generation_time - максимальное время в миллисекундах на генерацию блока.
  • max_fuel_tx - максимальный расход топлива на одну транзакцию. max_fuel_tx > 0.
  • max_fuel_block - максимальный расход топлива на блок. max_fuel_block > 0.
  • size_fuel - множитель, на который умножается плата за количество данных в смарт контракте.
  • commission_wallet - адреса кошельков, на которые начисляется комиссия в зависимости от текущей экосистемы. Представляет из себя массив из пар (номер экосистемы, идентификатор кошелька). Например, [[«1»,»-943604719945132508»]]. При записи идет проверка на валидность номеров кошельков.
  • commission_size - процент коммиссии, который будет начисляется с каждой операции на commission_wallet. commission_size >= 0.
  • fuel_rate - курс конверсии APL к топливу. Представляет из себя массив из пар (номер экосистемы, множитель). Например, [[«1»,»1000000000000000»]]. Значение множителя должно быть больше 0.
  • full_nodes - список нод, которые могут генерировать блоки. Представляет собой список списков вида [[хост, адрес аккаунта, публичный ключ],].
  • extend_cost_(funcname) - стоимость вызова встроенной функции в fuel. x_extend_cost >= 0.
  • (table|column|page|menu|contract)_price - стоимость создания какой либо сущности в fuel. x_price >= 0.

Механизм контроля прав доступа

Платформа обладает многоуровневой системой управления правами доступа. Условия доступа устанавливаются на операции создания и изменения всех элементов приложений: контрактов, таблиц базы данных, интерфейсов, параметров экосистемы. Также фиксируются и права на изменения прав.

По умолчанию все права на изменение всех элементов приложений экосистемы принадлежит ее основателю (что прописано в контракте MainCondition, который имеется в экосистеме по умолчанию). Однако после создания специальных смарт-законов, контроль прав может быть передан членам экосистемы или их группе.

Контролируемые операции

Права устанавливаются в поле Permissions в соответствующих разделах административной секции программного клиента Molis: в редакторах контрактов, таблиц, интерфейсов (страниц, меню, страничных блоков). Фиксируются права на следующие операции:

  1. Table column permission - право на изменение значения в колонке таблицы,
  2. Table Insert permission - право на запись в таблицу новой строки,
  3. Table New Column permission - право на добавление новой колонки,
  4. Conditions for changing of Table permissions - право на изменение прав, перечисленных в п.п. 1-3,
  5. Conditions for change smart contract - право на изменение контракта,
  6. Conditions for change page - право на изменение страницы интерфейса,
  7. Conditions for change menu - право на изменение меню,
  8. Conditions for change of ecosystem parameters - права на изменение определенного параметра настроечной таблицы экосистемы.

Способы управления правами

Правила, задающие права доступа, записываются в поля Permissions в виде произвольного выражения на языке Simvolio. Доступ предоставляется если на момент обращения выражение имеет значение true. Если поле Permissions остается пустым, то оно автоматом приобретает значение false, и выполнение соответствующих действий запрещается.

Простейшим способом предоставления прав является запись в поле Permissions логического выражения, например, $member == 2263109859890200332, в котором указан идентификационный номер конкретного члена экосистемы.

Универсальным и рекомендуемым методом фиксации прав является использование функции ContractConditions, которой в качестве аргумента передается имя контракта, содержащего условия, в которых могут использоваться данные таблиц (например, таблицы ролей) и параметры экосистемы.

Еще одним методом управления правами доступа является использование функции ContractAccess, которой в качестве параметров передается список контрактов, имеющих право реализовывать соответствующее действие. К примеру, если в таблице, содержащей аккаунты в токенах экосистемы, ввести в поле Permissions колонки amount функцию ContractAccess("TokenTransfer"), то изменение значения amount будет разрешено исключительно контракту TokenTransfer (все контракты, предусматривающие перевод токенов с аккаунта на аккаунт, смогут сделать это только через вызов контракта TokenTransfer). Условия получения доступа к самим контрактам контролируются в секции conditions и могут быть достаточно сложными, включающими множество других контрактов.

Исключительные права

Для разрешения конфликтных или опасных для деятельности экосистемы ситуаций в таблице Ecosistem parameters введены специальные параметры (changing_smart_contracts, changing_tables, changing_pages), в которых прописываются условия получения исключительных прав доступа к любым смарт-контрактам, таблицам или страницам. Эти права устанавливаются специальными смарт-законами, к примеру, предусматривающими голосование членов экосистемы или наличие нескольких подписей различных ролей.

Оффчейн-серверы

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

Обращение к web-ресурсам

Основным отличием OBS от обычных экосистем является возможность обращения из ее контрактов к любым web-ресурсам по HTTP/HTTPS. Для этого используется функция HTTPRequest, в которую передаются URL, метод запроса (GET или POST), заголовок и параметры запроса.

Права на чтение данных

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

Использование OBS

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

Создание OBS

OBS создается на любом из полных узлов сети. Администратор узла должен определить список экосистем, которым разрешено пользоваться функционалом оффчейн-серверов, а так же указать пользователя, который будет обладать правами основателя экосистемы: сможет устанавливать приложения, принимать в экосистему новых членов, настраивать права доступа к ресурсам экосистемы.