Синхронизация кошелька BIP32 с фильтрами Блума

Я работаю над своей библиотекой SPV, и мне все еще трудно понять, как подойти к комбинации фильтров BIP32 + Bloom. Вот как я сейчас синхронизирую существующий HD-кошелек (после быстрого наверстывания):

  1. Сгенерируйте количество отслеживаемых адресов просмотра вперед (скажем, 10).
  2. Загрузите фильтр Блума со всеми используемыми адресами плюс упреждающий просмотр (используется N + 10 упреждающий).
  3. Загрузите отфильтрованные блоки с расширением getdata.
  4. Отметьте отслеживаемые адреса как использованные, если они обнаружены в какой-либо блочной транзакции.
  5. Убедитесь, что последний просматриваемый адрес не использовался в транзакции.
  6. Если это так, создайте новые адреса просмотра вперед, перезагрузите фильтр Блума и снова загрузите последний блок, чтобы повторно сопоставить его. Используя новый адрес получения для каждой транзакции, мы могли пропустить другие транзакции в том же блоке.
  7. В противном случае вернитесь к 4 и загрузите новые блоки.

Теперь это звучит причудливо и слишком сложно для меня. В нескольких дискуссиях в Интернете говорится о «сканировании ключей» при синхронизации кошелька, и я действительно не понимаю, предполагают ли они полный узел или облегченный узел SPV, потому что я понятия не имею, как «сканировать ключи» без глобального База данных UTXO. Кроме того, ограничение зазора имеет смысл только для полного узла.

Я застрял, спасибо.

Ответы (1)

Причина, по которой вы предварительно генерируете некоторые прямые ключи, заключается в том, чтобы избежать ситуации, которую вы описываете, если вы смотрели только вперед, вы рискуете пропустить транзакцию в текущем блоке (порядок транзакций в блоке не связан с порядком ваших ключей) .

Термин «лимит пробела» относится к параметру клиентов SPV без фильтра цветения, которые выполняют поиск, запрашивая адресный индекс на удаленном узле. Ограничение промежутка — это конечная остановка текущего состояния кошелька, когда сканирующий кошелек видит 10 пустых адресов подряд, он решает, что это, вероятно, последний использованный адрес в кошельке, и прекращает дальнейшую генерацию. Если бы не было ограничения на промежутки, они бы искали неиспользуемые адреса до скончания времени (или 2 ** 128, что наступит раньше).