Як створити систему електронного голосування на блокчейні?

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

Навіщо потрібен блокчейн у системі голосування?

Голосування як процес прийняття рішень з найважливіших для суспільства питаннях відоме людству тисячі років. Був час, коли рішення приймалися вузьким колом уповноважених осіб шляхом кидання кольорових кульок у спеціальну амфору або жестом руки. Однак, населення зростало, суспільство розвивалося і в процесі прийняття рішень стали брати все більше людей – сотні тисяч і навіть мільйони. Тоді на зміну таким простим методам підрахунку голосів прийшли складніші: почали створюватись виборчі дільниці, амфори замінили на урни для голосування, а кульки – на виборчі бюлетені. Хоча такий підхід до голосування дозволив враховувати думку величезних мас населення, він має низку мінусів:

Технічні: можливість вкидання бюлетенів; використання зникаючого чорнила на ділянках для підробки результатів; підробка протоколів; порушення таємниці голосування; навмисні помилки у підрахунках; низька швидкість підрахунку результатів.
Соціальні: підкуп («каруселі» тощо); адміністративний тиск на виборця.
Економічні: висока вартість державного бюджету. Наприклад, вибори 2015 року в Росії коштували майже 100 000 000 $.

Частина з описаних проблем вирішують електронні системи голосування (застосовуються в таких країнах як Індія, Бразилія, Естонія, Нідерланди, США Німеччина), хоча їх використання також несе у собі ряд мінусів:

Проблеми з безпекою (електронні системи можуть бути зламані, найчастіше пов'язані гучні скандали)
Проблеми з верифікацією результатів виборів (на відміну від паперових бюлетенів, які можна перерахувати)
Можливість некоректної роботи системи через помилки в ПЗ

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

В основі технології блокчейн лежить транзакційна модель: у кожного користувача є гаманець з унікальними публічним та приватним ключами, якими він підтверджує будь-яку зміну даних. Вся інформація про транзакції зберігається в послідовно записаних блоках, таким чином, хеш даних попереднього блоку входить до наступного. Так забезпечується незмінність даних – зміна будь-якого блоку автоматично зробить невалідними наступні. Блокчейн зберігає всю інформацію про всі транзакції в повному обсязі одночасно на всіх вузлах, і вона не може бути змінена або видалена. Найбільш широке застосування блокчейн знайшов саме у сфері реєстрації даних про рух майнових прав на якісь цифрові об'єкти – на цій ідеї побудовано всі сучасні криптовалюти.Такі об'єкти, звані зазвичай «монетами» або «токенами», можуть або створюватися автоматично, за заздалегідь обумовленим алгоритмом, у процесі експлуатації системи («майнутися») або випускатися учасником системи, що має на це права.

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

Непідробленість результатів. Результати голосування, організованого із застосуванням блокчейн технологій, неможливо підробити. Завжди можна перевірити, скільки голосів було випущено на початку голосування, як вони розподілялися по гаманцях і коли проводилися транзакції
Прозорість процесу. Блокчейн дає можливість контролю над ходом голосування, оскільки будь-яка зацікавлена особа може розгорнути вузол з повною копією всіх даних і самостійно проаналізувати їх лише на рівні блокчейна.
Анонімність. Кожен учасник голосування має можливість створити пару з публічного та приватного ключа на локальній машині і ніхто, крім нього, не знатиме про те, що конкретний гаманець належить саме йому. Таким чином, ніхто не може знати, як проголосував цей учасник, за винятком випадку, коли учасник сам оголосить про те, що цей гаманець належить йому.
Швидкість обробки даних.Голосування в межах міста, регіону, країни або корпорації з офісами в різних країнах може бути пов'язане зі значними витратами, організаційними складнощами та тимчасовими втратами – як на проведення голосування, так і на обробку даних. Децентралізація дозволить бачити результати голосування по всій країні в цілому, незважаючи на те, що кожен регіон/місто/район може експлуатувати власний вузол системи для розподілу навантаження.

Багато з існуючих проектів засновані на будь-якій розвиненій платформі на зразок Ethereum або Bitcoin. Хоча останнім часом курс криптовалют дуже волатильний, той самий Ефір вражаюче виріс порівняно з початком року, що робить голосування, що базуються на цій платформі досить дорогими.
Більшість цих систем використовують алгоритм proof of work, що робить обчислення результатів при масштабному голосуванні дуже повільним (детально проблеми зазначені вище описані тут:
Вони просуваються виключно як самостійні платформи для голосування (тобто, для проведення голосування або участі в ньому ви повинні пройти явний процес реєстрації на платформі).
Більшість їх залишилася лише на рівні ідеї чи перестала розвиватися

Про процес голосування

Голосування у нашій системі є транзакцією. Кожен із варіантів, за який можна проголосувати, має свій гаманець, на який учасники голосування (кожен із яких також має гаманець), переводять голосувальні токени. Для кожного голосування випускається унікальний токен, таким чином, токеном, випущеним, наприклад, для голосування про улюблений чай, не можна проголосувати за будівництво стоянки замість дитячого майданчика.

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

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

У прототипі процес створення голосування складається з кількох етапів:

Користувач реєструється в системі та на локальній машині генерує ключову пару гаманця. Система просить у користувача кодове слово і шифрує їм дані гаманця, після чого зберігає зашифрований гаманець в той же блокчейн, щоб позбавити користувача необхідності встановлювати спеціалізоване програмне забезпечення гаманця. У той же час, гаманець у відкритому вигляді обробляється тільки на стороні клієнта, що гарантує доступ до гаманця тільки у його господаря. Однак, важливо розуміти, що при втраті кодового слова користувач втратить і доступ до гаманця, і в цьому випадку допомогти йому буде неможливо.
На етапі прототипу ми вирішили видавати всім зареєстрованим користувачам 10 IDV токенів, призначених для оплати створення голосування в системі.За їх допомогою будь-який зареєстрований учасник зможе організувати голосування та подивитися, як працює весь процес. Тому одразу після створення гаманця наш процесинговий сервер нараховує на гаманець користувача 10 IDV.
Вартість створення голосування у системі становить 1IDV. Таким чином, коли користувач створює голосування, система перевірять баланс і, якщо коштів достатньо, списує 1 токен і робить підготовку голосування: створює гаманці для варіантів голосувань і емітує деяку кількість унікальних голосувальних токенів. Результати створення голосування (чи було створено успішно, якщо ні, то чому) записуються в спеціальний лог, який також зберігається в блокчейні.

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

Трохи про вибрані технології

Перш ніж розповісти про технологічну складову проекту, зауважимо наступне: основним завданням проекту ми бачимо надання зручних засобів для вбудовування надійних голосувань на блокчейн платформі в будь-яку сторонню програму. Саме тому особливу увагу ми приділяємо розробці зручного API. Звичайно, ми надамо власні клієнти для голосування, проте ми розробляємо їх насамперед для демонстрації можливостей нашої платформи для голосування. Нижче розглянемо технологічну сторону проекту.
Як і в попередніх проектах, за базу ми взяли Mulitchain блокчейн. Ми виходили з таких міркувань:

Безпека. Одна з уразливостей більшості блокчейн систем криється в її гідності — анонімності. Коли будь-хто може розгорнути будь-яку кількість вузлів, що пишуть, є ризик, що він розгорне 51% від загальної кількості вузлів зі зміненою інформацією та інші вузли приймуть її до запису, так як за нею стоятиме найдовший ланцюжок блоків. Це називається атакою 51 відсоток. Для запобігання таким атакам у більшості публічних алгоритмів застосовується алгоритм підтвердження Proof of Work — кожен вузол вирішує складне математичне завдання, за що отримує певну винагороду (майніт монети). Розв'язання задачі потребує часу та значних обчислювальних потужностей. Це робить таку атаку надто дорогою та недоцільною. Основна особливість Multichain у тому, що він спеціально створено організації блокчейна за принципом консорціуму, тобто. для обмеженого кола осіб, які один одного, тобто. не анонімні. У нашій реалізації всі вузли, що підключаються до блокчейну, за замовчуванням є Read only вузлами. Тобто, вони зберігають усі дані, проте не мають права на запис нових даних. Для отримання права на запис вузол повинен отримати відповідні права Master вузла. Таким чином, ми забезпечимо запис нових даних у систему лише автентифікованими вузлами та знизимо ризики шахрайства. У той же час, Read only вузли отримують повну копію всіх даних блокчейна і можуть самостійно аналізувати дані голосування на несуперечність.
Ресурсоємність. Як було зазначено вище, при застосуванні алгоритму Proof of Work потрібні значні обчислювальні, а при зростанні числа користувачів ще й тимчасові ресурси. Для вирішення цієї проблеми ми відмовляємося від алгоритму Proof of Work на користь Proof of Authority, у цьому випадку ми даємо право на запис інформації лише вузлам, що тільки ідентифікували себе. Таким чином, нова інформація потрапляє до блокчейну значно швидше і «ціна запису» стає мінімальною.
Досвід. У нас є досвід застосування цієї блокчейн-платформи в минулих проектах, і ми добре знаємо, як вирішувати складності, що виникають.

Структура системи розділена на 3 сегменти:

UI – програми кінцевого користувача, які підключаються до загальнодоступних сегментів REST API (Common Area сегмент) або безпосередньо до читаючого вузла БЧ (на схемі не відображено). У прототипі для демонстрації функціоналу ми реалізували UI веб-сайт як SPA на Angular. Будь-який бажаючий може реалізувати свій UI на будь-якій доступній технології, використовуючи наші REST API або Read only вузол Multichain як джерело даних.

Common Area – це N вузлів системи, на яких розгорнуть Multichain у режимі запису та Web сервер із API для загального доступу.

REST API веб-сайт, написаний на ASP.NET Core 1.1. Реалізовано роботу з метаданими голосування, архівом метаданих, самим процесом голосування (вибір варіанта та віддача голосу за нього), а також гаманцем користувача. Детальний опис API можна переглянути тут.

Private Area - Закрита для загального доступу (запису) частина системи, до складу якої входить процесинговий сервер і сервер авторизації користувачів.
У пропрієтарну частину ми винесли процесинговий сервер та сервер авторизації користувачів:

Processing Server

Нарахування IDV токенів під час реєстрації користувача (для оплати створюваних голосувань)
Створення голосування
Управління станом голосування (відкриття та закриття згідно з заданими умовами)
Нарахування користувачеві голосувальних токенів.

Сервер ідентифікації користувачів системи. Реалізовано на ASP.NET Core 1.1 із використанням компонента IdentityServer 4.

Реєстрація користувачів;
Аутентифікація користувачів;
Авторизація користувачів;

Обмеження прототипу

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

Прототип

Подивитися прототип та випробувати створення голосування можна тут. Якщо ви хочете розгорнути у себе Read only вузол - зв'яжіться з нами через форму на сайті - ми надішлемо вам інструкції як це зробити.

Як влаштована федеральна система дистанційного електронного голосування у Росії

У 2019 році до нас звернувся «Ростелеком» із пропозицією взяти участь у розробці бекенду федеральної системи дистанційного електронного голосування (ДЕГ) на основі блокчейну. Порівняно із звичайним голосуванням ДЕГ на блокчейні явно дешевше та швидше для підрахунку голосів; воно також може забезпечити більшу явку.Але при цьому для більшості людей блокчейн-голосування — це чорна скринька, а в голосуваннях такого рівня скринька таки має бути прозорою. Про те, як ми досягли цього та виконали інші вимоги замовника, я розповім далі у пості.

Вимоги до системи ДЕГ формувала Центральна виборча комісія. Ось їхній вихідний список на 2019 рік.

Запуск понад 1000 голосувань одночасно. Забігаючи наперед, скажу, що у 2021 році, поки що найнавантаженішому для системи, ми одночасно запустили близько 1700 голосувань.
Обробка 10 млн. голосів за 12 годин, тобто приблизно 230 tps (транзакцій в секунду). Згодом мінімально допустима швидкість зросла вдвічі, оскільки на кожен голос довелося відправляти додаткову транзакцію, яка підтверджує факт видачі сліпого підпису, тобто видачі бюлетеня.
Гарантований облік голосів.
Захист таємниці голосування.
Захист проміжних результатів голосування.
Захист результатів голосування.
Можливість перевірки того, як усі ці вимоги дотримані.

На початок проекту ми вже мали готовий криптографічний протокол і власну блокчейн-платформу Waves Enterprise. Через смарт-контракти в ній можна було одразу розгорнути всю необхідну логіку та захистити дані відповідно до вимог. Але ж були нюанси.

Продуктивність (пропускна спроможність). Ми завжди приділяли їй увагу, але до 500 tps з ходу смарт-контрактах були не готові.
Гарантія виконання транзакцій. За замовчуванням блокчейн дуже намагається виконувати всі транзакції, але не гарантує цього принцип best effort basis. Для голосування так не піде, потрібні залізні гарантії.

Далі я загалом опишу, як працює наша блокчейн платформа WE.Vote для дистанційних голосувань, а потім те, як ми змінили її для ДЕГ, щоб відповідати вимогам до федеральної системи.

Вихідна архітектура WE.Vote

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

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

Третім іде класичний клієнт-серверний шар – веб-інтерфейси адміністратора та учасника голосування, а також деякі допоміжні сервіси. Адміністратор керує запуском/зупинкою голосувань через взаємодію із криптосервісами. Учасник відправляє бюлетень безпосередньо у ноду.

Зміни для федерального ДЕГ

Вихідна архітектура нашої платформи голосування відповідала вимогам ЦВК частково. Ось що ми зробили, щоб закрити питання, що залишилися.

У нашій платформі створення ключа голосування було повністю автоматизовано.У ЦВК нас попросили зробити його більш наочним та відокремленим від ядра системи — щоб члени виборчих комісій безпосередньо брали участь у запуску та проведенні голосувань, створюючи таким чином додатковий бар'єр для зловмисників.

У рамках федерального ДЕГ створення ключів частково винесено до офлайну. У виборчої комісії є ноутбук із спеціальною утилітою, яка створює ключ. Потім по схемою поділу секрету Шаміра ключ розбивають на кілька частин та на знімних носіях роздають власникам ключа. Після завершення голосування ключ знову збирають. Маючи ключ системи та зібраний ключ комісії, можна розшифрувати підсумки голосування. Завдяки розподіленому зберіганню зловмисник не зможе маніпулювати ключами, навіть потрапивши до контуру голосування.

Наступний крок - інтеграція з компонентами, розробленими "Ростелекомом". Тут ми створили чергу повідомлень. У цій частині системи немає ні особливих навантажень, ні секретних даних, зроблено це лише спрощення інтеграції.

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

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

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

Оптимізація пропускної спроможності

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

На початок проекту ДЕГ власна платформа, мейннет Waves Enterprise, забезпечував лише 10–20 транзакцій на секунду. Мала бути велика робота, і ми почали дослідження.

Число транзакцій в секунду обернено пропорційно розміру транзакції. На розмір транзакції ми не можемо вплинути, оскільки бюлетені надає замовник. Тому ми взяли за стандарт бюлетень із вибором однієї партії з восьми та зосередилися на оптимізації. Перевели транзакції у бінарний вигляд, навчили ноди серіалізувати Protobuf та перекодували криптографічні константи у HEX. Ноди отримали додаткове навантаження у зв'язку з введенням серіалізації/десеріалізації, але в результаті пропускна здатність зросла приблизно в 10 разів.

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

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

Спробували підійти через залізо. У результаті найпотужніших стендах домагалися 500–600 tps. В цілому вплив процесора і пам'яті виявилося не таким значним, як ми припускали, тому розвивати цю тему ми не стали. Однак за допомогою інструментів профілювання ми також знайшли пару багів, і після фіксування ноди почали працювати швидше.

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

Я писав вище, що блокчейн сам не гарантує, що всі транзакції будуть проведені. Нашим порятунком тут стала Kafka, за допомогою якої ми створили чергу на обробку голосів. Інший сценарій для Kafka тут — притулок під час перезавантаження системи для даних, які нода не прийняла в блокчейн. За замовчуванням дані зберігаються лише у оперативної пам'яті ноди і за перезавантаженні знищуються. У цій ролі Kafka, на щастя, нам не знадобилася, але варто було перестрахуватися.Третій сценарій Kafka - це тротлінг навантаження для пікового годинника. 40–50% виборців приходять голосувати в першу годину роботи ДЕГ, і Kafka дозволяє це навантаження згладжувати.

Також ДЕГ стала першим проектом, де ми розгорнули свою версію CFT-консенсусу, який не призводить до роллбеків. Коли ми починали з PoS, ролбеки ускладнювали взаємодію компонентів і нам доводилося пояснювати, що це не ми викинули голоси із системи, а потім щось назад записали, а це технологічна особливість. Якщо цікаво дізнатися про наш CFT-консенсус докладніше, напишіть у коментарях.

На наймасштабнішому голосуванні на даний момент, 2021 року, ми не втратили жодну з 1,5 млн транзакцій. Але один голос довелося таки відхилити — він не пройшов перевірку ZKP.

Моніторинг усієї системи ДЕГ

Фронтенд системи, як я вже писав, був у зоні відповідальності «Ростелекому». Нам залишилося протестувати лише бекенд — по суті велику трубу, яка має забезпечити на виході стільки ж голосів, як і на вході.

Для тестів ми розробили утиліту навантаження; вона вміла створювати голосування пачками і марнувати систему як слід. На кожній ділянці ми повісили лічильники транзакцій і стали чекати на помилки майнінгу та валідації.

Якщо у нас збільшується кількість голосів зі статусом pending — «було відправлено на ноду, але не опрацьовано» — ми розуміємо, що нода не справляється і є якісь проблеми. Аналогічно ми можемо відслідковувати інші етапи. Grafana може моніторити і Kafka: скільки голосів через неї було відправлено, який лаг вичитування.

Крім підрахунку голосів, ми повинні розподілити ресурси по компонентам «труби» так, щоб не виникало ботлнеків. Тому кожен компонент передбачає моніторинг ресурсів.Дивно, але інструмент моніторингу подекуди сам вимагав більше ресурсів, ніж окремі компоненти системи, що опрацьовують голоси. Тож лічильники ми повісили і на моніторинг.

Моніторинг блокчейн-мережі

Через Grafana ми розгорнули моніторинг майнінгу. Якщо висота блокчейна на графіку рівномірно зростає, значить, ноди майнят і все працює як слід:

Якщо ноди обробляють блоки нерівномірно, то мережа починає роз'їжджатися і треба вживати заходів:

Тут ми зіткнулися лише з одним цікавим епізодом на тестовому прогоні. На швидкості 200 tps безпечники відключили доступ по мережі. Після відновлення та перезапуску методу відправлення всі ноди протягом 5–10 хвилин зібралися, синхронізувалися та обробили всі транзакції з UTX-пулу — а їх накопичилося близько півтори тисячі. У результаті не втратили жодної.

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

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

Якщо говорити про бойові метрики, то цього року голосування було менш масштабним порівняно з минулим роком, коли показники сягали 120 tps. І в нас завжди був великий запас продуктивності.

Прозорість системи

Насамкінець — про те, що легко проґавити в процесі розробки.Зазвичай, якщо для завдання замовника ми маємо працююче рішення, то справа в капелюсі. Але у проекті національних виборів дуже важливо, щоб рішення було ще й прозорим. У цьому напрямі ми ведемо активну роботу.

Минулого року за нашою системою ДЕГ стежили всього п'ять спостерігачів, а в цьому їх стало вже 109. Для них був розроблений портал спостереження, який підключений до черги зворотного зв'язку і отримує дані одночасно з іншими компонентами системи. Вивантаження з цього порталу спостерігачі могли завантажувати додатково розроблену нами open-source утиліту. Порівнюючи дані, прозоро оброблені цією утилітою, і дані блокчейна голосування, спостерігачі могли переконатися, що все обробляється однаково.

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

Висновки

За підсумками проекту федеральної системи ДЕГ можна зробити кілька висновків з погляду технології.

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

Для подальшого занурення раджу свій попередній пост про те, як працює дистанційне голосування на блокчейні. Також у мережі виходили звіти незалежних спостерігачів про нашу із «Ростелекомом» систему за підсумками голосування 2021 і 2022 мм. На Youtube можна переглянути відеоверсію цієї посади.

Як включити себе до списку для електронного голосування