Автор: Фу Шаоцін, SatoshiLab, BTC-студія Wanwu Island

1 Передмова

Під час вивчення технології Біткойна автор виявив, що розуміння трьох ключових понять — SegWit, Taproot, TaprootAssets — через призму історії розвитку ізольованих свідків значно полегшує засвоєння закономірностей їх еволюції. Це також допомагає краще зрозуміти протокол Taproot Assets від Lightning Network Labs, роль Universe, функціональні можливості протоколу TaprootAssets та його потенційний розвиток у майбутньому. Таке розуміння дозволяє ефективніше проектувати відповідні продукти для користувачів.

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

Масштабування — це розширення обсягу даних, які Біткойн може використовувати та керувати. На ранніх етапах це обмежувалося розміром блоку, а згодом — усіма даними, які можуть управлятися Біткойном. Граничне масштабування — це керування необмеженим простором даних.

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

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

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

Усі BIP-протоколи, згадані в статті, мають позначення часу, щоб читач міг відчути цикл від виникнення ідеї до впровадження у виробничому середовищі, а також оцінити складність реалізації. Особливо важливі дати появи та впровадження трьох версій ізольованих свідків — це дозволяє простежити загальні закономірності розвитку та прогнозувати майбутнє. Для команд, що розробляють продукти на основі цих технологій і протоколів, це корисний орієнтир для вибору часу участі. Занадто рання участь часто призводить до того, що технологія ще не зріла, і учасники стають “піонерами”; надто пізня — втрачається перевага, і учасники стають “спостерігачами”. Автор вважає, що найкращий час — це період безпосередньо перед настанням доступності технології. Оцінка цього моменту часто базується на часових та технічних деталях.

# 1.1 Ранні транзакції (без ізольованих свідків)

Транзакції, визначені у Білій книзі (найпростіша модель транзакції)

![] ( https://img-cdn.gateio.im/social/moments-b 1 d 1 e 13125 aa 4168 cb 4 b 94759 c 9 f 4386)

Найбазовіша рання торгівля Біткойном дозволяє мати кілька входів і два виходи. Один вихід — це здача для себе, інший — переказ зовнішньому одержувачу. (Примітка: різниця між загальним входом і виходом — це Торгова комісія)

Більшість торгів мають 2 виходи, хоча бувають і з одним виходом. Підсумок:

![] ( https://img-cdn.gateio.im/social/moments-eb 2838590 b 599622064 e 59 c 7164 e 4672)

Для кращого пояснення різниці використаємо приклад з 2 входами і 2 виходами. (Ще одна причина — у джерелі, на яке я посилаюся, є така ілюстрація, тому не потрібно малювати нову. Трохи лінощів ^_^)

Чи не легше зрозуміти за допомогою такої порівняльної схеми?

![] ( https://img-cdn.gateio.im/social/moments- 3 bd 23 e 4224 babcd 8 d 070 dea 206 e 8 b 1 e 8)

Порівняння традиційної схеми торгівлі та схеми торгівлі з ізольованим свідком SegWit

# 1.2 Дослідження OP_RETURN

Чому при розгляді ізольованих свідків варто згадати OP_RETURN? Тому що це більш ранній етап досліджень, який допомагає краще зрозуміти причини появи ізольованих свідків.

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

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

Подальші зміни функціоналу OP_RETURN

У версії Bitcoin Core v0.9.0 “OP_RETURN вихід” став стандартним типом виходу, дозволяючи користувачам додавати дані до “невитраченого виходу транзакції (unspendable transaction output)”. Обсяг даних спочатку обмежувався 40 байтами, потім збільшився до 80 байт.

Зберігання даних у блокчейні

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

У період Bitcoin Cash (BCH) — з 1 серпня 2017 до 15 листопада 2018 — довжина даних, що додаються до OP_RETURN, була розширена до 220 байт, що сприяло інноваційним застосуванням на блокчейні, наприклад, публікації контенту у соціальних мережах.

У BSV обмеження 220 байт зберігалося недовго. У січні 2019 року, оскільки OP_RETURN завершує скрипт без перевірки подальших Код операції, ноди не перевіряють, чи скрипт відповідає максимальному розміру 520 байт. Оператори нод вирішили збільшити максимальний розмір транзакції до 100 КБ, що надало розробникам більше свободи для інновацій, дозволяючи розміщувати великі та складні дані у реєстрі Біткойна. Наприклад, хтось розмістив цілий сайт у реєстрі BSV.

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

# 1.3 Порівняльна схема ранніх транзакцій та трьох версій ізольованих свідків

Щоб краще зрозуміти всю історію ізольованих свідків у Біткойні, на початку статті наведено порівняльну схему чотирьох етапів.

![] ( https://img-cdn.gateio.im/social/moments-c 2 d 61 a 4507 ac 2 e 8 aa 7 c 743 d 6 e 938650 e )

2 Перший варіант ізольованих свідків — Segwit

# 2.1 Огляд та відповідні протоколи

Ізольований свідок, або Segregated Witness (SegWit), був вперше запропонований Pieter Wuile (основний розробник Біткойна, співзасновник Blockstream) у грудні 2015 року, згодом оформлений як BIP 141. SegWit вирішує три основні проблеми (див. нижче): перші дві — це підвищення безпеки та продуктивності, а третя — найбільше впливає на нові технології, оскільки опосередковано збільшує обсяг блоку (див. поняття Block weight), закладаючи основу для масштабування Біткойна, що дозволило подальше посилення у Taproot (другий варіант ізольованих свідків).

Відповідні протоколи:

BIP-141: Segregated Witness ( Consensus layer ) / 2015-12-21

BIP-143: Transaction Signature Verification for Version 0 Witness Program / 2016-01-03

BIP-144: Segregated Witness ( Peer Services ) / 2016-01-08

# 2.2 Причини та роль

Ізольований свідок вирішує такі проблеми:

1. transaction malleability (розтягуваність транзакцій).

2. У SPV-доказах передача підпису транзакції стала необов’язковою, що дозволяє зменшити обсяг даних для передачі Merkle proof.

3. Опосередковане збільшення обсягу блоку.

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

Хоча обсяг блоку опосередковано збільшено, ізольований свідок все ще обмежений розміром блоку. Максимальний розмір блоку Біткойна — 1 МБ, але дані witness не входять до цього обмеження. Щоб уникнути зловживань, введено загальне обмеження на розмір блоку — поняття Block weight.

Block weight = Base size * 3 + Total size

Base size — розмір блоку без даних witness

Total size — загальний розмір блоку згідно з серіалізацією транзакцій у BIP 144 (у байтах), включаючи базові дані та witness.

Ізольований свідок обмежує Block weight <= 4 МБ.

Ізольований свідок також технічно дозволяє масштабування Біткойна через Lightning Network, але ця частина тут не розглядається.

# 2.3 Детальний аналіз принципу

Технологія ізольованого свідка SegWit призвела до трьох важливих змін:

• Зміна структури торгівлі;
• Збільшення розміру блоку;
• Нова адресна форма Біткойна.

(1) Структура торгівлі:

![] ( https://img-cdn.gateio.im/social/moments- 656 dc 57 a 1 fc 9 d 42 b 81 e 3 e 9 f 2381 e 397 f )

Порівнюючи з початковою схемою торгівлі Біткойна, додано частину Witness — це розблокувальний код. Дані Witness зберігаються у розширеній області даних поза межами 1 МБ.

Більш детальна схема даних торгівлі Segwit:

![] ( https://img-cdn.gateio.im/social/moments- 1411673 aa 66 cdf 278 e 69966820 f 6 d 862)

Детальна схема торгівлі SegWit

(2) Опис розміру торгівлі

![] ( https://img-cdn.gateio.im/social/moments- 17 aada 02 e 03 d 03 cf 6029 fe 22336 f 410 c ) Збільшення розміру блоку

![] ( https://img-cdn.gateio.im/social/moments- 30 d 5482 c 73883 e 5 a 2 e 13 b 4 fb 03 ed 4 c 5 a )

Зміна структури підпису торгівлі та зміст BIP-141 показують, що максимальний розмір блоку Біткойна може бути розширений до 4 МБ, де 1 МБ — це базова область даних торгівлі, а додаткові 3 МБ — область даних Witness.

(3) Формат адреси ізольованого свідка

Ізольований свідок SegWit використовує два нових скрипти блокування: P2WPKH і P2WSH, що призвело до появи нового формату адреси на основі Bech32.

Формат кодування адреси Bech32:

![] ( https://img-cdn.gateio.im/social/moments- 3 ec 5 d 37 f 2 e 39 d 77658 c 7 b 9512 ba 50803)

Формати скриптів блокування P2WPKH і P2WSH описані нижче, тут також наведено приклад адреси другого варіанту ізольованого свідка Taproot.

![] ( https://img-cdn.gateio.im/social/moments-c 354 bfe 70 bd 53 cd 2 ab 07357 bbc 01 d 9 b 5)

Скрипт блокування

P2WPKH

![] ( https://img-cdn.gateio.im/social/moments-d 65 edd 35659 bfd 5 a 1 ea 10211 c 40 c 0474)

Тут 20 байт Відкритого ключа — це початкова форма адреси Біткойна.

P2WSH

![] ( https://img-cdn.gateio.im/social/moments- 621 e 4 c 57 b 92388 a 80 e 0 db 1 c 804 f 739 b 5)

wTXID Commitment

![] ( https://img-cdn.gateio.im/social/moments-c 9954 be 7248 a 41 edd 627 bae 7 d 2 f 27 cb 4)

У witness-області всі ідентифікатори торгівлі (wTXID) формують кореневий хеш через Дерево Меркла, який записується у coinbase, деталі — на схемі.

Схема формування wTXID для окремої witness-торгівлі

wTXID

![] ( https://img-cdn.gateio.im/social/moments-ae 0 cb 158016248243 aed 51 bc 02 c 6 e 4 eb )

# 2.4 Стан розвитку та підсумок

Технологія ізольованого свідка була запропонована у грудні 2015 року, а активована у 2017 році на висоті блоку 481824.

Посилання на перегляд блоку:

Детальний розбір та навчальні матеріали:

Ізольований свідок — одна з найважливіших змін в історії Біткойна, що започаткувала епоху масштабування та розширення функціональності. З точки зору масштабування та розширення, SegWit реалізував саме масштабування. Тому наступний етап розвитку — це розширення функціональності.

![] ( https://img-cdn.gateio.im/social/moments- 3667342 ba 93 c 72 df 5621 d 9 abb 4 bd 9868)

3 Другий варіант ізольованих свідків — Taproot

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

# 3.1 Огляд та відповідні протоколи

Якщо просто використовувати слово Taproot, багато хто сприймає це як нову концепцію, але якщо сказати, що це другий варіант ізольованого свідка SegWit, більшість зрозуміє зв’язок. Відповідні BIP: 340, 341, 342 — BIP 340 (Schnorr Signatures for secp256k1), BIP 341 (Taproot: SegWit version 1 spending rules), BIP 342 (Validation of Taproot Scripts).

Відповідні протоколи:

BIP-341: Taproot: SegWit version 1 spending rules / 2020-1-9

BIP-342: Validation of Taproot Scripts / 2020-1-19

BIP-340: Schnorr Signatures for secp256k1 / 2020-1-19

У листопаді 2021 року Taproot був офіційно активований як soft fork. Оновлення включає BIP 340, BIP 341 і BIP 342. BIP 340 впроваджує Schnorr-підписи, які дозволяють одночасно перевіряти кілька торгів, замінюючи алгоритм ECDSA, що ще більше розширює мережеву потужність і прискорює обробку пакетних торгів, відкриваючи можливості для складних смарт-ф’ючерсів; BIP 341 реалізує меркелізоване абстрактне синтаксичне дерево (MAST) для оптимізації зберігання даних торгів у блокчейні; BIP 342 (Tapscript) розширює можливості скриптової мови Біткойна.

Завдяки розширенню простору Segwit і Taproot з’явилися Schnorr, MAST і Taproot Scripts, які мають на меті розширити функціональність основної мережі Біткойна.

# 3.2 Причини та роль

Завдяки технології ізольованого свідка SegWit фактично збільшено обсяг блоку Біткойна. Але SegWit залишив низку проблем:

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

(2) Простір збільшено, але скрипт розблокування все ще має просту структуру “один до одного”. (З’являється MAST — складна умовна структура)

(3) SegWit не розширив функціональність скриптової мови Біткойна. (З’являється Tapscript)

Отже, другий варіант ізольованого свідка Taproot ефективно вирішив ці проблеми, забезпечивши подальший розвиток технології ізольованих свідків і можливість реалізації нових функцій. BIP 340 вирішує (1); BIP 341 — реалізує MAST для вирішення (2); BIP 342 (Tapscript) розширює скриптову мову Біткойна, вирішуючи (3).

# 3.3 Детальний аналіз принципу

Ключові нові особливості Taproot:

• Впровадження Schnorr-підписів
• Два типи скриптів блокування P2TR: Key Path Spend (аналог P2WPKH); Script Path Spend (аналог P2WSH)
• Скриптове дерево (MAST — меркелізоване абстрактне синтаксичне дерево)
• Taproot Script

1. Schnorr-підписи

Розвиток Taproot вимагав нових підходів до алгоритмів підпису, тому з’явилися Schnorr-підписи, які замінили ECDSA. Schnorr — це схема цифрового підпису, що дозволяє ефективно та безпечно підписувати торгівлі та повідомлення. Вперше описана Клаусом Шнорром у 1991 році. Schnorr цінується за простоту, доведену безпеку та лінійність.

Переваги Schnorr-підписів:

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

Найважливіша перевага Schnorr — агрегація ключів (key aggregation), тобто об’єднання кількох підписів в один, який дійсний для суми ключів. Це дозволяє кільком учасникам створити один підпис для суми їхніх Відкритих ключів. Агрегація підписів зменшує Торгову комісію та підвищує масштабованість, оскільки підпис для мультипідпису займає стільки ж місця, як і підпис для односторонньої торгівлі. Це корисно для зменшення розміру мультипідписних платежів та інших пов’язаних торгів, наприклад, каналів Lightning Network.

Ще одна важлива властивість Schnorr — незмінність.

Schnorr також забезпечує багато переваг для приватності. Мультипідписні схеми не відрізняються від звичайних одноключових підписів, що ускладнює спостерігачам ідентифікацію мультипідписних витрат. У n-of-m мультипідписних схемах Schnorr ускладнює визначення, хто підписав торгівлю.

Schnorr-підписи реалізовані у BIP-340 як частина soft fork Taproot, активовані 14 листопада 2021 року на висоті блоку 709,632. Schnorr робить цифрові підписи BTC швидшими, безпечнішими та простішими у використанні. Важливо, що Schnorr-підписи сумісні з криптографічними алгоритмами BTC, тому їх можна впроваджувати через soft fork.

2. Базова схема та Key Path Spend, Script Path Spend

![] ( https://img-cdn.gateio.im/social/moments- 0 eaaa 87 a 0 cb 8 da 7 ebdc 33600 d 49 f 61 f 8)

3. MAST — меркелізоване абстрактне синтаксичне дерево

Зрозумівши Key Path Spend і Script Path Spend, важливо, що ці скрипти можна організувати у дерево.

Це дерево — інтеграція AST і Дерева Меркла. Схема:

AST-дерево

![] ( https://img-cdn.gateio.im/social/moments- 093 eed 4 d 3754 b 7 bf 9029 abc 37 af 0569 c ) ![] ( https://img-cdn.gateio.im/social/moments- 5 d 3 c 25 d 5 c 0 b 9621 a 12 c 71 d 0 ce 66541 ed )

Побудова меркелізованого дерева на основі AST:

![] ( https://img-cdn.gateio.im/social/moments-c 03 ec 3788 c 9 a 3 ee 1 d 7 e 207 ac 9 a 937460)

4. Taproot Scripts

У BIP 342 впроваджено Tapscript — оновлену версію скриптової мови Біткойна, яку можна вважати мовою, але фактично це набір Код операції з командами, що допомагають реалізації двох інших BIP. Taprootscript також скасував обмеження на розмір скрипта у 10 000 байт, створюючи кращі умови для смарт-ф’ючерсів у мережі Біткойна. (Це оновлення стало основою для появи Ordinals, оскільки протокол Ordinals використовує script-path spend scripts Taproot для додавання даних). Детальніше — на офіційному сайті:

Потенціал TaprootScript ще не повністю реалізований, у майбутньому його можливості проявляться сильніше. Наприклад, для з’єднання першого та другого рівня мережі Біткойна варто більше використовувати Taproot, MAST і TaprootScripits.

Примітка: На першому рівні Taproot можливості TaprootScript ще обмежені, оскільки потрібна підтримка Віртуальної машини Біткойна. У третьому варіанті ізольованих свідків — протоколі TaprootAssets — є спеціальна Віртуальна машина TAP-VM для TaprootScript, що значно розширює можливості та краще ізолює середовище виконання від основної мережі Біткойна.

# 3.4 Стан розвитку та підсумок

Технологія Taproot була запропонована у січні 2020 року, а у листопаді 2021 року офіційно активована як soft fork. Після появи Taproot у екосистемі Біткойна почали з’являтися нові застосування, спочатку — легкі та прості.

Типові застосування:

(1) Протокол Ordinals, напис, BRC20

(2) Інші протоколи — Atomicals, ARC20

(3) Інші протоколи — Rune

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

Перше масштабування Біткойна — від 1 МБлоку до 4 МБлоку. Якщо продовжувати таке масштабування, навіть за наявності технічної підтримки, чи не призведе це до надмірного збільшення блоку, як у інших форках? Це може спричинити централізацію Біткойна та порушити безпеку блокчейна. Тому наступний етап масштабування потребує іншого технічного підходу.

Taproot хоча і реалізував перше розширення функціональності, також має обмеження. На основній мережі Біткойна Віртуальна машина для виконання BTCScript і TapScript — одна й та сама (стекова обробка Біткойна). Це обмежує розширення функціональності та може вплинути на стабільність і безпеку основної мережі. Якщо нове розширення функціональності буде ізольоване від Віртуальної машини основної мережі, створивши незалежну Віртуальну машину, що працює разом з основною, це буде більш раціональний шлях розвитку. Така ізольована Віртуальна машина може еволюціонувати від нетьюрінг-повної до тьюрінг-повної.

![] ( https://img-cdn.gateio.im/social/moments- 21 f 0 bc 002 d 952 b 8 cd 84 e 2 dc 4 dd 8 af 0 b 3)

4 Третій варіант ізольованих свідків — протокол TaprootAssets

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

# 4.1 Причини та роль

Завдяки розвитку Taproot екосистема Біткойна отримала нові можливості:

(1) Чи можна не займати простір блоку Біткойна, реалізувати ще більш ізольований свідок, тобто зберігати дані witness поза блоком, а лише докази — у основній мережі?

(2) Чи можуть дані witness мати більш складну структуру для підтримки ширшого спектра бізнес-функцій?

(3) Подальше розширення можливостей TaprootScript, використання окремої Віртуальної машини для виконання відповідних обчислень.

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

Чи достатньо розвитку Taproot для технологічного прогресу Біткойна? Чи є простір для подальших оновлень і розширень?

# 4.2 Огляд та відповідні протоколи

Lightning Network Labs саме з цих причин і на цьому тлі у кінці 2021 року створила протокол Taproot Assets (раніше — “Taro”). Taproot Assets має потужні можливості та дуже витончену структуру. (Велика подяка автору протоколу, CTO Lightning Network Labs, Olaoluwa Osuntokun)

Taproot Assets складається з 7 важливих BIP (поки без офіційних номерів):

BIP-TAP-ADDR: Taproot Asset On Chain Addresses Draft / 2021-12-10

BIP-TAP-MS-SMT: Merkle Sum Sparse Merkle Trees Draft / 2021-12-10

BIP-TAP-PROOF: Taproot Asset Flat File Proof Format Draft / 2021-12-10

BIP-TAP-PSBT: Taproot Assets PSBT Draft / 2023-02-24

BIP-TAP-UNIVERSE: Taproot Asset Universes Draft / 2021-12-10

BIP-TAP-VM: Taproot Asset Script v1 Draft / 2021-12-10

BIP-TAP: TAP: Taproot Assets Protocol Draft / 2021-12-10

TaprootAssets майже максимально реалізує масштабування та розширення функціональності Біткойна. Простір завдяки Universe теоретично необмежений; верхня межа можливостей — це скриптова потужність TaprootScript і особливості його Віртуальної машини (поки TAP-VM не тьюрінг-повна).

# 4.3 Детальний аналіз принципу

Ключові нові особливості Taproot Assets:

• Дані повністю зберігаються поза основною мережею Біткойна, а докази зберігаються у блоках основної мережі;
• Дані поза ланцюгом мають повноцінну структуру, дуже витончену, що забезпечує кращу масштабованість;
• Дані поза ланцюгом мають потужну підтримку Віртуальної машини VM, яка починає відокремлюватися від Віртуальної машини основної мережі, дозволяючи реалізувати більше функцій, ніж у основній мережі.

1. Зберігання даних поза ланцюгом та докази на ланцюгу

Taproot Assets використовує Universe для зберігання даних поза ланцюгом, що має багато переваг: можна публікувати дані для доступу або зберігати їх приватно.

У поточній версії Taproot Assets для вирішення питань, пов’язаних з Активами, використовується Sparse Merkle Sum Tree (MS-SMT).

![] ( https://img-cdn.gateio.im/social/moments- 20 cff 3175 ce 1 c 38197 a 830762864 d 3 f 3)

Схема випуску різних Активів за допомогою MS-SMT

![] ( https://img-cdn.gateio.im/social/moments-fcf 5 b 332 c 34 dc 2596 fa 22 f 833002 dc 42)

Схема передачі та зберігання Активів у TaprootAssets.

2. Повна структура даних — MS-SMT (Sparse Merkle Sum Tree)

Для випуску Активів Taproot Assets використовує ту ж модель UTXO, що і основна мережа Біткойна, але називає її vUTXO. Контроль загальної кількості vUTXO, їх поділ, об’єднання та передачу здійснює MS-SMT. Сума гарантує незмінність загальної кількості, а Sparse Merkle Tree фіксує стан усіх vUTXO.

( Від Virtual Byte у SegWit до Virtual UTXO у TA — який схожий шлях еволюції! )

“MS-SMT” — це варіант Дерева Меркла, визначений у bip-tap-ms-smt. Оскільки ключі — 256-бітні, дерево має 2^256 листків. Більшість листків порожні.

Кожен листок містить кількість, а кожен вузол фіксує суму кількостей у піддереві. Навіть якщо зміст піддерева невідомий, можна перевірити суму через вузол. Корінь дерева фіксує загальну кількість усіх листків.

Як і у звичайному Дереві Меркла, можна надати обрізане дерево з цільовим листком для доказу (Merkle proof). MS-SMT також підтримує “доказ відсутності” — для цього кількість у листку, що позначає відсутній ключ, має бути явно встановлена як “None”. Доказ “None” — це доказ відсутності. За замовчуванням MS-SMT має 2^256 листків