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

«Природа Биткойна такова, что как только была выпущена версия 0.1, основной дизайн был высечен в камне на всю оставшуюся жизнь. Из-за этого я хотел спроектировать его так, чтобы поддержка все возможные типы транзакций, которые только можно было придумать. Проблема заключалась в том, что каждая вещь требовала специального кода поддержки и полей данных, независимо от того, использовалась она или нет, и охватывала только один особый случай за раз. Это был бы взрыв особых случаев. Решением стал сценарий, который обобщает проблему, чтобы стороны транзакции могли описать свою транзакцию как предикат, который вычисляет сеть узлов." - Сатоши, 17 июня 2010 г.

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

Перед тем, как исчезнуть, Сатоши вырвал 15 из этих кодов операций, полностью отключив их и добавив жесткое ограничение на то, насколько большим фрагментом данных можно манипулировать в стеке скриптового движка (520 байт). Это было сделано потому, что он откровенно облажался и оставил открытым большое количество способов, с помощью которых сложные сценарии могут быть использованы для атаки типа «отказ в обслуживании» на всю сеть, создавая огромные и дорогостоящие для проверки транзакции, которые могли бы привести к сбою узлов.

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

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

ВЕЛИКОЕ ВОССТАНОВЛЕНИЕ СКРИПТОВ

На Биткойн++ в Остине в начале мая разработчик Core Lightning Расти Рассел сделал довольно радикальное предложение во время первой презентации конференции. По сути, он выдвинул идею возврата к большинству опкодов, которые Сатоши отключены в 2010 году, прежде чем он исчез.

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

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

ANYPREVOUT (APO), предложение о том, чтобы позволить повторно использовать подписи в разных транзакциях, лонг скрипт и объем входных данных были одинаковыми, было разработано специально для оптимизации Lightning и его многосторонних версий. CHECKTEMPLATEVERIFY (CTV), предложение по принудительному использованию монет может быть потрачено только транзакцией, которая точно соответствует предопределенной транзакции, было разработано специально для расширения функциональности цепочек предварительно подписанных транзакций, сделав их полностью ненадежными. OP_VAULT был разработан специально для включения «периода тайм-аута» для схем холодного хранения, чтобы пользователь мог «отменить» вывод средств из холодного хранилища, отправив его в еще более холодную установку с мультиподписью, если его ключи были скомпрометированы.

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

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

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

КОДЫ

ОПЕРАЦИЙ
• OP_CAT: берет два фрагмента данных в стеке и складывает их вместе, чтобы сформировать один.
• OP_SUBSTR: принимает аргумент длины в байтах и извлекает фрагмент данных из стека, удаляя из него это количество байтов и помещая его обратно.
• OP_LEFT & OP_RIGHT: принимает аргумент length и удаляет это количество байтов с той или иной стороны фрагмента данных в стеке.
• OP_INVERT & OP_AND & OP_OR & OP_XOR & OP_UPSHIFT & OP_DOWNSHIFT: Берет элемент данных из стека и выполняет над ним соответствующую операцию бит.
• OP_2MUL & OP_2DIV & OP_MUL & OP_DIV & OP_MOD: математические операторы для операций умножения, деления и деления по модулю (возвращающие остаток от деления).

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

• OP_CTV (ИЛИ TXHASH/эквивалент): что-то, что позволяет обеспечить детализированное применение, требующее, чтобы определенные части транзакции были точно определены заранее.
• CSFS: Позволяет сверять подписи с произвольными данными, а не только со всей транзакцией. Это позволяет требовать, чтобы части сценария или данные, которые они используют, подписывались в ордерах для выполнения.
• OP_TWEAKVERIFY: проверяет операции на основе Шнорра, связанные с открытыми ключами, такие как добавление или вычитание отдельных открытых ключей из совокупных. Это может быть использовано для того, чтобы гарантировать, что в случае, если одна сторона покинет общий UTXO в одностороннем порядке, средства всех остальных будут отправлены на совокупный открытый ключ, который не требует, чтобы ушедшая сторона подписывала ордера на совместные расходы.

ПОЧЕМУ МЫ ХОТИМ СДЕЛАТЬ ЭТО

Слой 2 по своей сути является продолжением базового уровня Биткойн, он по своей природе ограничен функциональностью базового уровня. Для реализации Lightning потребовалось три отдельных софтфорка: CHECKLOCKTIMEVERIFY (CLTV), CHECKSEQUENCEVERIFY (CSV) и Segregated Witness.

Вы просто не можете создать более гибкий уровень 2 без более гибкого базового слоя. Единственный короткий путь для этого — доверенные третьи стороны, чистые и простые. Это то, что, я надеюсь, мы все стремимся устранить из каждого аспекта взаимодействия с биткойном в том масштабе, который мы можем.

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

При высоком представлении это тот вид функциональности, который нам нужен:

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

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

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

КАК СДЕЛАТЬ ЭТО БЕЗОПАСНЫМ: VAROPS

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

У нас уже есть такое решение, когда дело доходит до проверки подписи, самой дорогой части проверки скриптов биткойна. Это называется бюджетом сигопса. Каждое использование кода операции проверки подписи потребляет определенный «бюджет» разрешенных операций подписи на блок. Это накладывает жесткое ограничение на затраты, которые транзакции могут наложить на пользователей за проверку отдельного блока.

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

Сдвиг в том, как Taproot обрабатывает ограничения sigops относительно каждой транзакции, предлагает способ обобщить это, что и предлагает Расти с ограничением varops. Идея состоит в том, чтобы назначить стоимость для каждого из реактивированных кодов операций счет наихудшем случае, т.е. самые дорогие вычислительные затраты на проверку, которые может создать каждый код операции. При этом каждый из этих кодов операций будет иметь свой собственный лимит "sigops", чтобы ограничить количество ресурсов, которые он может потреблять при проверке. Он также будет основан на размере любой транзакции с их использованием, поэтому сохраняйте простоту рассуждений об этом, но при этом добавляйте неявный глобальный лимит на блок.

Это решило бы риски отказа в обслуживании, которые заставили Сатоши отключить все эти коды операций в первую очередь.

FORWARD MOMENTUM

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

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

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

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

Отказ от ответственности:

1. Эта статья перепечатана с [bitcoinmagazine], Все авторские права принадлежат оригинальному автору [SHINOBI]. Если у вас есть возражения против этой перепечатки, пожалуйста, свяжитесь с командой Gate Learn, и они оперативно рассмотрят их.
2. Отказ от ответственности: Взгляды и мнения, выраженные в этой статье, принадлежат исключительно автору и не являются какими-либо инвестиционными рекомендациями.
3. Переводом статьи на другие языки занимается команда Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.