Скрипты без скриптов: поддержка смарт-контрактов без смарт-контрактов в Биткойне
❤ 370 , Категория: Биткоин, ⚑ 20 Дек 2017г
Известно, что пропускная способность блокчейна Биткойна ограничена. При этом смарт-контракты могут быть ресурсоёмкими. Поэтому, хотя Биткойн-блокчейн всегда поддерживал основные функции смарт-контрактов, две эти технологии никогда не подходили друг другу.
Однако, недавнее исследование, проведённое по инициативе Эндрю Поэлстра (Andrew Poelstra) – математика компании Blockstream — может помочь исправить это. Недавно представленное в качестве ключевой части его презентации на конференции Scaling Bitcoin Stanford предложение под названием «скрипты без скриптов» (Scriptless Scripts) имеет потенциал для полного переноса некоторых смарт-контрактов с Биткойн-блокчейна, оставляя при этом в распоряжении пользователей все средства безопасности сети Биткойн.
Биткойн и смарт-контракты
Смарт-контракты, впервые предложенные ветераном цифровой валюты Ником Сабо (Nick Szabo) в 1990-х годах, по сути являются самоисполнимыми договорами. В наиболее типичной варианте применения они посылают деньги от одного участника сделки к другому при выполнении определенных условий. Например, если кто-то прослушивает песню, автоматически происходит оплата от получателя контента к исполнителю (правообладателю).
В то время как смарт-контракты часто ассоциируются со «вторым поколением» блокчейнов, таких как Эфириум, Биткойн тоже всегда поддерживал основные функции смарт-контрактов. Некоторым образом, любая Биткойн-транзакция технически является смарт-контрактом: средства обычно перемещаются при условии предоставления действительной криптографической подписи. Немного более продвинутые смарт-контракты, такие как мультиподпись (multisig) и временные блокировки (timelocks), используются для работы протоколов второго уровня, таких как Lightning Network.
Однако, смарт-контракты на основе блокчейна имеют определённые проблемы. Во-первых, по мере того как они становятся более сложными, для их выполнения требуется больше ресурсов. Это особенно проблематично, потому что все узлы сети должны исполнять контракт, а не только стороны контракта (участники сделки).
Такое исполнение контракта по всей сети также означает, что об условиях контракте будет известно не только сторонам контракта: вся сеть будет точно знать суть контракта. В дополнение, это также негативно отразится на взаимозаменяемости. Если смарт-контракт по какой-то причине окажется непопулярен, репутация связанных с ним средств — публично видимых на блокчейне – может быть подпорчена.
По мере того, как смарт-контракты будут становиться более сложными, они станут представлять риск для безопасности. Альтернативные реализации кода могут, например, интерпретировать детали контрактов немного по-другому, затрудняя таким образом поддержание консенсуса между всеми узлами сети. Кроме того, потенциальные ошибки в этих смарт-контрактах также будут видны в публично доступной сети, что увеличивает вероятность хакерских атак.
Но Поелстра, среди прочего, считает, что многие из этих проблем можно решить, переместив большую часть контрактов с блокчейна [на периферию]. Вместо того, чтобы задействовать все узлы в сети для обработки всего смарт-контракта, выполнение этой функции должно быть отдано только сторонам, участвующим в контракте.
Смысл в том, чтобы обеспечить корректное выполнение самой сетью результатов контракта: оплата должна быть произведена только при соблюдении требуемых условий.
Шнорр
Первоначально, Поэлстра начал исследование «скриптов без скриптов» (название, которое он также придумал сам) в контексте протокола Mimblewimble. Это урезанная версия Биткойна предлагает более высокую конфиденциальность и лучшую масштабируемость, но не поддерживает скрипт (элементы кода, встроенного в Биткойн-транзакции, которые поддерживают самые основные функции смарт-контрактов).
Таким образом, Поэлстра выяснил, как получить полезную функциональность, обеспечиваемую скриптами, без необходимости их присутствия на блокчейне, то есть, «скрипты без скриптов».
Главное в «скриптах без скриптов» состоит в том, что (довольно) регулярные криптографические подписи могут косвенно указывать на то, что не является частью транзакции, включающей саму эту подпись. Другими словами, когда кто-либо прикладывает подпись для проверки обычной Биткойн-транзакции, считается, что смарт-контракт, даже находящийся вне блокчейна, добросовестно исполнен.
Это становится возможным благодаря подписям Шнорра (Schnorr signatures). Эти типы подписей пока не реализованы в протоколе Биткойна, однако, возможно, что они начнут применяться уже в течение года или чуть позже.
Подписи Шнорра позволяют объединять подписи, то есть, несколько подписей можно математически объединить в единую подпись. И, что важно для этого варианта применения, эта математическая операция является «линейной». В основном, это означает, что с этими подписями можно выполнять относительно простые, но очень выразительные математические операции.
В очень упрощенном виде это работает следующим образом:
Частные ключи и подписи — это, конечно же, просто числа, причём последнее получается из первого. Поскольку это упрощенный пример, допустим, один частный ключ выглядит как 10, и половина подписи Шнорра, полученной из этого частного ключа, выглядит как 10000. А другой частный ключ выглядит как 15, и вторая половина подписи Шнорра — 15000. В этом упрощенном примере подпись Шнорра в итоге будет выглядеть как 25000 (или 10000 + 15000).
И так как обе половины подписи — это просто числа, с ними можно выполнить математические операции. Так, в этом упрощённом примере, разница между этими половинами равна 5000 (или 15000 – 10000).
Хотя реальность более сложна, линейность Шнорра позволяет выполнять несколько видов математических «приёмов».
Смарт-контракт
Теперь допустим, что пользователь хочет послушать онлайн песню некоторого исполнителя. Право на эту песню принадлежит исполнителю, и песня будет доступна для пользователя, желающего её прослушать онлайн, если (и только в том случае, если) сервер, где хранится песня, получит подпись исполнителя. Так как мы упрощаем, допустим, «подпись песни» выглядит как 7000. Чтобы прослушать песню, пользователь готов заплатить исполнителю за эту подпись песни один биткойн. (Допустим, он так сильно хочет послушать эту песню.)
В этом упрощенном примере пользователь и исполнитель могут автоматизировать покупку с помощью двух процедур. Во-первых, они создают довольно нормальную Биткойн-транзакцию, которая отправляет один биткойн от пользователя к исполнителю, если и пользователь и исполнитель предоставят каждый свою половину подписи Шнорра для создания полной подписи Шнорра. (В действительности, этот шаг требует дополнительных мер предосторожности, чтобы никто не потерял деньги, но это решается относительно просто.)
На следующем этапе всё немного усложняется.
Исполнителю известно, как выглядит его половина подписи Шнорра; поскольку мы упрощаем, предположим, это будет 8000. И ему таже известно как выглядит его подпись песни — 7000. Тогда, исполнитель может вычислить разницу между двумя значениями, которая составит 1000. Эта величина называется «адаптивной подписью» (adaptor signature). Затем исполнитель передает эту «адаптивную подпись» (1000) пользователю – получателю контента.
Вот здесь-то и происходит криптографическая магия.
Изменяя обычный метод проверки подписи, получатель контента может на самом деле проверить, что «адаптивную подпись», которую он только что получил (1000) действительно равна разнице между половиной подписи Шнорра исполнителя и его подписью песни — хотя получатель контента пока ещё не имеет доступа ни к одной из этих подписей. (И благодаря криптографическим приёмам, называемым «доказательствами с нулевым разглашением» (zero-knowledge proofs), нечто подобное этому может быть сделано в удивительно широком диапазоне сценариев, а не только в подписях, как показано в этом примере.)
Теперь, убедившись в получении «адаптивной подписи» (1000), получатель контента, в свою очередь, может отдать исполнителю свою половину подписи Шнорра, потому что как только исполнитель использует половину подписи пользователя для создания полной подписи и передаст её в сеть Биткойн, исполнитель автоматически раскроет свою половину подписи Шнорра (8000) получателю контента.
Используя половину подписи Шнорра исполнителя, получатель контента теперь может вычесть «адаптивную подпись» (adaptive signature) (1000). Вычитая «адаптивную подпись» из половины подписи Шнорра исполнителя (8000 – 1000), получатель контента действительно узнаёт «подпись песни» исполнителя (7000). И теперь он может прослушать песню.
Другими словами, транслируя транзакцию, приносящую исполнителю один биткойн, он автоматически продает получателю контента подпись, это и есть смарт-контракт.
С точки зрения блокчейна, то есть, остального мира, сделка является достаточно типовой. Информация о смарт-контракте, не считая собственно «расчётной транзакции», никогда не записывается в блокчейн. Никто никогда не будет знать, что базовый контракт был исполнен — не важно, какую песню слушал пользователь — и относящиеся к контракту данные никогда не потребуется вычислять или хранить кем бы то ни было, кроме заинтересованных сторон, непосредственно участвовавших в сделке.
Источник
Related
Categories: Криптография, Теория, Технологии
