Биткоин-Хранители: OP_CHECKTEMPLATEVERIFY

О чём пойдёт речь: как OP_CHECKTEMPLATEVERIFY позволяет выполнять кастодиальные функции ончейн и какими интересными свойствами он обладает,

Дополнительные материалы:

• https://utxos.org/
• https://diyhpl.us/wiki/transcripts/ctv-bip-review-workshop/
• https://anchor.fm/tales-from-the-crypt/episodes/Tales-from-the-Crypt-130-Jeremy-Rubin-ead48q

“Bitcoin Covenants”

• https://fc16.ifca.ai/bitcoin/papers/MES16.pdf

Исследование эффективности опкода

https://github.com/JeremyRubin/CTVSims/blob/master/batch-splitting/README.md

OP_CHECKTEMPLATEVERIFY – это новый опкод, которые предполагается ввести в протокол Биткоина хард\софтфорком с заменой OP_NOP4(группа опкодов OP_NOP1, OP_NOP4-OP_NOP10 является “спящей” и игнорируется. Они не могут инвалидировать транзакцию). Разработчик Джереми Рубин полагал возможной реализацию функциональности OP_CHECKTEMPLATEVERIFY в рамках Тапрут (BIP-BIP-BIP 340-342: Шнорр, Тапрут и Тапскрипт) , но в конечном итоге выбрал независимый путь развития, поскольку Тапрут является технологией развития Bitcoin Script и более обобщённо решает адресованные проблемы, требует более тщательной проверки и результат этой проверки непредсказуем.

Мотивом разработки OP_CHECKTEMPLATEVERIFY (OP_CTV) послужила осознаваемая Рубином необходимость программирования Биткоина на уровне транзакций. В случае траты нормального выхода вы можете как угодно распорядиться монетами, OP_CTV позволяет “комитить” транзакции, т.е. закреплять определённый порядок траты, что подразумевается словом TEMPLATE (ШАБЛОН) в названии опкода.

Технические мотивации OP_CTV:

• выходы программируемы, транзакции в основном - нет
• пред-подписанные транзакции сложно анализировать статически: если нет приватного ключа, то невозможно доказать, валидны ли они
• протокол требует интерактивного взаимодействия (все онлайн)
• невозможно организовать последовытельные события с CSV

Как работает программирование на уровне транзакций? Рассмотрим схемы со входами и выходами транзакции Биткоина. Первый пример асинхронная группировка. Обычная группировка транзакций позволяет экономить до 80% места в блокчейне за счёт пропорционального увеличения единичных транзакций адресат - получатель в одной. Такова модель Биткоина и он допускает такую оптимизацию с первых дней своей работы. Минусом ситуативного создания групповой транзакции может быть то, что, если её осуществляет сервис, ему придётся точно спрогнозировать комиссию, иначе либо он переплатит, либо в мемпуле застрянет большое количество транзакций клиентов. Клиенты не любят получать свои деньги с задержкой.

Группировка выходов, которую позволяет OP_CTV, разбивает транзакцию на два этапа. Первый этап заключаеся в создании выхода с особым опкодом OP_CTV из нормально выхода Достоинство разбиения на два этапа проявляется именно здесь, поскольку трата на создание такой транзакции минимальна и она может быть включена в блокчейн заранее с фиксированной платой. Возникает вопрос, не является ли вторая транзакция принципиальным эквивалентом первой? Конечно, является, но с реализацией OP_CTV появляется дополнительная гибкость в распоряжении сформированным выходом по времени, и гибкость в смысле размера транзакции: в одну транзакцию невозможно включть 10 мегабайт выходов.

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

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

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

На первый взгляд выгода такой организации транзакций от источника к получателю может быть не очевидной. Аргументы в пользу того, что OP_CTV является решением для масштабирования Биткоина включают:

• Улучшенная пропускная способность подтверждений транзакций (меньше на пиках, больше, когда блоки пустые)
• Меньшие комиссии
• Меньшие комиссии для попадания в вершину мемпула
• Сервисы получают более гибкую возможность контроля собственной нагрузки на блокчейн

Предлагаемая технология в целом обеспечивает более оптимальный “отложенный расчёт” (deferred settlement), что в целом, как отмечает иногда Ник Картер, является методом масштабирования любой финансовой системы. Например, суть работы Lightning Network также заключается в формировании цепочки отложенных расчётов при платежах через каналы.

Технология Сбережений и OP_CHECKTEMPLATEVERIFY

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

Bitcoin Covenants – идея Malte Möser, Ittay Eyal, и Emin Gün Sirer, опубликованная в 2016 году, опиралась на расширение Биткоин Скрипта специально для целей организации примитива скриптового языка, который позволял бы выстраивать определённую логику трат в будущем и ограничивал их по каким-либо параметрам.

OP_COV позволял бы пользователю указывать паттерн и номер выхода. Паттерн вычислялся бы против этого выхода и проверялся бы на соответствие результатам реального выполнения скрипта.

Рубин показывает, что OP_CHECKTEMPLATEVERIFY имеет схожие свойства, если указать два паттерна на выходах 0 и 1 для определения правила расширения платёжного дерева.

Однако, идея OP_COV имеет следующие недостатки по его мнению:

• Данная схема не имеет механизма ограничения количества входов к одному, что означает, что можно потратить половину средств, без возможности вернуть оставшуюся половину на выходе.
• Пользователь должен указать 2 паттерна, против 1 хэша OP_CHECKTEMPLATEVERIFY
• OP_COV не спроектирован так, чтобы обеспечить неизменность идентификатора транзакции (т.е. локтаймы, блокировки по времени могут быть изменены), что делает OP_COV неприменимым для HTLC контрактов или платежей CPFP (“потомок платит за родителя”). Сделаем замечание, что это связано с предложением OP_COV до SegWit форка, в котором transaction malleability была “исправлена”.
• OP_COV паттерны не ограничены в вычислениях. Нельзя заранее предсказать все возможные траты с OP_COV. В то время как в OP_CHECKTEMPLATEVERIFY ограничения обеспечивают то, что отправитель средств знает все возможные пути выполнения Биткоин-Скрипта.

Рассмотрим подробнее, как могло бы быть устроено хранилище на основе OP_CHECKTEMPLATEVERIFY. Смотрим на схему сверху-вниз, начиная от произвольной “нормальной” транзакции. Распоряжаясь определённым “нормальным” выходом мы можем перевести биткоины на выход, управляемый OP_CHECKTEMPLATEVERIFY (CTV).

CTV выход далее регламентирует порядок траты по фиксированным адресам “холодного” и “горячего” хранилища. Правило, “монеты в холодное хранилище могут отправиться сразу, монеты в горячее хранилище ждут 6 блоков, монеты, которые идут на новый CTV выход ждут 100 блоков”, позволяет в определённых местах иметь задержку для “перехвата” траты с не безопасного выхода, на безопасный. На каждом новом “уровне” CTV (оранжевые блоки) мы имеем альтернативные сценарии:

• вывода. Внутри вывода новый CTV паттерн
• вывода на “горячий” адрес
• перевод обратно в хранилище
• перечисления средств на новый CTV
• перевод обратно в хранилище

Этап “перевод обратно в хранилище” резервный для любой альтернативной траты и его польза состоит в следующем. Если мы каким-либо образом скрыто развернули фулл-ноду с относительно небольшой программой, предназначенной для контроля выходов специфического кошелька, мы можем независимо от основной инфрастурктуры (облака, сервера, просто офиса с менеджерами, кошельками и минимальным ПО на персональных компьютерах) использовать блокчейн как источник информации о внешнем мире. Варианты взаимодействия оборудования с внешним миром сокращаются до протокола контроля работы этого оборудования (смс, радио сигналы, обычный “пинг” и так далее), и сводятся к практической устойчивости клиента протокола и программного обеспечения. В общем случае, “резервные” транзакции могут заготавливаться заранее и отправляться независимому сервису “хранителей” и он не будет обладать никакими приватными ключами, имея возможное условие вещания транзакции только после проверки наличия резервной транзакцией. Такие сервисы могут находиться в разных странах ведь единственное что им нужно для работы – это доступ в Интернет.

Описываемая технология иллюстрирует последний рубеж безопасности хранилищ – уровень блокчейн-протокола, чья работа обеспечивается исключительно Биткоин-скриптом или “смарт-контрактом”, без вмешательства людей в процессе работы (только в настройке, но и для этого могут быть разработаны методы автоматизации). Мы надеемся, что нам удалось достаточно ясно изложить техническую сторону сути “технологии сбережений”, которая представлена в протоколе Биткоин. Она также включает относительно простые инструменты, например мультиподпись, которой может быть достаточно в большинстве случаев. В будущем вероятно появятся инструменты, которые будут скрывать всю описанную механику за очень простыми “прогресс-строками” или “окнами статусов”, но позволят гарантировать практически безопасное обращение с криптовалютой. И это будет одним из главных ценностных предложений Биткоина, если CTV войдёт в протокол, даже в виде софтфорка.

Данная статья публикуется в открытом доступе, поддержите публикаторов, используя страничку.  
https://lntxbot.bigsun.xyz/@c3p0rs

Либо просто перечислите сатоши пользователю @c3p0rs через @lntxbot.

Если вы ещё не знаете как использовать сатоши в Лайтнинг сети, прочитайте руководство для кошелька BLW или исследуйте Телеграм-бот @lntxbot.