" Paradigm недавно запустила Reth v0.1.0, реализацию узла с открытым исходным кодом для Ethereum, направленную на повышение производительности узла, повышение стабильности и децентрализации протокола.
Reth, разработанный на языке программирования Rust и выпущенный под лицензией Apache/MIT, фокусируется на сокращении задержек и поддержании времени безотказной работы, делая блокчейн Ethereum более доступным для разработчиков и способствуя разнообразию клиентов в экосистеме Ethereum.
На кодирование проекта команда из 98 разработчиков потратила 9 месяцев.
Проект направлен на сокращение задержки между узлом и сетью при постоянном поддержании времени безотказной работы. Тем не менее, основная цель Reth выходит за рамки технических: она заключается в том, чтобы сделать блокчейн Ethereum более доступным для разработчиков за счет повышения производительности узлов.
Хотя разнообразие клиентов не является насущной проблемой для Ethereum, для пользователей сети крайне важно полагаться на разнообразные клиентские проекты, которые предлагают полнофункциональное программное обеспечение узла и хорошо подключены к сети. Здесь в игру и вступает Reth.
Reth: клиентское программное обеспечение Ethereum, ориентированное на производительность
Клиентов узлов Ethereum можно разделить на две категории: те, которые предназначены для уровня исполнения Ethereum, обрабатывающего расчеты транзакций, и те, которые предназначены для уровня консенсуса, отвечающего за достижение консенсуса в сети. Примечательно, что Paradigm присоединилась к растущему списку компаний, разрабатывающих такое программное обеспечение для Ethereum на и без того переполненном рынке клиентского программного обеспечения.
Существующие популярные клиенты исполнения включают Geth, Nethermind, Besu и Erigon, а согласованные клиенты — Lighthouse, Lodestar, Nimbus, Prysm и Teku. Тем не менее, экосистема Ethereum всегда выигрывает от притока новых клиентских проектов, особенно тех, которые поддерживаются влиятельным венчурным фондом, таким как Paradigm, известный своим высоким техническим мастерством и финансовой состоятельностью.
Основная роль Reth будет заключаться в выполнении функций исполняющего клиента, что позволит пользователям использовать его для построения блоков и извлечения максимальной ценности по мере необходимости. Более того, он также может поддерживать узлы консенсуса Ethereum.
Reth уже продемонстрировал впечатляющие показатели производительности. Команда заявила, что Reth может выдерживать большой трафик и быстро синхронизироваться. Он смог синхронизироваться с блокчейном Ethereum с момента своего возникновения до 17,4 миллиона блоков за 50 часов. Paradigm утверждает, что это самая высокая скорость синхронизации среди всех клиентских проектов.
Рисунок 1. Сравнение производительности Reth и Erigon.
Несмотря на эти значительные достижения, Reth все еще находится в стадии альфа-тестирования, и команда работает над повышением стабильности и отказоустойчивости программного обеспечения.
Георгиос Константинопулос, технический директор Paradigm и разработчик Reth, ответил на вопросы о роли Reth в экосистеме Ethereum и рассказал о проблемах, с которыми команда столкнулась при создании Reth, и своем видении будущего индустрии.
Какой вы видите роль Reth в экосистеме Ethereum в ближайшие 5 лет? Вы стремитесь обогнать существующих клиентов или планируете остаться нишевым альтернативным вариантом?
— Мы считаем, что, используя Reth в качестве узла, мы можем активно способствовать расширению разнообразия клиентов Ethereum, тем самым улучшая стабильность и децентрализацию протокола. Кроме того, роль Reth в качестве SDK гарантирует, что он предоставляет удобный и доступный инструмент для разработки ориентированной на EVM инфраструктуры, такой как индексаторы, построители блоков и многое другое.
Мы надеемся, что Reth сможет стать подходящей альтернативой для людей, которым нужны высокая производительность и отличный опыт работы с узлами.
С какой самой неожиданной проблемой вы столкнулись при разработке Reth? Чему вы научились?
Сложнее всего было, во-первых, изучить все крупные сбои, которые имели место в истории Ethereum, и должным образом учесть их при разработке, во-вторых — оптимизацировать каждый компонент узла при наличии таких сбоев.
Самый большой урок, который мы извлекли из этого, вряд ли вас удивит: зрелые методы тестирования и сравнительного анализа являются основой для любого инструментария разработчика высокопроизводительных/сложных систем. Мы уделяли этому большое внимание на раннем этапе, и это позволило нам очень быстро внедрять новые функции, не опасаясь сбоев или регрессий.
Насколько тщательно Reth был протестирован в неблагоприятных условиях, таких как большие объемы транзакций, разделение сети или атаки типа «отказ в обслуживании»? Есть ли у вас беспокойство по поводу его устойчивости?
— Хочу подчеркнуть, что Reth находится в фазе «альфа», и мы все еще активно тестируем и улучшаем его стабильность.
Мы применяем многоуровневый подход к безопасности, чтобы обрести уверенность в отказоустойчивости. Во-первых, мы сами управляем узлами и внимательно следим за ними, их логами, метриками, оповещениями и т.д. Во-вторых, мы каждую ночь запускаем пакет тестирования Hive на Github Actions, который проверяет реорганизацию и другие пограничные случаи, связанные с консенсусом. Наконец, мы разработали Flood для стресс-тестирования Reth при высоких объемах RPC, которые выглядят как DoS-атаки.
В целом мы довольны тем, как ведет себя узел сегодня, хотя нам еще предстоит раскрыть дополнительные случаи сбоев. Мы уверены в правильности исторической синхронизации, и любые проблемы с устойчивостью будут связаны с крайними случаями, которые мы еще не наблюдали. Тестирование никогда не заканчивается, и это процесс, к которому мы относимся очень серьезно в долгосрочной перспективе.
В какой момент вы сочтете, что Reth «готов к производству» и какие шаги вам нужно предпринять, чтобы достичь такого уровня зрелости? Как сообщество может помочь ускорить прогресс?
— Готовность к производству — это действительно высокая планка, которой мы стремимся соответствовать в будущем. Мы спросили операторов узлов, что для является самыми важными показателями готовности, и они назвали следующие:
Время безотказной работы Reth. Для стекинга это почти 100% время безотказной работы, иначе вы можете быть урезаны протоколом.
Способность выживать в суровых условиях без повреждения базы данных, например, при SIGKILL, перебоях в подаче электроэнергии или перезапуске узла/машины.
Может ли узел оставаться синхронизированным и быстро следовать подсказке, даже при большой нагрузке (тогда как другие узлы иногда начинают отставать создавая проблему для надежности).
Все эти показатели мы активно отслеживаем на всех наших работающих узлах. Узким местом для готовности к работе будет время, больше внимания к коду и больше операторов, управляющих узлом. Мы просим членов сообщества быть максимально открытыми и прямыми в своих отзывах. Мы очень серьезно относимся к обратной связи и хотели бы, чтобы люди запускали узлы и делились с нами своим опытом.
Если бы вам пришлось выбрать одну часть дорожной карты Ethereum, на которой Reth сосредоточил бы усилия, что бы это было и почему? Что Reth мог бы сделать по-другому в этой области?
— Дорожная карта Ethereum длинная и амбициозная! Я думаю, что трудно выбрать один пункт из этого списка, учитывая его долгосрочность. Я думаю, что EIP-4844 и Cancun — это самое важное, что нам нужно сделать правильно из-за последствий для масштабируемости объединения.
Что вы думаете о разнообразии клиентов для Ethereum? Достаточно ли у нас сейчас независимых реализаций протокола? Что можно улучшить?
Разнообразие клиентов имеет решающее значение для такой устойчивой сети, как Ethereum. Если доминирует один клиент с долей рынка 66% и более, существует значительный риск нарушения блокчейна и причинения денежных потерь операторам узлов. Это связано с тем, что если у этого клиента есть ошибка и он разветвляется на свой форк, он может завершить разветвление, что затрудняет для валидаторов возврат к реальному блокчейну без штрафных санкций.
Любой может начать новую реализацию протокола Ethereum на любом языке по своему выбору, как это сделали мы. Основная проблема разнообразия клиентов заключается в том, что тестирование всех клиентских реализаций становится сложнее. Мы должны больше инвестировать в инфраструктуру тестирования интеграции между узлами, как это делает Ethereum Foundation, поддерживая Hive.
Где вы видите самые большие возможности для улучшения производительности или функциональности по сравнению с существующими клиентами Ethereum? В чем заключается преимущество Reth?
Во-первых, нам посчастливилось извлечь уроки из клиентской разработки за прошедшие годы, что позволило избежать многих ошибок. Во-вторых, мы решили построить Reth как совершенно новую современную кодовую базу, написанную на Rust, которая хорошо документирована, протестирована и модульна, что обеспечивает высокую производительность при быстрой скорости разработки с небольшим техническим долгом.
Тем не менее, мы видим много областей, требующих улучшения. Мы хотели бы поддерживать OP Stack как часть реализации вышестоящего узла и дополнительно реорганизовать кодовую базу, чтобы ее было легче использовать. Наконец, мы также за дальнейшую оптимизацию производительности, особенно в отношении чтения и записи на диск, а также размера базы данных.
Мы приглашаем всех разработчиков присоединиться к нам в этом процессе расширения и оптимизации узла!
