Compact Block Filters — небольшие фильтры данных для отдельных блоков. Блок — группа транзакций, добавленная в общую историю сети. Эти фильтры помогают лёгкому кошельку выбрать блоки, которые могут содержать его транзакции и заслуживают загрузки. Это компактный ориентировочный указатель, допускающий ложные совпадения. Поиск происходит внутри кошелька, поэтому серверу не нужно отправлять список отслеживаемых данных.
Анна открывает кошелёк в телефоне после долгого перерыва. Приложение должно узнать, заплатил ли ей кто-нибудь после последнего подключения и не потрачена ли часть её средств. Вместо всех транзакций оно скачивает небольшие фильтры и сравнивает их с условиями отслеживаемых выходов. Выход — часть транзакции, задающая сумму и правила её дальнейшего расходования. При совпадении приложение запрашивает весь блок и ищет настоящую транзакцию. Увеличивать баланс только по совпадению нельзя. Фильтр не является выпиской по счёту или доказательством владения. Перед поиском клиент синхронизирует заголовки — краткие идентифицирующие данные блоков — и связанные заголовки фильтров. [1]
При более старом подходе BIP 37 клиент отправлял другому узлу фильтр из данных, которые хотел отслеживать. Здесь направление обратное: сервер предоставляет фильтр блока, а Анна ищет локально. Для одинакового блока и типа фильтра клиенты получают одинаковое содержимое. Поэтому им не нужно прямо раскрывать каждому серверу искомые скрипты. Это не обеспечивает анонимность: другой узел по-прежнему может видеть IP-адрес, время подключения и полные блоки, которые кошелёк запросит затем. Распределение загрузок между узлами ограничивает сведения у каждого, но не устраняет все возможности их сопоставления. [1]
Compact Block Filters выбирают блоки для дальнейшей проверки. Compact Blocks по BIP 152 решают другую задачу: экономят трафик при передаче блока благодаря коротким идентификаторам транзакций, которые получатель часто уже знает. Он берёт их из своего Mempool, локального набора неподтверждённых транзакций, а недостающие запрашивает. Ни один инструмент сам по себе не проверяет все правила Bitcoin. Full Node, то есть полный узел, независимо проверяет блоки и транзакции по правилам сети. Лёгкий кошелёк, проверяющий только заголовки и включение своей транзакции, выполняет более узкую проверку. Экономия данных и полная валидация — разные свойства. [1] [5]
Формат задаёт BIP 158. Фильтр basic включает scriptPubKey, скрипт с условиями расходования, новых выходов, кроме начинающихся с OP_RETURN. Он также включает скрипты прежних выходов, расходуемых внутри блока. Для входов исключение — coinbase, первая транзакция блока, распределяющая вознаграждение майнера и не расходующая обычных прежних выходов. Её новые выходы включаются по тем же правилам, что и остальные новые выходы. Пустые элементы пропускаются. Кошелёк должен преобразовать адрес в правильный скрипт; искать его печатный текст недостаточно. Фильтр не является универсальным поиском txid, то есть идентификаторов транзакций, данных witness вроде подписей или произвольных заметок. [2] [3]
Скачав блок, Анна может обнаружить, что в нём нет ничего относящегося к ней. Ложное совпадение — обычная плата за компактность фильтра, а не само по себе доказательство сбоя. Технически элементы преобразуются в числовые отпечатки, сортируются, а разности компактно записываются кодированием Golomb-Rice. Для basic заданы P=19 и M=784931. Один запрос об отсутствующем элементе совпадает с вероятностью примерно 1/M; больше отслеживаемых элементов создаёт больше возможностей для совпадения. Это не постоянная частота ошибок всего кошелька. Правильно построенный фильтр не пропускает включённый элемент. Отрицательный результат надёжен лишь при правильном фильтре, охваченном типе данных и правильном запросе. [2]
BIP 157 определяет передачу фильтров и их связанные заголовки. Каждый заголовок соединяет hash, криптографический отпечаток текущего фильтра, с предыдущим заголовком. Изменение фильтра нарушает ожидаемую связь. Но эта цепочка не является частью заголовка блока Bitcoin, и майнинг не закрепляет её содержимое непосредственно. Нечестный узел может подготовить ложные фильтры с правильно рассчитанными связанными отпечатками. Он не меняет Bitcoin, но может скрыть информацию от изолированного клиента. Поэтому проверку математических связей необходимо дополнять проверкой исходных данных. [1]
BIP 157 предусматривает сравнение узлов при наличии хотя бы одного честного источника. При расхождении клиент может найти первую разницу и проверить фильтр по исходным данным. Для построения basic одного нового блока может не хватить: нужны также скрипты прежних выходов, которые расходуют его транзакции. Особого внимания требует реорганизация, когда сеть переходит на другую ветвь действительных блоков с большей накопленной работой. Кошелёк должен связать фильтры с новой ветвью и обновить историю и баланс. Одна высота, то есть позиция в цепочке, не обязательно означает один и тот же блок. [1] [3]
Кошельку нужны доступные фильтры и способ получить выбранные полные блоки. Узел может удалить старые блоки после создания фильтров; тогда их должен предоставить другой источник. В Bitcoin Core команда getblockfilter возвращает фильтр и его заголовок для заданного блока при включённом соответствующем индексе. Доступность команды не доказывает наличия публичного сервиса P2P для других узлов или доступа ко всей истории. Фильтры уже созданных блоков также не сообщают о неподтверждённых транзакциях в Mempool. Для отображения ожидающего платежа нужен другой механизм. От этих рабочих деталей зависит, будет ли лёгкий кошелёк действительно удобен. [1] [4]
Для полной картины прочитайте эту статью вместе с Compact Block Filters, Neutrino, Full Node, Приватность в Bitcoin, Compact Blocks, Bitcoin. На эту статью также ссылаются Neutrino, Erlay.