Taproot приходить до Bitcoin: як це працює, його історія та наслідки

Підписи Taproot і Schnorr запрацюють на біткойнах у блоці 709,632 XNUMX. Це стане величезним фундаментальним досягненням, яке можна продовжувати розвивати в майбутньому. Минуло чотири роки відтоді, як Segregated Witness запрацював у мережі, наше останнє велике оновлення протоколу. Це стільки ж, скільки цикл удвоєння!

Подумайте про це. Чотири роки від запуску SegWit до запуску Taproot. Повільне, методичне терпіння, як і годиться. Але історія Taproot/Schnorr сягає набагато далі.

Історія Taproot

Деякі, хто був тут деякий час, можуть вважати це іронією, але перша згадка про підписи Шнорра, про яку я знаю, насправді була від колишнього розробника Bitcoin Core, який перетворився на розробника корпоративних блокчейнів Майка Хірна. У 2012 році він вихований ідея нової криптографічної кривої щодо пакетної перевірки підписів, щоб зробити валідацію вузла менш дорогою з точки зору обчислень. Зрештою, схема, яку він пропонував, залежала від підписів Шнорра.

Адам Бек обговорював наївне схеми створювати мультисиг-адреси, які виглядали як односиг-адреси ще в 2014 році, використовуючи підписи Шнорра. Навіть Гевін Андресен включав Шнорр замість ECDSA у своєму списку бажань змін, які він зробив би в біткойнах, якби міг помахати чарівною паличкою.

З самого початку існування біткойна більшість розробників, які активно брали участь у Bitcoin Core, бажали підписів Schnorr, і завжди існував досить твердий консенсус щодо їх переваги над підписами ECDSA. Насправді можна стверджувати, що ECDSA було створено спеціально тому, що схема підпису Шнорра була запатентована, і існувала величезна потреба у схемі криптографічного підпису з відкритим кодом, не обтяженій патентами.

Schnorr є набагато ефективнішим і ним легко маніпулювати (з підписів можна додавати, віднімати тощо, і якщо все зроблено правильно, користувачі все ще можуть залишати дійсні підписи, коли вони повинні їх мати), ніж ECDSA. Протягом багатьох років у більшості криптографічних програм використання ECDSA було радше необхідністю, ніж бажанням.

Merkelized Abstract Syntax Trees (MAST), частина Taproot цього майбутнього оновлення Taproot, має подібну давню історію. Я не можу знайти цитату, але я досить чітко пам’ятаю, як бачив цю фразу, яку кинули такі люди, як Пітер Тодд, на Bitcointalk.org приблизно в 2013 чи 2014 роках.

Оригінальний BIP для MAST була запропонована Джонсоном Лау в 2016 році. Ця пропозиція також мала певну активність приблизно в 2017 році, коли Марк Фріденбах, BTCDrak і Калле Алм розділили її на два окремих BIP (116 та 117) і розширив оригінальну пропозицію Лау.

Наступний рік MAST просидів у підвішеному стані, поки Грег Максвелл не придумав початкову ідею Taproot і опублікований до списку розсилки bitcoin-dev. Його ключове розуміння полягало в тому, що в будь-якому випадку контракту між декількома учасниками, який він міг придумати, існував «оптимальний результат», коли договір міг бути врегульований, коли кожен просто підписав відповідний результат, замість того, щоб забезпечити результат за допомогою більш просунутих сценаріїв і транзакцій. Це основоположне твердження, на якому базується Taproot, тобто налаштування дерева MAST на звичайний ключ верхнього рівня, який можна витрачати, не відкриваючи, чи взагалі існує дерево Merkle з іншими умовами витрат.

Останній невеликий фрагмент цього уроку історії починається з оголошення Пітера Вілле проект БІП для Schnorr і Taproot у тандемі до списку розсилки 6 травня 2019 року. До січня 2020 року це було офіційно завершено в BIPs 340, 341 і 342. З цього моменту це було просто багато дрібних деталей, які вдосконалювалися на рівні реалізації, деякий період перегляду, а потім довгий затягнутий боротьба за механізми активації. Це веде нас до того, що ми просто соромимося активації.

Важливість підписів Шнорра

Отже, в чому ж справа з підписами Шнорра? Ну, для початку вони роблять транзакції меншими. Підпис ECDSA зазвичай має розмір близько 72 байтів для одного підпису в транзакції. Підписи Schnorr мають максимум 64 байти на підпис. Це приблизно 12% економії розміру в порівнянні з ECDSA для кожного підпису Schnorr. Це пряма вигода для користувача Schnorr, який платитиме менше, ніж користувач ECDSA, але також пряма вигода для людей, які не користуються Schnorr, оскільки для обробки та перевірки чужого Schnorr потрібно зберігати трохи менше даних у блокчейні. підписи.

Зберігати менше даних — це завжди добре, але ще краще — це підвищити ефективність перевірки даних, які потрібно зберігати. Одна з приємних властивостей Schnorr, лінійність математики, що стоїть за ним, також забезпечує приємну властивість, яку ви хочете мати в даних Bitcoin: пакетну перевірку. Коли ваш вузол отримує блок від мережі, він аналізує кожну окрему транзакцію та перевіряє кожен підпис один за іншим.

Це велика частина того, чому перевірка блоків споживає багато енергії ЦП. Сигнатури Шнорра можна об’єднати разом і одночасно математично підтвердити, ніби з’єднати їх разом і виконати одну математичну операцію замість купи окремих. Отже, чим більше сигнатур Шнорра, тим більша економія обчислювальних ресурсів. Це величезна перемога в масштабуванні для мережі.

Ще одне колосальне вдосконалення, яке вносить Шнорр, — сценарії з кількома підписами. Кожна мультипідписна адреса має явно розкривати всі окремі відкриті ключі, задіяні в мультипідписному сценарії під час витрачання часу, і підпис має бути наданий для кожного ключа, який бере участь у процесі витрачання. Завдяки математичним властивостям Шнорра відкриваються двері для MuSig, мультисигнатурного стандарту. Ви можете просто додати ключі разом і отримати єдиний відкритий ключ, який усі приватні ключі можуть підписувати за допомогою нових протоколів підпису. Джонас Нік з Blockstream орієнтир MuSig2 за дві хвилини один мільйон учасники в адресі multisig для підпису. Неможливо недооцінити покращення масштабування мультипідписних сценаріїв.

Цей величезний крок вперед для сценаріїв із мультипідписом також має величезні наслідки для профілю конфіденційності та вартості численних додатків, створених на основі біткойнів. Канали Lightning на основі MuSig тепер можуть змішуватися з усім набором анонімних пристроїв Schnorr/Taproot UTXO у ланцюзі, тому що ніхто більше не зможе розрізнити той факт, що вони є мультисиг виходом два з двох.

Вони поєднуватимуться й виглядатимуть як єдиний сценарій підпису. Те ж саме стосується будь-якого мультипідписного UTXO загалом. Це матиме багато наслідків для людей, які використовують сценарії з кількома підписами для кращого захисту свого холодного сховища за допомогою надійнішої моделі безпеки та відновлення, ніж сценарій з одним підписом.

По-перше, не буде очевидно, що вони використовують налаштування multisig, спостерігаючи за блокчейном, тому це, як у випадку з Lightning, змусить їх зливатися з усім іншим. Але ключова перевага полягає в економіці: використання мультипідпису прямо зараз вимагає надання окремого підпису для кожного ключа, який бере участь у остаточному витрачанні UTXO. За допомогою Schnorr/MuSig речі будуть стиснуті в єдиний підпис для єдиного комбінованого відкритого ключа, а це означає, що використання UTXO з кількома підписами за допомогою MuSig стане набагато дешевшим, оскільки він надсилає менше даних до блокчейну.

Остання цікава річ, яку роблять підписи Schnorr, це різке спрощення реалізації підписів адаптерів. Подумайте про підпис адаптера, який «зашифрований» значенням, яке було додано або віднято від дійсного підпису. Він недійсний, доки ви не скасуєте цю математичну операцію або не «розшифруєте» за допомогою «ключа», який використовувався для маніпулювання ним. Це можливо з ECDSA, але через те, що математика є нелінійною порівняно з Schnorr, це відносно складно, і існує багато проблем безпеки, які слід враховувати при його реалізації.

Однак через лінійні властивості Шнорра сигнатура адаптера така ж проста, як взяти одиницю (скажімо, число 9,300,030 30 XNUMX) і відняти з неї значення (скажімо, XNUMX). Коли сторона, яка володіє підписом адаптера, дізнається відняте значення, вона може просто додати його назад і вуаля, вони знову мають дійсний підпис.

Наслідки Taproot

Як обговорювалося трохи вище, насправді Taproot — це просто MAST, за винятком того, що він працює як P2SH (де ви хешуєте сценарій або, у випадку MAST, корінь Merkle верхньої частини дерева сценаріїв), ви «налаштовуєте» Відкритий ключ Шнорра в корені дерева Меркла.

Налаштування працює завдяки лінійним властивостям Шнорра — коли ви «налаштовуєте» відкритий ключ за допомогою кореня Merkle (додаєте цей корінь Merkle до відкритого ключа), ви можете просто додати корінь Merkle до вихідного закритого ключа та створити ключ витрат для новий налаштований відкритий ключ. Тобто, ви додаєте одне й те саме до відкритого та закритого ключів, і вони залишаються дійсною парою ключів. Це приховує існування дерева MAST, якщо тільки не використовується його гілка, але, по суті, це все одно дерево MAST, лише одне, яке дотримується більш ефективним і приватним способом.

Можливість використовувати різні сценарії витрат у дереві Merkle і розкривати лише використаний сценарій є величезною перевагою масштабованості з точки зору складності смарт-контракту, який можна створити на біткойнах.

Подібно до того, як розмір блоку обмежує кількість транзакцій на блок, існує обмеження розміру транзакції в 100 кілобайт. Єдина відмінність полягає в тому, що це не правило консенсусу, а правило політики. Це означає, що майнер може видобути транзакцію, що перевищує 100 кілобайт, але за замовчуванням жоден вузол у мережі не передаватиме майнеру транзакцію, більшу за цю.

Це за своєю суттю обмежує розмір сценарію, який використовується для блокування Bitcoin UTXO. Навіть із P2SH, де UTXO прив’язаний до хешу сценарію, який не розкривається, доки ви його не витратите, вам все одно доведеться розкривати повний сценарій під час витрачання. Taproot збільшує цей ліміт масштабованості сценарію, не вимагаючи від вас відкривати весь сценарій під час його використання. Замість того, щоб загальний розмір усіх способів витрати UTXO обмежувався лімітом розміру транзакції, вам потрібно лише переконатися, що будь-який спосіб витрати UTXO Taproot дотримується цього обмеження.

Крім того, у Taproot є багато переваг конфіденційності. Однією з великих переваг дерева MAST є можливість створювати різноманітні умовні ситуації, коли інші сторони можуть витрачати монети.

Уявіть собі такі речі, як схеми успадкування, де приблизно через рік ваші діти можуть витратити ваші монети, або у випадку, якщо ви відмовляєтеся підписати, ваша дружина та адвокат мають потенційний шлях повернути монети. Ніщо про ці умови витрат не розкривається громадськості, якщо вони фактично не використовуються. Цей подвійний процес забезпечує правдоподібне заперечення для інших сторін, залучених до різних гілок витрат, які ви створюєте, щодо їх участі в цьому UTXO, а також захищає їх від злодія або зловмисника, який завчасно націлюється на них, знаючи, що вони мають певний контроль над своїми UTXO цілі.

На технічному рівні Taproot також був відносно добре розроблений. Будь-хто, хто читає і знайомий із сегрегацією свідків на будь-якому глибокому рівні, повинен бути знайомий із версією свідка.

Коли було впроваджено Segregated Witness, було створено новий розділ «witness» транзакції, куди було переміщено дані підпису. Дані свідків мали позначку версії, щоб їх можна було оновити до нових функцій без використання невизначених OP_CODE на базовому рівні для нових функцій.

Насправді так було реалізовано Taproot/Schnorr. Відокремлені транзакції свідків використовують нульову версію свідків. Коли Taproot/Schnorr незабаром запрацює, вони використовуватимуть нову версію свідка, щоб відрізнити їх від старіших транзакцій Segregated Witness. Подібно до того, як SegWit представив версії-свідки, Taproot представляє «версію tapleaf» для скриптів, що використовуються в деревах MAST для UTXO, які використовують Taproot. Це дозволяє не лише оновлювати скрипти, заховані в MAST, без використання нових кодів OP_CODE на базовому рівні, але також без необхідності оновлення версій-свідків! Тому Taproot було розроблено, щоб бути максимально ефективним для оновлення в майбутньому, не обмежуючи інші непов’язані оновлення протоколу.

Taproot забезпечить багато різноманітних випадків використання. Для початку всі некооперативні пункти в каналі Lightning, такі як штрафні ключі або блокування часу, щоб дозволити їх використовувати, можна поховати під MAST за допомогою Taproot. Ніхто ніколи не дізнається про їх існування, якщо їх не потрібно буде використовувати, ще більше приховуючи, які UTXO насправді є каналами Lightning, а чи ні.

Іншим випадком використання є схеми успадкування. Уявіть собі дерево Taproot, структуроване таким чином, що через шість місяців, коли ви не переміщуєте свої гроші, уся ваша родина може зібратися разом і витрачати UTXO як завгодно. Потім, через шість місяців, кожен мінус одна особа може витратити їх (тож уявіть, що ваша дружина, двоє дітей і батьки є власниками ключів, а потім уявіть, що після додаткових шести місяців ваша дружина, одна дитина та батьки можуть підписати , або ваші двоє дітей і батьки можуть підписати без вашої дружини і так далі).

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

Або що, якщо ви використовуєте multisig для захисту вашого холодного сховища, але у вас є лише одне місце, яке ви вважаєте безпечним і передбачуваним у довгостроковій перспективі? Ви можете створити MAST, де врешті-решт, через кілька років, ключ у цьому безпечному місці зможе витрачати ці монети окремо, на випадок, якщо інші ключі будуть втрачені або знищені, але без ризику крадіжки ваших монет зараз, якщо це один ключ зламано.

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

Це справді виграш у багатьох відношеннях щодо масштабованості та корисності протоколу біткойн, що це важко передати через те, наскільки витонченими та «несексуальними» є деякі з них. Але це не применшує перемоги. Отже, усі пристебніться та готуйтеся грати з новими іграшками, якими нам незабаром доведеться користуватися, адже Taproot приходить!

Це гостьовий пост від Shinobi. Висловлені думки є повністю їх власними і не обов’язково відображають думки BTC Inc або Журнал Bitcoin.

Джерело: https://bitcoinmagazine.com/technical/bitcoin-taproot-explainer