Чи буде загальна кількість DOT зафіксована? Gavin розкрив ключові напрямки дизайну в чаті JAM!

Gavin не відпочиває навіть на вихідних — він відповідає на запитання у чаті JAM! Він поділився чималою кількістю важливих Alpha щодо дорожньої карти JAM протоколу. 👀

Він не лише пояснив, як у майбутньому розвиватиметься Bootstrap-сервіс JAM і які можливі варіанти його реалізації, а й вперше чітко висловив радикальну ідею з "конституційним значенням" — зафіксувати загальну кількість DOT як π × 10⁹ (приблизно 3.14 мільярда) і записати це у genesis block JAM.

Ключові слова цієї дискусії:

• Bootstrap-сервіс: "система запуску плагінів" JAM-ланцюга, яка в майбутньому більше не буде монополізована Parity, а може реалізовуватися і замінюватися різними командами
• π × 10⁹: пропозиція фіксованої кількості DOT із символічним значенням, що стоїть за більш стабільним і захищеним від зловживань дизайном економіки
• Gray Paper Editorial Board (GPEB): поступово замінить Gavin і визначатиме напрямок розвитку версій JAM-протоколу
• Автономне форкування: Polkadot може у будь-який момент обирати версію протоколу або навіть створити власний "Blue Paper", забезпечуючи технічний суверенітет спільноти
• Хто фінансує? Якщо Polkadot Treasury використовує JAM, він має забезпечити базовий бюджет для роботи редакційної ради

Це не просто "підсумок Q&A", а фактично окреслення повної концепції того, як JAM-протокол поступово рухається до технічної нейтральності + контрольованого управління + автономної еволюції у баченні Gavin.

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

Як розвиватиметься Bootstrap-сервіс JAM?

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

Ще важливіше: у майбутньому Bootstrap-сервіс JAM не буде мати лише одну версію і не буде монополізований Parity.

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

Можливо, вам цікаво, що таке Bootstrap-сервіс JAM?

Просте пояснення:

Коли JAM-ланцюг запускається, він завантажує сервіс "найбільш базових функцій", як комп’ютер при запуску запускає BIOS.

Наприклад, якщо у майбутньому JAM-протокол замінить релейний ланцюг Polkadot, що потрібно зробити на першому кроці запуску цього ланцюга? Потрібно повідомити ланцюгу:

• Чи є система стейкінгу (Staking)?
• Чи є система управління?
• Хто є початковими акаунтами? Як розподіляються початкові DOT?
• Чи потрібно налаштовувати певні функції смарт-контрактів?
• Чи потрібно підключати зовнішні сервіси (наприклад, систему голосування, оракул тощо)?

Усе це не прописано жорстко у протоколі, а інжектується у ланцюг під час запуску (bootstrap) через модульний сервіс. Цей сервіс і є "Bootstrap-сервіс", про який говорить Gavin.

Отже, роль Bootstrap-сервісу:

• Ініціалізує модулі JAM-ланцюга: такі як staking, governance, treasury тощо
• Інжектує логіку виконання: наприклад, "яка загальна кількість DOT", "як розподіляються DOT", "хто може голосувати" тощо
• Визначає початковий стан ланцюга: які сервіси є у genesis block, у якому порядку вони активуються

Bootstrap — це "кастомізоване меню запуску" JAM-ланцюга, яке визначає, які функції та налаштування будуть при запуску ланцюга.

Чому Gavin вважає, що Bootstrap не має контролюватися лише Parity?

Тому що це як: якщо всі комп’ютери у світі могли б запускатися лише з BIOS від Microsoft, це було б небезпечно і несвобідно.

Він хоче, щоб у майбутньому не лише Parity, а й інші команди могли розробляти різні Bootstrap-сервіси, наприклад:

• З акцентом на приватність
• З акцентом на масштабування продуктивності
• Для певних галузей (наприклад, ігрові ланцюги, ланцюги даних тощо)

Тільки так JAM стане по-справжньому відкритою, комбінованою обчислювальною платформою.

Bootstrap-сервіс = механізм додавання "плагінів запуску" для JAM-ланцюга.

Він визначає, які можливості і вигляд матиме ланцюг при запуску.

Gavin хоче зробити його гнучким, стандартизованим і відкритим для розробки будь-якою командою, а не лише Parity.

Що означає π × 10⁹? Чи це пов’язано із загальною кількістю DOT?

Gavin запропонував радикальну і водночас елегантну ідею: зафіксувати загальну кількість DOT як π × 10⁹ (приблизно 3.14 мільярда) і прямо записати це у genesis block JAM.

Він хоче таким чином повністю вилучити можливість зміни загальної кількості DOT через on-chain governance, щоб уникнути довільних змін чи повторних пропозицій. Якщо все ж потрібно змінити — це має бути зроблено лише через хардфорк всього протоколу.

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

Хоча "фіксація загальної кількості DOT як π × 10⁹" — це наразі політична ідея, вона ґрунтується на базових можливостях JAM-протоколу.

У Gray Paper JAM (v0.7.0), розділ 4.6 "Economics", чітко зазначено:

• JAM — це криптоекономічна система, що поєднує криптографію і теорію ігор;
• Вона визначає нативне поняття "token", усі баланси акаунтів належать до N₂⁶⁴, тобто не перевищують приблизно 18 мільярдів токенів;
• Також визначено мінімальну одиницю як 10⁻⁹, а стандартна одиниця — 10⁹ (на відміну від Ethereum, де це 10¹⁸);
• Gray Paper зазначає: фактична емісія токенів має бути значно меншою за цю межу.

Це створює протокольну можливість для пропозиції Gavin щодо "фіксації загальної кількості DOT як π × 10⁹ (приблизно 3.14 мільярда)".

Тобто, JAM сам по собі не визначає економічну політику, але надає достатньо нейтральний і гнучкий механізм, щоб такі мережі, як Polkadot, могли самостійно визначати загальну кількість токенів, спосіб розподілу тощо через Bootstrap-сервіс.

Можна сказати, JAM дає вам "гаманець" (технічно здатний вмістити 18 мільярдів токенів), але скільки грошей покласти і хто контролює емісію — вирішуєте ви самі (через Bootstrap-сервіс). Це лише фреймворк, а не політика.

Хто визначає версію JAM-протоколу?

Кожна версія JAM-протоколу відповідає певній версії Gray Paper.

Gavin зазначив, що найновіша Gray Paper відображає найновішу версію JAM-протоколу, деякі версії проходять зовнішній аудит і вважаються "production ready".

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

Чи Gavin завжди буде головним редактором Gray Paper?

Хоча наразі Gavin залишається головним редактором Gray Paper, він також планує створити Gray Paper Editorial Board (GPEB).

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

Якщо одного дня Gavin перестане бути активним, ця рада стане "де-факто" органом управління JAM-протоколом.

Що, якщо спільнота не погодиться з напрямком GPEB?

Gavin чітко заявив: спільнота Polkadot зберігає повний протокольний суверенітет.

Якщо напрямок GPEB не влаштовує, Polkadot може обрати іншу версію JAM-протоколу або навіть зробити fork власної версії — жартома він сказав, що Polkadot DAO цілком може зробити fork "Blue Paper" 😄

Він також планує після v1.0 відкрити Gray Paper під ліцензією (можливо, Copyleft із патентним захистом), дозволяючи вільно форкати, використовувати і вдосконалювати за відповідних умов.

Хто фінансуватиме роботу GPEB?

Якщо Polkadot вирішить довгостроково будувати мережу на JAM, Gavin вважає, що Polkadot Treasury має фінансувати нормальну роботу GPEB, включаючи організацію зустрічей, обговорення пріоритетів і встановлення стандартів.

Водночас, якщо інші мережі також базуються на JAM, він сподівається, що вони теж братимуть на себе відповідальність за підтримку.

Gavin планує на початковому етапі особисто обирати членів GPEB, надаючи перевагу тим, хто має глибокий технічний бекграунд і реально долучався до розробки JAM. Надалі він призначить заступників і поступово передасть право вибору членів самій раді, Polkadot Fellowship, Web3 Foundation тощо.

Gavin прагне створити JAM-"конституційний рівень" без залежності від голосування

Від фіксації загальної кількості DOT до передачі еволюції JAM редакційній раді Gray Paper і до можливості спільноти зберігати суверенітет через форки — Gavin намагається створити протокольну модель управління, яка протистоїть зловживанням governance і є технічно орієнтованою.

Це не лише корекція поточного on-chain governance, а й основна ідея JAM-протоколу: "модульність + можливість перемикання суверенітету".

Що ви думаєте про таку модель управління JAM? Запрошуємо до обговорення у коментарях!