Забезпечення консенсусу за алгоритмом Community PoS у системі обліку токенів розподіленого реєстру Системи Bitbon

Блокчейн[i] є одним із видів розподіленого реєстру[i]. Ключовою особливістю розподіленого реєстру є децентралізація, тобто відсутність єдиного центру зберігання та реєстрації даних. Водночас інформація в усіх вузлах розподіленого реєстру має бути валідною та актуальною, що можливо лише завдяки досягненню консенсусу між усіма вузлами такого реєстру. Перший алгоритм досягнення консенсусу, що був застосований для мережі блокчейн, є загальним випадком розв’язання задачі візантійських генералів, у якому кількість вузлів мережі необмежена та може динамічно змінюватися.

Для розв’язання цієї задачі можна застосувати підхід до організації спільнот, що використовують блокчейн, у тому значенні, що замість спонтанних порядків мають бути запропоновані форми спільної діяльності, де учасники спільнот створювали б децентралізовані громадські організації, що представляють їх інтереси, та брали б участь у розвитку Соціальної мережі «Система Bitbon»[i]. Упровадження такого рішення приводить до потреби створення не лише інструментів, що дозволять спільноті управляти системою обліку токенів розподіленого реєстру[i], але й до створення соціально-правової моделі взаємовідносин користувачів та державних органів.

Такий підхід відкриває можливість підвищити продуктивність систем обліку токенів розподіленого реєстру завдяки використанню синхронних протоколів зі збереженням безпеки та децентралізації блокчейну. Гарним прикладом є запропонований у 2014 році Д. Ларимером протокол Delegated Proof-of-Stake (DPoS, делегований доказ частки), його впровадження дозволило значно підвищити продуктивність системи обліку токенів розподіленого реєстру (число транзакцій за секунду). Проте цей протокол має низку технологічних особливостей, що суттєво обмежують можливості його застосування.

Враховуючи актуальні питання в розвитку технології розподіленого реєстру (TPP), а також ті особливості та недоліки, що виявлені в сучасних консенсусних протоколах, компанією «Сімкорд» було розроблено власне рішення — алгоритм досягнення консенсусу Community PoS (спільний доказ частки).

Алгоритм досягнення консенсусу Community PoS становить удосконалений протокол DPoS завдяки таким рішенням:

• уведення системи автоматичного розподілу часток Реєстраторів[i] (виражених у вигляді потужностей Assetbox[i]) між вузлами мережі, що приводить до усунення проблеми централізації голосування учасників у DPoS, зумовленої принципом Парето 80/20;
• уведення системи рейтингу вузлів для запобігання некоректної поведінки вузлів мережі;
• розвиток системи peer-to-peer (P2P) протоколів і комунікацій;
• децентралізована верифікація блоку всіма вузлами мережі й формування рейтингів вузлів залежно від результатів верифікації;
• уведення стану мережі «відмова в обслуговуванні» для фіксації значення періоду невизначеності, коли бізнес-додаток не може кваліфікувати стан операції, що виконується вузлами мережі;
• організація системи розподілу винагороди за участь у забезпеченні консенсусу Community PoS із урахуванням мотивації розвитку Соціальної мережі «Система Bitbon».

1.1. Головна ідея Community PoS

Головна ідея Community PoS полягає в організації Провайдерів[i] у ролі Реєстраторів, які об’єднують свої Assetbox у пули Реєстраторів за допомогою надання одиниць цифрового активу[i] Bitbon[i] на таких Assetbox для автоматичного розподілу потужності таких Assetbox між вузлами системи обліку токенів розподіленого реєстру для виконання процедури голосування з метою формування послідовності блок-продюсерів, що будуть підписувати та публікувати блоки.

Кожен Провайдер у ролі Реєстратора прагне залучити нових Реєстраторів із метою збільшення потужності свого пулу. Пули Реєстраторів, що мають більшу потужність, мають більше шансів взяти участь у формуванні блоків, тому що їх підтримує більша кількість учасників більшою кількістю Bitbon. Кожен новий Реєстратор автоматично отримує можливість взяти участь як у валідації блоків, що генерують інші Реєстратори, так і у формуванні нових блоків, що суттєво ускладнює організацію атак зловмисників на мережу. Кожен новий Реєстратор зменшує ймовірність потрапляння до групи блок-продюсерів вузлів-зловмисників і водночас збільшує вимоги до апаратних ресурсів і кількості Bitbon, що зловмисник повинен мати для здійснення атаки на мережу. Як свідчать проведені розрахунки, імовірність передбачення зловмисником моменту, коли він зможе здійснити атаку, тобто в нього буде контроль над Assetbox і вузлами, що забезпечить потрапляння таких вузлів до складу блок-продюсерів, становить 10^-40. Отже, збільшення кількості Реєстраторів приводить до подальшого підвищення стійкості до атак на систему обліку токенів розподіленого реєстру Системи Bitbon[i], що робить будь-який із видів атак неможливим.

Компанією «Сімкорд» заплановано два етапи реалізації алгоритму забезпечення консенсусу. У цій статті описано алгоритм, що реалізується на першому етапі (рисунок 1), який є підготовчим до переходу на повністю децентралізовану модель Системи Bitbon згідно з Дорожньою картою децентралізації. Під час переходу на другий етап буде розширено алгоритм і забезпечено прив’язку Assetbox до нод[i] Користувачів[i] (рисунок 1*). Це дозволить Провайдерам запускати власні ноди системи обліку токенів розподіленого реєстру та гарантувати їх надійну роботу, що зі свого боку збільшить диверсифікацію, надійність та безпечність Системи Bitbon загалом.

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

• Атака 51%.
• Timejacking.
• Канібалізм пулів.
• Утримання блоку.
• Дезорганізуюча атака.
• Eclipse атака.
• Атака P + epsilon.
• Чорний список.
• Гнучкість транзакцій.
• Егоїстичний майнінг.
• Скасування всіх транзакцій.
• Подвійне витрачання.
• Випадкові хардфорки.

Організація інфраструктури[i] системи обліку токенів розподіленого реєстру Системи Bitbon на базі консенсусу Community PoS дає можливість побудувати таке децентралізоване середовище виконання Системи Bitbon, соціально-правові, архітектурні та технічні рішення якого дозволять оперативно реагувати на запити сучасного світу та зміни умов без зниження якості сервісу такої системи для її Користувачів.

2.1. Мета Community PoS і способи її досягнення

Головна мета консенсусу Community PoS — забезпечення реальної децентралізації процесу публікації, верифікації та збереження даних розподіленого реєстру за умови високого рівня продуктивності мережі зберігання та малого гарантованого інтервалу очікування підтвердження завершення транзакції.

Досягнення цієї мети забезпечується:

• використанням схеми попереднього узгодження послідовності виробництва блоків блок-продюсерами для запобігання форків і колізій блоків;
• централізацією мережі на момент формування блоку вузлом мережі відповідно до послідовності формування блоків;
• упровадженням жорсткої синхронної циклограми роботи вузлів мережі для забезпечення однозначного визначення стану мережі;
• уведенням стану мережі «відмова в обслуговуванні» для фіксації значення періоду невизначеності, коли бізнес-додаток не може кваліфікувати стан операції, що виконується вузлами мережі;
• взаємною синхронізацією вузлів мережі для забезпечення дотримання циклограми голосування та формування блоків;
• використанням фіксованого максимального часу оброблення транзакції[i] (з відміною в разі невиконання її у визначений період);
• уведенням трьох типів протоколів функціонування вузлів мережі:
  • протокол контролю кворуму та забезпечення синхронізації часу вузлів, що є фоновим процесом, заснованим на опитуванні P2P-мережі та таким, що забезпечує підтримку в актуальному стані інформації про доступність вузлів, які можуть брати участь у процедурах голосування та формування блоків;
  • протокол жеребкування-голосування, у межах якого формується послідовність вузлів мережі, згідно з якою вузли мережі виконуватимуть роль блок-продюсера;
  • протокол формування блоку, що містить створення блоку блок-продюсером, його верифікацію іншими вузлами мережі та систему рейтингу вузлів, що забезпечують коректність виконання вузлами мережі функцій блок-продюсерів;
• використанням алгоритму випадкового розподілу часток (потужностей Assetbox) Реєстраторів між вузлами мережі перед жеребкуванням-голосуванням серед вузлів, рейтинг яких дозволяє їм бути кандидатами у блок-продюсери. Таке рішення дозволяє підвищити рівень складності передбачення послідовності блок-продюсерів. Алгоритм засновано на значенні параметра «nonce» (останнього блоку або генезис-блоку), що, зі свого боку, будується на основі випадкового числа від апаратного генератора випадкових чисел і часової позначки через генерацію хеш-коду від цієї інформації за допомогою Keccak-256 на базі еліптичних кривих. Отримана числова послідовність використовується як ключ для розподілу потужностей Assetbox Реєстраторів на користь вузлів мережі — кандидатів у блок-продюсери;
• механізмом децентралізованого жеребкування-голосування під час визначення порядку виконання вузлами ролі блок-продюсерів, який здійснюється за допомогою сортування списку вузлів за обсягом потужностей, розподілених на користь цих вузлів, визначення меж послідовності та контролю правил участі вузлів у сформованій послідовності блок-продюсерів;
• децентралізованою верифікацією блоку всіма вузлами мережі та розсиланням повідомлення про підвищення або зниження рейтингу блок-продюсера, що генерував блок, залежно від результатів верифікації.

2.2. Ролі вузлів у межах консенсусу Community PoS

Кожен вузол мережі Системи Bitbon може виконувати такі ролі:

• Вузол синхронізації. У межах цієї ролі вузол мережі під час підключення до мережі здійснює синхронізацію з іншими вузлами через отримання блоків, транзакцій та пов’язаних із ними об’єктів від інших вузлів мережі, їх верифікації та збереження в локальному сховищі. Синхронізація часу вузла здійснюється згідно з позначкою часу останнього валідного блоку та метрикою затримки до блок-продюсера, що сформував цей блок, а також позначок часу від інших вузлів мережі. Після процедури синхронізації вузол виконує верифікацію та збереження транзакцій і блоків, що надходять до нього. Якщо метрика часу поширення блоку для цього вузла менше за 1 секунду, то цей вузол мережі зобов’язаний брати в оброблення транзакції від клієнтських додатків і після верифікації ретранслювати їх усім іншим вузлам мережі. В іншому випадку або якщо кворум мережі вузлів не досягнутий, то вузол не бере транзакції в оброблення, повертаючи помилку «відмова в обслуговуванні».
• Вузол-учасник кворуму. У цій ролі може бути будь-який вузол синхронізації, у якого величина мережної затримки до вузлів, що входять до складу кворуму, не має перевищувати 400 мс. Для реалізації протоколу роботи консенсусу Community PoS у мережі має бути присутньою кількість вузлів, що більша за розмір кворуму, визначений Операторами Системи Bitbon[i] (не менше 2/3 кількості вузлів мережі). Вузол-учасник кворуму бере участь у процедурі формування рейтингу відповідно до системи рейтингу вузлів. Якщо в процесі оброблення транзакцій і блоків учасник кворуму виявляє порушення правил оброблення, то він надсилає всім вузлам мережі відповідне повідомлення про зниження рейтингу джерел невалідних даних. Якщо дані валідні, то надсилається повідомлення про підвищення рейтингу відповідних блок-продюсерів.
• Кандидат у блок-продюсери. У цій ролі може бути будь-який вузол-учасник кворуму з рейтингом вище за 10, якщо в нього вміщений режим провайдингу[i]. У цьому випадку такий вузол братиме участь у процедурі розподілу потужностей (часток) Assetbox пулу Реєстраторів.
• Блок-продюсер. У цій ролі виступає вузол мережі — кандидат у блок-продюсери, що був доданий до послідовності блок-продюсерів через виконання процедури жеребкування-голосування для підпису та публікації лише одного блоку у визначений момент часу (тайм-слот) (рисунок 2).

2.3. Забезпечення системи жеребкування-голосування

Щоб запобігти загрозам централізації Системи Bitbon і з метою автоматизації процедури голосування Реєстраторів у межах участі у забезпеченні консенсусу в системі обліку токенів розподіленого реєстру Системи Bitbon передбачено процедуру автоматичного перерозподілу часток (потужностей Assetbox) між кандидатами у блок-продюсери.

Для участі Assetbox в автоматичному голосуванні досить один раз здійснити передачу потужності Assetbox Реєстратора до пулу за допомогою переказу 0,0001 Bitbon із коментарем «/pool» на будь-який Assetbox пулу Реєстратора.

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

2.4. Процедура жеребкування-голосування

Метою процедури жеребкування-голосування є формування на основі розподілених потужностей Assetbox між кандидатами в блок-продюсери послідовності блок-продюсерів, згідно з якою ці блок-продюсери будуть підписувати та публікувати блоки в наступному раунді.

Процедура жеребкування-голосування здійснюється згідно з циклограмою голосування та формування блоків (рисунок 2) і складається з раундів, тривалість яких дорівнює кількості блок-продюсерів, помноженій на інтервал часу, що дорівнює 1 секунді. Число блок-продюсерів задається Операторами Системи Bitbon.

Процедура жеребкування-голосування починається після закінчення чергового раунду. Жеребкування-голосування виконується протягом усього раунду. Ознакою закінчення чергового раунду може стати фінальний блок раунду або повідомлення позначки часу замість нього, якщо в цей тайм-слот не було транзакцій. Голосування виконується в такому порядку:

• протягом перших 2 секунд кожен вузол на основі розподілених потужностей Assetbox між кандидатами у блок-продюсери має випадковим чином сформувати список можливих позицій (послідовність) від 1 до n для кожного з вузлів-кандидатів у блок-продюсери з потужністю вищою за нижню межу та відповідним рейтингом, потім надіслати хеш цього списку (послідовності) усім вузлам-учасникам кворуму;
• із числа вузлів, що можуть бути додані до послідовності, виключається блок-продюсер, який останнім формує блок у поточному раунді;
• елементи послідовності з однаковими позиціями не допускаються;
• заборонено додавати до послідовності 2 елементи з одним ідентифікатором;
• на 5-й секунді кожен вузол-учасник кворуму має за кількістю голосів за кожен унікальний хеш послідовності визначити, чи набрала максимум голосів сформована ним послідовність. Якщо ні, то вузол переходить у режим очікування отримання послідовності блок-продюсерів. В іншому випадку вузол перевіряє, чи число голосів більше або дорівнює 2/3 кворуму. Якщо число голосів більше або дорівнює 2/3 кворуму, то вузол публікує отриману послідовність. В іншому випадку вузол публікує повідомлення про помилку формування послідовності та переходить у режим очікування початку наступного раунду;
• кожен вузол до 9-ї секунди отримує послідовність створення блоків або помилку від інших вузлів.

Кожен вузол, незалежно від ролі, верифікує блоки, що надходять, відповідно до розрахованої/отриманої послідовності блок-продюсерів. Кандидат у блок-продюсери, зазначений у послідовності, що результує, у свій тайм-слот виконує роль блок-продюсера.

2.5. Формування блоків

Блоки формуються блок-продюсерами в раундах довжиною n блоків (наприклад, довжина раунду 21 блок). Блок-продюсер формує блок із транзакцій, що знаходяться у його транзакційному пулі в період між позначкою часу останньої транзакції в останньому валідному сформованому блоці та часом формування блоку в поточному тайм-слоті, що він обслуговує, згідно з правилами:

• якщо на оброблюваний тайм-слот не припало жодної транзакції, блок не формується, але водночас усім вузлам надсилається позначка часу закінчення тайм-слоту;
• вузол у ролі блок-продюсера формує блок на базі хеш-коду попереднього валідного блоку з транзакцій, що знаходяться в його транзакційному пулі;
• у межах раунду блок-продюсер може формувати блок лише 1 раз;
• блок-продюсер за жодних умов не може формувати 2 блоки підряд;
• усі вузли (зокрема і блок-продюсери в поточному раунді) виконують роль вузла синхронізації, отримуючи транзакції, виконуючи їх та перевіряючи блоки, що надходять:
  • якщо блок валідний, то він та транзакції, що до нього входять, фіксуються у сховищі;
  • якщо блок невалідний, вузол його ігнорує та чекає на прихід валідного блоку з таким самим номером;
• якщо блок-продюсер не зміг верифікувати попередній блок під час обслуговування свого тайм-слоту, то він формує новий із тим самим номером, долучаючи до нього всі транзакції у транзакційному пулі, зокрема й такі, що надійшли у минулі тайм-слоти, відсортовані за часом створення (за винятком тих, у яких закінчився час оброблення). Як і вузли синхронізації, блок-продюсер розсилає повідомлення про зниження рейтингу попереднього блок-продюсера.

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

2.6. Рейтинг вузла

Рейтинг кожного вузла формується за допомогою повідомлень, що розсилаються P2P-мережею всіма вузлами як результат верифікації чергового формування блоку. Зміни рейтингу приймаються всіма вузлами мережі на користь усіх вузлів мережі, зокрема на користь блок-продюсера, та застосовуються через період часу, що за тривалістю дорівнює 3 тайм-слотам після формування блоку, за умови, що кількість повідомлень буде більшою або дорівнюватиме кворуму (водночас контролюється кількість повідомлень від кожного вузла). Враховується лише одне повідомлення від вузла на кожен блок. Далі наведено основні фактори, що впливають на рейтинг вузлів:

• підвищення рейтингу:
  • за коректно сформований блок;
  • за виконання умов участі у кворумі (видається Оператором Системи Bitbon);
  • якщо блок-продюсер сформував за добу хоча б один блок і не отримав зниження рейтингу;
• зниження рейтингу:
  • якщо блок-продюсер умістив понад 10 транзакцій, що належать до попереднього тайм-слоту;
  • якщо блок-продюсер сформував блок не у свій тайм-слот;
  • якщо блок-продюсер не сформував блок і не надіслав пакет із часовою позначкою в свій тайм-слот;
  • якщо вузол надіслав більше ніж 2 повідомлення про підвищення/зниження рейтингу на один блок (паузу);
  • якщо вузол транслював невалідну транзакцію або одну й ту саму транзакцію повторно (за кожний повтор);
  • обнуління рейтингу, якщо блок-продюсер сформував невалідний блок (умістив невалідну транзакцію).

Описана система зворотного зв’язку дозволяє ефективно припиняти атаки та некоректну поведінку потенційних зловмисників, а також вилучати з кворуму нестабільні вузли мережі.