Назад

      WHITEPAPER

      • 1. Введение
      • 2. Транзакции
      • 3. Сервер меток времени
      • 4. Блоки
      • 5. Закрепление временных меток
      • 6. Реализация Nimses
      • 7. Заключение
      • 8. Ссылки
      Nimses Blockchain: система цифровых активов

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

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

      1. Введение

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

      Необходима система, основанная на криптографии, а не на доверии, при этом обладающая приемлемой пропускной способностью для массового повседневного пользования.

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

      2. Транзакции

      Определим электронный актив как публичную цепочку цифровых подписей, а счёт как упорядоченную пару: уникальный идентификатор, далее именуемый адресом, и некоторый актив.

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

      1 Здесь и далее под хешем подразумевается результат односторонней функции

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

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

      3. Сервер меток времени

      Правилами системы будем называть некоторые общепризнанные требования, установленные внутри неё. Например: транзакционная комиссия, налоговый сбор и так далее.

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

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

      4. Блоки

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

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

      5. Закрепление временных меток

      Под закреплением истории понимается открытая публикация, как в газете или Usenet-постах, некоторых данных, гарантирующих однозначность её происхождения в неизменяемом реестре. В условиях 2019 года полагается разумным в качестве реестра для закрепления использовать открытые одноранговые децентрализованные системы, обладающие достаточным уровнем надёжности, такие как Bitcoin и Ethereum.

      6. Реализация Nimses

      6.0 Технические требования

      • Потенциальная аудитория: 3x109 пользователей
      • Скорость подтверждения транзакций: ~1 секунда
      • Пропускная способность: до 106 транзакций в секунду

      6.1 Счета

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

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

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

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

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

      Address	= {16 byte} + {asset_id: 4 byte}
      
      Account	= (Address, Asset, Type, Emission,
          {Public Key}, State)
      
      State = (Time Point, Balance, Nonce, ...)
      
      Account Type = {
          COMMON,
          HUMAN,
          GENESIS,
          TAX,
          REMOVED,
          ...
      }

      6.2 Транзакции

      Обычная транзакция состоит из трех частей: заголовка, тела и свидетельств отправителей.

      Tx = (Header, Body, Witnesses)

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

      Tx Types = {
          CREATE_ACCOUNT,
          SPEND,
          TAX_SPEND,
          GENESIS_SPEND,
          REG_KEY,
          REVOKE_KEY,
          ...
      }
      
      TxHeader = (Version, Type, Time Window)

      Адрес счёта и количество получаемого или отправляемого актива определим как ссылку на значение.

      ValueRef = (Account Address, Value)

      Тело транзакции — это упорядоченная пара множеств, содержащих ссылки на значения отправителей и получателей соответственно.

      Tx.Body = (From: {ValueRef}, To: {ValueRef})

      Свидетельствами отправителей называется упорядоченное множество свидетельств каждого из отправителей. Свидетельством отправителя назовём упорядоченную пару: подпись отправителя и хеш публичного ключа из подписывающей пары. В качестве хеш-функции используется SHA3-256 [4] (FIPS-202).

      Witnesses = ({Witness})
      
      Witness	= (Signature, Public Key Hash)

      Цифровая подпись, полученная посредством подписания заголовка и тела транзакции любой парой ключей из набора, прикрепленного к счёту отправителя, является подписью отправителя. В качестве механизма цифровых подписей используется ECDSA [2] (NIST.FIPS.186-4) на кривой SECP256R1 [3] (RFC 5480).

      Signature	= ECDSA(Public Key, Tx.SigId[i], Private Key)

      При записи транзакции в цепочку она дополняется хешами входных звеньев и выходными звеньями. Звенья идентифицируются 256-битной хеш-функцией. Их уникальность гарантируется системой и проверяется при записи транзакции в цепь. Так же гарантируется уникальность и самих транзакций.

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

      Такие сервисные ключи регистрируются в системе посредством специальной транзакции, подписанной одним из корневых ключей. Сервисные ключи используются для реализации необходимых функций экономической системы Nimses. Примерами таких функций выступают налоговые списания или штрафы за нарушение правил. Эти ключи могут быть использованы вместо пользовательских. Секретные части таких ключей хранятся на специальных устройствах, известных как «Аппаратные модули безопасности», в защищённых сетях, откуда их невозможно извлечь.

      Key Types = {
          KEY_USER,
          KEY_ROOT,
          KEY_MASTER,
          KEY_IDENTITY,
          KEY_TAX,
          KEY_FAMILYPAYMENT,
          ...
      }

      Правила валидации транзакций определяются их типом и типами участвующих счетов.

      6.3 Активы

      Как упоминалось ранее, тип актива определяется 4 байтами, что позволяет добавлять новые типы по мере развития системы.

      На данный момент в системе используются активы двух типов: ним и доминим.

      6.3.1 Ним

      Ним — базовый актив экономической системы Nimses. Он выступает в качестве основного инструмента взаимодействия с Nimses и между пользователями системы.

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

      Для определения количества эмитируемых нимов при проведении транзакций сервер временных меток дополнительно помечает записываемые в цепь транзакции метками астрономического времени и рассчитывает выходные звенья транзакции, учитывая эмиссию нимов.

      2 обычный ним - здесь используется как тип счета

      6.3.2 Доминим

      Доминим — актив, задуманный как основной инструмент захвата и удержания фиксированных территорий (см. Нимономика, Темплы). Один доминим эквивалентен 525960 нимам (1440 * 365.25). В момент регистрации пользователь также автоматически создает себе и доминимовый счет.

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

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

      Иных способов эмитировать доминимы не существует.

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

      6.4 Блоки

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

      Блок состоит из набора транзакций и заголовка блока. Заголовок блока включает в себя хеш заголовка предыдущего блока и корни двух деревьев Меркла. Нумерация высоты блоков начинается с нуля. Самый первый блок с высотой, равной нулю, не имеет предыдущего, и вместо хеша заголовка предыдущего блока используется хеш от слова “nimses”.

      Block Header = (Version, Height, CommitAt, Gen, Prev Block Hash, Tx Root, Receipt Root, Witness)
      
      SHA3-256(nimses)="b6d1672a4ef816d08bfb6c491c946b4eb4f991e6783a0b337b89b1ac94a2b472"

      В Nimses Blockchain блоки не ограничены в размерах. Каждый блок отвечает за некоторый промежуток времени, сейчас это 10 минут. Все транзакции, произошедшие в течение промежутка времени, попадут в соответствующий блок.

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

      Расчёт дерева Меркла для идентификаторов транзакций аналогичен алгоритму, описанному в RFC6962 [5] секция 2.1.2. Применяется хеширующая функция SHA3-256 [4] (FIPS-202). На уровнях с нечётным количеством вершин последняя вершина дублируется.

      6.4.1 Закрепление истории

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

      Сеть Bitcoin удовлетворяет требованиям к публичности и иммутабельности, а потому и выбрана нами для закрепления истории транзакций Nimses. По состоянию на май 2019 года стоимость атаки 51% составляет более девяти миллиардов долларов. Закрепление происходит посредством проведения транзакции с OP_RETURN[6] выходом, в котором записан хеш заголовка блока.

      Nimses открыто публикует заголовки каждого блока на своем сайте и периодически закрепляет хеши заголовков вышеописанным образом. Как только транзакция, которая закрепляет блок высоты h получила безопасное количество подтверждений в сети Bitcoin, все блоки с высотой ≤ h целесообразно считать иммутабельными.

      6.5 Горизонтальное масштабирование (внутренний консенсус)

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

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

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

      В текущей реализации обработка транзакции занимает примерно одну секунду, при этом пропускная способность прямо пропорциональна скорости достижения внутреннего консенсуса.

      7. Заключение

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

      8. Ссылки

      1. [1] Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, https://bitcoin.org/bitcoin.pdf

      2. [2] Federal Information Processing Standards Publication, Digital Signature Standard, July 2013, https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.186-4.pdf

      3. [3] S. Turner, D. Brown, K. Yiu, R. Housley, T. Polk, Elliptic Curve Cryptography Subject Public Key Information, RFC 5480, March 2009, https://tools.ietf.org/html/rfc5480

      4. [4] Federal Information Processing Standards Publication, SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions, August 2015, https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.202.pdf

      5. [5] B. Laurie, A. Langley, E. Kasper, Certificate Transparency, RFC 6962, June 2013, https://tools.ietf.org/html/rfc6962

      6. [6] https://en.bitcoin.it/wiki/OP_RETURN