Объяснение дерева Меркла Ethereum

Вот мое основное понимание того, как Ethereum хранит транзакции

  1. Хэш генерируется для каждой транзакции
  2. Затем выбираются пары и генерируется хэш для каждой пары.
  3. Таким образом, последний оставшийся хеш становится корнем
  4. Заголовок блока содержит три дерева Меркла
    • Для поддержания состояния
    • Для поддержания транзакций
    • Для сохранения квитанций
  5. Каждый блок ссылается на хеш предыдущего блока.
  6. Я прилагаю очень распространенную схему, показывающую эту структуру

введите описание изображения здесь

Вопросы:
1. Корень состояния блока 180994 указывает на первого левого дочернего элемента корня состояния блока 180993. Что это значит и зачем это нужно?
2. Возьмем пример.
Первый блок 180993 имеет транзакцию, в которой Счет 98 передает 30 эфиров на Счет 100.
Второй блок 180994 имеет транзакцию, в которой Счет 99 передает 20 эфиров на Счет 100.

Как это отразится на дереве? Будет ли подобное перекрестное сопоставление деревьев Меркла, как показано на диаграмме? Пожалуйста, объясни

Добавлено больше деталей

введите описание изображения здесь

Ответы (3)

В состоянии есть информация обо всех аккаунтах в блокчейне, она не хранится в каждом блоке. Состояние генерируется при обработке каждого блока, начиная с блока генезиса. Каждый блок будет изменять только части состояния.

Как генерировать состояние описано в желтой книге (pdf) . Он определен таким образом, что его можно реализовать на любом языке программирования, и все такие реализации будут генерировать одно и то же представление.

  1. Это означает, что левая сторона не была изменена в блоке 180994. Это только представление, помните, что все состояние не сохраняется, только корневой хеш.

  2. В Ethereum есть статья про Merkle Trees , лучше я, наверное, не смогу. Основная идея деревьев Меркла заключается в том, что для одной операции будет изменено только минимальное количество узлов для пересчета корневого хэша.

спасибо за Ваш ответ! Вот мое понимание, пожалуйста, поделитесь своим мнением. 1. Каждый узел поддерживает всего три дерева. Каждый блок относится к одному из корней всего дерева. 2. На основе сопоставленного корня можно было найти состояние на этом этапе.
3. Допустим, 180994 имеет транзакцию (A->B 50 eth). Таким образом, это означает, что если я ссылаюсь на блок 180994, то на основе хэша корня состояния я могу найти, что состояние учетной записи A равно 50 eth, а состояние учетной записи B равно 150 eth (поскольку начальное состояние B было 100). 4. Если я имею в виду 180993, имеющую транзакцию, в которой общая сумма A становится 100 eth, то на основе корневого хэша состояния я могу найти, что состояние учетной записи A равно 100 eth.
1) Требуется только дерево состояний. Деревья транзакций и квитанций должны строиться из данных блока. Он используется только для проверки блока. Их необходимо хранить, потому что они больше не будут использоваться. 2. Да, если ваш узел хранит всю историю состояний, вы можете получить состояние в любой точке истории. Но некоторые узлы могут обрезать старую историю. 4) y 5) Государство покажет только окончательный баланс. Для блока 180993 A: 100, B: 100 и для блока 180994 A: 50, B: 150.
Спасибо за ваш ответ! Вы хотите сказать, что все деревья транзакций и квитанций хранятся в самом блоке, а не только в их корневом хэше? Можете ли вы также взглянуть на мой другой вопрос, т.е. «Как формируется дерево транзакций Ethereum», и поделиться своим мнением, поскольку оно находится в тех же строках.
Да, в каждом блоке есть полные транзакции. Корневой хэш txs предназначен для быстрой проверки того, что транзакции внутри блока не были изменены.

Говорят, что Ethereum имеет блокчейн на основе учетной записи . Состояние не хранится напрямую в каждом блоке.

Чтобы улучшить концептуальное понимание, мы можем сказать, что все состояния учетной записи находятся локально на узле Ethereum в виде «данных состояния». Это распространено из соображений производительности и предполагается, что он будет храниться в дереве Merkle Patricia, но спецификация протокола этого не требует. Желтая бумага утверждает,

Мировое состояние (состояние) представляет собой сопоставление между адресами (160-битными идентификаторами) и состояниями учетных записей (структура данных, сериализованная как RLP, см. Приложение B). Хотя это и не хранится в блокчейне, предполагается , что реализация будет поддерживать это сопоставление в модифицированном дереве Merkle Patricia .

Итак, помимо самого блокчейна, мы имеем дело со « вторым состоянием ». Данные состояния можно описать как неявные, то есть их можно рассчитать на основе фактических данных блокчейна. Транзакции содержат все соответствующие поля для определения новых данных состояния. В отличие от Биткойна, блоки Ethereum содержат копию как списка транзакций, так и корневого хэша Merkle всего дерева состояний.

Взято из « Желтой книги » доктора Гэвина Вуда:

Среда выполнения Ethereum: (иначе ERE) среда, которая предоставляется автономному объекту, выполняющемуся в EVM. Включает в себя EVM, а также структуру состояния мира, на которую EVM опирается для определенных I/Oинструкций, включая CALL& CREATE.

В заключение, хранение состояния управляется клиентской реализацией протокола Ethereum. Я прикрепил созданное мной (слишком упрощенное) изображение, целью которого является показать изменение состояния до и после отправки транзакции между двумя сторонами.

Изображение, которое я создал, чтобы помочь понять концептуальную модель перехода состоянияЧто касается понимания дерева Merkle Patricia, я бы указал вам на любую статью, посвященную деревьям Radix .

Прежде всего спасибо за подробный ответ! Только что немного переделал схему. Список моего понимания и запросов. Пожалуйста, поделитесь своим мнением о них. Q1. Что я получаю, так это то, что заголовок блока хранит только корневые хэши для каждого дерева, т.е. состояния/транзакции/квитанции. Фактическое дерево — это единое дерево с различными корнями по мере роста. Q2. Корень состояния этого блока указывает на корень, который может дать вам состояние (т.е. на тот момент) всех учетных записей, участвующих в этих транзакциях, присутствующих в блоке.
Q3. Таким образом, основываясь на недавно добавленном изображении, если я ссылаюсь на блок 180993 (при условии, что учетная запись A получает эфир, что делает его в общей сложности 100), то с помощью корневого хэша состояния я могу найти, что состояние учетной записи A равно 100, относящееся к этому блоку. Q4. Допустим, 180994 имеет транзакцию (от A до B 50 eth). Таким образом, это означает, что если я ссылаюсь на блок 180994, то на основе корневого хэша состояния я могу найти, что состояние учетной записи A равно 50 eth, а состояние учетной записи B — 150 eth, специфичных для этого блока. Q5. Надеемся, что деревья состояний/транзакций/квитанций поддерживаются каждым клиентом на соответствующих узлах.
Q6. Но предположим, что узел A (т. е. имеющий учетную запись A) не работает, но вызов от узла B может определить баланс A, возможно, с помощью дерева транзакций и суммирования всех переводов учетной записи с/на учетную запись A. Q7. Если допустим, что узел A был активен, то, если был вызов для поиска баланса A, он запросит узел A напрямую. Поверьте, этого никогда не происходит, он просто пытается выяснить, используя корневой хэш состояния из последнего блока, а затем находит состояние A, которое здесь равно 50 eth?

Украдите эту диаграмму у Бадра в этом фантастическом ответе . Где хранятся данные о состоянии?

«Блок 180994 указывает на первого левого потомка блока 180993» просто означает, что первый левый потомок был мутирован . Таким образом, мы могли бы просто ссылаться на один и тот же хэш. Обратите внимание, что этот подход применяется рекурсивно . И именно поэтому мы видим много отсылок к предыдущему блоку.

введите описание изображения здесь

Объяснение дерева Меркла Ethereum
СпросиСетьПолитика конфиденциальности1y, 3v