Предпосылки
Фаза 1
Темы подсети:
-синхронизация сети шардов
Eth1x :
-синхронизация состояний
-хранение ретроспективных данных
Масштаб:
-служба обнаружения
-сетевая репутация
-синхронизация сети шард Eth1
Служба обнаружения
В своей статье eth1+eth2 client relationship Дэнни @djrtwo разумно предлагает сохранить P2P-интерфейсы eth2-клиент и eth1-движок отдельно. Эти пары интерфейсов должны работать под одной и той же сетевой идентификацией. В противном случае было бы трудно оправдать репутацию пиров, составляющих сеть шардов Eth1.
Работа под единым идентификатором подразумевает совместное использование службы обнаружения между eth2-клиент и eth1-движок. Это имело бы смысл, если бы eth2-клиент взял на себя ответственность за обнаружение сети, предоставив услугу обнаружения eth1-движку. Такой подход к распределению обязанностей обнаружения, вероятно, делает коммуникацию в паре клиент-движок двунаправленной из-за шаблона, широко используемого в клиентах eth1 для запроса обнаруженных одноранговых узлов по требованию.
Другой подход к службе обнаружения пары клиент-движок будет заключаться в сохранении обнаружения eth1-движка и начальной загрузке его с идентификатором узла, используемым eth2-клиентом. Этот способ менее инвазивен для кодовой базы eth1-движка и все еще позволяет поддерживать общую сетевую идентичность, не требуя, чтобы связь клиент-движок была двунаправленной.
Сетевая репутация
Работающая под одним и тем же сетевым идентификатором пара клиент-движок становится единым субъектом репутации. Однако управление репутацией других одноранговых узлов в сети требует дополнительной связи между eth2-клиентом и eth1-движком, поскольку они все еще разделяют сетевые обязанности, такие как сплетни о транзакциях и синхронизация состояний eth1-движком против сплетен о блоках eth2-клиентом. Например, обе части пары должны будут уведомлять друг друга о плохом поведении, наблюдаемом на их стороне сети, что приведет к отключениям и дальнейшим запретам вредоносных пиров.
Сетевые спецификации не охватывают эвристику репутации, что делает ее специфичной для конкретной реализации. Таким образом, он может отличаться не только между клиентами eth1 и eth2, но и между различными реализациями клиентов eth2. Это несоответствие оставляет небольшое пространство для эвристики совместного управления репутацией, которая, вероятно, будет урезана только для отключения сигналов. Эта часть протокола также требует двунаправленной связи в паре клиент-движок.
Синхронизация шардов Eth1
Eth1-движок будет отвечать за синхронизацию состояния либо с существующим в настоящее время алгоритмом, либо с любым другим решением, которое предложит Eth1x. Но управление процессом синхронизации должно быть выполнено eth2-клиентом, который изначально просматривает сеть, чтобы найти самую последнюю завершенную контрольную точку и отправить команду eth1-движку, чтобы начать синхронизацию с определенным состоянием корневого узла.
Другая часть того, что в настоящее время называется быстрой синхронизацией в Eth1, связывает загруженное состояние с блоком генезиса цепочкой Ethash-valid, проверяя, что состояние принадлежит канонической цепочке. В мире Eth2 такая проверка будет выглядеть иначе из-за слабой субъективности. Таким образом, eth2-клиент завершит синхронизацию шард Eth1, проверив, является ли состояние каноническим. Весьма вероятно, что обе части процесса синхронизации могут выполняться одновременно.
Другая ответственность, которую стоит отметить в этом разделе, это доступ к данным истории Eth1. В общем, древние данные будут полностью обрабатываться eth1-движком. После завершения процесса синхронизации eth2-клиент может отправить команду eth1-движку для получения всей цепочки блоков и квитанций. Однако иметь дело с историей, представленной цепочкой блоков и квитанциями, довольно обременительно. Одна из целей исследований Eth1x - улучшить управление историческими данными, что может значительно повлиять на впечатление от использования шардов Eth1.
Старая регулярная блочная синхронизация все еще может быть использована для быстрого восстановления состояния после относительно коротких периодов простоя. Однако для этого потребуется дополнительная информация, полученная из сети шардов Eth1, например номер блока Eth1, соответствующего началу цепочки. Если это число будет слишком далеко от текущего состояния клиента, то стоит вернуться к состоянию синхронизации или использовать другие методы, вероятно, заимствованные из синхронизации луча. В любом случае, с точки зрения eth2-клиента, это будет единственная команда для синхронизации с конкретным корневым узлом состояния, и эвристика этой синхронизации должна быть полностью обработана eth1-движком.
Клиент
Объем
-обновления кода
Избавление от PoW
-условия действия
-производство блоков
-выбор форка
Сетевой стек
-открытие
-репутация
Состояние триединой обрезки
-Eth1-Eth2 коммуникационный протокол
Консенсус
-установление главы
-создание блока
-вставка блока
-завершение блока
сеть
-открытие
-репутация
-синхронизация
UX дизайн интефейса
-фасадный интерфейс
-легкий клиент
-клиентная оснастка
Состояние триединой обрезки
Очистка устаревших версий состояния триединой обрезкой очень важна для поддержания нормального состояния Eth1 в течение всего времени работы клиента.
В настоящее время этот механизм использует отслеживание расстояния, чтобы определить, какие версии состояний устарели и должны пройти процесс сокращения. Параметр distance должен быть достаточно большим, чтобы защитить клиента от случайной реорганизации, требующей перехода от старой версии состояния, которое уже было обрезано, например клиент geth использует 128 блоки в качестве расстояния следования по умолчанию в основной сети.
Для шардов Eth1, более органичным триггером для обрезки будет завершение контрольной точки. Как только eth2-клиент получает новые завершенные контрольные точки, он может вызвать eth1-движок с хэшем завершенного блока Eth1 и тем самым запустить процесс состояния тройной обрезки вплоть до этого блока.
Набор инструментов
С точки зрения пользователя переключение с Eth1 на шарды Eth1 означало бы поддержание еще одного клиента и настройку соединения между двумя частями нового клиента. Это звучит как значительный недостаток UX дизайна. Клиентский инструментарий может быть средством от этого. Этот вид инструментария должен обеспечивать поддержку всех основных eth1-движков и eth2-клиентов, иметь возможность загружать и настраивать их, а также устанавливать канал связи пары клиент-движок.
Окончание в следующем посте
