Масштаб слияния Eth1-Eth2 Переход от Eth1 к Eth2 Оригинал:
https://ethresear.ch/t/the-scope-of-eth1-eth2-merger/7362 Автор Mikhail Kalinin(
@mkalinin)
Спасибо
@timbeiko,
@djrtwo,
@gballet за обсуждение и комментарии.
Эта статья является продолжением статьи
@djrtwo, о
взаимодействии клиентов Eth1+Eth2. Принимая во внимание разделение обязанностей, описанное в предыдущем документе, в качестве основы, оно нацелено на определение объема работ, необходимых для осуществления слияния.
Наряду с областью применения, в нем содержатся соображения относительно реализации конкретных компонентов eth1-движок и eth2-клиент в контексте шардов Eth1. В зависимости от раздела эти мысли имеют разный уровень детализации. Эта информация предназначена для того, чтобы стать отправной точкой для дальнейшего обсуждения спецификаций и реализации.
Примечание: результаты Eth1.x(это кодовое имя для полного набора обновлений в основной сети Ethereum), предназначенного для краткосрочного внедрения не являются строго обязательными для технической стороны слияния. Несмотря на это, предварительные условия включают Eth1.x, чтобы подчеркнуть, насколько важны его усилия для принятия валидаторов и взаимодействия с пользователем после слияния.
Консенсус 
Предпосылки Фаза 1:
-переход между состояниями
-выбор форка
-валидатор
Eth 1.x:
-выполнение без управления состоянием
Масштаб:
движок Eth1:
-обработка блоков
-производство блоков
-выбор внешней вилки
Шард Eth1:
-функция состояния перехода
-обязанности валидатора
Цепь Маяков(Beacon chain):
-шарды Eth1 как источник депозитов
-возможности валидатора
-выбор комитета по шардам Eth1
-вознаграждения Eth1
Движок Eth1(Eth1-engine)Для совместимости с шардами Eth1, eth1-движок должен будет предоставлять производство и обработку блоков через свой интерфейс. В настоящее время конечная точка
eth_getWork производит блок, но не возвращает его полную структуру, и обработка блоков также кажется примитивной (см.
InsertChain ). Кроме того, объем работы по этим двум направлениям включает в себя избавление от алгоритма Ethash и управление случаем параллелизма, когда производство блоков зависит от обработки.
Выбор форка для шард Eth1 будет полностью зависеть от Eth2 клиента. Поскольку для оптимизации пула транзакций необходимо заранее знать, кто является главным в цепи, то механизм Eth1 должен знать о реорганизациях, произошедших на стороне клиента Eth2. Для определения выбора конечной точки для форка можно использовать интерфейс комплекта с воздействующей функцией
SetHead. Это изменение также подразумевает удаление повторных заявок из потока обработки блока eth1-движком.
Шарды Eth1Состояние перехода шардами Eth1 вызывает eth1-движок для обработки блока и проверки результата. Чтобы создать блок, производителям блоков шардов Eth1 также придется вызвать eth1-движок. Аттестаторы, назначенные на шарды Eth1, должны будут выполнить блок Eth1 и проверить результат выполнения. Эти расширения перехода являются предметом спецификации шардов Eth1.
Учитывая потенциальное использование, тело блока шардов Eth1 должно содержать, по крайней мере, следующие данные:
-Хэш блока в стиле Eth1. Скорее всего, он будет задействован в производстве блоков, чтобы указать eth1-движку на родительский блок
-корневой узел состояния Eth1. С помощью этих данных становится возможным построение доказательств состояния Eth1, превращая различные варианты использования, пересекающие границу eth1-eth2, в реальность.
-Квитанции транзакций. Другой способ установить связь между eth1-eth2 - это использование квитанций.
-RLP(Recursive Length Prefix) кодирование блока Eth1. Основная полезная нагрузка блока шардов Eth1.
Объект
ShardStateбудет содержать корень хэш-дерева этих данных в поле данных, поставляющем цепочку маяков со всеми основными элементами блока Eth1 через доказательства merkle.
Примечание: представление квитанций о транзакциях превращается в дополнительную работу для поставщика блоков шардов Eth1. Он должен будет анализировать RLP-кодированные квитанции, возвращаемые eth1-движком, и публиковать их в формате, подходящем для цепочки маяков.
Цепь маяка (Beacon Сhain)Механизм голосования данными Eth1, используемый в настоящее время в Фазе 0, может получить значительное улучшение после слияния. Более того, он может стать первым прецедентом использования нового консенсуса. Когда шарды Eth1 стартуют, кореневой депозит может обновляться так же часто, как и перекрестные связи корневого каталога состояния Eth1. Корневой депозит Merkle, проверенный любым клиентом сети маяков, дополняется возможностью мгновенного включения новых депозитов. Обратите внимание, что для проверки корректных подтверждений, созданных на основе корневого состояния Eth1 или, например, полиномиальных обязательств, которые могут прийти взамен, клиент маяк должен знать алгоритм проверки. Например, если клиент-маяк должен был проверить корневой каталог состояния Eth1 в текущий момент, он должен будет поддерживать хэш функцию Merkle Patricia Trie и keccak256.
Существует более удобный способ обработки депозита, который использует квитанции транзакций Eth1. Участники цепочки маяков смогут анализировать квитанции, соответствующие
DepositEvent, и вызывать новые депозиты после сшивания фрагмента Eth1.
Согласно существующему уровню технологии, валидатор, удостоверяющий или создающий на шардах Eth1, должен будет поддерживать полное состояние Eth1. Снижение этого требования является одной из целей исследований Eth1.x. После того как выполнение без управления состоянием будет осуществлено, аттестаторы станут свободными от поддержания состояния, но не производителей. Такое разделение создает потребность в управлении возможностями валидатора. Это может быть реализовано путем добавления флагов возможностей в качестве еще одного поля в запись валидатора. Такое изменение подразумевает новую операцию в цепи маяка для обновления флагов возможностей. Выбор комитета по шардам Eth1 должен будет отслеживать возможности валидаторов, делая выбор комитета еще одним предметом для спецификации шардов Eth1.
Eth1 награды После того, как произойдет слияние, и PoW(Proof Of Work) перестанет существовать в основной сети, произойдет существенное сокращение эмиссии, избавившись от вознаграждений за блокировку и uncle-блоков.
Награды претендентов на шард блок в Фазе 1 описаны в
этом выпуске и состоят из следующих частей:
-награда нашедшему блок
-EIP-1559 плата за байт в блоке данных
-комиссия за транзакцию
Переход состояния цепочки маяков отвечает за обработку первого и второго этапов, то есть основной протокол оплачивает предложение блока Eth1 и вычитает плату
EIP-1559 из баланса предложения. Плата за транзакцию, взимаемая (если таковая имеется), предполагается вне основного протокола.
На этапе 2, когда блок шардов становится исполняемым, газ, используемый блоком, заменит размер в схеме выше. Он сохраняет логику EIP-1559 в базовом протоколе. Следуя менее агрессивной стратегии слияния, мы могли бы взять на себя ответственность за обеспечение оплаты EIP-1559 с помощью eth1-движка с последующими изменениями в Фазе 2.
В этом случае расчет лимита газа может быть перенесен в основной протокол и явно передаваться eth1-движком во время процесса создания блока. Разработчики шардов Eth1 могли бы просто использовать монетную базу для оплаты комиссии за транзакцию. Другим вариантом было бы явно включить транзакционные сборы в блок шардов и сделать основной протокол ответственным за депонирование этих сборов на счет валидатора. Этот компромисс между валидатором, поддерживающим несколько идентификаций, и усложнением основного протокола еще предстоит решить.
Еще одна трата, которую придется учитывать валидаторам шардов Eth1, - это плата за хранение, необходимая для поддержания состояния Eth1. К счастью, если валидатор с поддержкой Eth1 в настоящее время не участвует в комитете по шардам Eth1, он может отказаться от состояния, уменьшив плату за хранение и синхронизируя его обратно, когда это необходимо.
Сеть 
Продолжение в следующем посте
Poll
