Отже, ваша команда закінчила alpha-версію вашого блокчейна, і настав час запускати testnet, а потім і mainnet. У вас справжній блокчейн, з незалежними учасниками, гарною економічною моделлю, безпекою, ви спроектували governance і тепер настав час спробувати все це у справі. В ідеальному криптоанархічному світі ви викладаєте в мережу genesis block, остаточний код ноди і валідатори самі все запускають, піднімають усі допоміжні сервіси і все трапляється само собою. Але це у вигаданому світі, а в реальному, команда має підготувати досить багато допоміжного софту та різних маніпуляцій, щоб допомогти валідаторам запустити стійку мережу. Про це ця стаття.
Запуск мереж на базі консенсусів типу “proof-of-stake”, де валідатори визначаються голосами власників токенів системи є досить специфічним заходом, адже навіть запуск традиційних централізовано керованих систем з десятками та сотнями серверів саме по собі непросте завдання, а блокчейн потрібно стартувати зусиллями лояльних, але незалежних учасників. І, якщо в корпорації, при запуску адміністратори мають повний доступ до всіх машин, логів, загального моніторингу, то валідатори нікого не підпустять до своїх серверів і, швидше за все, віддадуть перевагу будувати свою інфраструктуру самостійно, адже вона контролює доступ до основних активів валідатора — стейків. голосуючих. Саме така поведінка дозволяє будувати розподілені безпечні мережі - незалежність хмарних провайдерів, віртуальних і "baremetal" серверів, різні операційні системи, все це дозволяє зробити атаки такої мережі вкрай неефективними - занадто багато різного софту використовується. Наприклад в Ethereum використовується дві основні імплементації ноди, на Go і Rust, і атака, ефективна для однієї імплементації не працює для іншої.
Тому всі процеси запуску та експлуатації блокчейнів повинні бути організовані так, щоб будь-який валідатор, або навіть невелика група валідаторів, могли б у будь-який момент викинути свої комп'ютери у вікно, і піти, при цьому нічого не повинно зламатися і валідатори, що залишилися, повинні продовжувати ефективно підтримувати роботу мережі та підключати нових валідаторів. При запуску мережі, коли один валідатор у Європі, другий у Південній Америці, а третій в Азії, досягти узгодженої роботи кількох десятків незалежних груп і зацікавити їх у результаті досить складно.
Валідатори
Давайте уявімо запуск гіпотетичного сучасного блокчейну (більша частина описуваного підходить для блокчейнів на базі будь-якого сучасного сімейства блокчейнів: Ethereum, EOS, Polkadot, Cosmos та інших, в яких передбачений консенсус proof-of-stake. Головними дійовими особами таких блокчеданів є команди , що займаються встановленням власних незалежних серверів, що валідують і виробляють нові блоки, і отримують нагороди передбачені мережею для тих, хто бере участь у консенсусі.Для запуску нових мереж потрібно кілька десятків валідаторів (стільки зараз можуть більш-менш ефективно досягати консенсусу за секунди), тому проект оголошує реєстрацію, при якій валідатори діляться публічною інформацією про себе з користувачами, переконуючи їх у тому, що збираються якісно обслуговувати мережу, що запускається.
Валідаторство — бізнес, який дозволяє вкрай точно оцінювати потенційний дохід валідатора, швидко переносити потужності між проектами, а у разі успіху обраної ним мережі, валідатор може як повноцінний учасник DAO та відповідальна особа розвивати проект, або просто надавати відмінний технічний сервіс за повністю прозорі чесно зароблені гроші. При розрахунку нагороди валідаторам проекти намагаються враховувати витрати валідаторів і робити нагороду за блоки такою, щоб цей бізнес був прибутковим, але при цьому не давав би валідаторам обвалити економіку заваливши їх грошима та позбавивши інших користувачів мережі.
Бізнес валідаторів вимагає забезпечення високої стійкості до відмови сервісів, а значить — високого рівня підготовки девопсов і розробників і недешевих обчислювальних ресурсів. Навіть без необхідності майнути хеші в proof-of-work мережах, блокчейн нода - це великий сервіс, що займає багато пам'яті, що споживає багато обчислень, валідує, записує на диск і віддає в мережу великі обсяги даних. Для зберігання лога транзакцій та ланцюжків блоків для блокчейна з кількома тисячами невеликих транзакцій у блоці зараз потрібно storage від 50 Gb і більше, і для блоків це має бути SSD. State database блокчейнів із підтримкою смарт-контрактів вже може перевищувати 64Gb оперативної пам'яті. Сервера з необхідними характеристиками є досить дорогими, але Ethereum або EOS може обходитися від 100 до 200 $/month. Додайте до цього збільшену оплату праці за цілодобову роботу розробників та девопса, які в період запуску вирішують проблеми навіть уночі, оскільки частина валідаторів легко може перебувати в іншій півкулі. Тим не менш, у вдалі моменти володіння нодою-валідатор може приносити серйозний дохід (у випадку EOS - до 10 000 $ per day).
Валідаторство - лише одна з нових потенційних IT-ролей для підприємців і компаній, у міру вигадування програмістами все більш витончених алгоритмів, що дозволяють нагороджувати чесність і карати обман і злодійство, з'являються сервіси, що виконують функції публікації важливих даних (оракулів), що виконують нагляд (слешинг) і покарання обманщиків шляхом публікації доказу обману), сервіси вирішення спорів, страховок та опціонів, навіть garbage collection є потенційно великим ринком у системах смарт-контрактів, де необхідно платити за зберігання даних.
Проблеми запуску блокчейну
Відкритість блокчейна, що уможливила вільну участь у роботі мережі комп'ютерів з будь-яких країн та простота підключення до мережі будь-якого script kiddie за інструкцією на GitHub не завжди є перевагою. Погоня за новим токеном часто змушує валідаторів "помайнити нову монетку на старті", сподіваючись на зростання курсу і можливість швидко скинути зароблене. Також, це означає, що вашим валідатором може бути будь-хто, навіть анонім, за нього можна так само голосувати, як і за інших валідаторів (правда, аноніму буде важко зібрати за себе голоси стейкхолдерів, так що страшні казки про анонімні криптовалюти залишимо політикам) . Проте
У команди проекту є завдання — якось отримати у свою мережу тих, хто в майбутньому здатний забезпечити стабільну роботу нід, розуміється на безпеці, вміє швидко вирішувати проблеми, кооперуватися з іншими валідаторами і діяти спільно — від цих якостей повною мірою залежить якість того самого токена, в який зібралися вкласти свій час та ресурси учасники мережі. Адекватні фаундери, оцінюючи ризики, добре розуміють, що при запуску програмного забезпечення такого обсягу обов'язково доведеться зіткнутися з помилками в коді, конфігурації нід, і що стабільність мережі залежить від того, наскільки добре розробники та валідатори спільно вирішуватимуть подібні проблеми.
Команда готова голосувати в mainnet за будь-яких валідаторів, от тільки б знати за яких, які хороші? Найбільшим портфоліо? Його зараз майже ніхто не має. За профілями команди в Linkedin? Досвідчених девопси або безпечники не даватимуть вам жодних профілів у Linkedin. За заявами в чаті, постах та допомозі іншим на етапі підготовки? Добре, але суб'єктивно та неточно.
У таких умовах залишається одне — те, що добре вирішує проблеми всіх — гру, в якій можна буде вибрати найкращих валідаторів, але головне — перевірити блокчейн на міцність та провести повномасштабний бойовий тест блокчейну в умовах активного використання, змін у консенсусі, появи та виправлення помилок. . Вперше цю процедуру подали як гру хлопці з проекту Cosmos, і ця ідея безперечно є чудовим способом підготовки мережі до запуску надійного та стійкого до відмови mainnet
Game of Validators
Я опишу гру валідаторів так, як ми проектували її для блокчейну DAO.Casino (DAOBet) на основі форка EOS, який називається Haya і має близький механізм governance — валідатори обираються голосуваннями з будь-якого облікового запису, при якому частина балансу, яким голосують за валідатора, заморожується. Будь-який обліковий запис, що має на балансі основний токен BET, може проголосувати за обраного валідатора будь-якою частиною свого балансу. Голоси підсумовуються та за підсумками будується top валідаторів. У різних блокчейнах цей процес організований по-різному, і зазвичай саме в цій частині новий блокчейн відрізняється від батьківського, і, треба сказати, що в нашому кейсі EOS повністю виправдовує “OS” у своїй назві, ми дійсно використовуємо EOS як базову операційну систему розгортання модифікованої версії блокчейна під завдання DAOBet.
Я описуватиму окремі проблеми і те, як їх можна вирішити в рамках гри. Уявимо мережу, в якій твій сервер можуть відкрито атакувати, де щоб утримати позицію валідатора потрібно безперервно взаємодіяти з мережею, просуваючи свого валідатора і стежачи за тим, щоб він виробляв блоки і вони вчасно доставлялися до інших валідаторів, інакше валідатор буде викинутий зі списку.
Як вибрати top переможців?
Головна технічна вимога до гри — щоб її результати були публічно перевірені. Це означає, що результати гри: TOP переможців повинні бути сформовані строго на основі даних, які може перевірити будь-який учасник. У централізованій системі ми могли б вимірювати “uptime” кожного валідатора та нагороджувати тих, хто більше був online або пропустив через себе максимум мережевого трафіку. Можна збирати дані про завантаження процесора, пам'яті та нагородити тих, хто гідно працював. Але будь-який такий збір метрик означає існування центру збору, та й ноди всі незалежні і можуть поводитися як хочуть і надсилати будь-які дані.
Тому природне рішення — переможці мають визначатися за даними з блокчейну, оскільки за ним можна побачити, хто з валідаторів який блок зробив і які транзакції до нього були включені. Ми назвали це число Validator Points (VP), і їх заробляння і є основною метою валідаторів у грі. У нашому випадку, найпростішою, легко публічно перевіряється та ефективною метрикою "корисності" валідатора є VP = число_зроблених_валідатором_блоків за заданий тимчасовий період.
Такий простий вибір обумовлений тим, що governance в EOS вже передбачає безліч проблем, що виникають, оскільки EOS — спадкоємець вже трьох поколінь реально працюючих блокчейнів з великим досвідом складного управління мережею, і, практично будь-які проблеми валідатора з мережею, процесором, диском ведуть лише до однієї проблемі — він підписує менше блоків, отримує меншу оплату за роботу, що веде нас знову ж таки просто до блоків, що підписуються — для EOS це відмінний і простий варіант.
В інших блокчейнів, спосіб підрахунку Validator Points може відрізнятися, наприклад для pBFT-based консенсусів (Tendermint/Cosmos, консенсус Aura з Parity Substrate), де кожен блок повинен бути підписаний безліччю валідаторів, має сенс вважати окремі підписи валідаторів, а не блоки, можливо, має сенс враховувати не завершені раунди консенсусу, які витрачають ресурси інших валідаторів, загалом це залежить від типу консенсусу.
Як змоделювати реальні умови експлуатації
Завдання фаундерів — перевірити валідаторів в умовах, наближених до реальності, не маючи ніякого централізованого контролю. Цю проблему можна вирішити за допомогою контракту-faucet-а, який роздає рівні кількості основного токена валідаторам та всім охочим. Для отримання токенів на баланс треба сформувати транзакцію і домогтися того, щоб мережа включила її в блок. Таким чином, валідатор для перемоги необхідно постійно поповнювати свій баланс новими токенами і голосувати за себе, просуваючи себе в топі. Ця діяльність створює постійне навантаження на мережу, а параметри можна підібрати так, щоб потік запитів був серйозним для повноцінного тесту мережі. Тому плануйте контракт-faucet заздалегідь як важливий інструмент для запуску мережі і починайте підбирати його параметри заздалегідь.
Запит токенів з faucet та голосування валідаторів все ж таки не до кінця чесно емулює роботу БЧ, особливо у вкрай навантажених режимах. Тому команді блокчейну все одно так чи інакше доведеться писати додаткові бенчмарки, що дозволяють навантажити мережу. Особливу роль у цьому відіграють заздалегідь створені смарт-контракти, що дозволяють протестувати окрему підсистему. Для тестування storage контракт зберігає в блокчейн випадкові дані, а для перевірки мережевих ресурсів тестовий контракт вимагає великий обсяг вхідних даних, тим самим роздмухуючи обсяг транзакцій - запускаючи потік таких транзакцій у довільні моменти часу команда одночасно тестує стабільність коду і стійкість валідаторів.
Окремим питанням стоїть оновлення коду нод та проведення хардфорків. Потрібно, щоб у разі появи бага, уразливості, змови зловмисних валідаторів, валідатори мали б план дій, вже відпрацьований у грі валідаторів. Тут можна вигадувати схеми нарахування VP за швидке застосування хардфорка, наприклад штрафуючи всіх валідаторів, хто ще не накотив нову версію коду ноди, але це складно реалізувати, ускладнює підрахунок. Семулювати ситуацію екстреного застосування хардфорка можна штучно "зламавши" блокчейн на заданому блоці. Виробництво блоків зупиняється, і в результаті у виграші виявляться ті, хто раніше увімкнеться, і почне підписувати блоки, тому VP на основі числа підписаних блоків тут добре підходить.
Як інформувати учасників про стан мережі та чинити помилки
Незважаючи на недовіру між валідаторами, своєчасно отримувати актуальну інформацію про стан мережі вигідно всім, щоб швидше приймати рішення, тому команда проекту піднімає сервіс для збору та візуалізації безлічі метрик із серверів валідаторів, що дозволяє побачити ситуацію одночасно для всієї мережі, дозволяючи швидко визначити, що відбувається. Також, і валідаторам і проекту вигідно, щоб команда проекту швидко виправляла знайдені помилки, тому, крім збору метрик, має сенс відразу ж запустити збір з машин валідаторів логів і даних про помилки на машину, доступну розробникам блокчейну. Тут нікому не вигідно спотворювати інформацію, тому ці послуги піднімаються командою проекту і їм можна довіряти. Має сенс збирати системні метрики з валідаторів, і, обов'язково, найважливіші метрики самого блокчейну — для DAOBet — це час фіналізації та відставання останнього блоку, що фіналізується. Завдяки цьому команда бачить зростання споживання пам'яті на нодах під час запуску бенчмарку, проблеми окремих валідаторів.
Важливі моменти проведення гри валідаторів
Як виявилося, якщо ви бажаєте офіційно дозволити валідаторам атакувати машини один одного (неофіційно вони і так можуть це робити) — потрібно окремо юридично сформулювати це як тестування безпеки, оскільки за законодавством деяких країн за DDoS або атаки можуть покарати. Ще важливим питанням є те, як нагороджувати валідаторів. Природними призами є токени проекту, які будуть перенесені до mainnet, але масована роздача токенів будь-кому, хто зміг запустити ноду, — теж не найкращий варіант. Швидше за все вам доведеться балансувати між двома крайніми варіантами:
Роздати весь призовий фонд відповідно до зароблених VP
це дуже демократично і дозволяє заробити всім, хто вклав час та ресурси у гру валідаторів
але залучає до гри випадкових людей без підготовленої інфраструктури
Роздати призовий фонд top-N валідаторам за підсумками гри
переможцями швидше за все виявляться валідатори, які найбільше стабільно протрималися протягом гри, дуже строго налаштовані на перемогу
частина валідаторів не захоче брати участь, низько оцінюючи свої шанси перемогти, особливо якщо у складі учасників є маститі валідатори
Якому варіанту віддати перевагу — справа ваша
Є ще один момент — зовсім не факт, що десятки валідаторів кинуться брати участь у грі за вашим покликом, а з тих, хто вирішить спробувати не всі навіть встановлять і запустять ноду — зазвичай, на цьому етапі у проектів досить мізерна документація, трапляються помилки, а розробники, що працюють у цейтноті, відповідають на запитання не надто оперативно. Тому перед запусками гри треба так само передбачити дії, якщо потрібно числа валідаторів не набереться. У цьому випадку на старті гри, валідатори, що бракують, запускаються командою проекту, беруть участь у консенсусі, але не можуть бути переможцями.
Висновок
Наприкінці я постарався зібрати з вищеописаного список того, що потрібно вигадати, зробити та запустити для ефективного проведення гри валідаторів
Що потрібно зробити для запуску справжньої гри валідаторів:
розробити свій блокчейн 🙂
- зробити та підняти web-інтерфейс та надати CLI для голосування за валідаторів
- зробити так, щоб метрики із запущеної ноди валідатора могли вирушати до централізованого сервісу (наприклад Prometheus)
- підняти сервер збору метрик (Prometheus + Grafana) для гри валідаторів
- придумати, як підраховуватимуться Validator Points (VP)
- розробити публічний скрипт, який підраховує VP валідатора на основі даних з блокчейну
- розробити web інтерфейс для відображення top-а валідаторів, та стану гри валідаторів (скільки часу залишилося до кінця, у кого скільки VP тощо)
- розробити та автоматизувати запуск довільної кількості власних нід, спроектувати процес підключення валідаторів до гри (коли і як відключати свої ноди, подавати та прибирати за них голоси)
- розрахувати скільки потрібно видавати токенів та розробити контракт-faucet
- зробити скрипт-бенчмарк (трансфери токенів, масивне використання storage, масивне використання мережі)
- зібрати всіх учасників в одному чаті для швидкої комунікації
- запустити блокчейн трохи раніше початку гри
- дочекатися стартового блоку, почати гру
- протестувати мережу кількома типами транзакцій
- накотити хардфорк
- змінити список валідаторів
- повторювати п.13,14,15 у різному порядку, підтримуючи стабільність мережі
- дочекатися фінального блоку, закінчити гру, підрахувати VP
Треба сказати, що гра валідаторів — історія нова, і проводилася лише кілька разів, тому не варто сприймати цей текст як готове керівництво. Жодних аналогів у сучасному IT бізнесі не існує — уявіть собі, що банки перед запуском системи платежів змагаються між собою, хто краще проводитиме транзакції клієнтів. Традиційні підходи навряд чи допоможуть вам створювати великі децентралізовані мережі, так що освоюйте нові бізнес-моделі, проводьте свої ігри, визначайте гідних, нагороджуйте їх і нехай ваші розподілені системи працюють швидко та стабільно.
Джерело: habr.com