پروتکل Taproot Assets یا TAP پروتکلی برای بازنمایی دارایی‌های مبتنی بر UTXO در شبکه بیت کوین است. هدف این مقاله از فکت کوینز درک چگونگی ایجاد و انتقال دارایی توسط TAP است. با ما همراه باشید.
مشخصات به شرح زیر است. در اینجا من عمدتاً bip-tap و bip-tap-ms-smt را توضیح خواهم داد.
پروتکل TapRoot Assets چیست؟
Taproot نوع جدیدی از خروجی بیت کوین است که امکان تعیین دو نوع شرایط پرداخت را به طور هم‌زمان فراهم می‌کند: مسیر Key Pathو Script Path.
مسیر کلید (Key Path)، مانند P2PKH مرسوم، با امضای یک کلید عمومی خرج می‌شود. همچنین می‌توان از تجمیع کلید (چند امضایی) با امضاهای اشنور (Schnorr) استفاده کرد.
مسیر اسکریپت Script Path))، مانند P2SH مرسوم، شرایط پرداخت پیچیده را توسط یک زبان برنامه‌نویسی امکان‌پذیر می‌کند. همچنین اجازه می‌دهد تا چندین اسکریپت به طور هم‌زمان تعیین شود. این اسکریپت‌ها مستقیماً در خروجی Taproot قرار نمی‌گیرند، بلکه توسط یک درخت مرکل (Merkle) ساختار یافته و در روت هش (Root Hash) آن فشرده می‌شوند. اسکریپت‌های منفرد تنها در صورتی به صورت آنچین منتشر می‌شوند که خروجی تحت شرایط آنها خرج شود.
TAP داده‌های خود (درخت دارایی-Asset Tree) را در مسیر اسکریپت جاسازی می‌کند. این داده‌ها از منظر بیت کوین غیر‌قابل تفسیر و غیرقابل‌شناسایی هستند زیرا هش شده‌اند.
است تری (Asset Tree) یا درخت دارایی چیست؟
است تری، یک ساختار دو سطحی Merkle Sum Sparse Merkle Tree، نمایانگر Taproot Assets است. سطح پایینی نشان دهنده مجموعه UTXOهای یک دارایی است که توسط asset_id شناسایی شده است. سطح بالایی قسمت‌های پایینی را تجمیع می‌کند.
مقدار روت هش بالایی (asset_tree_root) در خروجی های Script Pathof Taproot تعبیه شده است و حالت درختی شکل می‌گیرد.
انتقال دارایی یک درخت دارایی (Asset Tree) جدید ایجاد می‌کند و درخت قبلی به روز می‌شود. اینها با صدور یک تراکنش جدید بیت کوین همراه است که خروجی Taproot قبلی را خرج می‌کند. نقل و انتقالات غیرمجاز که مشخصات را برآورده نمی‌کنند (مثلاً تورم، دوبار خرج شدن) نامعتبر تلقی می‌شوند. *
* این به «اعتبار سنجی سمت مشتری» یا Client Side Validation معروف است.
درخت مرکلMerkle Sum Sparse
Merkle Sum Sparse Merkle Tree (که از این به بعد MS-SMT نامیده می‌شود) گونه ای از درخت مرکل است که با bip-tap-ms-smt تعریف شده است. از آنجایی که کلید 256 بیتی است، دارای 2 ^ 256 برگ است که اکثر آنها خالی هستند.
هر برگ حاوی مقداری است و هر شاخه مقدار کل برگ‌های زیردرخت را متعهد می‌شود. حتی اگر محتویات یک زیردرخت مشخص نباشد، تنها با نگاه کردن به شاخه، می‌توان مقدار کل موجود در آن را فهمید.
مانند درخت مرکل به طور کلی، یک درخت هرس شده حاوی هر برگی می‌تواند گواهی inclusion این برگ ها (Merkle Proof) را ارائه دهد، اما MS-SMT از گواهی‌های non-inclusion نیز پشتیبانی می‌کند. این با این محدودیت انجام می‌شود که برگ یک کلید غیرموجود باید به صراحت روی مقداری تنظیم شود که نشان دهنده عدم وجود آن (هیچ) باشد (اثبات گنجاندن “هیچ” = اثبات عدم درج). بنابراین درخت پیش فرض دارای 2 ^ 256 ” None” برگ است.
است لیف (Asset UTXO) یا برگ دارایی
MS-SMT های پایینی درخت دارایی در پروتکل TapRoot Assets دارای asset_script_key به عنوان کلید و است لیف (Asset Leaf) به عنوان مقدار هستند. هر برگ دارایی یک UTXO از دارایی را نشان می‌دهد (که از این پس برای سادگی UTXO نامیده می‌شود) و موارد زیر، از جمله موارد اختیاری، در قالب Type-length-value سریال می‌شوند.
taproot_asset_version
asset_genesis
asset_id
asset_type
amt
lock_time
relative_lock_time
prev_asset_witnesses
– prev_asset_id
– asset_witness
– split_commitment_proof
split_commitment
asset_script_version
asset_script_key
asset_group_key
canonical_universetaproot_asset_version
asset_genesis
asset_id
asset_type
amt
lock_time
relative_lock_time
prev_asset_witnesses
– prev_asset_id
– asset_witness
– split_commitment_proof
split_commitment
asset_script_version
asset_script_key
asset_group_key
canonical_universeasset_genesis یک تصویر اولیه از داده‌هایی است که asset_idis از آن مشتق شده است.
asset_script_key هم کلید Asset Leaf و هم کلید عمومی از نوع تپروت است (در یک tap-vm مجازی، جدا از بیت کوین) و شرط پرداخت برای خرج کردن UTXO است که توسط این است لیف نشان داده شده است.
در پروتکل TapRoot Assets هنگام خرج کردن UTXO، شرط پرداخت بیت کوین (خارجی) نیز باید رعایت شود، زیرا شرط پرداخت TAP (داخلی) مشخص شده در asset_script_key نیز باید توسط prev_asset_id و asset_witness رعایت شود. به عنوان مثال، asset_witness یک امضا توسط asset_script_key از UTXO مصرف‌شده است.
اگر یک UTXO در یک انتقال تقسیم شود، به split_commitment و split_commitment_proof نیاز است.
split_commitment یک MS-SMT است که به تمام UTXO ها پس از تقسیم اشاره دارد (در این مورد Asset Tree دارای سه لایه است) و مقدار مجموع ریشه مقدار کل دارایی‌های منتقل شده است.
split_commitment_proof یک مدرک Merkle برای split_commitment است که وجود یک split را اثبات می‌کند.
فقط یکی از همه تقسیمات دارای prev_asset_id، asset_witness و split_commitment است. همه تقسیمات دیگر فقط split_commitment_proof دارند. همه تقسیمات prev_asset_id و asset_witness را به اشتراک می‌گذارند.
ایجاد دارایی (Asset Creation) در پروتکل TapRoot Assets
دارایی با جاسازی یک است تری جدید حاوی UTXO دارایی‌های جدید در خروجی تپروت تراکنش بیت کوین (تراکنش پیدایش دارایی) ایجاد می‌شود. شناسه دارایی (asset_id) با فرمول زیر تعریف می‌شود.
asset_id := sha256(genesis_outpoint || sha256(asset_tag) || asset_meta_hash || output_index || asset_type)
genesis_outpoint خروجی تراکنش قبلی است که توسط تراکنش خرج شده و output_index موقعیت خروجی تراکنش حاوی است تری (درخت دارایی) است. اینها تضمین می‌کنند که asset_id در سطح جهانی منحصر به فرد است.
انتقال دارایی در پروتکل TapRoot Assets
مانند UTXO های بیت کوین، ادغام و تقسیم UTXO ها ممکن است در انتقال دارایی ها رخ دهد. اما ما با یک سناریو ساده شروع می‌کنیم که در آن هیچ یک از موارد فوق رخ نمی‌دهد *.
* در توضیح زیر چند ساده سازی صورت گرفته است. به عنوان مثال، خروجی های تغییر کرده بیت کوین حذف شده است.
آلیس 10 بیت کوین تا دارد و همه آنها را بدون تقسیم به باب منتقل می‌کند.
آلیس یک تراکنش بیت کوین را ایجاد و مخابره می‌کند که خروجی تپروت را در جایی که UTXO تعبیه شده است خرج می‌کند. این دارای دو خروجی Taproot جدید است. یکی شامل یک درخت دارایی جدید حاوی یک UTXO جدید با 10 است که باب می‌تواند آن را کنترل کند (به عنوان مثال، با استفاده از کلید بیت کوین باب). دیگری شامل یک درخت دارایی است که دارایی UTXO از درخت دارایی اصلی حذف شده است، که آلیس می‌تواند آن را کنترل کند.
UTXO جدید با 10 برای باب به UTXO قبلی آلیس توسط prev_asset_id اشاره دارد. در asset_witness، امضای asset_script_key قبلی قرار می گیرد. در asset_script_key UTXO جدید، یک کلید جدید توسط Bob از قبل قرار داده شده است.
برای تأیید دریافت دارایی در پروتکل TapRoot Assets ، باب باید تأیید کند که شرایط پرداخت برآورده شده است و دارایی پس از انتقال متورم نشده است.
آیا درخت دارایی تازه ایجاد شده برای باب حاوی UTXO جدیدی است که شرایط پرداخت را برآورده می‌کند؟
آیا ورودی UTXO از درخت دارایی به روز شده برای آلیس حذف شده است؟
اگر خروجی های Taproot دیگری در تراکنش وجود داشته باشد، آیا آنها شامل درخت دارایی دیگری نیستند؟ *
و غیره
اینها با گواهی‌های inclusion/non-inclusion MS-SMT و تصاویر اولیه و گواهی‌های خروجی‌های تپروت تأیید می‌شوند.
* اگر یک UTXO متفاوت به چنین درخت دارایی اضافه شود، منجر به دولار خرج کردن (Double Spending) می‌شود.
آلیس 3 و 7 دارد و همه آنها را به باب منتقل می‌کند.
هر UTXO ورودی ممکن است به طور جداگانه به درخت دارایی متفاوت یا کلیدهای مختلف (asset_script_key) از همان درخت تعلق داشته باشد. UTXO جدید برای باب باید شامل prev_asset_id و asset_witness برای هر یک از دو UTXO باشد.
تقسیم UTXO در پروتکل TapRoot Assets
آلیس 10 تا دارد و 7 تای آنها را به باب منتقل می‌کند. در نتیجه، آلیس 3 برای تغییر و باب 7 دارد.
change UTXO آلیس دارای prev_asset_id، asset_witness و split_commitment است. UTXO جدید باب فقط دارای split_commitment_proof است.
من توضیح نمی دهم که چه زمانی باید UTXO ها را به طور هم‌زمان ادغام و تقسیم کرد.
* این کمی با آنچه در مشخصات گفته شده متفاوت است، اما روند فعلی احتمالاً شبیه این است.
منشأ دارایی در پروتکل TapRoot Assets
اگرچه پیش‌تر ذکر نشده است، هر UTXO ورودی باید قبل از تأیید انتقال دارایی، قانونی بودنش تأیید شود. برای هر UTXO ورودی، باید ثابت/تأیید شود که تمام انتقالات در طول مسیرها از تراکنش پیدایش دارایی، به UTXO جدید به درستی انجام شده است.
مسیرها یک نمودار پیچیده از تراکنش پیدایش تا آخرین تراکنش هستند. در بالا، در Tx A، باید نقل و انتقالات را روی تمام تراکنش‌های آبی قبلی خود تأیید کند، و در Tx B، باید نقل و انتقالات را روی همه تراکنش‌های آبی و قرمز تأیید کند. این یک چالش مقیاس پذیری قابل توجه است.
همچنین، از آنجایی که‌تصاویر اولیه (preimage) و شواهد مورد نیاز برای تأیید در زنجیره منتشر نمی‌شوند، نحوه انتقال آنها از فرستنده به گیرنده در حین انتقال دارایی یک مسئله است.
سخن آخر
افزایش تاریخچه (history) یک چالش مقیاس پذیری مهم است. چندین راه حل پیشنهاد شده است، اما پشتیبانی از شبکه لایتنینگ یکی از امیدوارکننده ترین آنها است. معاملات خارج از زنجیره تاریخچه را افزایش نمی‌دهد. به طور کلی، پروتکل TapRoot Assets هنوز جدید است و مشخصات آن ناقص است، پس باید منتظر ماند و دید در آینده چه تغییراتی در این پروتکل ایجاد خواهد شد.
