Автор: PolkaWorld

Гевін Вуд, співзасновник Ethereum, творець Polkadot та пропагандист бачення Web3.

Перш ніж розпочати, поділюся деякими висловлюваннями Гевіна в цій частині!

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

Чи є Ethereum успішним проектом? — Якщо дивитися за моїми критеріями успіху? Очевидно, що не всі критерії відповідають, можливо, лише невелика частина. Звичайно, він фінансово успішний.

З введенням JAM напрямок Polkadot змінився. Його можна розглядати як рідну проектну Rollup-мережу, а технології, які ми розробляємо, значно перевершують оптимістичні Rollup та нульові знання Rollup на Ethereum.

Яке найбільше досягнення Polkadot до сих пір? — Створення безпечного шардового блокчейну.

Яка найбільша проблема, з якою сьогодні стикається Polkadot? — Це якраз шардінг.

Як вирішити ці проблеми? — JAM

Продовжуйте читати, щоб дізнатися більше!

Яке найбільше досягнення Ethereum на сьогодні?

Кевін: Отже, ти кажеш, що ти співзаснував Ethereum у 2014 році? Чому ти приєднався до них як співзасновник і технічний директор?

Гевін: Я вважаю, що це рідкісна можливість, і відразу зрозумів, що повинен її використати, віддаючи всі сили. Можливо, не на все життя, але принаймні на певний час зосередитися на ній. Це інноваційний проект, який з'явився у відповідний момент, з командою деяких видатних і зосереджених людей, а також з невеликим, але зацікавленим ринком. Чесно кажучи, я був дуже зацікавлений у цьому проекті, вважав, що він має великий потенціал для розвитку і, принаймні, може внести свій внесок у принципи лібералізму, які я розумію.

Кевін: Що це таке?

Гевін: В основному це оптимістичний погляд на суспільство і розвиток, який, напевно, виник у Західній культурі близько чотирьох-п'ятисот років тому.

Кевін: Яке найбільше досягнення Ethereum на сьогодні?

Гевін: Можливо, це CryptoKitties, я не знаю, насправді не впевнений. Я чув, що Ethereum створив найбільшу кількість мільйонерів в історії. Можливо, це пов'язано з тим, що багато людей брали участь у краудфандингу, а ціна згодом зросла досить високо. Отже, це, можливо, його найбільший внесок. Але, чесно кажучи, важко сказати, чи дійсно він досягнув чогось корисного. Звичайно, це не відповідає моїм очікуванням, які я мав 10 років тому.

Кевін: Отже, якщо я запитаю тебе, чи вважаєш ти Ethereum успішним проектом? Твоя відповідь буде негативною?

Гевін: Моя відповідь: чи вважаю я його успішним, виходячи з моїх критеріїв успіху? Очевидно, що не всі критерії відповідають, і, можливо, лише незначна частина. Звичайно, він фінансово успішний. Я думаю, можливо, один або два співзасновники Ethereum, можливо, сподівалися на кращі результати.

Кевін: Які критерії можуть змусити тебе вважати, що він успішний?

Гевін: Корисність (Utility)

Кевін: Як виміряти корисність?

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

Кевін: Це проблема всього криптоіндустрії, а не тільки Ethereum?

Гевін: Це так. Це дійсно проблема, з якою стикається вся криптоіндустрія. У 2014 і 2015 роках ми висунули багато ідей, намагаючись розблокувати деякі економічні сфери, які були раніше недоступні, через "без довіри". Один з прикладів, який мені особливо подобається, це постачальницький ланцюг. Наприклад, коли ви йдете в супермаркет, на всіх товарах є QR-код, який ви можете відсканувати, щоб дізнатися всі складові цього товару: коли, де і в якій кількості тощо. Я хотів би, щоб, купуючи футболку, я міг дізнатися, звідки взято бавовну.

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

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

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

Чому ти вирішив залишити Ethereum?

Кевін: Чому ти залишив Ethereum у 2016 році?

Гевін: Насправді це сталося наприкінці 2015 року. Тоді ми вирішили, що Ethereum потрібно зробити багато речей, щоб бути більш широко прийнятим. Ми шукали зовнішнє фінансування, і один з найбільш очевидних способів — це створити стартап, пов'язаний з Ethereum, і шукати зовнішнє фінансування для нього. Це спочатку було спільним рішенням Віталіка та Джеффа (основних розробників та інженерів).

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

Ми тоді залучили деякі кошти, перевівши приблизно половину технічної команди Ethereum Foundation до Ethcore, і розробили клієнт Ethereum. Я залишив Ethereum Foundation наприкінці 2015 року, насправді, щоб створити цю дочірню компанію, з метою збільшення наявності приватного фінансування в екосистемі Ethereum.

Проте я повністю покинув екосистему Ethereum наприкінці 2017 року, коли я заснував Polkadot.

Polkadot розробляє технологію Rollup

Кевін: Як би ти пояснив своїй мамі, що таке Polkadot?

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

Протягом багатьох років Polkadot намагався відрізнитися від Cosmos у цьому аспекті. Тому що у моделі Cosmos кожен ланцюг повинен сам нести відповідальність за безпеку. А Polkadot вирішує цю проблему через спільну безпеку. Але, на жаль, ці два проекти насправді вирішують дуже різні проблеми. Згадуючи про це, я можливо, більше схиляюся до опису Polkadot як "системи шардінгу", а не "системи з декількома ланцюгами". Оглядаючись назад, ця формулювання є дуже важливим для пояснення та передачі основної ідеї Polkadot, особливо під час спілкування з іншими або просування Polkadot, це відмінність допомагає чіткіше описати його технічні характеристики та відмінності від інших проектів (таких як Cosmos).

Зараз, з введенням JAM, цей напрямок зазнав деяких змін. Технології, які ми розробляємо для Polkadot, можна розглядати як технології Rollup, а сам Polkadot можна вважати спеціально спроектованою Rollup-мережею. Розробка та проектування цієї технології не є простими, тому не дивно, що ми бачимо, що інші дві конкурентні технології за своєю ефективністю значно поступаються тим технологіям, які ми розробляємо для Polkadot. Зокрема, це оптимістичні Rollup (Optimistic Rollups) і нульові знання Rollup (ZK Rollups), які вже використовуються на Ethereum. Тому ми можемо описати Polkadot як рідну Rollup-мережу — звичайно, це може не підійти для пояснення мамі, але для тих, хто має певне уявлення про криптосферу, це цілком прийнятно.

Завдяки JAM, який є наступною метою розвитку Polkadot, ми намагаємося перетворити Polkadot з моделі з декількома ланцюгами на більш універсальну модель обчислювальних ресурсів. У моделі з декількома ланцюгами різні ланцюги Polkadot (в межах системи Polkadot відомі як паралельні ланцюги) ділять один і той же безпечний каркас, здатний взаємодіяти між собою. А в новій моделі наша мета — ще більше розширити область застосування Polkadot, як Ethereum розширив основні функції Bitcoin в універсальні обчислювальні ресурси. Ми хочемо усунути надмірні суб'єктивні обмеження проектування, щоб Polkadot підтримував ширший спектр випадків використання.

Отже, яке майбутнє Polkadot? В основному, він стане великим спільним комп'ютером, який завжди працює так, як ви очікуєте. На цьому спільному комп'ютері ви можете завантажувати програми для виконання, ці програми можуть бути послугами для вирішення певних проблем. Оскільки це спільний комп'ютер, ці послуги можуть взаємодіяти та координуватися між собою.

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

Найбільше досягнення Polkadot — це найбільша проблема

Кевін: Я думаю, ти, можливо, маєш на увазі той факт, про який ми всі знаємо, і який насправді викликав багато плутанини в сьогоднішній екосистемі Ethereum. Отже, яке найбільше досягнення Polkadot до сих пір?

Гевін: Створення безпечного шардового блокчейну.

Кевін: Яка найбільша проблема, з якою сьогодні стикається Polkadot?

Гевін: Це шардінг.

Кевін: Що це конкретно означає?

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

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

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

Тому з цього погляду проектування шардінгу є доцільним. Однак це також приносить свої проблеми. Наприклад, що робити, якщо один ящик переповнений? Вам, можливо, потрібно буде переналаштувати розподіл записів, наприклад, змінити записи з A до E на A до D, а записи, що починаються з E, перенести в нижній ящик. Але це може призвести до того, що наступний ящик також не вмістить їх, тому вам потрібно буде знову налаштувати, і щоразу налаштовувати ще й етикетки ззовні ящика. Цей процес може стати складним і клопітким.

Отже, шардінг також приносить свої проблеми.

Суть в тому, що ці "ящики" (шарди) працюють незалежно, як у проектуванні шардового блокчейну, так і в проектуванні бази даних. По суті, дані залишаються розподіленими, якщо ви не виконуєте дуже специфічну операцію, що зазвичай є дуже витратним, дорогим і ресурсомістким процесом, щоб перемістити записи або дані з одного ящика (шарду) в інший. Це означає, що реорганізувати записи в одному ящику може бути легко, але реорганізувати записи між різними ящиками — дуже складно. Це саме та проблема шардінгу. Для даних це може не бути серйозною проблемою, і саме тому шардінг широко використовується в проектуванні бази даних. Але для послуг, наприклад, для смарт-контрактів, які потребують частих взаємодій і змін, цей підхід не є ідеальним. Якщо смарт-контракти вважаються об'єктами, що знаходяться в ящиках, а ви хочете, щоб смарт-контракт з одного ящика взаємодіяв зі смарт-контрактом з іншого ящика, вам потрібно буде одночасно відкрити обидва ящики. Це означає, що вам доведеться витягнути їх обидва, щоб дозволити їм з'єднатися один з одним, виконуючи всі необхідні взаємодії смарт-контрактів, а потім знову розділити їх і повернути назад у свої ящики. Цей процес є складним та неефективним, що зовсім не підходить для застосувань, які потребують частих взаємодій.

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

Інший підхід полягає в тому, щоб дозволити ящикам взаємодіяти, надсилаючи повідомлення. Один ящик (шард) може надіслати повідомлення, яке пізніше буде передане до іншого ящика. Саме це Polkadot робить за допомогою XCM (перехресна передача повідомлень консенсусу). Хоча цей підхід можливий, проблема в тому, що він не може забезпечити ту щільну, ефективну і гнучку взаємодію, яка була б такою плавною, якщо все працювало б в одному просторі або "ігровому майданчику".

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

Отже, "схованки" — це гра, яку можна грати лише на одному ігровому майданчику. Саме це є проблемою між шардом; взаємодія між шардом — це як намагатися грати в гру через ігрові майданчики, що ускладнює ефективне проведення.

Якщо деякі рішення повинні працювати у дуже асинхронному режимі, то їх нормальне функціонування стане дуже складним. Це як грати через повідомлення. Якщо це гра, як шахи, можливо, це не так важко; але якщо це гра, як "схованки", то це практично неможливо.

Аналогічна ситуація і зі смарт-контрактами. Деякі смарт-контракти можуть працювати в цьому режимі не дуже важко, можливо, лише трохи повільніше, але це не велика проблема. А деякі випадки використання, наприклад, перевірка особи (KYC), є відносно простими. Наприклад, у вас може бути один ланцюг, відповідальний за перевірку особи, а інший ланцюг, що обробляє перекази. Ланцюг переказів може вимагати підтвердження, що цільова адреса пройшла перевірку KYC і AML, перш ніж виконати переказ. Він може надіслати повідомлення, запитуючи: "Чи пройшла ця адреса перевірку KYC і AML?" Ланцюг перевірки особи відповідає: "Так", а потім ланцюг переказів виконує переказ. Весь процес може зайняти кілька секунд більше, але це не велика проблема.

Проте є й інші випадки, наприклад, децентралізовані біржі (DEX), які є набагато складнішими. Наприклад, вам потрібно буде запитати поточну ціну, а потім вирішити, чи варто здійснювати угоду. У цьому випадку вам, можливо, потрібно буде надіслати повідомлення на інший ланцюг, а інший ланцюг відповідає: "Поточна ціна така, угода може бути виконана так." Тоді повідомлення повертається назад на первісний ланцюг, первісний ланцюг підтверджує: "Я приймаю цю ціну, будь ласка, виконайте угоду." Але коли угода має бути виконана, інший ланцюг може знову сказати: "Ціна змінилася, тепер вона така." Повідомлення буде передаватися туди-сюди, і дуже швидко весь процес стане дуже неефективним або навіть не зможе бути виконаним.

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

Рішення — це JAM

Кевін: Які існують можливі рішення?

Гевін: Ну, JAM — це моя пропозиція, тобто Join Accumulate Machine (Машина поєднання та накопичення).

Кевін: Що таке JAM?

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

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

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

Якщо ми реалізуємо систему таким чином, ми можемо уявити собі систему, яка одночасно може масштабуватися і підтримувати синхронізоване об'єднання. Її суть полягає в тому, що не відбувається постійного розподілу так званого "стану". Іншими словами, гравці не будуть фіксовано прив'язані до конкретного ігрового майданчика, а будуть динамічно групуватися в реальному часі за потребою. Система буде ділити гравців на різні групи відповідно до фактичних потреб і просувати гру на основі цих груп.

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

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

#ETH