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.