Как деревья Меркла могут гарантировать, что полный узел не ложится на тонкий узел, что txn t отсутствует в блоке B, если фактически B содержит t? Как тонкий узел может определить, лжет ли полный узел, если полный узел отрицает наличие txnt в блоке B и не отправляет никаких хэш-значений (для проверки тонким узлом) и вместо этого утверждает, что не может генерировать хэши, которых нет.
PS: Не обращайте внимания на неформальный стиль моих вопросов. Сначала я просто пытаюсь получить интуитивное представление о деревьях Меркла.
Ваша интуиция верна: полный узел может обмануть легкого клиента и лишить его доказательств того, что транзакция была включена в блок. Это хорошо задокументированная уязвимость кошельков SPV, и единственное ее решение — подключиться к большему количеству пиров (вам нужен только один «честный» пир).
Эта проблема также частично решается BIP157 , также известным как «Neutrino». В этом протоколе легкий клиент сканирует целые блоки для собственных транзакций. Он знает, какие блоки проверять на основе фильтров, предоставляемых полными узлами. Конечно, это возвращает нас к первому вопросу: что, если полный узел предоставляет недопустимый фильтр? В конце концов мы можем увидеть софт-форк, требующий вставки допустимых фильтров в какую-то часть блока, защищенных доказательством работы.
В настоящее время BIP157 предлагает следующее:
Если клиент не имеет безопасного подключения к доверенному узлу, который обслуживает заголовки фильтров, клиенту СЛЕДУЕТ подключаться к нескольким исходящим узлам, поддерживающим каждый тип фильтра, чтобы снизить риск загрузки неправильных заголовков. Если клиент получает конфликтующие заголовки фильтров от разных одноранговых узлов для любого блока и типа фильтра, он ДОЛЖЕН опросить их, чтобы определить, какой из них неисправен. Клиенту СЛЕДУЕТ использовать getcfheaders и/или getcfcheckpt, чтобы сначала определить первые заголовки фильтра, с которыми не согласны одноранговые узлы. Затем клиент ДОЛЖЕН загрузить полный блок с любого узла и получить правильный фильтр и заголовок фильтра. Клиенту СЛЕДУЕТ блокировать любые пиры, отправившие заголовок фильтра, который не соответствует вычисленному.