Мы уже начинаем видеть появление потенциала второго уровня из базовых примитивов, которые были добавлены или оптимизированы в течение первого десятилетия. Lightning, хотя до сих пор подвержен некоторым довольно серьезным ограничениям, действительно начинает процветать. И это только ограниченная первая версия, которая в настоящее время указана и развернута. Теперь развернуты сайдчейны различного рода: Liquid, RSK, и даже токен-цепочки, привязанные к Биткойн, разработанные Commerceblock. Это только начало.
Шнорр и Taproot
Прямо на горизонте у нас есть комбинация Schnorr и Taproot. С точки зрения Шнорра, это гораздо более дешевая пакетная проверка схемы подписи, а также следующий большой скачок в оптимизации конструкции скриптов с мультиподписью в Биткойне. Мультиподпись начиналась с того, что все публичные ключи и скрипт для мультиподписи помещались в выходные данные транзакции для отправки на нее, и все это нужно было включить во входные данные, чтобы потратить их. P2SH оптимизировал аспект вывода, включив хеш постоянной длины открытых ключей и скриптов мультиподписи, сэкономив комиссию для всех, кто отправляет на адрес мультиподписи, и оставив повышенную стоимость только для отправителя. SegWit, возможно, «оптимизировал» еще больше, удешевив расходы на UTXO с мультиподписью со скидкой свидетеля. Шнорр доводит всю эту инкрементальную оптимизацию до крайности. Вы объединяете отдельные открытые ключи в один ключ, для которого каждый может совместно поставить одну подпись, и просто проверяете это. Это обеспечивает значительную экономию средств при использовании мультиподписи, включая вторые уровни, такие как Lightning и федеративный сайдчейны, а также создает преимущество конфиденциальности, делая все эти UTXO с мультиподписью неотличимыми от UTXO с одной подписью.
Теперь это не просто волшебным образом делает все полностью частными. Состояния молнии (transactions) все еще требуют отдельных ключевых путей для своих штрафных транзакций для реагирования на представление старых состояний. Это означает, что они должны быть в выходных сценариях, что создает отпечаток. Taproot решает эту проблему с помощью своей крипто-магии, позволяя вам фиксировать дерево Меркла различных условий расходов, которые требуют только использованного условия и доказательства Меркла для корневого дерева, чтобы потратить, на обычно выглядящий открытый ключ Schnorr. Теперь вы можете скрыть этот путь скрипта штрафа с taproot. Вы можете скрыть любой условный путь скрипта с Taproot, спрятанным под совершенно обычно выглядящим ключом Schnorr, который позволяет всем участникам согласиться на что-то и совершить вполне обычно выглядящую транзакцию.
СИГАШ_ANYPREVOUTPUT
SIGHASH_ANYPREVOUTPUT (previously SIGHASH_NOINPUT) надеюсь, что это следующий новый примитив, который выйдет на конвейере. Это новый формат открытого ключа/обновление флага sighash. Флаги Sighash указывают, в каких частях транзакции фиксируется подпись. Эта функциональность предназначена для того, чтобы вы могли подписывать только свои входные и выходные данные, но позволять другим людям добавлять свои собственные входы и выходы в транзакцию, не делая ее недействительной. Но в настоящее время подпись должна фиксироваться в точном UTXO из точной транзакции. SIGHASH_ANYPREVOUT, помимо всего прочего, позволит зафиксировать подпись только в UTXO-скрипте, а не в конкретном UTXO. Это позволяет создать новый способ (eltoo) построения состояний канала Lightning, который не требует штрафного ключа, или иметь дело со старыми состояниями, позволяя обманутой стороне конфисковать все деньги. Вместо этого текущее состояние канала может просто повторно потратить старое состояние канала, если оно проиграло гонку двойных расходов, гарантируя, что каждый получит свой текущий баланс канала в цепочке, а не предыдущий устаревший баланс. Вы достигаете этого, просто повторно используя тот же скрипт в нужном месте и используя SIGHASH_ANYPREVOUT.
Это снимает множество рисков, связанных с потерей текущего состояния канала, что приведет к штрафной транзакции, которая заберет ваши средства за честную ошибку. Это также позволяет ГОРАЗДО больше. Теперь мы можем иметь каналы Lightning с более чем 2 участниками, и даже можем накладывать на них «подканалы». Кроме того, SIGHASH_ANYPREVOUT и eltoo позволяют создавать Statechains, тип конструкции федеративного канала, которая позволяет новым участникам входить и выходить полностью вне цепочки с предположением о том, что федерация не будет вступать в сговор с прошлыми участниками, чтобы обмануть кого-либо. Это открывает большой потенциал для того, что я называю для себя «многопользовательскими статическими протоколами UTXO».
ОП_CHECKTEMPLATEVERIFY
OP_CTV - это предложение Джереми Рубина о включении очень базового типа "завета" на Биткойн. Завет - это более сложные ограничения на расходование монеты, превышающие подписи от определенных ключей. Тип завета, который предлагает Рубин, является "шаблоном". По сути, это позволяет скрипту UTXO требовать создания определенных точных выходов, которые должны быть созданы транзакцией расходования. Таким образом, после создания UTXO с использованием OP_CTV, по согласию наступает обязательство потратить UTXO на конкретные адреса в определенных суммах, определенных в скрипте этого UTXO. Вы даже можете объединить их в цепочку, чтобы одно из этих UTXO было вынуждено создать еще несколько из них, которые затем будут вынуждены создавать еще несколько, и так далее.
Это имеет огромную общую применимость повсюду. В средах с высокой комиссией один UTXO может быть создан кастодиальным субъектом, который на 100% в соответствии с правилами консенсуса гарантирует, что все средства их клиентов окажутся под контролем их клиентов, даже если у них нет немедленного доступа к ним в данный момент. У этого есть много потенциального синергетического эффекта с многопартийными каналами (фабриками каналов), в том, что массовый «вывод» можно выполнить также одновременно создав и использовав как фабрику каналов. OP_CTV можно использовать для создания платежных каналов, которые по крайней мере работают в одном направлении без необходимости участия получателя или наличия ключа онлайн для получения платежей (и помните, что вы можете накладывать каналы друг на друга). Его даже можно использовать для того, чтобы один канал мог обрабатывать больше HTLC одновременно, объединяя их вместе с тем же трюком, который используется в первом примере с кастодиальными выводами. И даже может создать потенциал для новых типов coinjoins.
Сведение всего воедино
Предполагая, что все вышеуказанные предложения будут приняты и внедрены в Биткойн, я действительно думаю, что помимо разработчиков, работающих на передовой в этих вопросах, люди даже не имеют малейшего понятия, какие протоколы и сервисы будут созданы с использованием этих примитивов. Или странные вещи, когда нет четкой границы между сервисом или протоколом.
Они позволят создавать многосторонние каналы с теоретически неограниченным количеством участников, которые могут накапливать подканалы поверх с более малыми подгруппами участников базового канала. На основе этих «фабрик каналов» можно строить каналы, позволяющие людям получать деньги без наличия ключей в сети для горячего кошелька. Эти многосторонние каналы могут сами быть накоплены поверх федеративных каналов (statechains), которые позволяют участникам входить или выходить при нулевой активности на цепи! А конструкция «склеивания» каналов позволит ликвидности перемещаться относительно бесшовно между различными каналами способами, которые позволят реализовать все виды вещей, о которых люди даже еще не начали задумываться.
Моё последнее слово в этом разделе: это учитывает только то, что можно сделать с тем, что я считаю прямыми частями стека протокола Биткойн. Вы можете сделать гораздо больше, если начнёте рассматривать централизованные кастодиальные услуги и то, какой поднабор свойств Биткойн они могут предоставить, игнорируя регуляторные или юридические барьеры для этого.
Это всего лишь Часть 2 из 4, прочитайте следующую часть завтра
Содержание носит исключительно справочный характер и не является предложением или офертой. Консультации по инвестициям, налогообложению или юридическим вопросам не предоставляются. Более подробную информацию о рисках см. в разделе «Дисклеймер».
Следующее десятилетие, Часть 2: Путь вперед
Мы уже начинаем видеть появление потенциала второго уровня из базовых примитивов, которые были добавлены или оптимизированы в течение первого десятилетия. Lightning, хотя до сих пор подвержен некоторым довольно серьезным ограничениям, действительно начинает процветать. И это только ограниченная первая версия, которая в настоящее время указана и развернута. Теперь развернуты сайдчейны различного рода: Liquid, RSK, и даже токен-цепочки, привязанные к Биткойн, разработанные Commerceblock. Это только начало.
Шнорр и Taproot
Прямо на горизонте у нас есть комбинация Schnorr и Taproot. С точки зрения Шнорра, это гораздо более дешевая пакетная проверка схемы подписи, а также следующий большой скачок в оптимизации конструкции скриптов с мультиподписью в Биткойне. Мультиподпись начиналась с того, что все публичные ключи и скрипт для мультиподписи помещались в выходные данные транзакции для отправки на нее, и все это нужно было включить во входные данные, чтобы потратить их. P2SH оптимизировал аспект вывода, включив хеш постоянной длины открытых ключей и скриптов мультиподписи, сэкономив комиссию для всех, кто отправляет на адрес мультиподписи, и оставив повышенную стоимость только для отправителя. SegWit, возможно, «оптимизировал» еще больше, удешевив расходы на UTXO с мультиподписью со скидкой свидетеля. Шнорр доводит всю эту инкрементальную оптимизацию до крайности. Вы объединяете отдельные открытые ключи в один ключ, для которого каждый может совместно поставить одну подпись, и просто проверяете это. Это обеспечивает значительную экономию средств при использовании мультиподписи, включая вторые уровни, такие как Lightning и федеративный сайдчейны, а также создает преимущество конфиденциальности, делая все эти UTXO с мультиподписью неотличимыми от UTXO с одной подписью.
Теперь это не просто волшебным образом делает все полностью частными. Состояния молнии (transactions) все еще требуют отдельных ключевых путей для своих штрафных транзакций для реагирования на представление старых состояний. Это означает, что они должны быть в выходных сценариях, что создает отпечаток. Taproot решает эту проблему с помощью своей крипто-магии, позволяя вам фиксировать дерево Меркла различных условий расходов, которые требуют только использованного условия и доказательства Меркла для корневого дерева, чтобы потратить, на обычно выглядящий открытый ключ Schnorr. Теперь вы можете скрыть этот путь скрипта штрафа с taproot. Вы можете скрыть любой условный путь скрипта с Taproot, спрятанным под совершенно обычно выглядящим ключом Schnorr, который позволяет всем участникам согласиться на что-то и совершить вполне обычно выглядящую транзакцию.
СИГАШ_ANYPREVOUTPUT
SIGHASH_ANYPREVOUTPUT (previously SIGHASH_NOINPUT) надеюсь, что это следующий новый примитив, который выйдет на конвейере. Это новый формат открытого ключа/обновление флага sighash. Флаги Sighash указывают, в каких частях транзакции фиксируется подпись. Эта функциональность предназначена для того, чтобы вы могли подписывать только свои входные и выходные данные, но позволять другим людям добавлять свои собственные входы и выходы в транзакцию, не делая ее недействительной. Но в настоящее время подпись должна фиксироваться в точном UTXO из точной транзакции. SIGHASH_ANYPREVOUT, помимо всего прочего, позволит зафиксировать подпись только в UTXO-скрипте, а не в конкретном UTXO. Это позволяет создать новый способ (eltoo) построения состояний канала Lightning, который не требует штрафного ключа, или иметь дело со старыми состояниями, позволяя обманутой стороне конфисковать все деньги. Вместо этого текущее состояние канала может просто повторно потратить старое состояние канала, если оно проиграло гонку двойных расходов, гарантируя, что каждый получит свой текущий баланс канала в цепочке, а не предыдущий устаревший баланс. Вы достигаете этого, просто повторно используя тот же скрипт в нужном месте и используя SIGHASH_ANYPREVOUT.
Это снимает множество рисков, связанных с потерей текущего состояния канала, что приведет к штрафной транзакции, которая заберет ваши средства за честную ошибку. Это также позволяет ГОРАЗДО больше. Теперь мы можем иметь каналы Lightning с более чем 2 участниками, и даже можем накладывать на них «подканалы». Кроме того, SIGHASH_ANYPREVOUT и eltoo позволяют создавать Statechains, тип конструкции федеративного канала, которая позволяет новым участникам входить и выходить полностью вне цепочки с предположением о том, что федерация не будет вступать в сговор с прошлыми участниками, чтобы обмануть кого-либо. Это открывает большой потенциал для того, что я называю для себя «многопользовательскими статическими протоколами UTXO».
ОП_CHECKTEMPLATEVERIFY
OP_CTV - это предложение Джереми Рубина о включении очень базового типа "завета" на Биткойн. Завет - это более сложные ограничения на расходование монеты, превышающие подписи от определенных ключей. Тип завета, который предлагает Рубин, является "шаблоном". По сути, это позволяет скрипту UTXO требовать создания определенных точных выходов, которые должны быть созданы транзакцией расходования. Таким образом, после создания UTXO с использованием OP_CTV, по согласию наступает обязательство потратить UTXO на конкретные адреса в определенных суммах, определенных в скрипте этого UTXO. Вы даже можете объединить их в цепочку, чтобы одно из этих UTXO было вынуждено создать еще несколько из них, которые затем будут вынуждены создавать еще несколько, и так далее.
Это имеет огромную общую применимость повсюду. В средах с высокой комиссией один UTXO может быть создан кастодиальным субъектом, который на 100% в соответствии с правилами консенсуса гарантирует, что все средства их клиентов окажутся под контролем их клиентов, даже если у них нет немедленного доступа к ним в данный момент. У этого есть много потенциального синергетического эффекта с многопартийными каналами (фабриками каналов), в том, что массовый «вывод» можно выполнить также одновременно создав и использовав как фабрику каналов. OP_CTV можно использовать для создания платежных каналов, которые по крайней мере работают в одном направлении без необходимости участия получателя или наличия ключа онлайн для получения платежей (и помните, что вы можете накладывать каналы друг на друга). Его даже можно использовать для того, чтобы один канал мог обрабатывать больше HTLC одновременно, объединяя их вместе с тем же трюком, который используется в первом примере с кастодиальными выводами. И даже может создать потенциал для новых типов coinjoins.
Сведение всего воедино
Предполагая, что все вышеуказанные предложения будут приняты и внедрены в Биткойн, я действительно думаю, что помимо разработчиков, работающих на передовой в этих вопросах, люди даже не имеют малейшего понятия, какие протоколы и сервисы будут созданы с использованием этих примитивов. Или странные вещи, когда нет четкой границы между сервисом или протоколом.
Они позволят создавать многосторонние каналы с теоретически неограниченным количеством участников, которые могут накапливать подканалы поверх с более малыми подгруппами участников базового канала. На основе этих «фабрик каналов» можно строить каналы, позволяющие людям получать деньги без наличия ключей в сети для горячего кошелька. Эти многосторонние каналы могут сами быть накоплены поверх федеративных каналов (statechains), которые позволяют участникам входить или выходить при нулевой активности на цепи! А конструкция «склеивания» каналов позволит ликвидности перемещаться относительно бесшовно между различными каналами способами, которые позволят реализовать все виды вещей, о которых люди даже еще не начали задумываться.
Моё последнее слово в этом разделе: это учитывает только то, что можно сделать с тем, что я считаю прямыми частями стека протокола Биткойн. Вы можете сделать гораздо больше, если начнёте рассматривать централизованные кастодиальные услуги и то, какой поднабор свойств Биткойн они могут предоставить, игнорируя регуляторные или юридические барьеры для этого.
Это всего лишь Часть 2 из 4, прочитайте следующую часть завтра