Роздуття блокчейну: як Ethereum вирішує проблеми зберігання

24 270 жетонів. 27 358 незавершених транзакцій. 463,713 цифрові кошенята.

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

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

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

І розробники визнають проблему.

По ONE , розробники Ethereum активно розробляють зміни на рівні протоколу, такі як шардинг, спрямовані на мінімізацію бази даних.

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

«Той факт, що покращення цього матеріалу є критично важливим, відомий з кінця 2016 року, ідеї виношувалися від півроку до більше року. Де впровадження?» сказав творець Ethereum Віталік Бутерін нещодавно на каналі розробників.

Розчарування відчутне як у Бутеріна, так і у Афрі Шоедон, яка керує технічними комунікаціями в постачальнику клієнтського програмного забезпечення Ethereum Parity. Шодон сказав CoinDesk:

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

Щоб обмежити вплив громіздкого стану, два найпопулярніші клієнти Ethereum – Geth і Parity – нещодавно випустили оновлення, які намагаються покращити ситуацію.

Турбонаддув

The перше оновлення, випущений минулого тижня компанією Parity, зменшив вимоги до пам’яті, видаливши непотрібні тимчасові файли, які створюються, коли програмне забезпечення запам’ятовує історію Ethereum.

Завдяки значній мінімізації вимог до пам’яті користувачі, які підключаються до повних вузлів, отримують швидше синхронізацію. І при цьому компанія заявила, що її програмне забезпечення Ethereum тепер можна запускати на жорсткому диску, а не на твердотільний накопичувач (SSD), особливо помітний результат, оскільки тривалий час синхронізації зробив Ethereum неможливим працювати на жорсткому диску з минулого літа.

Оновлення навіть викликало схвильовану реакцію Бутеріна, який сказав на каналі розробника: «Вау! Як вам, хлопці, це вдалося?»

В результаті оновлення користувачі повідомляли значно покращений досвід.

У той же час незалежний розробник Олексій Ахунов працює над переписом клієнта geth під назвою «turbo geth». Описаний Ахунов як ан "одержимість", Метою проекту є усунення багатьох непотрібних повторень у тому, як клієнти ethereum обробляють загальний стан.

Хоча він і NEAR не готовий, він відкрив кілька цікавих шляхів «спекулятивної оптимізації», сказав Ахунов у нещодавньому чаті розробників.

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

Розробники самого Geth також працюють над оптимізацією, ONE виправити помилку в тому, як зберігається інформація, коли клієнт синхронізується з мережею в так званому «швидкому» режимі. Описаний CORE розробником Geth Петером Сілягі як «справді жахливий», існуючий код, ймовірно, буде замінено разом із цілою купою оновлень, які зроблять синхронізацію набагато швидшою та менш інтенсивною для зберігання.

Межі

Також проводяться дослідження типу клієнта під назвою «клієнти без стану», які зберігають лише стиснення загального стану.

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

«Я тепер за підхід клієнта без громадянства», — написав Бутерін.

І навіть є припущення, що клієнти без стану можуть бути можливими без внесення змін на рівні протоколу.

Рекламуючи таких клієнтів як можливе вирішення проблем масштабування, з якими стикається Ethereum після успіху CryptoKitties, Ахунов написав у нещодавньому публікація в блозі: «Я вважаю, що (клієнти без стану) можуть бути реалізовані вже зараз, без будь-якого хардфорка, «просто» шляхом зміни клієнтів Ethereum ... Це означає, що вузлам не потрібен доступ до сховища з файлів, а час перевірки блоків має значно скоротитися».

Однак оптимізація клієнта T може бути єдиним, на що покладається мережа, щоб зменшити проблеми щодо стану.

За словами Szilágyi

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

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

«Ми можемо оптимізувати базу даних і зробити її в десять разів швидшою та оптимальнішою, що дає нам можливість збільшити в десять разів наш поточний розмір», сказав Сілаґі, додавши:

«Але врешті-решт ми дійдемо до того моменту, коли більше T зможемо оптимізувати базу даних, і до того часу ми повинні мати можливість шардувати наші дані».

Жорсткий диск зображення через Shutterstock