Як співробітники, які працювали у 2010 році, дивляться на шлях будівництва BTC через десять років

Автор: BTC подкаст Block Digest співзасновник Shinobi; переклад: Ву Чжу, золотий фінансовий

Цей текст - це стаття, написана Shinobi десять років тому, яка досліджує, яким був BTC у 2020 році.

Першу статтю цієї серії можна переглянути, натиснувши на "Як виглядає екосистема BTC через десять років з погляду фахівців 2010 року?"

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

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

Незабаром ми матимемо комбінацію Schnorr та Taproot. З точки зору Schnorr, це схема пакетної перевірки підписів, яка є більш вигідною вартістю, а також наступним великим стрибком у оптимізації конструкції BTC для багаторазового підпису. Спочатку багаторазовий підпис просто вставляв усі відкриті ключі та сценарії багаторазового підпису у вихідну транзакцію та мусив включити усе це у вхід, щоб використовувати його. P2SH, оптимізуючи вихід, шляхом включення постійної довжини хеш-значення відкритого ключа та сценарію багаторазового підпису, заощаджує вартість для будь-якого, хто надсилає на адресу багаторазового підпису, лише додаючи витрати відправнику. SegWit, можна сказати, подальшим "вдосконаленням" робить витрати багаторазових підписів UTXO дешевшими за допомогою знижки на свідоцтво. Schnorr досяг переваги за допомогою всіх цих інкрементальних оптимізацій. Ви об'єднаєте всі відкриті ключі в один ключ, кожен може співпрацювати для його створення підпису та перевірки. Це дає значні економічні вигоди для всіх технологій, що використовують багаторазові підписи (включаючи мережу Lightning та другий шар, такий як федеративні бокові ланцюги), а також, зробивши неможливим розрізнення між усіма цими багаторазовими підписами UTXO та UTXO з одиночним підписом, приносить переваги в приватності.

Зараз це не чарівно зробити все абсолютно конфіденційним. Статус (операції) мережі Lightning все ще вимагає окремих ключових шляхів, щоб відповідати покаранню за операції в старому стані. Це означає, що вони повинні бути у вихідному скрипті, в якому створюється відбиток пальця. Taproot вирішує цю проблему за допомогою своєї шифрувальної магії, дозволяючи вам відправити дерево Меркла з різними умовами витрат, достатньо вказати умови та довести Мерклу до кореня, щоб здійснити витрати, до Schnorr публічного ключа, який виглядає як звичайний. Тепер ви можете приховати шлях покарання для цього. Ви можете приховати будь-який шлях скрипту умов, прихований під 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, який гарантує 100% коштів своїх клієнтів відповідно до правил консенсусу, що всі кошти його клієнтів в кінцевому підсумку будуть контролюватися клієнтом, навіть якщо вони в даний час не мають безпосереднього доступу до цих коштів. Це має великий потенціал синергії з багатоканальністю (фабрикою каналів), оскільки такі великомасштабні «вилучення» також можуть бути створені та використовуватися як фабрика каналів одночасно. OP_CTV можна використовувати для створення платіжних каналів, які працюють принаймні в одному напрямку, без необхідності участі одержувача або наявності ключа в Інтернеті для отримання платежів (пам'ятайте, що ви можете складати канали один на одного). Його навіть можна використовувати, щоб дозволити одному каналу обробляти більше HTLC одночасно, об'єднуючи їх разом, використовуючи ті ж трюки, що і перший приклад виведення коштів. Це може навіть створити певний потенціал для нового типу coinjoin.

###Інтеграція всіх елементів

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

Вони дозволять теоретично необмежену кількість учасників у багатосторонніх каналах, які можуть бути накладені на менші підгрупи учасників базового каналу. Можна будувати канали над цими "фабриками каналів", щоб люди могли отримувати платежі без необхідності мати ключі гарячого гаманця в онлайні. Ці багатосторонні канали можуть бути накладені на спільні канали (ланцюжок станів), що дозволяє учасникам входити або виходити на ланцюжку за умови нульової активності на ланцюжку! Конструкція "зшивання" каналів дозволить ліквідності відносно безшовно переміщуватися між різними каналами, що дозволить реалізувати різноманітні речі, навіть які люди ще не розглядають.

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