Стандарты: Формат данных для доказательства Меркла

Автор предложения: Стив Шеддерс (nChain)
Спонсор КТС: Райан Чарльз (Money Button)
Авторы: (по умолчанию автор предложения) Стив Шеддерс
Рецензенты: БОП

Дополнительно: при необходимости КТС может назначать пользователей, исполнителей, технических экспертов и экспертов по стандартам на дополнительные роли в рамках рабочей группы.

Специалисты-рецензенты: право, ИС, соблюдение требований

1. Вводная информация

  1. Описание проблемы

    Доказательство Меркла представляет собой ветвь дерева Меркла, корень которого, как правило, является частью заголовка биткоин-блока. Реализация доказательства требует рекомбинации предоставленных элементов данных вместе с рассчитанными элементами данных в соответствии с определенным алгоритмом.

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

  2. Цели/обоснование

    Доказательство Меркла является фундаментом для модели Упрощенной Проверки Платежей (Simplified Payment Verification или SPV), описанной в оригинальной «Белой книге биткоина», которая лежит в основе масштабирования биткоина. Для того, чтобы SPV-кошельки могли их использовать, майнеры или другие пользователи сети, загружающие полные блоки, должны предоставить кошелькам доказательства Меркла. Поскольку, вероятно, по различным причинам существует большое разнообразие способов реализации передачи и получения доказательства Меркла, принятие стандартного формата упрощает реализацию во всей экосистеме.

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

  3. Цель

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

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

    Несмотря на то, что мы считаем SPV-конверт чрезвычайно важным для удовлетворения потребностей сектора, мы считаем, что он должен рассматриваться отдельно, что он и не входит в сферу охвата данного предложения по стандартам, поскольку такой стандарт может инкапсулировать элемент доказательства дерева Меркла независимо от его формата.

  4. Преимущества

    Программное заявление КТС включает следующую цель: «Улучшение практической применимости Bitcoin SV путем повышения функциональной совместимости через стандартизацию». Доказательства Меркла лежат в основе одноранговых взаимодействий в биткоине. По определению, такое взаимодействие требует сотрудничества между системами, которые, вероятно, отличаются друг от друга и являются уникальными. Таким образом, основное преимущество разработки стандартного формата данных для доказательства Меркла соответствует заявленным целям КТС и отвечает потребности в более простой реализации фундаментально примитивной операции SPV во всей экосистеме.

  5. Ожидаемый результат

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

    Стандарт должен описывать формат таким образом, чтобы его можно было реализовать как в бинарном, так и в удобном для восприятия человеком формате.

2. Краткое описание процесса для рабочей группы

Внешний: Приглашение к выражению заинтересованности в участии в работе обзорной коллегии

Внутренний: Черновик >> Рецензирование >> Итерация (если требуется)

Внутренний: Специализированное рецензирование (право, ИС, соблюдение требований) >> Итерация (при необходимости)

Внешний: Общественное рецензирование >> ответы на замечания >> итерация (при необходимости)

Внешний: Утверждение КТС

3. Отбор рецензентов

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

  1. Критерии

    Лица, желающие подать заявку на вступление в эту рабочую группу КТС, должны соответствовать следующим требованиям:

    • Способность продемонстрировать, по меньшей мере, одно из следующих преимуществ:
      1. Предметная компетенция в конкретной области, касающейся разрабатываемого стандарта:
        • степень бакалавра или эквивалентный опыт в соответствующей области исследований;
          • например, инженерное дело, информатика, математика и другие научные области.
      2. Принадлежность к ключевыми сторонам, заинтересованным в результатах применения данного стандарта, либо к текущим или будущим пользователям либо специалистам по внедрению данного стандарта;
      3. Значительный опыт в разработке стандартов, связанный с международно признанным учреждением по стандартизации.
    • Готовность подписать соглашение о конфиденциальности (NDA) на время жизненного цикла рабочей группы;
    • Обладание достаточным количеством свободного времени для того, чтобы взять на себя обязательства в отношении процесса рецензирования в течение ожидаемого срока деятельности рабочей группы (согласно руководящим рекомендациям, жизненный цикл рабочей группы будет составлять от 3 до 4 месяцев и, как правило, потребует нескольких рабочих дней для участия в рецензировании в рамках 2–3 итераций черновика стандарта).
  2. Заявка на участие

    Заявку на участие в этапе внутренней разработки данного стандарта можно подать по электронной почте, отправив сообщение на адрес: [email protected]. Заявки должны быть получены до 3 июля 2020 года.