Ми вже починаємо бачити прорости потенціалу другого рівня з базових примітивів першого десятиліття. Блискавка, хоча й піддається деяким досить великим обмеженням, починає справжньо процвітати. І це лише обмежена перша версія, яка в даний час зазначена та розгорнута. Тепер вже розгорнуті сайдчейни різних видів: Liquid, RSK, та навіть токен-чейни, пов'язані з Біткойн, розроблені Commerceblock. Це лише початок.
Шнорр і стрижневий корінь
Трохи за горизонтом ми маємо комбінацію Schnorr і Taproot. З точки зору Шнорра, це набагато дешевша схема перевірки підпису пакетами, а також наступний великий стрибок в оптимізації конструкції скриптів мультипідпису в Біткойн. Мультипідпис починався з того, що він просто запхав усі публічні ключі та скрипт для мультипідпису у вихідні дані транзакції для надсилання йому, і мав включити все це у вхідні дані, щоб витратити їх. P2SH оптимізував вихідний аспект, включивши хеш постійної довжини публічних ключів і сценаріїв мультипідпису, заощадивши комісію для будь-кого, хто надсилає на адресу з мультипідписом, і залишивши підвищену вартість лише для відправника. Можливо, SegWit ще більше «оптимізувався», зробивши витрати на UTXO з мультипідписом дешевшими за допомогою знижки свідків. Шнорр доводить всю цю поступову оптимізацію до крайності. Ви об'єднуєте окремі відкриті ключі в один ключ, для якого кожен може співпрацювати, щоб створити єдиний підпис, і просто перевірте це. Це створює значну економію коштів для будь-якого використання мультипідпису, включаючи другі рівні, такі як Lightning і федеративний сайдчейни, а також створює переваги конфіденційності, роблячи всі ці мультипідписні UTXO неможливо відрізнити від однопідписних.
Зараз це просто чарівно не робить все абсолютно приватним. Стани каналу молниї (transactions) все ще потребують окремих шляхів ключів для їхніх пенальних транзакцій, щоб реагувати на подання старих станів. Це означає, що вони повинні бути в вихідних сценаріях, що створює відбиток пальця. Taproot вирішує це своєю крипто-магією, що дозволяє вам зобов'язати merkle tree різних умов витрат, які вимагають лише умову, використану та merkle proof до кореня merkle для витрат, до звичайного Schnorr громадського ключа. Тепер ви можете приховати цей шлях пенального сценарію за допомогою taproot. Ви можете приховати будь-який умовний сценарій за допомогою Taproot, захований під зовсім звичайним Schnorr ключем, що дозволяє всім учасникам погодитися на щось і зробити зовсім звичайну транзакцію.
СІГАШ_ANYPREVOUTPUT
SIGHASH_ANYPREVOUTPUT (раніше SIGHASH_NOINPUT), сподіваємося, що наступним новим примітивом, який прийде по трубопроводу, буде саме цей. Це оновлення нового формату публічного ключа / прапора підпису. Прапори 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 одночасно, пакуючи їх разом за тим самим трюком, який використовується у першому прикладі з кастодіальними виведеннями. І може навіть створити деякий потенціал для нових типів coinjoin.
Зведення всього разом
Припускаючи, що всі вищезазначені пропозиції будуть прийняті та включені до Біткойну, я вважаю, що окрім розробників, які фактично працюють на передовому фронті цих речей, люди навіть не мають найблідшого уявлення, які типи протоколів та сервісів будуть побудовані з використанням цих примітивів. Або дивних речей, де немає чіткої межі між сервісом або протоколом.
Вони дозволять багатосторонні канали з теоретично необмеженою кількістю учасників, які можуть накладати підканали з меншими підгрупами учасників базового каналу. Канали можуть бути побудовані на основі цих “фабрик каналів”, які дозволяють людям отримувати гроші без ключів онлайн для гарячого гаманця. Ці багатосторонні канали можуть бути накладені на федеративні канали (statechains), що дозволяють учасникам входити або виходити з нульовою активністю на ланцюгу! І конструкція “злиття” каналу дозволить ліквідності переміщуватися відносно плавно між різними каналами таким чином, що дозволить всілякі речі, про які люди навіть справді не починали думати.
Моє останнє слово в цьому розділі: це лише розгляд того, що можна зробити з речами, які я вважаю прямими частинами самого стека протоколів Біткойн. Ви можете зробити набагато більше, якщо почнете розглядати централізовані кастодіальні послуги, і які підмножини властивостей Біткойн вони можуть забезпечити, ігноруючи нормативні або правові бар'єри для цього.
Це лише Частина 2 з 4, прочитайте наступну частину завтра
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Наступне десятиліття, Частина 2: Шлях уперед
Ми вже починаємо бачити прорости потенціалу другого рівня з базових примітивів першого десятиліття. Блискавка, хоча й піддається деяким досить великим обмеженням, починає справжньо процвітати. І це лише обмежена перша версія, яка в даний час зазначена та розгорнута. Тепер вже розгорнуті сайдчейни різних видів: Liquid, RSK, та навіть токен-чейни, пов'язані з Біткойн, розроблені Commerceblock. Це лише початок.
Шнорр і стрижневий корінь
Трохи за горизонтом ми маємо комбінацію Schnorr і Taproot. З точки зору Шнорра, це набагато дешевша схема перевірки підпису пакетами, а також наступний великий стрибок в оптимізації конструкції скриптів мультипідпису в Біткойн. Мультипідпис починався з того, що він просто запхав усі публічні ключі та скрипт для мультипідпису у вихідні дані транзакції для надсилання йому, і мав включити все це у вхідні дані, щоб витратити їх. P2SH оптимізував вихідний аспект, включивши хеш постійної довжини публічних ключів і сценаріїв мультипідпису, заощадивши комісію для будь-кого, хто надсилає на адресу з мультипідписом, і залишивши підвищену вартість лише для відправника. Можливо, SegWit ще більше «оптимізувався», зробивши витрати на UTXO з мультипідписом дешевшими за допомогою знижки свідків. Шнорр доводить всю цю поступову оптимізацію до крайності. Ви об'єднуєте окремі відкриті ключі в один ключ, для якого кожен може співпрацювати, щоб створити єдиний підпис, і просто перевірте це. Це створює значну економію коштів для будь-якого використання мультипідпису, включаючи другі рівні, такі як Lightning і федеративний сайдчейни, а також створює переваги конфіденційності, роблячи всі ці мультипідписні UTXO неможливо відрізнити від однопідписних.
Зараз це просто чарівно не робить все абсолютно приватним. Стани каналу молниї (transactions) все ще потребують окремих шляхів ключів для їхніх пенальних транзакцій, щоб реагувати на подання старих станів. Це означає, що вони повинні бути в вихідних сценаріях, що створює відбиток пальця. Taproot вирішує це своєю крипто-магією, що дозволяє вам зобов'язати merkle tree різних умов витрат, які вимагають лише умову, використану та merkle proof до кореня merkle для витрат, до звичайного Schnorr громадського ключа. Тепер ви можете приховати цей шлях пенального сценарію за допомогою taproot. Ви можете приховати будь-який умовний сценарій за допомогою Taproot, захований під зовсім звичайним Schnorr ключем, що дозволяє всім учасникам погодитися на щось і зробити зовсім звичайну транзакцію.
СІГАШ_ANYPREVOUTPUT
SIGHASH_ANYPREVOUTPUT (раніше SIGHASH_NOINPUT), сподіваємося, що наступним новим примітивом, який прийде по трубопроводу, буде саме цей. Це оновлення нового формату публічного ключа / прапора підпису. Прапори 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 одночасно, пакуючи їх разом за тим самим трюком, який використовується у першому прикладі з кастодіальними виведеннями. І може навіть створити деякий потенціал для нових типів coinjoin.
Зведення всього разом
Припускаючи, що всі вищезазначені пропозиції будуть прийняті та включені до Біткойну, я вважаю, що окрім розробників, які фактично працюють на передовому фронті цих речей, люди навіть не мають найблідшого уявлення, які типи протоколів та сервісів будуть побудовані з використанням цих примітивів. Або дивних речей, де немає чіткої межі між сервісом або протоколом.
Вони дозволять багатосторонні канали з теоретично необмеженою кількістю учасників, які можуть накладати підканали з меншими підгрупами учасників базового каналу. Канали можуть бути побудовані на основі цих “фабрик каналів”, які дозволяють людям отримувати гроші без ключів онлайн для гарячого гаманця. Ці багатосторонні канали можуть бути накладені на федеративні канали (statechains), що дозволяють учасникам входити або виходити з нульовою активністю на ланцюгу! І конструкція “злиття” каналу дозволить ліквідності переміщуватися відносно плавно між різними каналами таким чином, що дозволить всілякі речі, про які люди навіть справді не починали думати.
Моє останнє слово в цьому розділі: це лише розгляд того, що можна зробити з речами, які я вважаю прямими частинами самого стека протоколів Біткойн. Ви можете зробити набагато більше, якщо почнете розглядати централізовані кастодіальні послуги, і які підмножини властивостей Біткойн вони можуть забезпечити, ігноруючи нормативні або правові бар'єри для цього.
Це лише Частина 2 з 4, прочитайте наступну частину завтра