Бесскриптовые скрипты: как биткоин может поддерживать смарт-контракты без их наличия

Вместимость биткоина довольно ограничена. Между тем, смарт-контракты могут быть ресурсоемкими. Поэтому, биткоин всегда поддерживал базовые функциональные возможности смарт-контракта, они никогда не были естественными.

Но недавняя тема исследований, возглавляемая математиком Blockstream Эндрю Поелстрой (Andrew Poelstra), может помочь исправить это.
Недавно, представленный в качестве ключевой части его презентации в Scaling Bitcoin Stanford, “Scriptless Scripts” может полностью переместить некоторые смарт-контракты с блокчейна биткоина, при этом все еще используя всю безопасность биткоин-архитектуры.

Биткоин и смарт-контракты

Смарт-контракты, впервые предложенные ветераном цифровой валюты Ником Сабо (Nick Szabo) в 1990-х годах, по своей сути являются самостоятельными контрактами. Как правило, они отправляют деньги от кого-то другому, если выполняются особые условия.

Например, если кто-то стримит песню, платеж автоматически переносится с стримера на исполнителя.

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

Чуть более совершенные смарт-контракты, такие как “multisig” и “timelocks”, используются для включения протоколов второго уровня, таких как Lightning Network.
Однако также есть проблемы и с ориентированными на блокчейн смарт-контрактами. Во-первых, по мере того как они становятся более сложными, для их выполнения требуется больше ресурсов. Это особенно проблематично, поскольку все узлы в сети должны выполнять контракт, а не только стороны, участвующие в самом контракте.

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

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

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

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

Шнорр

Первоначально, Поелстра начал исследовать “бесскриптовые скрипты” (термин он также придумал) в контексте протокола Mimblewimble.

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

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

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

Другими словами, когда кто-то подписывается на проверку обычной биткоин-транзакции, он считает, что смарт-контракт, который не размещен на блокчейне, все еще выполняется корректным способом.

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

Подписи Шнорра допускают агрегацию подписи. Несколько подписей могут быть математически объединены в одну подпись. И, что важно для этого случая использования, эта математика является “линейной”. Это, в основном, означает, что на этих подписях можно выполнить относительно простое, но очень выразительное вычисление.

На примитивном уровне, все работает примерно так:

Частные ключи и подписи — это, конечно же, просто цифры, где последнее происходит от первого. Так как это упрощенный пример, скажем, один закрытый ключ выглядит как 10, а половина подписи Шнорра, полученная из этого закрытого ключа, выглядит как 10000.

А другой закрытый ключ выглядит как 15, в то время как вторая половина подписи Шнорра выглядит как 15000.

В этом упрощенном примере, подпись Шнорра будет выглядеть как 25000 (или 10000 + 15000).

И поскольку обе половины подписи являются просто цифрами, можно выполнить математический расчет между ними. Например, в этом упрощенном примере разница между этими половинами составляет 5000 (или 15000 — 10000).

В то время, как реальность более сложна, линейность Шнорра допускает некоторые из этих видов математических приемов.

Смарт-контракт

Теперь скажем, что стример хочет послушать песню исполнителя. Автор имеет право на эту песню, и он будет транслировать ее в стриме, если подпись исполнителя предоставляется серверу, на котором размещена песня.

Так как мы упрощаем, допустим, что эта “подпись песни” выглядит как 7000. Стример готов заплатить автору песни в биткоине за эту песню, чтобы послушать песню.
В этом упрощенном примере стример и исполнитель могут автоматизировать эту сделку, делая две вещи. Во-первых, они создают довольно обычную транзакцию биткоинов, которая отправляет один биткоин из стримера исполнителю, если стример и исполнитель предоставляют свою половину подписи Шнорра, чтобы создать полную подпись.
Исполнитель знает, как выглядит его половина подписи Шнорра.

Поскольку мы упрощаем, допустим, это выглядит как 8000. И он знает, как выглядит его подпись в песне: 7000. Таким образом, он может рассчитать разницу между этими двумя: 1000. Это называется сигнатурой адаптера. Затем исполнитель передает эту сигнатуру адаптера — 1000 — на стример.
Вот где и осуществляется криптографическое волшебство.

Модифицируя обычный метод проверки подписи, стример может фактически проверить, что сигнатура адаптера, которую он только что получил (1000), действительно является разницей между половинной подписью исполнителя Шнорра и ее сигнатурой песни, хотя стример еще не имеет доступа к любой из подписи.
Теперь, проверив, что сигнатура адаптера (1000) проверяется, стример может, в свою очередь, отдавать свою половину подписи Шнорра исполнителю, потому что, как только исполнитель использует половину стримера, чтобы создать полную подпись и протранслирует это по биткоин сети, она автоматически показывает свою половину подписи Шнорра (8000) стримеру.

Используя половину подписи Шнорра, стример теперь может вычесть адаптивную подпись: 1000. Вычитая адаптивную подпись из половины подписи исполнителя Шнорра (8000-1000), стример действительно узнает “подпись песни” исполнителя: 7000. И теперь он может слушать песню.

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

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

Оставьте ответ

Ваш электронный адрес не будет опубликован.

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.

This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. Accept Read More