Віталік Бутерин: центральний елемент Casper успішно випробуваний в тестової мережі

Наради розробників Эфириума проходять у відкритому режимі, однак спілкування між розробниками не адресоване широкій публіці, і тому багато потребує роз’яснень.

На останній щотижневій нараді розробників Фонду Эфириума, Віталік Бутерин сказав:

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

Гібридний протокол PoS Casper FFG вже протягом декількох тижнів працює в тестової мережі Эфириума, однак спостерігачі відзначають суттєві проблеми в його роботі. Зв’язок між вузлами постійно переривається, і мережа перевантажена зайвою потоком сполук. У результаті для того, щоб мережа працювала безперервно, розробникам доводиться керувати нею в ручному режимі.

Відповідаючи на питання користувачів Reddit, Віталік Бутерин так роз’яснив ситуацію:

Протокол Casper – це лише специфікація, це не код, він не «побудований» на чому-небудь. Технічне співтовариство Эфириума традиційно поділяє специфікацію та імплементацію (реалізацію). В даний час є тільки одна реалізація специфікації Casper на платформах pyethereum (Casper консенсус) та pyethapp (комунікації в мережі), заснованих на мові python, але вже зараз завершуються роботи над імплементацією на Java, яка буде використовуватися в новому клієнта Harmony. До того часу, як Casper буде розгорнуто на основному блокчейне, повинні бути готові імплементації на Geth і Parity.

У коді мережі pyethapp виявлені критичні помилки, в той час як імплементація логіки Casper протестована успішно. Швидше за все, розгорнути Casper в основній мережі у другому кварталі не вдасться, оскільки Geth і Parity потрібно час для розробки власних імплементацій. А їх, у свою чергу, потрібно починати тільки після фінального раунду критичних елементів протоколу, (саме, часткових штрафів і операцій, пов’язаних з тривалістю сесій валідаторів).

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

Що стосується шардинга, який стане основою технології майбутнього Эфириума, то в цьому напрямку, за словами Бутерина, «почалася велика робота».

В даний час, кожен вузол блокчейна повинен виконати однаковий обсяг обчислень, a це означає, що загальна обчислювальна потужність мережі обмежена потужністю її найслабшої сайту. Шардінг вводить паралельні обчислення: замість того, щоб відтворювати всі транзакції, ноди будуть об’єднані в групи (шарды), наприклад, за 100 нсд в кожній, і кожен шард буде підписувати 1000 транзакцій.

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

Незабаром послідувало
роз’яснення від розробника Фонду Ніка Джонсона (Nick Johnson):

[В плані робіт по шардингу] всього буде 4 фази в довгостроковій перспективі і 4 етапу в першій фазі найближчим часом. Перший етап майже готовий і тестування плюс деякі роботи по інтеграції будуть закінчені протягом місяця. (Паралельно, ми починаємо роботи по другому етапу).

Між тим, нинішня мережа Эфириума по раніше працює на межі пропускної здатності, хоча транзакційні комісії і впали до норми – близько 10 центів. До цих пір розробники інфраструктури більше уваги приділяли шардингу і Casper, а у робіт з оптимізації клієнтського софта був менший пріоритет. Зараз ця ситуація змінилася і зниження комісій, нехай тимчасове, стало результатом таких робіт. Петер Жиляги (Péter Szilágyi), розробник Geth – одного з клієнтів, проілюстрував роботу оптимізованого клієнта Geth v1.8.0 (ще не випущений), порівняно з експлуатованої версією v1.7.3.