Назад

      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 відповідає вимогам до публічності та іммутабельності, і саме тому вибрана нами для закріплення історії транзакцій. Станом на травень 2019 року вартість атаки 51% становить більше ніж дев’ять мільярдів доларів. Закріплення відбувається шляхом проведення транзакції з OP_RETURN[6] виходом, в якому записаний геш заголовка блоку.

      Nimses відкрито публікує заголовки кожного блоку на своєму сайті й періодично закріплює геші заголовків вищеописаним чином. Тільки-но транзакція, що закріплює блок висотою h, отримала безпечну кількість підтверджень у мережі Bitcoin, всі блоки з висотою ≤ h доцільно вважати іммутабельними.

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

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

      Відсутність необхідності повної реплікації цілої історії між величезною кількістю учасників задля прийняття рішень дозволяє розпаралелити обробку транзакцій та забезпечити високу пропускну здатність.

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

      У поточній реалізації обробка транзакції займає приблизно одну секунду, при цьому пропускна здатність прямо пропорційна швидкості досягнення внутрішнього консенсусу.

      7. Висновок

      Запропонована гібридна система відповідає заданим технічним вимогам. Довіра з боку користувача обумовлена неприйнятною трудомісткістю зміни даних, закріплених у зовнішньому реєстрі. Спеціальна модель транзакцій, яка допускає паралельну обробку, динамічний розмір блоку – все це дозволяє досягнути пропускної здатності, необхідної для загальнопланетарної системи обміну активами.

      8. Посилання