Neutrino — легкий клієнт Bitcoin від Lightning Labs, написаний мовою Go й розрахований також на мобільні застосунки з Lightning Network. Він використовує BIP 157 і BIP 158 для роботи з компактними фільтрами блоків. Це конкретна програмна бібліотека, а не загальна назва легких гаманців чи заміна Full Node, який сам перевіряє всі правила.
Анна відкриває гаманець і очікує побачити отриманий платіж. Для правильного відображення стану застосунок має отримати й обробити дані мережі Bitcoin. Neutrino може виконувати цю частину роботи без постійного зберігання всього ланцюга блоків на телефоні. Блок — це група транзакцій, записана до спільної історії мережі Bitcoin. У програмі за це відповідає ChainService: служба керує з’єднаннями, локальною базою та синхронізацією заголовків. Заголовок — це стислий виклад основних відомостей про блок. Приватний ключ — це секретне число, за допомогою якого створюють цифровий підпис для дозволу на витрачання коштів. Саме використання Neutrino не визначає, хто зберігає приватні ключі Анни чи дозволяє надсилання. Керування ключами, екрани й резервні копії належать до завдань гаманця, що використовує бібліотеку. [1]
Компактний фільтр схожий на невеликий пошуковий покажчик для одного блоку. Гаманець завантажує його й на власному пристрої перевіряє збіг із тим, що шукає. Насправді він порівнює скрипти — умови, за яких можна витратити певні виходи Bitcoin. Вихід — це частина транзакції, яка визначає суму та умови її подальшого витрачання. Надсилати іншій стороні весь список своїх адрес не потрібно. Якщо є збіг, гаманець завантажує відповідний блок і шукає справжню транзакцію. Навіть правильно створений фільтр може дати хибнопозитивний результат: блок завантажиться дарма, бо потрібного елемента в ньому немає. Сам збіг не доводить отримання платежу, його суму чи здатність гаманця витратити гроші. [1] [2] [3]
Анна змінює телефон і відновлює гаманець. Пошуку лише від сьогоднішніх блоків недостатньо, якщо платежі надходили раніше. Застосунок має передати правильні відстежувані скрипти та достатньо ранній початок пошуку. Згідно з документацією, Rescan без указаного початкового блоку починає з останнього відомого блоку, а не автоматично з початку всієї історії. Справний фільтр не знайде адресу, якої гаманець не шукає, або давні платежі в пропущеному діапазоні. Тому завершене відновлення слід відрізняти від сканування, яке ще триває. Порожній список у процесі відновлення сам собою не доводить втрати коштів. [1]
Neutrino синхронізує заголовки блоків і заголовки фільтрів. Заголовки блоків дають змогу перевірити зв’язки та Proof of Work — доказ виконаної обчислювальної роботи — і відстежувати ланцюг із найбільшою сумарною роботою. Це набагато більше, ніж сліпо прийняти баланс від сервера, але менше, ніж самостійно перевірити кожну транзакцію й правило, як робить Full Node. До того ж це два різні ланцюги заголовків. Заголовки блоків Bitcoin не містять прямого криптографічного зобов’язання щодо правильності цих фільтрів. Самої перевірки хешів, криптографічних відбитків, недостатньо, щоб виключити підроблений, але внутрішньо узгоджений набір фільтрів. Економія роботи має конкретну межу довіри. [2] [4]
Пір — інший комп’ютер мережі, від якого клієнт отримує дані. BIP 157 спирається на порівняння відповідей і наявність хоча б одного чесного піра для виявлення неправильних фільтрів. Якщо всі з’єднання контролює один нападник, сама кількість комп’ютерів не допоможе. Вони можуть узгоджено дати неправдиву відповідь або приховати новіший стан. Таке відрізання від чесних джерел пов’язане з Eclipse Attack. Гаманцю потрібні доступні й достатньо незалежні джерела, а не просто з’єднання. Зелена позначка мережі не доводить, що він уже має повну й актуальну історію платежів. [2]
Ян щойно надіслав Анні гроші. Його транзакція може спочатку чекати в Mempool — локальному наборі непідтверджених транзакцій вузла — доки майнер включить її до блоку. Задокументовані сповіщення Neutrino recvtx і redeemingtx надходять при підтвердженні в блоці, а не вже при потраплянні до Mempool. Застосунку, який показує вхідні непідтверджені платежі, потрібен додатковий відповідний механізм. Сам фільтр блоку не може повідомити це до появи блоку. Надсилання, прийняття піром і підтвердження — різні події; відсутність сповіщення ще не означає, що Ян нічого не надіслав. [1]
Збіг фільтра корисний лише тоді, коли клієнт може отримати й потрібний блок. Якщо мережа зараз його не надає, правильний висновок — «даних поки бракує», а не «баланс нульовий». Стан може змінитися і при реорганізації: мережа приймає іншу гілку з більшою сумарною роботою та від’єднує раніше приєднані блоки. Rescan повідомляє про обидві події, щоб застосунок перерахував записи. Приватність теж не абсолютна: пір не отримує списку шуканих адрес, але бачить запити конкретних блоків і мережеві відомості про з’єднання. Спосіб отримання даних і далі має значення. [1] [2]
Lightning Network — це платіжна мережа, побудована на Bitcoin. У платіжному каналі двоє учасників оновлюють розподіл спільних коштів між собою замість того, щоб записувати кожен платіж до блоку Bitcoin. Neutrino постачає дані ланцюга; саме по собі воно не зберігає за користувача дані для відновлення актуального стану каналів. Відновлення історії гаманця та каналів — різні завдання. README описує зберігання запитаних фільтрів і отримання блоків без постійного запису; реальні вимоги залежать від версії та конфігурації застосунку. Перш ніж покладатися на такий гаманець, варто зрозуміти його власний порядок резервування, відновлення й поведінку при збоях джерел даних. Менша база на телефоні не скасовує цих обов’язків. [1] [4]
Для повної картини прочитайте також Compact Block Filters, Compact Block Filters, Full Node, Lightning Network, Eclipse Attack, Bitcoin. На цю статтю також посилаються Compact Block Filters, Compact Block Filters.