АВТОР ОРИГИНАЛА: SHINOBI

Оригинальная подборка: Блок единорога

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

OPCODES (Код операции)

• OP_CAT: Берет два фрагмента данных из стека и складывает их вместе, чтобы сформировать одни данные.
• OP_SUBSTR: Принять параметр длины (в байтах), получить фрагмент данных из стека, удалить байты этой длины и поместить его обратно в стек.
• OP_LEFT и OP_RIGHT: Принимает параметр длины, который берет фрагмент данных из стека и удаляет байты указанной длины с той или иной стороны.
• OP_INVERT, OP_AND, OP_OR, OP_XOR, OP_UPSHIFT и OP_DOWNSHIFT: принимает элемент данных и выполняет над ним соответствующие битовые операции.
• OP_ 2 MUL, OP_2D IV, OP_MUL, OP_DIV и OP_MOD: математические операторы для операций умножения, деления и деления по модулю (возвращающие остаток от деления).

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

OP_CTV (или TXHASH/ эквивалентный Код операции): позволяет точно применять определенные части транзакции, которые должны быть точно определены.

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

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

Почему мы это делаем

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

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

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

В более высокой перспективе вот что нам нужно:

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

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

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

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

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

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

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

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

Импульс для движения вперед

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

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

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

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