Как смотрят на путь развития BTC через десять лет участники отрасли в 2010 году

Автор: BTC подкаст Block Digest совместно с Shinobi; Перевод: 五铢, Золотая Финансовая

Этот текст - это статья, написанная Shinobi десять лет назад, где обсуждается, каким был BTC в 2020 году.

Первая статья в этой серии может быть найдена по ссылке "Как профессионалы относились к экосистеме BTC через десять лет с 2010 года?"

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

###ШНОРР И ТАПРОТ

Это было незадолго до того, как у нас появилась комбинация Schnorr и Taproot. С точки зрения Шнорра, это схема подписи с пакетной проверкой, которая стоит дешевле и является следующим крупным скачком вперед в оптимизации построения скриптов мультиподписи BTC. Мультиподпись изначально заключается в том, чтобы отправить ее со всеми публичными ключами и скриптами мультиподписи, встроенными в выходные данные транзакции, и все это должно быть включено во входные данные, чтобы ее можно было использовать. P2SH оптимизирует аспект вывода, включая открытый ключ с мультиподписью и хэш скрипта постоянной длины, избавляя от любых отправок на адрес с мультиподписью и только увеличивая стоимость отправителя. SegWit, возможно, «оптимизирует» дальше, наблюдая скидки, чтобы сделать UTXO, которые стоят мультиподписью, дешевле. Шнорр доводит все эти инкрементальные оптимизации до крайности. Вы объединяете отдельные открытые ключи в один ключ, и каждый может совместно сделать для него подпись, а затем проверить ее. Это обеспечивает значительную экономию средств для всех технологий, использующих мультиподпись, включая уровень 2, такой как (Lightning) Lightning Network и федеративные сайдчейны, а также обеспечивает преимущества конфиденциальности, делая все эти UTXO с мультиподписью неотличимыми от UTXO с одной подписью.

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

###СИГАШ_ANYPREVOUTPUT

SIGHASH_ANYPREVOUTPUT (ранее SIGHASH_NOINPUT) может стать следующим новым языком. Это новый формат открытого ключа/обновление флага sighash. Флаг Sighash указывает, какая часть транзакции будет представлена подписью. Эта функция существует для того, чтобы вы могли выполнять операции, такие как подписание только ваших входных и выходных данных, но позволять другим добавлять свои входные и выходные данные в транзакцию, не делая ее недействительной. Однако в настоящее время подпись должна быть представлена из конкретной UTXO конкретной транзакции. Среди прочего, SIGHASH_ANYPREVOUT может представлять подпись в UTXO-скрипт, а не в фактический конкретный UTXO. Это позволяет построить новый способ (eltoo) для управления состоянием молнии, не требующий наказательного ключа или обработки старого состояния, позволяющий обманутой стороне конфисковать все средства. Вместо этого, если текущее состояние канала неудачно в конкурентной двойной оплате, его можно просто использовать снова, чтобы гарантировать, что каждый может получить свой текущий баланс канала на цепи, а не предыдущий просроченный баланс. Просто повторно используйте тот же скрипт в правильном месте и используйте SIGHASH_ANYPREVOUT.

Это устраняет многие риски, такие как потеря ваших текущих состояний каналов, что может привести к блокировке ваших средств на штрафной транзакции из-за непреднамеренной потери. Это также позволяет реализовать больше функций. Теперь у нас может быть более 2 участников в молнии, даже можно создавать «дочерние каналы» поверх этих каналов. Кроме того, SIGHASH_ANYPREVOUT и eltoo могут создавать Statechains, которые являются совместными конструкциями каналов, позволяющими новым участникам полностью входить и выходить вне цепи и предполагать, что альянс не сговорится с предыдущими участниками, обманывая кого-либо. Это открывает много потенциала для протокола, который я всегда называл «протоколом многопользовательских статических UTXO».

###ОП_CHECKTEMPLATEVERIFY

OP_CTV - это предложение Джереми Рубина, направленное на реализацию очень простого "контракта" на BTC. Контракт ограничивает использование одного BTC более сложными способами, чем простая подпись некоторых ключей. Предложенный Рубиным тип контракта - "шаблон". По сути, это позволяет скрипту UTXO требовать, чтобы тратящаяся транзакция создавала определенные точные выходные данные. Таким образом, после создания UTXO с использованием OP_CTV, это будет обязательно соблюдаться консенсусом, т.е. UTXO должен быть потрачен на определенный адрес с суммой, определенной в скрипте этого UTXO. Вы даже можете связать их вместе, чтобы один UTXO был вынужден создавать еще несколько, а затем эти UTXO были бы вынуждены создавать еще несколько, и так далее.

Это имеет широкое применение в любом месте. В среде с высокими издержками хостинговая сущность может создать отдельный UTXO, который по согласованным правилам гарантирует, что все средства ее клиентов в конечном итоге будут контролироваться клиентом, даже если в настоящее время они не могут немедленно получить доступ к этим средствам. Это имеет большой потенциал для совместного использования с многоканальными каналами (фабриками каналов), поскольку массовые «снятия» такого рода могут одновременно создаваться и использоваться как фабрики каналов. OP_CTV может использоваться для создания платежных каналов, функционирующих как минимум в одном направлении, без участия получателя или необходимости онлайн-доступа к ключу для получения платежей (помните, что можно объединять каналы). Он даже может использоваться для обработки большего количества HTLC за один раз через отдельный канал, связывая их вместе, используя те же приемы, что и в примере с первым примером хостинга. Даже возможно создание нового типа coinjoin.

###Интеграция всех элементов

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

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

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