مرحله ۵: بیت‌کوین، taproot دو از دو و دامنه‌ای صادقانه
۲۰ آوریل ۲۰۲۶ — بیت‌کوین زنجیره‌ای است که در آن باید صادق باشیم. سطح اسکریپت لایه ۱ قدرت بیان EVM یا سولانا را ندارد، پس الگوی «قرارداد لینک پرداختی که به‌صورت اتمیک تقسیم می‌کند» قابل انتقال نیست. کاری که می‌توانیم بکنیم کاهش امانت‌داری است؛ از «OrcaRail مالک xpub است» به «مولتی‌سیگ دو امضاکننده با یک امضاکننده از طرف فروشنده و یک بازپرداخت از پیش امضاشده»؛ و پرداخت‌های دوره‌ای را به مسیر آینده Lightning بسپاریم.
خلاصه
- هر لینک پرداخت BTC یک مولتی‌سیگ taproot دو از دو می‌شود: یک امضاکننده فروشنده و یک امضاکننده پلتفرم. پلتفرم نمی‌تواند به‌تنهایی وجوه را جابه‌جا کند.
- هر واریز یک PSBT بازپرداخت از پیش امضاشده دارد که خارج از زنجیره ذخیره می‌شود تا اگر فروشنده ناپدید شد، پرداخت‌کننده بتواند وجهش را پس بگیرد.
- xpubهای اصلی از سرور API به یک سرویس HSM یا MPC (مثلاً Lit یا Turnkey) منتقل می‌شوند. هیچ عبارت بازیابی روی دیسک نیست.
- پرداخت دوره‌ای روی BTC خارج از دامنه است تا وقتی Lightning BOLT12 آماده محیط عملیاتی شود. امروز هم برداشت خودکار اعلام کرده که BTC برای برداشت خودکار پشتیبانی نمی‌شود؛ این همچنان صادق است.
این مرحله چه چیزی را تغییر می‌دهد
امروز BitcoinHotWalletService در api/src/withdrawals/services/bitcoin-hot-wallet.service.ts یک آدرس p2wpkh یک‌جانبه از عبارت بازیابی نگهداری‌شده روی سرور مشتق می‌کند و از طریق bitcoin-withdrawal-transfer.service.ts جاروبش می‌کند. این یک کلید واحد است که ما کنترلش می‌کنیم.
پس از مرحله ۵:
هیچ طرفی به‌تنهایی نمی‌تواند خرج کند. هیچ سروری seed یک‌جانبه نگه نمی‌دارد.
آنچه منتشر می‌کنیم
۱. taproot دو از دو برای هر لینک
- کیف پول مبتنی بر توصیف‌گر برای هر لینک:
wsh(multi(2, merchant_pubkey, platform_pubkey))یا معادل taproot آن (tr(NUMS, {pk(m), pk(p)})با MuSig2 برای خروجی‌ای که شبیه تک‌امضا به نظر می‌رسد؛ خوب برای حریم خصوصی و کارمزد). - کلید فروشنده در مرورگر یا افزونه موبایل فروشنده نگهداری می‌شود. جریان ثبت‌نام فروشنده یک xpub درخواست می‌کند و کلیدهای هر لینک از آن مشتق می‌شوند.
- کلید پلتفرم پشت سرویس HSM یا MPC است. سرور API هرگز داده خصوصی را نمی‌بیند.
۲. PSBT بازپرداخت از پیش امضاشده
وقتی واریزی شناسایی می‌شود:
- API یک PSBT می‌سازد که مبلغ واریز منهای گس را به آدرس پرداخت‌کننده برمی‌گرداند (آدرسی که هنگام ساخت لینک پرداخت، اگر کیف پول پرداخت‌کننده مشخص باشد، ثبت شده؛ در غیر این صورت سیاست
sendbackاعمال می‌شود). - هر دو امضاکننده بلافاصله PSBT بازپرداخت را امضا می‌کنند و آن (رمزنگاری‌شده) در پایگاه داده ذخیره می‌شود.
- فروشنده هر زمان با یک کلیک می‌تواند بازپرداخت را منتشر کند؛ امضای دیگری لازم نیست.
این معادل BTC برای تابع refund() روی زنجیره است.
۳. چرخش کلید MPC
- xpubهای اصلی کلیدهای پلتفرم سالانه چرخش می‌یابند.
- همه کلیدهای مشتق‌شده هر لینک با چرخش‌ها جلو می‌روند؛ لینک‌های قدیمی همچنان کار می‌کنند چون مولتی‌سیگشان با pubkey مشخص از قبل روی زنجیره است.
- چرخش در همان سابقه حسابرسی استقرارهای مولتی‌سیگ مرحله ۰ ثبت می‌شود.
آنچه منتشر نمی‌کنیم
- اشتراک / برداشت خودکار BTC. امروز هیچ طرح معتبری روی لایه ۱ وجود ندارد. مستندات برداشت خودکار از قبل BTC را مستثنا کرده و این همچنان درست است.
- تقسیم اتمیک روی زنجیره برای BTC. تقسیم در PSBT تسویه‌ای انجام می‌شود که فروشنده امضا می‌کند. تقسیم همچنان قطعی است و در تراکنش منتشرشده دیده می‌شود، اما اسکریپت آن را اجبار نمی‌کند.
- Fedimint یا statechainها. پژوهش جالبی است؛ اما در این مرحله نیست.
Lightning به‌عنوان مسیر آینده
پرداخت‌های دوره‌ای BTC یک گزینه واقع‌بینانه دارند: پیشنهادهای BOLT12 در Lightning + افزونه recurrence. این به ما راهکاری برای اشتراک BTC می‌دهد که با approve + برداشت در ERC-20 قابل مقایسه است. آن را به‌عنوان مرحله‌ای آینده پیگیری می‌کنیم:
- وابسته به پیاده‌سازی‌های بالغ recurrence در BOLT12 روی LND و CLN.
- وابسته به پشتیبانی کیف پول‌های Lightning (Phoenix، Zeus، Blink) از recurrence در BOLT12.
- نیازمند ناوگانی از نودهای LN با نقدینگی کافی؛ احتمالاً از طریق یک شریک (Voltage، Greenlight).
وقتی ابزارهای پایه آماده شوند، یک سند طراحی اختصاصی منتشر می‌کنیم. تا آن زمان، BTC فقط پرداخت یک‌باره دارد.
موارد منسوخ‌شده
BitcoinHotWalletService— رابطش را حفظ می‌کند، اما تأمین‌کننده کلید به HSM/MPC منتقل می‌شود. آدرس واریز p2wpkh یک‌جانبه دیگر برای لینک‌های جدید ساخته نمی‌شود.- آدرس‌های واریز BTC قدیمی تا زمان انقضا از طریق مسیر جاروب قدیمی قابل تسویه می‌مانند.
برنامه مهاجرت
- لینک‌های پرداخت BTC جدید: آدرس‌های مولتی‌سیگ دو از دو. رابط کاربری بدون تغییر؛ قالب آدرس به taproot به‌روز می‌شود.
- لینک‌های BTC باز فعلی: آدرس‌های یک‌جانبه قدیمی تا انقضا فعال می‌مانند؛ مهاجرت را اجباری نمی‌کنیم.
- فروشندگان بدون امضاکننده BTC تنظیم‌شده: فعلاً به مولتی‌سیگ فقط با پلتفرم برمی‌گردند، با یک گام اجباری ثبت‌نام برای افزودن کلید فروشنده ظرف ۳۰ روز. این کار مسیر بازپرداخت را حفظ می‌کند و حجم فعلی BTC را متوقف نمی‌کند.
ریسک‌ها و راهکارها
- گم شدن کلید فروشنده. راهکار: ثبت‌نام فروشنده دو xpub درخواست می‌کند (اصلی + پشتیبان)؛ پشتیبان اختیاری است اما به‌شدت توصیه می‌شود.
- قطعی HSM پلتفرم. راهکار: HSM در چند منطقه افزونگی دارد؛ بازیابی اضطراری کلید از طریق مراسم مولتی‌سیگ که در runbook مستند شده است.
- نفوذ به محل ذخیره PSBTهای بازپرداخت. راهکار: PSBTهای بازپرداخت در حالت ذخیره با کلید KMS جداگانه رمزنگاری می‌شوند؛ ضمن اینکه بدون امضای دوباره فروشنده برای مقصدی دیگر بی‌فایده‌اند (مقصد در PSBT از پیش امضاشده ثابت است).
- بلوغ MuSig2. راهکار: نسخه ۱ با دو از دوی صریح
wsh(multi(...))منتشر می‌شود؛ MuSig2 بعداً و پس از حسابرسی گسترده ابزارها می‌آید. - جهش بازار کارمزد. راهکار: PSBTهای تسویه یک قلاب CPFP دارند که فروشنده می‌تواند کارمزد را با آن بالا ببرد؛ keeper ممپول را پایش می‌کند و وقتی گس تسویه از آستانه‌ای بگذرد به فروشندگان هشدار می‌دهد.
چک‌لیست وضعیت
- نهایی شدن قالب توصیف‌گر taproot
- انتخاب ارائه‌دهنده HSM / MPC (Lit در برابر Turnkey در برابر HSM داخلی)
- جریان ثبت xpub فروشنده در داشبورد
- مشتق‌گیری و ذخیره توصیف‌گر برای هر لینک
- تولید PSBT بازپرداخت از پیش امضاشده + ذخیره رمزنگاری‌شده
- رابط هم‌امضای تسویه (امضای فروشنده با یک کلیک)
- runbook برای جایگزینی خودکار HSM و گم شدن کلید فروشنده
- گروه آزمایشی فروشندگان روی BTC دو از دو
قدم بعدی
غیرمتمرکزسازی اختیاری keeper از طریق EigenLayer: مرحله ۶.
مستندات مرجع: وضعیت مرحله ۵ · ملاحظات بیت‌کوین · مدل امنیتی