Universa Blockchain – Technical overview (Russian)


Universa Blockchain – это платформа распределённого реестра (DLT-платформа), обеспечивающая хранение и проверку структурированных данных («контрактов») с методикой, обеспечивающей надёжную проверку и исполнение заложенных в контракт гарантий, ограничений и требований («смарт-контрактов»), при отсутствии доверия к каждому конкретному узлу/ноде системы, но при этом наличии доверия к всей системе в целом (BFT-безопасно).

Universa проектировалась с учётом проблем имеющихся распределённых, централизованных и децентрализованных решений, но не как их эволюция, а как самостоятельно и во многом отличающееся решение. В некоторых случаях для упрощения понимания будут описываться сходные концепции в других DLT-решениях (Bitcoin, Ethereum, Hyperledger Fabric), и подчёркиваться отличия от них. Тем не менее, код Universa разрабатывался абсолютно самостоятельно, лицензионно чист, не является «форком» или развитием кодовой базы каких-то других DLT-проектов.

Исходный код ключевых компонентов сети Universa – нода/клиентское API и др., такие, как U8, Ubot servers (см. ниже) – доступен в Github: github.com/UniversaBlockchain/universa.

См. также:

  • Universa.today – неофициальный сайт, развиваемый комьюнити Universa и содержащий как новости Universa, так и (написанные участниками и переводимые ими на разные языки) научно-популярные статьи о архитектуре Universa, её особенностях, отличиях от других систем.
  • kb.universablockchain.com – Universa Knowledge Base. Основной структурированный источник технической информации по Universa – от общих идей и особенностей (включая словарь терминологии Universa) до разделов, предназначенных для авторов смарт-контрактов Universa или разработчиков ПО, интегрированного с сетью Universa.
    • Основное API доступно для Java/Scala/JDK-языков;
    • Есть официальное API для JavaScript;
    • Для доступа из прочих языков (Python, Ruby, etc) описан UMI – RPC-подобный механизм работы с Java API.
  • github.com/UniversaBlockchain – Github-репозитории основных компонентов системы, а также runtime-среды U8.
  • hub.docker.com/r/universa – Docker-репозитории с образами некоторых компонент системы Universa, а также runtime-среды U8.
    • Использование Docker-образов описано в отдельной статье в KB, в которой рассказано, как с их помощью развернуть минимальную тестовую сеть локально.
    • Используя Docker-образы и информацию из этой статьи/из исходников Docker-образов, возможно разворачивать минимальные тестовые сети и на физических серверах. В production-использовании настоятельно рекомендуется не просто не использовать Docker-контейнеризацию, а именно использовать аппаратных серверов в максимально защищённых окружениях (для защиты от Meltdown/Spectre-подобных атак в случае общих хостингов).
    • Имеется и модуль для benchmark-тестов системы, позволяющий оценить производительность сети Universa в каждом конкретном сценарии/сетевом окружении.
  • Development Map – наглядная карта для быстрого ориентирования по различным статьям про архитектуру Universa.

Хранящиеся данные

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

Форма хранимых данных

  • Bitcoin – позволяет хранить факты передачи монетарной ценности («отправка денег»/BTC) между участниками сети, идентифицируемыми с помощью ключевых пар асимметричных криптографических алгоритмов. Напр.:

    • «пользователь с адресом ABCD, производным от его публичного ключа, отправил 123.45 BTC на адрес CDEF».

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

  • Ethereum – позволяет хранить не только факты передачи монетарной ценности (ETH), но и управлять созданием и исполнением «распределённых приложений» (dApps). Напр.:

    • «пользователь с адресом ABCD зарегистрировал по адресу DEFB распределённое приложение для виртуальной машины EVM с таким-то байт-кодом и такими-то данными: ...»;
    • «пользователь с адресом CDEF запустил распределённое приложение, хранящееся по адресу DEFB, и при этом в распределённом приложении хранящиеся данные/переменные изменились таким-то образом: ...».

В отличие от вышеописанных систем, в архитектуре Universa не предусмотрено никаких низкоуровнево встроенных «криптовалют» или «единиц ценности» (таких, как BTC или ETH). Основной элемент обрабатываемых данных — это **смарт-контракт*, представляющий собой структурированный набор данных (в структурах, похожих на YAML/JSON/XML; более того, эти структуры могут быть экспортированы/импортированы в YAML/JSON/XML). Часть этой структуры строго формализована (обязательные поля и элементы структуры), часть этой структуры может хранить совершенно произвольные поля (и может быть гибко расширена для любых частных случаев использования). Для эффективного хранения бинарных данных используется собственный алгоритм сериализации BOSS.

Более того, по умолчанию сами смарт-контракты (их тела) не хранятся на узлах (нодах) сети Universa. Полное хранение всех используемых данных на всех узлах сети (как это происходит в Bitcoin/Ethereum/пр.) приводит к катастрофическому росту затрат на хранение данных сетью: каждый полнофункциональный узел сети должен хранить каждую историческую транзакцию. Поэтому в сети Universa (по умолчанию) хранится:

  1. Только факт корректности сети конкретного смарт-контракта (а точнее, т.н. ItemState этого контракта),
  2. Факт корректности хранится только для наиболее актуальной ревизии смарт-контракта, но не для всех предыдущих (неактуальных) ревизий.

(Тем не менее, доступны расширения протокола, позволяющие как хранить тела смарт-контрактов на узлах сети, так и хранить факты корректности/ItemState каких-то отобранных ревизий из прошлого, подтверждая «слепок состояния» контракта на какой-то момент времени).

Проверка данных

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

  • В смарт-контракте могут быть указаны разрешения (**permissions*), описывающие правила, кому и как можно менять какие-то компоненты смарт-контракта;
  • Механизм ролей (**roles*) позволяет описать, какие участники взаимодействия имеют какие разрешения;
  • Механизм «ссылок», или «ограничений» (**references/constraints*) предоставляет достаточно гибкий язык для более сложной логики проверки контроля доступа (см. отдельную статью про доступные возможности).

Смарт-контракты

В платформах вроде Ethereum (а также распределённых, но централизованных/BFT-unsafe решениях вроде Hyperledger Fabric) под понятием «смарт-контракт» обычно подразумевается распределённое приложение (dApp), выполняющееся в децентрализованной сети.

В сети Universa такой подход возможен, но абсолютно опционален и ортогонален основной функциональности сети (и реализуется системой Ubot servers). Основная модель смарт-контрактов в Universa, как описано выше, более точно описывается термином Ricardian contract — описание условий контракта/документа в формализованном виде, и проверка их внутренних ограничений при каждом изменении.

Технология консенсуса

Алгоритм консенсуса

Для определения, какой из (анархически и бесконтрольно добавляемых) узлов в сети имеет право на регистрацию нового блока в распределённом журнале, DLT-системы вроде Bitcoin и Ethereum обычно используют алгоритм Proof-of-Work, вынуждающий каждый узел тратить огромное количество вычислительных ресурсов/тактов процессора на случайный перебор неиспользуемых данных, так, чтобы случайно наткнуться на такую комбинацию, которая позволит узлу быть «решающим». Такой алгоритм часто критикуется за то, что пользователи, обладающие значительными финансовыми и техническими ресурсами, могут повлиять на принятие консенсуса и осуществить «атаку 51%».

Развиваются также системы вроде Proof-of-Stake, в которых для принятия решающих решений в консенсусе узел должен заблокировать некоторое количество «денег». Опасность атаки 51% в таких системах ещё более заметна — влияние конкретного участника консенсуса определяется уже напрямую финансовым вкладом, а не просто его технологическими мощностями.

В Universa принципиально не существует возможности «анархического подключения» к сети, а каждая новая добавляемая нода может быть добавлена только в случае согласия участников и KYC-подобной проверки её владельца. Это обеспечивает невозможность одним пользователем, даже при значительном финансовом вкладе, регистрации большого количества участвующих в консенсусе узлов и осуществления «атаки Сивиллы». Обычно такой подход принято называть Proof-of-Authority.

CAP-теорема и моментальная согласованность

В системах вроде Bitcoin/Ethereum механизмы консенсуса не обеспечивают «моментальной» согласованности данных, обеспечивается только “eventual consistency” – любой блок с транзакциями технологически может быть «отозван» (объявлен orphaned/uncle), и поэтому частью процесса проверки данных из блокчейна является ожидание, чтобы после конкретного блока появилось некоторое количество «подтверждений» – новых блоков, «нарощенных блокчейном» после изучаемого, так что, вероятно, достаточно длинная цепочка в блокчейне не может быть отозвана.

В терминах CAP-теоремы это означает, что системы вроде Bitcoin и Ethereum обеспечивают скорее AP-гарантии:

  • Consistency (every read receives the most recent write or an error) – не только не выполняется, но и может факт «попытки записи» может быть отменён постфактум.
  • Availability (every request receives a (non-error) response, without the guarantee that it contains the most recent write) – выполняется; типичные DLT-сети достаточно хорошо распределены, пусть и содержат несогласованные данные;
  • Partition tolerance (the system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes) – выполняется, аналогично availability.

В Universa количество «требуемых подтверждений» для регистрируемого блока — 0; после успешной регистрации блока узлами система сама по себе не может решить его «отозвать» (сделать orphaned), и дополнительных «подтверждений» ждать не обязательно.

В терминах CAP-теоремы подход Universa более соответствует CA-гарантиям:

  • Consistency – выполняется; любое изменение данных выполняется согласованно по всей сети;
  • Availability – выполняется; если есть хотя бы один работающий узел в сети, проверить данные возможно;
  • Partitioning – все узлы сети знают про все узлы сети; партиционирование сети невозможно, но поскольку оно понизило бы эффективность использования сети, то лицензирование нод (в Mainnet) и тщательное администрирование их подразумевают высокую их доступность и стабильность.

«Мир Universa»

Инфраструктурные компоненты

U8

Созданный внутри Universa JavaScript-runtime для разработки решений на Universa и для Universa. Использует [V8 JavaScript engine], поэтому поддерживает актуальные возможности JavaScript/ECMAScript, плюс много высокооптимизированных функций для Universa-специфичных задач.

  • Узлы Ubot servers (см. ниже) работают на U8/JavaScript;
  • Доступны тестовые реализации узлов Universa network на U8/JavaScript.

Подробнее – см. раздел в KB.

UBots

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

  • Для разработки и запуска dApps (в терминологии системы – Ubots) используется современный язык JavaScript;
  • Запускаемые «уботы», в отличие от типичных dApps в системах Ethereum, могут иметь доступ к внешним данным/«оракулам» стандартными способами, и перепроверяют/синхронизируют как полученные снаружи, так и посчитанные самостоятельно данные;
  • Количество узлов, на которых должен быть запущен uBot (степень параллелизации), равно как и требования по избыточности, гибко управляются.

Подробнее – см. статью в KB.

Parsec

Безопасный слой сетевой коммуникации, заменяющий одновременно слой SSL-аутентификации (многочисленные централизованные CA) и DNS (централизованную архитектуру ICANN и DNS-регистраторов), и децентрализованно решающий проблемы, связанные с их централизацией:

  • Безопасное определение адресов и ключей сервисов для традиционных протоколов;
  • Поддержка библиотеками соединений parsec-h (over HTTP);
  • Средства создания, оплаты и регистрации, и управления контрактами UNS, используемыми для Parsec;
  • Доступный на уровне протокола механизм для RPC-доступа к узлам;
  • HTTP/S прокси для legacy-доступа к содержимому, DNS/DNS-over-HTTPS-прокси для доступа к именам;
  • Поддержка как TCP, так и UDP.

При этом механизмы работы с адресами и сертификатами в сети Parsec используют смарт-контракты Universa.

Предлагаемые решения

UDC

Платформа для разворачивания Digital Currency/CBDC на базе смарт-контрактов и токенов Universa. Механизмы смарт-контрактов Universa обеспечивают как ролевой контроль эмиссии денег, так и гарантии невозможности «подделки».

Подробнее – см. раздел в KB.