Хотя объем предложений довольно широк, почему «Большое восстановление сценария» Расти Рассела считается перспективным путем развития биткойна?

Заметка о блокчейн-единороге: Расти Рассел - активный разработчик в биткойн-сообществе и пользуется высоким уважением в нем. Он внес значительный вклад в развитие ядра Linux и участвовал в различных проектах развития Bitcoin Core.

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

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

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

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

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

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

Восстановление отличного скрипта

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

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

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

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

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

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

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

Опкоды (операционные коды)

• OP_CAT: Получите два данных из стека и добавьте их, чтобы сформировать один набор данных.
• OP_SUBSTR: Принимает параметр длины (в байтах), получает часть данных из стека, удаляет байты этой длины и возвращает их обратно в стек.
• OP_LEFT и OP_RIGHT: Принимает параметр длины, берет кусок данных со стека и удаляет байты указанной длины с одной стороны или с другой.
• 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), средства от всех других сторон отправляются на агрегированный открытый ключ, который позволяет кооперативное потребление без необходимости подписи стороны, покидающей общий UTXO.

Зачем мы это делаем?

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

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

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

С высокой точки зрения, это функциональность, которая нам нужна:

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

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

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

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

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

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

Движущая сила вперед

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

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

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

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

Утверждение:

1. Эта статья, первоначально названная «伟大的脚本恢复：比特币的前进之路», воспроизведена с сайта [Gate.io]Блок единорог]. Все авторские права принадлежат оригинальному автору [SHINOBI]. Если у вас есть какие-либо возражения против перепечатки, пожалуйста, свяжитесь с Gate Learnкоманда, команда обработает это как можно скорее.

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

3. Переводы статьи на другие языки выполняются командой Gate Learn. Если не указано иное, копирование, распространение или плагиатирование переведенных статей запрещено.