Есть ли способ индексирования транзакций, чтобы на команды фильтрации можно было ответить без повторения всех транзакций в блоке?

Некоторые клиенты SPV используют команду filterload, чтобы получать транзакции только с привлечением адресов в своем кошельке. Для этого требуется линейное время удаленного узла (относительно количества транзакций в блоке), которое кажется субоптимальным.

Можно ли каким-то образом индексировать транзакции, чтобы мы могли отвечать на эти запросы быстрее, чем линейная? Это кажется возможным, но я не уверен, как это сделать, особенно в присутствии nTweak.

5 голосов | спросил Nick ODell 27 PMpMon, 27 Apr 2015 22:08:03 +030008Monday 2015, 22:08:03

1 ответ


7

Существует известный, но довольно недокументированный метод радикального улучшения фильтрации SPV, который, случается, устраняет это как проблему полностью, но это связано с тем, что требуется жесткое изменение вилки в биткойне.

Традиционный BIP37 SPV

Для BIP37 клиент устанавливает фильтры цветения на своих одноранговых узлах и последовательно загружает транзакции и блоки, опираясь на удаленный одноранговый узел, чтобы просеять все данные для этого однорангового узла и создать сокращенные блоки, соответствующие их фильтру.

Это нежелательно по ряду причин:

  • В Bitcoin BIP37 цветные фильтры SPV-клиентов имеют абсолютно нулевую конфиденциальность , даже при использовании необоснованно высоких ложноположительных показателей.

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

  • Клиенты BIP37 SPV могут быть лишены путем упущения.

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

Обязательства фильтра цветка

  • Перед добычей фильтр цветения будет детерминированно сконструирован из всех элементов pubkey-hash (address) и pay-to-script-hash (P2SH) в блоке-кандидате.

  • Хэш этого фильтра цветения должен быть помещен рядом с вершиной шаблона блока Merkle, а его содержимое не записывается в блок в любой форме.

  • При проверке блока этот фильтр цветения будет детерминистически реконструирован и проверен в соответствии с хешем, расположенным в дереве Merkle. Если хеш фильтра не совпадает, блок недействителен.

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

Новый процесс для клиентов SPV:

  • Загрузите заголовки блоков, полный фильтр цветения для каждого блока в цепочке и короткий путь Merkle к хешу фиксации фильтра цветения. Проверьте правильность заголовка, проверьте путь Merkle к хешу, проверьте, что фильтр цветения соответствует хешу.

  • Локально сравнить фильтр цветения для потенциальных совпадений с данными пользователя кошелька (адреса, скрипты P2SH). Эксперт независимо выбирает, какие блоки им интересны и какие из них не имеют необходимости фактически загружать содержимое. Аналогично нормальной работе фильтров цветка в BIP37 могут возникать ложные срабатывания, но никогда не ложные негативы.

  • Если обнаружен блок, который может быть интересным, он может загрузить весь блок и обработать его, чтобы найти нужные транзакции.

Это аккуратно решает ряд проблем с традиционным подходом:

  • Случайные удаленные одноранговые узлы больше не получают копии фильтра цветения пользователей. Они могут экстраполировать эту информацию из блоков, загружаемых клиентом, но клиент может сделать много попыток замаскировать это, загрузив отдельные блоки из разных источников, сделав покрытие трафика известными неинтересными блоками или даже используя сетевое хранилище не Bitcoin, как только они знаете, какие блоки они, скорее всего, заинтересованы.

  • Удаленные одноранговые узлы больше не могут лежать, не допуская клиенту SPV. Если они изменят фильтр цветения, зафиксированный в блоке, он больше не будет соответствовать хешу в блоке, и клиент SPV будет знать, что они были обмануты.

  • Клиенты SPV могут выполнять быстрые rescans, не загружая никаких новых данных. Удерживая фильтры цветения после их проверки, они могут выполнять столько скинаций против него, не связываясь с сетью. Для узлов полного хранилища это означает значительно более быстрое сканирование без необходимости загрузки целых блоков.

  • Узлы в сети больше не имеют клиентов SPV с нагрузкой, не обслуживая дополнительные данные по запросу. Их выбор заключается в том, чтобы кэшировать фильтры при проверке блоков (это происходит практически без затрат, поскольку в любом случае они должны всегда создавать фильтр). Эти шкалы значительно лучше, чем BIP37, поскольку данные остаются одинаковыми для всех сверстников, а не для индивидуального вычисления.

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

Не очевидно, где это сладкое пятно, или даже если оно существует.

ответил Anonymous 28 AMpTue, 28 Apr 2015 03:43:29 +030043Tuesday 2015, 03:43:29

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132