Виталик Бутерин: центральный элемент 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.