Пользователь A отправляет транзакцию пользователю B. Эти транзакции объединяются в дерево Меркла. Пользователь A и B могут использовать транзакцию плюс корень merkle, а также путь merkle, чтобы доказать правильность корня merkle в заголовке блока.
Я все это понимаю ... чего я не понимаю, так это того, как A и B узнают правильный путь Меркла, не нуждаясь во всем блоке?
Нужен ли им централизованный провайдер, который обрабатывает блоки для их расчета? Возможно ли это сделать децентрализованно?
Пользователь A отправляет транзакцию пользователю B. Эти транзакции объединяются в дерево Меркла. Пользователь A и B могут использовать транзакцию плюс корень merkle, а также путь merkle, чтобы доказать правильность корня merkle в заголовке блока.
Позвольте мне перефразировать ваш вопрос, чтобы убедиться, что мы согласны с ним:
Алиса платит Бобу. Когда Алиса отправляет свою транзакцию в сеть, она остается неподтвержденной. Транзакция подтверждается включением в блок. Заголовок блока включает корень Меркла, который является криптографическим обязательством для включенного набора транзакций (по порядку).
На данный момент ни Алиса, ни Боб не знают пути Меркла. В зависимости от тонкого клиента, на котором они работают, их кошелек либо запрашивает полноценный одноранговый узел, чтобы пометить транзакции, которые соответствуют фильтру Блума, кодирующему их интересы (BIP 37 (устарело)), либо они доверяют провайдеру услуг знание своих адресов (Electrum, различные централизованные службы кошельков), или они загружают компактные фильтры блоков на стороне клиента, которые они могут использовать локально, чтобы увидеть, может ли блок включать что-либо интересное (BIP 157/158).
Как только тонкий клиент узнает об интересующей его транзакции, тонкий клиент либо запрашивает блок merkle для конкретной транзакции, либо полный блок у однорангового узла с полным узлом или у своего поставщика услуг. Структура данных блока Merkle имеет всех необходимых партнеров по хэшированию для восстановления полной ветви от листа транзакции до корня, а также заголовка блока (как, конечно, и всего блока). Вот как они знают!
Как написал Читрик в другом ответе, большинство тонких клиентов следуют за сетью, синхронизируя цепочку заголовков блоков. Поскольку они не анализируют полные блоки, они не отслеживают полную книгу балансов биткойнов (неизрасходованный выходной набор транзакций) и, следовательно, не могут проверять транзакции. Однако они могут выполнять базовые проверки достоверности блоков, например, соответствуют ли они текущему требованию сложности и действительно ли содержимое заголовка блока соответствует заданному хэшу.
как A и B узнают правильный путь Меркла, не нуждаясь во всем блоке?
Многие легкие клиенты будут синхронизироваться с самой длинной цепочкой заголовков, предполагая, что другие узлы в сети будут проверять полное содержимое этих блоков на достоверность. (Учтите: если бы каждый узел был лайт-клиентом, майнеры могли бы включать в блоки недопустимые транзакции, и ни один из лайт-клиентов не знал бы об этом!)
Запрашивая промежуточные состояния дерева Меркла у узла, имеющего полный блок, легкий клиент может удостовериться, что интересующая пользователя транзакция действительно включена в блок, являющийся частью самой длинной цепочки, в более эффективной схеме. способом, чем проверка всего блока (оговорка заключается в предположении о достоверности, упомянутом выше).
Нужен ли им централизованный провайдер, который обрабатывает блоки для их расчета? Возможно ли это сделать децентрализованно?
Это полностью зависит от реализации. Некоторые легкие кошельки могут просто перезвонить на определенный сервер, например, управляемый разработчиками кошелька. Другие легкие клиенты могут попытаться получить эту информацию от случайных узлов в сети. Некоторые даже созданы для подключения к вашему собственному узлу.
В конечном счете, самый высокий уровень уверенности достигается при самостоятельном запуске узла с полной проверкой (т. е. полного узла). Как любят говорить биткойнеры: не доверяй, проверяй.