JAM буде доставлено протягом 12-20 місяців? Троє ключових розробників розкривають економічну модель M1, PoP та майбутнє ZK!

JAM — це ім'я, яке вже давно обговорюється у спільноті Polkadot. Після того, як Gavin Wood на Web3 Summit оголосив низку важливих новин, очікування та питання щодо JAM досягли нового піку — що ж таке JAM? Які зміни він принесе Polkadot? Наскільки далеко він від офіційного запуску?

Щоб надати спільноті більш повне розуміння, PolkaWorld запросив трьох гостей, які безпосередньо беруть участь у розробці JAM: Bryan з команди Acala, Junha — розробник JAM Rust-реалізації “FastRoll”, а також Boy Maas — розробник JAM Zig-реалізації “JAMZig” і співзасновник проекту Polona.

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

У цьому інтерв'ю вони з першої особи проведуть нас у світ JAM:

• Що насправді означають важливі оновлення JAM, оголошені Gavin?
• Яким чином обмеження токенів JAM (π × 1 мільярд) і механізм PoP (Proof of Personhood) змінять економічну модель Polkadot?
• Які технічні цілі та прогрес Milestone 1? Коли буде запущено тестову мережу?
• Як у майбутньому ZK (Zero-Knowledge Proof) буде інтегровано з JAM?
• Як механізм управління JAM і редакційний комітет Gray Paper вплинуть на довгострокову еволюцію протоколу?

Якщо ви хочете дізнатися про майбутнє JAM і про те, як він змінить інфраструктуру екосистеми Polkadot — цей випуск не можна пропустити.

Знайомство з трьома командами розробників JAM

Kristen: Вітаю всіх, я Kristen. Сьогодні ми запросили трьох основних розробників JAM, які безпосередньо беруть участь у розробці JAM. Якщо ви стежите за PolkaWorld або останніми новинами Polkadot, то вже знаєте, що зараз проходить Web3 Summit, і Gavin на конференції оголосив важливі новини про JAM. Спільнота вже почала часто надсилати нам питання, тому ми терміново організували цей стрім, щоб за допомогою трьох гостей допомогти спільноті повністю зрозуміти все, що Gavin оголосив про JAM на Web3 Summit.

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

Junha: Дякую, Kristen, за запрошення. Всім привіт, я Junha, вперше беру участь у цій програмі.

Зараз я розробляю Rust-реалізацію протоколу JAM, проект називається “FastRoll”. У моїй команді наразі лише я, тобто я незалежний розробник.

Я працюю над цим проектом вже близько року, зараз готуюся до оцінки першого етапу (milestone), а також вже почав працювати над деякими завданнями другого етапу.

Kristen: Ласкаво просимо, Junha! Далі попрошу Bryan представитися.

Bryan: Всім привіт, я Bryan з команди Acala. Зараз я керую невеликою командою, яка розробляє ще одну реалізацію протоколу JAM, проект називається “Boka”.

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

Kristen: Добре, дякую, Bryan, що знову завітав до нас. Bryan, до речі, був нашим першим гостем, який розповідав про JAM, дуже рада, що ти знову з нами. Нарешті привітаємо Boy Maas, з яким ми вже робили інтерв'ю.

Boy Maas: Так, так, всім привіт, я Boy Maas. Я незалежний розробник Zig-реалізації протоколу JAM, наш клієнт називається “JAMZig”.

Також я співзасновник проекту в екосистемі JAM, наша мета — повністю перенести інструментарій Solana та Solana Virtual Machine (SVM) на JAM. Ми вже завершили початковий етап proof-of-concept, тобто вже можемо запускати деякі базові функції.

JAM буде офіційно запущено через 12–20 місяців?

Kristen: Ласкаво просимо, Boy Maas. Polona справді є піонерським проектом, спрямованим на залучення розробників Solana до екосистеми Polkadot, чудова ідея! Отже, вітаю всіх трьох гостей.

Першу тему я хочу адресувати Boy Maas. Ти брав участь у Web3 Summit, ми вже бачили багато новин про виступ Gavin у Twitter, але хочу почути твої враження з перших вуст. Ти дивився виступ Gavin? Можеш поділитися, які важливі моменти ти відзначив?

Boy Maas: Звичайно, бути на місці — це справді чудово. Можна зустріти багатьох членів спільноти Polkadot, багато цікавих виступів дозволяють відчути динаміку спільноти, атмосфера дуже позитивна, енергійна, і це надихає на майбутнє. Сьогодні останній день, і я з нетерпінням чекаю, щоб повернутися і продовжити нашу розробку.

Kristen: Ти дивився виступ Gavin?

Boy Maas: Так, дивився.

Kristen: Що тобі найбільше запам'яталося? Ми бачили деякі тези у Twitter, але хочемо почути від вас, розробників, простими словами.

Boy Maas: Звісно. Gavin у своєму виступі торкнувся багатьох тем. Він дуже далекоглядний і досвідчений, тому його рішення та нові ідеї сильно впливають на майбутній напрямок спільноти.

Найважливіше — він оголосив, що загальна пропозиція токенів JAM буде жорстко обмежена “π помножити на 1 мільярд” (π × 1,000,000,000), це дуже важлива подія, яка матиме багато наслідків.

Ще один важливий момент — він намагався чіткіше донести до спільноти Polkadot, що таке JAM. JAM по суті створений для посилення та підтримки екосистеми Polkadot, його роль — підсилювати інфраструктуру всієї екосистеми. Зараз усі перебувають у стані дослідження та адаптації: що таке JAM? Що він може? Як він співпрацює з основною мережею Polkadot? Як це реалізується?

Як розробники, ми розуміємо технічні деталі JAM, але я також розумію, що для більшості людей це ще етап “незрозуміло, які зміни принесе JAM”. Усі намагаються уявити, яким буде майбутній світ, керований JAM.

Kristen: Звучить дуже цікаво. Я також помітила, що Gavin згадав, що JAM буде офіційно запущено через 12–20 місяців. Ваш проект Polona, мабуть, також залежить від цього графіка? Ваші темпи розробки синхронізовані з JAM?

Boy Maas: Так, Kristen, ти абсолютно права. Ми не планували бути повністю готовими до запуску тестової мережі, але згідно з оголошеним графіком, наші плани ідеально збігаються, і як тільки JAM тестова мережа буде запущена, ми зможемо одразу почати використовувати її. Коли мережа запрацює офіційно, ми також одразу підключимося.

Що таке M1 JAM?

Kristen: Добре, чудово чути про такі успіхи. Далі хочу поставити питання Junha.

Нещодавно JAM випустив велике технічне оновлення та чітко визначив цілі першого етапу (milestone 1). Але деякі слухачі ще не дуже розуміють, що таке milestone 1, на якому він етапі. Можеш розповісти, що саме включає milestone 1? Який прогрес тестової мережі? Коли очікується запуск?

Junha: Звичайно. Як ти згадала, Gray Paper JAM нещодавно оновлено до версії 0.7.0. Gavin у своєму виступі також сказав, що з цієї версії Polkadot Fellowship може почати оцінювати milestone 1. Тому зараз більшість команд, які працюють над реалізацією JAM node client, готуються до цієї оцінки.

Мета milestone 1 — надати node client, який може “правильно імпортувати блоки”, тобто перевірити найосновнішу логіку виконання JAM.

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

Оцінка milestone 1 — це перевірка, чи може твоя реалізація node після імпорту цих блоків згенерувати правильний наступний стан.

Метод оцінки також простий: ми готуємо набір тестових блоків і порівнюємо, чи всі реалізації отримують однаковий наступний стан. Цей результат можна підсумувати у “vertical root”, тому порівнювати дуже зручно. Вже є тестовий інструмент JAM Conformance Fuzzer, який може автоматично генерувати багато блоків із випадковими даними й тестувати, чи всі реалізації отримують однаковий state root.

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

Kristen: Зрозуміло, а коли очікується запуск тестової мережі?

Junha: Ти маєш на увазі JAM тестову мережу? Деякі команди вже намагаються забезпечити крос-реалізаційну взаємодію через власні бінарники, але я особисто вважаю, що справжня тестова мережа буде більш зрілою лише після milestone 2.

Оскільки milestone 1 в основному перевіряє логіку зміни стану node, цього недостатньо для повноцінної роботи тестової мережі. Milestone 2 вже оцінюватиме, чи реалізовано всі мережеві протоколи (networking spec). Але наразі ці протоколи ще нестабільні, навіть не вписані в Gray Paper. Як тільки специфікація мережевого протоколу стабілізується, і всі реалізації завершать відповідну розробку, можна буде тестувати взаємодію між node.

Тоді вже можна буде готуватися до запуску тестової мережі. Звісно, деякі команди можуть спробувати зробити це раніше, але я особисто планую приєднатися до тестової мережі після milestone 2.

Kristen: Добре. А чи вплинуть новини, які Gavin оголосив на саміті, на твій темп розробки?

Junha: Я вважаю, що більшість його новин стосуються довгострокового бачення, тому найближчим часом на мій план розробки це не вплине. Зараз я зосереджений на завершенні milestone 1, думаю, ще потрібно кілька тижнів або навіть місяць, щоб надати повністю відповідний вимогам клієнт. Тому наразі моя стратегія розробки не зміниться.

Звісно, у перспективі одного-трьох років ці нові напрямки можуть вплинути, але зараз я зосереджений на milestone 1.

Які наслідки матиме заміна NPoS на PoP?

Kristen: Зрозуміло, дякую за твою розповідь! Далі хочу поставити “хардкорне” питання Bryan, воно стосується токен-економіки. Всі знають, що розробники зазвичай не люблять оцінювати ефективність економічної моделі, але це одне з найважливіших питань для спільноти. Gavin на саміті сказав, що PoP (Proof of Personhood) замінить NPoS, винагороди для валідаторів стануть фіксованими, а також буде введено механізм щорічного халвінгу для обмеження загальної пропозиції DOT. Як ти, як розробник, оцінюєш ці зміни? Який, на твою думку, буде найбільший вплив? Чи підтримуєш ти це особисто? Чи є якісь побоювання чи поради?

Bryan: Дійсно, це велика зміна.

Я коротко нагадаю передумови: чи то Proof of Work (PoW), чи Proof of Stake (PoS), чи теперішній Proof of Personhood (PoP) — всі ці механізми покликані захищати мережу, запобігати double-spend, форкам тощо.

Кожен механізм має свою вартість: PoW — це витрати на винагороди за блоки, електроенергія та обчислювальні потужності, PoS — це винагороди для стейкерів.

Новий Proof of Personhood суттєво відрізняється у винагородах. Polkadot раніше використовував NPoS (Nominated Proof of Stake), який хоч і не такий дорогий, як PoW, але все одно має проблему: для підтримки безпеки мережі потрібно постійно випускати нові токени для винагороди валідаторам і номінаторам, що призводить до інфляції.

Введення PoP має на меті знизити вартість безпеки мережі, не покладатися на економічні стимули чи покарання, а перейти до нового підходу — як саме, поки неясно, але головна ідея — “одна людина — один голос”. Якщо це спрацює, шахраювати стане набагато складніше, мережу легше захистити, і не потрібно буде платити великі винагороди токенами.

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

Це також може позитивно вплинути на DeFi. Коли прибутковість стейкінгу знижується, користувачі можуть переводити кошти в інші DeFi-протоколи, наприклад, у кредитування, ліквідність тощо, що активізує DeFi-екосистему.

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

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

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

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

Що таке zkJAM?

Kristen: Дійсно, думки спільноти розділилися. Спочатку всі закликали “зменшити інфляцію”, а тепер, коли йдемо до дефляції, з'явилися скарги. Я вважаю, що це правильний напрямок, дякую за глибоку думку.

Далі поговоримо про технічну тему — ZKJAM. Я побачила цей термін у презентації Gavin, поки що це виглядає концептуально. Але Zero-Knowledge Proof (ZK) останні роки дуже популярний у Web3, багато хто каже, що ZK — це ідеальне рішення для Rollups і масштабованості. Якщо в майбутньому ZK буде інтегровано з JAM, яким буде сценарій? Хочу почути думки всіх трьох. Junha, почни ти.

Junha: Добре. Gavin у своєму виступі порівняв JAM із децентралізованим “супер-бейр-метал комп'ютером”, а різні сервіси на ньому — це як операційні системи на апаратному забезпеченні, наприклад, Windows чи macOS.

Якщо в майбутньому ZK буде інтегровано в JAM, з точки зору розробників сервісів чи додатків це не принесе якихось “революційних” змін, загальний досвід розробки та користування залишиться майже незмінним.

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

Тому, якщо буде доведено, що ZK і JAM добре сумісні й це вигідніше, оновлення цілком можливе, і загальний досвід не зміниться суттєво.

Kristen: Дякую за відповідь. Можливо, деякі слухачі вже заплуталися у технічних термінах, але не хвилюйтеся, буде оглядова стаття українською, можна перечитати. Далі, Bryan, поділися своєю думкою.

Bryan: Думаю, треба розрізняти два поняття: одне — JAM як інфраструктура для ZK-безпечних Rollup, інше — JAM, який сам забезпечує безпеку через ZK. Це різні речі.

Через PVM у JAM будь-які ZK-алгоритми чи архітектури, наприклад, нові ZK-Rollup протоколи, можуть бути розгорнуті як сервіси на JAM. Це досить просто реалізувати.

Але якщо JAM сам має забезпечувати безпеку через ZK, це потребує багато передових досліджень і оптимізації алгоритмів. Наразі це дуже “фронтирна” сфера. Все залежить від поточного стану — зараз алгоритми ще не досить швидкі чи дешеві, але завтра хтось може винайти алгоритм у 100 разів ефективніший, і все зміниться.

Тому, якщо з'явиться справді корисна інтеграція ZK, яка зробить JAM безпечнішим, я, звісно, підтримую її впровадження.

Kristen: Зрозуміло, сподіваюся, у цій сфері справді буде прорив. Boy Maas, як досвідчений розробник, що думаєш?

Boy Maas: Насправді Bryan і Junha вже дуже повно відповіли. Мені подобається JAM, бо це дуже прагматична система. Всі дизайн-рішення спрямовані на те, щоб система реально працювала, могла виконувати обчислення. Як сказав Bryan, зараз робити все через ZK занадто дорого й нереально. Тому я уявляю, що в майбутньому можна буде застосовувати “гібридну модель”, тобто традиційний аудит і ZK паралельно.

Але наразі ZK занадто дорогий і непрактичний, хоча за 12 місяців — 5 років у цій сфері точно буде багато змін. Якщо ZK стане справді ефективним, це буде дуже приваблива технологія, яка може переосмислити всю нашу архітектуру безпеки.

Але зараз гібридна модель виглядає практичнішою: і зберігається практичність, і ті додатки, яким справді потрібна ZK-безпека, зможуть її використовувати.

JAM створить редакційний комітет Gray Paper

Kristen: Дякую всім за відповіді. Далі переходимо до наступної теми: механізм управління JAM.

Gavin залишиться головним редактором Gray Paper і оголосив про створення “редакційного комітету Gray Paper”, до якого увійдуть активні розробники JAM з технічними навичками. У майбутньому вони разом вирішуватимуть оновлення, пріоритети та ключові рішення протоколу JAM. Як ви, як розробники, оцінюєте таку модель управління? Чи може вона призвести до “відхилення від початкової ідеї”? Як діяти у такому разі? Почнемо з Boy Maas.

Boy Maas: Вважаю, це дуже важливе питання. Для такої високотехнологічної, спеціалізованої сфери наявність комітету для оновлення Gray Paper — це розумно й необхідно. Ті, хто приймає рішення, мають глибоко розуміти JAM і мати багаторічний досвід, щоб приймати мудрі рішення. І те, що Gavin очолює цей комітет, цілком логічно, тому я повністю підтримую таку модель управління.

Kristen: Тобто ти вважаєш, що рішення мають приймати професіонали колективно?

Boy Maas: Так, повністю згоден.

Kristen: Добре, Bryan, а ти як думаєш?

Bryan: Насправді всі проекти по суті управляються певним “комітетом”, просто масштаб і склад різні. Питання лише в тому, чи прописано процес управління.

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

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

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

Kristen: Тобто ти вважаєш, що комітет має мати чіткі правила: хто може приєднатися, як організовано членство тощо. Бо якщо немає правил, легко виникнуть суперечки чи відхилення від ідеї.

Bryan: Тому нам і потрібні смарт-контракти, чіткі процеси, все має бути прописано. Якщо правила чітко прописані, всі можуть контролювати виконання, все прозоро — тоді ймовірність відхилення мінімальна. Якщо все робиться “у темній кімнаті”, ніхто не знає, що відбувається — тоді легко піти не туди. Прозорість дуже важлива, особливо якщо процес можна забезпечити смарт-контрактами — тоді ця система може існувати довго.

Kristen: Зрозуміло, пам'ятаю, у спільноті Bitcoin теж є подібний комітет розробників.

Bryan: Так, у спільноті Bitcoin є група core-розробників, але остаточне рішення приймається через форк: яка ланцюжок має найбільшу хеш-потужність, та й перемагає.

Kristen: Зрозуміло, дякую за пояснення. Нарешті послухаємо Junha з цього приводу.

Junha: Я вважаю, створення редакційного комітету — це дуже природний і важливий крок. JAM — дуже особливий проект: ще до створення повноцінного програмного забезпечення було опубліковано повну технічну специфікацію (Gray Paper). У цьому документі багато математичних формул, які визначають вхідні та вихідні параметри системи. Публікація документа до розробки — це прагнення до більшої децентралізації та стійкості системи.

Тому Gray Paper вже багато разів редагувався, і навіть після релізу 1.0 буде редагуватися далі.

З появою нових команд, які реалізують JAM і запускають тестові мережі, ми точно знайдемо, що можна оптимізувати, щоб підвищити ефективність чи реалізованість протоколу. Тому для JAM природно, що Gray Paper буде еволюціонувати навіть після запуску mainnet, можливо, навіть буде хардфорк.

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

Як сказав Bryan, прозорість дуже важлива, процес прийняття рішень має бути відкритим. Я також сподіваюся, що більше команд, які використовують JAM, братимуть участь у рецензуванні, перевірці та зворотному зв'язку, а не просто “віритимуть, що Gavin завжди правий”. Такий підхід дозволить знаходити нові точки для покращення. Це гарний початок, вартий очікування. З огляду на особливості JAM, такий спосіб постійного оновлення специфікації дуже природний і розумний.

Ми, можливо, недооцінюємо, що JAM принесе блокчейну

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

На завершення, чи є у вас щось додати? Про JAM, про Web3 Summit, можливо, щось не встигли сказати? Почнемо з Bryan.

Bryan: Немає нічого особливого. JAM — це базова інфраструктура, вона важлива, але не все. Справді важливі сервіси та додатки, побудовані на JAM — користувачі не будуть напряму використовувати JAM, а сервіси на його основі.

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

Kristen: Дякую. Boy Maas, хочеш щось додати про Polona чи JAM?

Boy Maas: Звісно. Спершу про JAM. Пам'ятаю, у Лісабоні Gavin робив презентацію про JAM. Тоді у мене було відчуття, що ми, можливо, недооцінюємо, що ця платформа принесе блокчейн-спільноті.

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

Ще одна новина: наш проект Polona дуже швидко розвивається, вже є proof-of-concept версія на JAM. Ми вже перенесли Solana SVM на PVM, тобто тепер можна запускати Solana bytecode на JAM, включаючи крос-контрактні виклики — все працює, це дуже круто. Це ще раз доводить потужність JAM.

Kristen: Чудово, дякую! Нарешті, Junha, додай щось від себе.

Junha: Я сподіваюся, що більше людей звернуть увагу на JAM, Polkadot і Gray Paper. Дуже хочу познайомитися з новими людьми, поділитися ідеями.

Зараз JAM-клієнти ще в розробці, тому мало “готових” прикладів додатків. Хоча команда Gavin показувала деякі демо, наразі ще немає достатньо реальних кейсів, щоб усі “повірили”, на що здатна ця система.

Але якщо вам цікава ідея Web3 і ви хочете розширити межі цієї індустрії, JAM — це проект, який варто глибоко вивчити. Я сам останнім часом працюю над цим самостійно, тому дуже хочу познайомитися з однодумцями, навіть просто разом читати Gray Paper чи обговорювати — це вже добре. Сподіваюся, ми зможемо обмінюватися ідеями, а після завершення node-клієнта навіть створити щось нове разом.

Kristen: Добре, дякую за твою відповідь і дякую всім гостям за чудові думки та ідеї! Дякую всім слухачам за участь, підписуйтеся на Twitter наших гостей, акаунти можна знайти в оголошеннях PolkaWorld. Чи ви звичайний користувач, чи розробник — знати останні новини про JAM дуже корисно. Дякую за прослуховування, до зустрічі! Бувайте!