SPV проверяет заголовки, а не всё состояние
Раздел 8 whitepaper описывает simplified payment verification: клиент хранит заголовки цепочки с наибольшей работой и ветвью Меркла проверяет включение. Он проверяет proof of work и порядок заголовков, не загружая все транзакции.
При этом он не строит набор UTXO и не проверяет каждую подпись, скрипт и правило выпуска. Он сильнее полагается на стимулы майнеров и на то, что peer-узлы не скроют важные сведения.
BIP 37 раскрывает фильтр серверу
Кошелёк BIP 37 отправляет фильтр Блума, созданный из отслеживаемых ключей, скриптов и выходов. Полный узел возвращает совпадения и частичное дерево Меркла; ложные срабатывания скрывают точный интерес, но увеличивают трафик.
Повторные фильтры всё равно могут связать адреса между собой и с сетевым соединением клиента. Вредоносный peer способен пропустить данные, а доказательство наличия не подтверждает полноту ответа.
BIP 157 и 158 меняют направление
Полный узел создаёт для каждого блока детерминированный компактный фильтр. Клиент скачивает его, локально ищет свои скрипты и при совпадении получает весь блок, а не отправляет каждому peer запрос, выведенный из адресов.
BIP 157 связывает заголовки фильтров в цепочку и определяет их получение по P2P. Сравнение ответов помогает выявить неверный фильтр при наличии хотя бы одного честного источника, хотя загрузка совпавшего блока всё ещё может оставить сетевой след.
Два значения слова compact
Фильтры BIP 157/158 помогают лёгким клиентам находить нужные исторические блоки. Compact block relay по BIP 152 восстанавливает новый объявленный блок из транзакций, уже имеющихся в mempool полного узла. Они решают разные задачи.
Собственный полный узел даёт наиболее сильную независимую проверку, но требует ресурсов и обслуживания. Лёгкий клиент — допустимый компромисс для ограниченного устройства, если интерфейс честно объясняет, что проверяется и откуда поступают данные.