Криптовалютная венчурная фирма Парадигма Вчера внес один из самых заметных вкладов в сеть Ethereum, запустив альфа-версию реализации узла с открытым исходным кодом под названием Reth v0.1.0.
Reth, разработанный на языке программирования Rust и выпущенный под лицензией Apache/MIT, является частью стремления Paradigm к активному влиянию на криптосферу путем создания клиентского программного обеспечения, ориентированного на производительность. На кодирование проекта ушло девять месяцев, преданная команда из восьми основных разработчиков и 90 участников.
Он направлен на сокращение задержки между узлом и сетью при постоянном поддержании времени безотказной работы. Тем не менее, основная цель Reth выходит за рамки технических, поскольку она направлена на то, чтобы сделать блокчейн Ethereum более доступным для разработчиков за счет повышения производительности узлов.
Хотя разнообразие клиентов не является насущной проблемой для Ethereum, для пользователей сети крайне важно полагаться на разнообразные клиентские проекты, которые предлагают полнофункциональное программное обеспечение узла и хорошо подключены к сети. Здесь в игру вступает Рет.
«Мы считаем, что, используя Reth в качестве узла, мы можем активно способствовать расширению разнообразия клиентов Ethereum, тем самым улучшая стабильность и децентрализацию протокола», — сказал The Block Георгиос Константинопулос, технический директор Paradigm и разработчик 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 утверждает, что это самая высокая скорость синхронизации среди всех клиентских проектов.
Несмотря на эти значительные улучшения, Reth все еще находится в стадии альфа-тестирования, и команда работает над повышением стабильности и отказоустойчивости программного обеспечения.
Блок догнал Георгиоса из Paradigm Константинопулос чтобы обсудить роль Reth в экосистеме Ethereum, проблемы, с которыми пришлось столкнуться при создании Reth, и то, что индустрия должна ожидать в будущем. Вот полный ответ на вопросы:
Какой вы видите роль Reth в экосистеме Ethereum в ближайшие 5 лет? Вы стремитесь обогнать существующих клиентов или остаться нишевым альтернативным вариантом?
Мы считаем, что, используя Reth в качестве узла, мы можем активно способствовать расширению разнообразия клиентов Ethereum, тем самым улучшая стабильность и децентрализацию протокола. Кроме того, роль Reth в качестве SDK гарантирует, что он предоставляет удобный и доступный инструмент для разработки ориентированной на EVM инфраструктуры, такой как индексаторы, построители блоков и многое другое.
У нас нет мышления с нулевой суммой, и мы надеемся, что Reth предложит альтернативный вариант для людей, которым нужна высокая производительность и отличный опыт работы с узлами.
С какой самой неожиданной проблемой вы столкнулись при разработке Reth? Чему вы научились?
Самыми большими проблемами были:
- Изучение всех крайних случаев, которые существуют как часть истории Ethereum, и их правильная реализация.
- Оптимизация каждого компонента узла при наличии таких крайних случаев.
Самый большой урок, который мы извлекли из этого, неудивителен: зрелые методы тестирования и сравнительного анализа являются основой для любого инструментария разработчика высокопроизводительных/сложных систем. Мы уделяли этому большое внимание на раннем этапе, и это позволило нам очень быстро внедрять новые функции, охватывая крайние случаи и оптимизируя компоненты, не опасаясь сбоев или регрессий.
Насколько тщательно Reth был протестирован в неблагоприятных условиях, таких как большие объемы транзакций, разделение сети или атаки типа «отказ в обслуживании»? Что вас беспокоит по поводу его устойчивости?
Хочу оговорить этот ответ, сказав, что Reth находится в фазе «альфа», и мы все еще интенсивно тестируем и улучшаем его стабильность.
Мы применяем многоуровневый подход к безопасности, чтобы обрести уверенность в отказоустойчивости:
- Мы сами управляем узлами и внимательно следим за ними, их логами, метриками, оповещениями и т.д.
- Мы запускаем Улей набор тестов каждую ночь на Github Actions, который проверяет реорганизацию и другие пограничные случаи, связанные с консенсусом.
- Мы разработали Наводнение для нагрузочного тестирования Reth при высоких объемах RPC, которые выглядят как DoS-атаки.
В целом мы довольны тем, как сегодня ведет себя узел, хотя есть еще много пограничных случаев, которые предстоит раскрыть. Мы уверены в правильности исторической синхронизации, и любые проблемы с устойчивостью будут связаны с крайними случаями, которые мы еще не наблюдали на вершине цепочки, например, во время реорганизации, которая не зафиксирована в наборе для тестирования Hive. Тестирование никогда не заканчивается, и это процесс, к которому мы относимся очень серьезно в долгосрочной перспективе.
В какой момент вы сочтете, что Рет «готов к производству» и какие шаги вам нужно предпринять, чтобы достичь этого уровня зрелости? Как сообщество может помочь ускорить прогресс?
Готовность к производству — это действительно высокая планка, которой мы стремимся соответствовать в будущем. Мы спросили узловые операторы что это за планка для них, и это самые важные показатели, которыми они поделились для производственной готовности:
- Рета работает без сбоев. Для ставок это почти 100% время безотказной работы, иначе вы можете быть урезаны протоколом.
- Способность выживать в суровых условиях без повреждения базы данных, например, SIGKILL, перебоев в подаче электроэнергии или перезапусков узлов/машин.
- Может ли узел оставаться синхронизированным и быстро следовать совету даже при большой нагрузке (хотя, как ни странно, другие узлы иногда начинают отставать, и это проблема для вашей надежности).
Все это показатели, которые мы активно отслеживаем на всех наших работающих узлах. Узким местом для готовности к производству будет время, больше внимания к коду и больше операторов узла, управляющих узлом. Мы просим сообщество быть максимально открытыми и прямыми в своих отзывах. Мы очень серьезно относимся к каждому циклу обратной связи и хотели бы, чтобы люди запускали узлы и делились с нами своим опытом.
Если бы вам пришлось выбрать одну часть дорожной карты Эфириума, на которой сосредоточил бы усилия Рет, что бы это было и почему? Что Рет мог бы сделать по-другому в этой области?
Дорожная карта Ethereum длинная и амбициозная! Я думаю, что трудно выбрать один пункт из этого списка, учитывая его долгосрочность. Я думаю, что EIP-4844 и Cancun — это самое важное, что нам нужно сделать правильно из-за последствий для масштабируемости объединения. Я не думаю, что мы будем реализовывать что-то по-другому, но процесс реализации будет более совместным с остальными основными разработчиками, по сравнению с тем, как мы до сих пор догоняем известную цель.
Что вы думаете о разнообразии клиентов для Ethereum? Достаточно ли у нас сейчас независимых реализаций протокола? Что можно улучшить?
Разнообразие клиентов имеет решающее значение для такой устойчивой сети, как Ethereum. Если доминирует один клиент с долей рынка 66% и более, существует значительный риск нарушения цепочки и причинения денежных потерь операторам узлов. Это связано с тем, что если у этого клиента есть ошибка и он разветвляется на свою собственную цепочку, он может завершить разветвление, что затрудняет для валидаторов возврат к реальной цепочке без штрафных санкций.
Любой может начать новую реализацию протокола Ethereum на любом языке по своему выбору, как это сделали мы. Основная проблема разнообразия клиентов заключается в том, что тестирование всех клиентских реализаций становится сложнее. Мы должны больше инвестировать в инфраструктуру тестирования интеграции между узлами, как это делает Ethereum Foundation, поддерживая Улей.
Где вы видите самые большие возможности для улучшения производительности или функциональности по сравнению с существующими клиентами Ethereum? В чем заключается «несправедливое преимущество» Рета?
Во-первых, нам посчастливилось извлечь уроки из клиентской разработки за прошедшие годы, что позволило избежать многих ошибок. Во-вторых, мы решили построить Reth как совершенно новую современную кодовую базу, написанную на рабочем Rust, которая хорошо документирована, протестирована и модульна, что обеспечивает высокую производительность при быстрой скорости разработки с небольшим техническим долгом.
Тем не менее, мы видим много областей, требующих улучшения. Мы хотели бы поддерживать OP Stack как часть реализации вышестоящего узла и дополнительно реорганизовать кодовую базу, чтобы ее было легче использовать. Наконец, мы также рады дальнейшей оптимизации производительности, особенно в отношении чтения и записи на диск, а также размера базы данных.
Мы приглашаем всех разработчиков присоединиться к нам в этом процессе расширения и оптимизации узла!
