Розробники CORE Ethereum обговорюють переваги більш частих хардфорків

Як часто занадто часто змінювати консенсус?

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

Бажаючи «перевірити температуру», розробник, ставлячи запитання, пояснив, що деякі майбутні пропозиції щодо вдосконалення Ethereum (EIP), такі як державна рента для повного ефекту вимагатиме кількох оновлень, розташованих послідовно.

Однак три місяці, на думку Джозефа Делонга, старшого інженера-програміста студії венчурного капіталу Consensys, «занадто QUICK для повороту».

Керівник команди Ethereum Foundation Петер Сіляджі погодився, пояснивши:

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

Керівник безпеки Ethereum Foundation Мартін Хосте Свенде, погоджуючись, що хардфорк кожні три місяці «було б погано», зауважив, що окремі випадки з простими змінами, про які одностайно погоджуються, можуть мати коротший час виконання.

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

Але заохочуючи розробників виконувати свої плани «по кроках», Фредрік Гаррісон, технічний директор Parity Technologies, зазначив, що навіть шість місяців для запланованого хардфорку Ethereum ніколи не було досягнуто.

"Є кілька речей, які нам, ймовірно, потрібно автоматизувати, щоб робити [коротші хардфорки] дійсно добре. Багато часу, який йде на хардфорк, не просто створюється код. Це все, що відбувається навколо", - сказав Гаррісон.

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

На це Гаррісон відповів, що справа в тому, що у нього недостатньо фінансів, щоб залучити таких членів команди. "Для нас це гроші. У нас за ними T грошей", - іронізував Гаррісон.

Багатоетапні оновлення

Але справа не лише в тому, чи мають бути частіші хардфорки.

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

Припускаючи, що такі розробники, як Олексій Ахунов і засновник Ethereum Віталік Бутерін, застерігали від «змін, які T сприяють виживанню [теперішнього ланцюжка Ethereum]», Гаррісон запитав:

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

EIP 615 є ONE з п’яти пропозицій, які розглядаються для включення в наступний хардфорк Ethereum під назвою Istanbul. Він має на меті впровадити вдосконалення в саму серцевину кодової бази Ethereum , відомої як віртуальна машина Ethereum (EVM), яка відповідає за виконання всіх саморозгортаючих рядків коду, які також називають смарт-контрактами, на платформі.

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

"Конструкція EVM ускладнює виконання з низькою вартістю газу та високою продуктивністю. Ми пропонуємо просуватись із пропозиціями щодо вирішення цих проблем шляхом посилення гарантій безпеки та розширення меж продуктивності EVM", пише автори EIP 615 Colvin, Brooklyn Zelenka, Pawel Bylic та Christina Reitwiessner.

Однак, як зазначив Свенде під час сьогоднішньої розмови, запропонований EIP 615 вимагатиме принаймні двох хардфорків для повного виконання, і «позитивний ефект швидкості» фактичних обчислень коду в EVM не буде помітним, доки не буде виконано останній хардфорк.

"Це моє головне занепокоєння щодо цього EIP, це багато роботи, але я T думаю, що це призведе до набагато кращого EVM. Це може бути краще для зовнішніх інструментів, наприклад, якщо ви виконуєте зворотний аналіз властивостей безпеки смарт-контракту", - сказав Свенде.

Такий інструментарій, який Зеленка запропонував, необхідний для забезпечення постійної «передньої сумісності» з майбутніми оновленнями EVM, такими як eWASM, і плавної роботи з розробниками смарт-контрактів у світлі «невизначеної дати випуску Ethereum 2.0».

"Існують інші варіанти для розробників смарт-контрактів. Нам потрібно KEEP Ethereum 1.x, а це означає продовжувати рух", - заявив Зеленка під час сьогоднішньої розмови.

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

Але погоджуючись із сумнівними настроями щодо майбутнього Ethereum 2.0, Гаррісон, який підняв початкове запитання щодо амбітних оновлень кількох хардфорків, сказав:

«Ми T повинні коригувати нашу дорожню карту або мислення на основі того, яким може бути або не може бути Ethereum 2.0».

Зображення розгалуження через Shutterstock