MAST: Следующий шаг к улучшению гибкости, масштабируемости и конфиденциальности Биткойна

MAST: Следующий шаг к улучшению гибкости, масштабируемости и конфиденциальности Биткойна

13 октября 2016, 19:56 — Аарон ван Вирдум

Предлагаемый софтфорк SegWit, который должен состояться в ближайшее время, расширит потенциал Биткойна разными способами. Одной из потенциально перспективных инноваций, которую SegWit делает возможной, является MAST (Merkelized Abstract Syntax Trees — меркелизованные абстрактные синтаксические деревья). Хотя предназначен прежде всего для повышения гибкости смарт-контрактов, MAST в то же время повысит масштабируемость и конфиденциальность платформы.

Идея MAST родилась у Blockstream-разработчика Расселла О’Коннора (Russell O’Connor), Blockstream- и Core-разработчика д-ра Питера Велле (Pieter Wuille), и Core-разработчика Питера Тодда (Peter Todd). Она была недавно описана в предварительном предложении по улучшению Биткойна (BIP) Core-разработчиком д-ром Джонсоном Лау (Johnson Lau).

Несмотря на свой потенциал, MAST на удивление прост.

P2SH: Введение для начинающих

Одна часть MAST основана на P2SH, который используется в определенных транзакциях Биткойна в течение уже нескольких лет.

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

Это «запирание» осуществляется на практике с помощью сценария — пары строк кода. Для стандартных транзакций, сценарий добавляется в выход транзакции и определяет необходимые условия для траты данных биткойнов в следующей транзакции.

Большинство нестандартных Биткойн-транзакций, таких как multisig или CheckLockTimeVerify, используют немного более сложную схему, именуемую «P2SH» (Pay to Script Hash). С P2SH биткойны по-прежнему запираются в сценарии, но сам сценарий не добавляется в выход транзакции. Вместо этого, сценарий хэшируется, то есть шифруется и сжимается в короткую и случайную на вид последовательность чисел. Эта последовательность чисел не может быть использована для восстановления исходного сценария. Однако имея исходный сценарий, можно легко воссоздать последовательность чисел путем повторного хэширования. Хэш сценария — это и есть то, что включается в выход транзакции. Для того, чтобы потратить P2SH-выход в следующей транзакции, недостаточно просто выполнить условия, определенные в сценарии, так как узлы сети Биткойна знают только о хэше сценария: о самом сценарии им ничего не известно. Следовательно, узлы не могут удостовериться в том, что условия, определенные в сценарии выполнены. То есть, они не могут подтвердить транзакцию.

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

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

Деревья Меркла: Введение для начинающих

Вторая часть MAST — это криптографическая хитрость под названием дерево Меркла.

По сути, дерево Меркла является математической структурой, в которой различные наборы данных хэшируются в один компактный хэш: корень Меркла. Так же, как и любой другой хэш, корень Меркла не может быть использован для восстановления его составных данных в дереве Меркла.

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

В качестве упрощенного примера, предположим, что Алиса создала дерево Меркла с сочитанием наборов данных «123» и «456» и получив на выходе корень дерева Меркла «789». Алиса тогда сообщает Бобу, что пакет данных «123» находится где-то в дереве Меркла. Теперь Боб, имея только корень Меркла («789»), может удостовериться в том, что «123» действительно содержится в дереве Меркла, даже если он ничего не знает о находящемся в нем также «456». И сколько еще пакетов данных данное дерево Меркла содержит ему тоже неизвестно — может быть тысячи, но Бобу необязательно что-либо знать о них.

MAST = P2SH + Деревья Меркла

MAST в сущности объединяет потенциал P2SH с возможностями деревьев Меркла.

C MAST, вместо того, чтобы запереть какие-то биткойны только в одном сценарии, те же биткойны можно запереть в серии различных сценариев. Другими словами, одни и те же биткойны могут быть заперты в соответствии с набором разных и взаимоисключающих условий (требующих, например, криптографическую подпись только от Алисы, или подписи от Боба и Кэрол вместе, или подпись только от Кэрол по истечению определенного количество времени, и так далее).

Какое из этих условий будет выполняться первым в (подтвержденной) транзакции определяет, каким образом биткойны будут потрачены. (Если Алиса первой подпишет транзакцию, потратившую выход, тогда её транзакция будет действительна. Если Боб и Кэрол сумели опередить Алису, то будет принята их транзакция. Или же, если прошло заданное количество времени, и Кэрол подписала первой, тогда выиграет её транзакция).

Так же, как и с P2SH, все эти различные сценарии хэшируются. Но теперь они объединяются в дерево Меркла. И корень этого дерева добавляется в выход транзакции в качестве некоего замка высшей инстанции.

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

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

Узлы сети Биткойна могут проверить правильность включенного сценария с помощью вышеописанной хитрости с деревом Меркла. Они используют корень Меркла, включенный в выходе, чтобы определить, действительно ли данный сценарий присутствует в дереве Меркла. Если да, тогда узлы знают, что включенный сценарий является одним из допустимых вариантов расходования данных биткойнов и могут подтвердить новую транзакцию.

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

MAST улучшает Биткойн тремя основными способами: она расширяет гибкость смарт-контрактов, улучшает масштабируемость, и увеличивает приватность.

Тип гибких смарт-контрактов, предоставляемый MAST не является абсолютно новым: в P2SH уже существовали некоторые конструкции «или/или» (позволяющие требовать подпись только от Алисы, или от Боба и Кэрол, и т.д.). Но в настоящее время существует ограничение на размер различных опций, установленное протоколом для предотвращения DoS-атак.

Ввиду того, что MAST устраняет все подобные ограничения, он увеличивает гибкость смарт-контрактов. Сети все равно, существуют ли два возможных варианта траты средств, или 20, или 1000, так как в конечном итоге только один сценарий включается в транзакцию. Это делает возможными новые и сложные транзакции, такие как 1-из-1000-и multisig, являющие в настоящее время недопустимыми в силу их большого размера. Или длинные списки пользователей, имеющих право потратить определенные биткойны в разные моменты времени.

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

В качестве дополнительного бонуса, MAST улучшает конфиденциальность, опять-таки в силу того, что неиспользуемые сценарии остаются скрытыми навсегда. Арбитры депонированных транзакций, например, могут оставаться неизвестными, если не будут участвовать в сделке (из-за того, что обе стороны задействовали свой 2-из-2-х multisig-скрипт, оставив скрипт 2-из-3-х неиспользованным). Таким же образом, неиспользованные time-lock предохранители могут навсегда оставаться скрыты от публики.

Примечание автора: MAST находится в стадии разработки; детали реализации могут отличаться от описания в этой статье.

Источник: Bitcoin Magazine



Categories: Инфраструктура, Криптография, Разработчикам, Стандарты, Технологии

Tags: , , , , , , , , , , ,

27 replies

  1. Впечатляет. Судя по всему это только начало. А теперь представьте, что сообщество отказывается от этого улучшения, разумеется не принимая требуемого предварительно активировать SW, а просто продолжает увеличивать блок… Да ну нахрен.

    • Да, для смарт контрактов и Биткойна это было бы здорово.

    • Может кто-то на пальцах объяснить, почему для такой транзакции обязательно нужен SW?
      По моим прикидкам, ничего не мешает такого вида транзакции внедрить в обычный блок.

      • Так же тебе ничего не мешало, и не будет мешать, продолжать напрягать сеть “пластичными” транзакциями. А вот Сегвит изменит положение.

        • Причем тут “пластичность”. Вопрос был про MUST.
          Кстати, проблему пластичности можно решить без SW. Поэтому возникает аналогичный вопрос:
          почему пластичность надо обязательно решать через SW?

          • А где это решение? Кто его уже предложил? А может его уже и протестировали, типа как сегвит тестировали в четы этапа, с выкладыванием кода для возможности участия всем желающим. Можно, возможно решить и не через SW, но проблеме сто лет в обед, а решают ее реально только разрабы core. Дайте линк на код вашего решения, хотя-бы сырой.

      • А как, при текущем протоколе, ты внедришь MUST? Для этого нужен софтфорк. Имея сегвит форкать сеть не будет необходимости. SW вносит так называемую”версионность”, т.е определение типа транзакции. Кстати, сами транзакции сегвит будут первыми новыми типами транзакций. Последующая реализация новых фич не будет требовать софтфорков, как это сейчас, будет достаточно понимания к какой версии(типу) относится транзакция.

        • “А как, при текущем протоколе, ты внедришь MUST? Для этого нужен софтфорк.”
          То есть SW не обязателен. Вы ответили на мой вопрос.🙂

          Значит утверждение выше:
          “сообщество отказывается от этого улучшения (MUST),не принимая SW” – ложное.

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

          Когда только майнеры решают, можно корежить структуру блокчейна или нет, это никуда не годится.

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

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

            • “каждый софтфорк заходит в тупик” – какие-то обобщения. Вы такими утверждениями сами себя обманываете. Может ошибаюсь, но это первый софтфорк, который, возможно, не найдет поддержки большинства. По крайней мере, из значительный изменений.

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

              “как проводить потенциально толковые изменения в будущем”
              А как мы определим без дискуссий и голосования, какие изменения толковые, а какие бестолковые.
              Если можно будет проводить любые изменения, можно провести не только бестолковые, а даже вредные.

            • Кто это мы? Лично вы какой вклад внесли во все это?

          • Уважаемый Georg, выше Вы просили на пальца объяснения, вы получили объяснения. Объяснение вполне логично. Есть дорожная карта, в соответствии с которой идет движение разработки. Первый шаг – убираем malleability и внедряем версионность. Без решения проблемы malleability невозможно работать с версиями транзакции, да и в целом это проблема, и ее нужно решить. Вот решили. Следующая потенциальная проблема, которая уже начинает проявлять это возможность внедрения изменений в код, софт-форки. Эту проблему, не важно насколько она уже выражена, так же решает Сегвит. Следующий шаг реализация MUST, Schnorr подписи, новые OPcodes – это то, что будет внедряться в ближайший год. Следующий шаг – сайдчейны. Я без понятия насколько все сообщество, или хотя бы майнеры согласны со всеми предлагаемыми, потенциальными возможностями. Но чем сообщество больше, тем больше таких как Вы и я, т.е людей с диаметрально противоположными взглядами, и это уже начинаем проявляться, и возможно усугубляться.
            Теперь, вы говорите – “версионность, если она так уже хороша, можно ввести без SW? Думаю, да. Скорее всего, все дополнительные плюсы,что дает SW, можно реализовать без нее.” Я уже предлагал Вам, и предлагаю еще раз – пишите код, пишите решение, выкладывайте для сообщества, которое бы приходило к так желаемому консенсусу. Если я правильно прочитал между строк, то Вам нравится идея MUST, но вот ее реализации без SW пока нет, так же как и нет реализации подписей Schnorr, а эти технологии очень уместны в случае использования P2SH. Давайте будем доказывать свою правоту реальной реализацией.
            Ваши – “думаю, скорее всего” это все теория. Когда будет готовый, протестированный, перспективный код, тогда можно по факту вести диалог. А пока, это – если, да ка-бы, во рту выросли грибы.

            • Вы меня извините. Но зачем Вы столько времени потратили, описав дорожную карту SW?
              Ведь вопрос был “почему для MUST обязательно нужен SW”.
              Ну да, Вы пишете, что реализации MUST без SW нет. Но это же не означает, что его не может быть.
              Нет ответа – ну не тратьте время. Это же Ваше время. 🙂

              Я прочитал статью от строки
              “Несмотря на свой потенциал, MAST на удивление прост.”
              до конца 2 раза. Отличная технология. Отличные возможности. Только я не увидел, причем тут SW. Поэтому и возник вопрос.

            • Тогда и Вы меня извините, но вы же не понимаете зачем для MAST нужен SW в контексте видения разработчиков Core. Мы же говорим зачем они хотят внедрить прежде SW.
              Нет ответа на что? На вашу теорию о возможностях внедрения MAST? Есть уже реальная работа, мы можем на чем-то основываться? Если вам хочется просто теоретизировать, тогда умываю руки.

          • “версионность, если она так уже хороша, можно ввести без SW? Думаю, да.”
            Оппа, местный тролль придумал свою версию SW. И вообще, как почитаешь, так все “скорее всего” можно. Только где твое можно?

          • “Значит утверждение выше:
            “сообщество отказывается от этого улучшения (MUST),не принимая SW” – ложное.”
            Чудо логик, ты читай внимательно. Имеется реализация SW, под нее, в связке пишется реализация MUST. Если сообщество
            отказывается от предложенной реализации SW, то реализовать написанный под эту связку MUST, не удастся. Поэтому улучшение, в текущей реализации не пройдет. Если же ты предложишь свою версию, без SW, то она, возможно, и будет работать. Как ты будешь внедрять текущий код MUST без основы в виде сегвита, это вопрос. Но, если у тебя есть решение, то удиви.
            Закос под логика зачетный! – ложно, истинно, ЛОЛ!!!

            • Эксперд хотел казаться солиднее, ну обделался немножко, с кем не бывает. Все мы люди )))

            • Вас послушать, так теперь ничего нельзя внедрить без SW.🙂
              Ведь когда-то внедряли мультисиг транзакции, как-то обошлись без него. Даже удивительно, что смогли. /s

              Еще раз. В описании технологии MUST нет ни одного слова про SW.
              Я понимаю, что с SW его можно реализовать. Может уже и реализовали. Это неважно.
              Вопрос был, можно ли реализовать MUST без SW.
              Если ответ – да, то надо просто так и сказать.

              А почему этот вопрос так не нравится?🙂 Вроде обычный вопрос.

            • А вы в курсе как внедряли мультисиг, или хотя-бы более близкий P2SH? 55% мощностей и сосите конфетку дорогое сообщество, как Гевин решил, так и стало. Я бы послушал ваши – а как мы определим без дискуссии и голосования; только хардфорк подтверждает консенсус; когда только майнеры решают,…, это никуда не годится. Сейчас же 95% мощностей, конференции, тесты, опять конференции, обучающие лекции, презентации в сети, стенография выступлений разработчиков, огласка для широкой общественности. Почувствуй что называется разницу.

      • Учитывая с каким спорами и противостаянием проходит внедрение текущего софт-форка, необходимость в изминении просто огромна. Как развивать сеть, если невозможно что-то изменить? Вот как сейчас, Вы же сами писали о тупике. И сегвит подходит для решения как нельзя лучше.

        • Да это местный провокатор, учитывайте это

          • То что ты (и я) не согласен с мнением Georg о необходимости снятия лимитов на размер блока – не делает его провокатором.

        • Как развивать сеть, если невозможно что-то изменить?

          Невозможность изменения не только затрудняет развитие, но и препятствует попыткам ухудшения сети.

Trackbacks

  1. MAST: Следующий шаг к улучшению гибкости, масштабируемости и конфиденциальности Биткойна | Заработок онлайн доступный каждому
  2. MAST: Следующий шаг к улучшению гибкости, масштабируемости и конфиденциальности Биткойна | Народные Новости

Поделитесь своими мыслями

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s