پرش به مطلب اصلی

ملاحظات بیت‌کوین

بیت‌کوین زنجیره‌ای است که در آن درباره محدوده از همه جا صریح‌تریم. لایه اول قدرت بیان اسکریپت لازم برای تکرار الگوی لینک پرداخت با تقسیم اتمیک را که در EVM و سولانا استفاده می‌کنیم ندارد. پس روی BTC حضانت کاهش‌یافته داریم، نه حضانت صفر، و پرداخت‌های دوره‌ای را تا آماده شدن تکرار در Lightning BOLT12 برای production خارج از محدوده می‌گذاریم.

این صفحه مرجع توضیح چرایی آن است.

«حضانت کاهش‌یافته» روی BTC یعنی چه​

از فاز ۵ به بعد:

  • هر لینک پرداخت جدید یک آدرس مولتی‌سیگ taproot دو از دو است.
  • یک امضاکننده پذیرنده است، با کلیدی که خودش کنترل می‌کند (xpub ثبت‌شده هنگام راه‌اندازی پذیرنده؛ اشتقاق برای هر لینک).
  • امضاکننده دیگر پلتفرم است، از طریق یک HSM یا سرویس MPC (گزینه‌ها: Lit، Turnkey، HSM داخلی). سرور API کلید خام پلتفرم را نگه نمی‌دارد.
  • تسویه به هر دو امضا نیاز دارد؛ هیچ طرفی نمی‌تواند به‌تنهایی وجوه را جابه‌جا کند.
  • برای هر واریز یک PSBT بازپرداخت از پیش امضاشده به‌صورت رمزنگاری‌شده خارج از زنجیره ذخیره می‌شود تا اگر به پذیرنده دسترسی نبود، پرداخت‌کننده بتواند وجوه را پس بگیرد.

آنچه نسبت به امروز تغییر می‌کند:

  • هیچ xpub نگهداری‌شده روی یک سرور واحد، وجوه را کنترل نمی‌کند. نفوذ به سرور API به مهاجم اختیار خرج کردن نمی‌دهد.
  • پذیرندگان به‌صراحت در چرخه امضا حضور دارند. هیچ تسویه‌ای آن‌ها را غافلگیر نمی‌کند.
  • بازپرداخت همیشه ممکن است (پذیرنده PSBT از پیش امضاشده را منتشر می‌کند).

آنچه می‌ماند​

  • حسابداری تقسیم همچنان در PSBT تسویه انجام می‌شود: خروجی‌ها به پذیرنده، پلتفرم، معرف، کارمزد پل و (در صورت وجود) باقی‌مانده. تقسیم قطعی است و در تراکنش منتشرشده به‌صورت آن‌چین دیده می‌شود. این تقسیم با اسکریپت اجبار نمی‌شود (اسکریپت بیت‌کوین نمی‌تواند درصد حساب کند)، اما قابل مشاهده و حسابرسی است.
  • مسیر جمع‌آوری در api/src/withdrawals/services/bitcoin-withdrawal-transfer.service.ts می‌ماند، اما به جای کلید یک‌طرفه از طریق مراسم مولتی‌سیگ امضا می‌کند.

آنچه خارج از محدوده است​

اشتراک / برداشت خودکار BTC​

مستندات فعلی برداشت خودکار از قبل می‌گوید برداشت اشتراک فقط روی EVM و سولانا پشتیبانی می‌شود. پس از فاز ۵ هم همین طور می‌ماند.

معادل معتبری برای برداشت از allowance روی لایه اول BTC وجود ندارد:

  • هیچ ابزار پایه استانداردی برای allowance توکن نیست.
  • هیچ قرارداد عمومی‌ای نیست که بتواند از طرف پرداخت‌کننده transferFrom انجام دهد.
  • دنباله‌ای از PSBTهای از پیش امضاشده (یکی برای هر دوره) در تئوری وجود دارد، اما هیچ‌یک از انعطاف لغو و تغییری را که پرداخت‌کنندگان از اشتراک انتظار دارند ارائه نمی‌کند.

Fedimint، Cashu، statechainها​

پژوهش‌هایی جالب‌اند؛ اما هیچ‌کدام امروز در جایگاهی نیستند که به ریل پرداخت production قابل ارائه به همه پذیرندگان تبدیل شوند. با تغییر میزان پذیرش دوباره بررسی می‌کنیم.

مسیر Lightning​

پرداخت‌های دوره‌ای BTC فقط یک خانه واقع‌بینانه در آینده دارند: پیشنهادهای BOLT12 در Lightning + افزونه recurrence. این به BTC معادلی برای approve + pull در ERC-20 می‌دهد.

وابستگی‌ها (همه بیرونی):

  • پیاده‌سازی‌های بالغ تکرار BOLT12 در نودهای اصلی LN ‏(LND، Core Lightning).
  • پشتیبانی از تکرار BOLT12 در کیف پول‌هایی که پرداخت‌کنندگان ما استفاده می‌کنند (Phoenix، Zeus، Blink، کیف پول‌های سخت‌افزاری).
  • نقدینگی: ناوگانی از نودهای LN یا شبکه شریکانی با ظرفیت حجم مورد انتظار.
  • تجربه کاربری: اپ پرداخت باید Lightning دوره‌ای را به سادگی approve(cap) در EVM کند.

وقتی پشته بیرونی آماده شد سند طراحی منتشر می‌کنیم. تا آن زمان، BTC یک‌باره می‌ماند.

جزئیات عملیاتی​

ثبت‌نام پذیرنده​

  • پذیرنده یک xpub ارائه می‌کند (یک یا دو: اصلی و پشتیبان اختیاری).
  • OrcaRail کلیدهای پذیرنده را برای هر لینک از xpub مشتق می‌کند؛ پذیرنده همان کلیدها را به‌صورت محلی مشتق می‌کند تا هم‌امضا کند.
  • xpub پشتیبان برای مقابله با گم شدن کلید پذیرنده اکیداً توصیه می‌شود.

بازیابی پس از گم شدن کلید​

  • پذیرنده کلید اصلی را گم کرده و پشتیبان دارد: از پشتیبان مشتق کند و ادامه دهد.
  • پذیرنده هر دو را گم کرده: لینک‌های باز موجود از سمت پذیرنده قابل تسویه نیستند. PSBTهای بازپرداخت از پیش امضاشده همچنان کار می‌کنند (بازیابی پرداخت‌کننده). لینک‌های جدید به xpub جدید نیاز دارند.
  • چرخش کلید پلتفرم (سالانه): همه واریزهای موجود همچنان کار می‌کنند، چون کلید قدیمی برای همان آدرس‌ها معتبر می‌ماند. لینک‌های جدید از مسیر اشتقاق جدید استفاده می‌کنند.

جایگزینی خودکار HSM یا MPC​

  • HSM پلتفرم به‌صورت افزونه در چند منطقه مستقر می‌شود.
  • گزینه MPC یک لایه امضاکننده اضافه می‌کند اما پیچیدگی هم می‌افزاید؛ آن را در طراحی فاز ۵ ارزیابی می‌کنیم.
  • runbook جایگزینی اضطراری مستند شده و هر فصل تمرین می‌شود.

گس / بازار کارمزد​

  • PSBT تسویه کارمزد را در زمان انتشار می‌پردازد. رابط هم‌امضایی نرخ کارمزد فعلی را نشان می‌دهد و مقادیر غیرعادی بالا را علامت می‌زند.
  • اگر تراکنش تسویه در mempool گیر کند، hook ‏CPFP (child-pays-for-parent) در دسترس است.

وضعیت مقرراتی​

با حضور امضاکننده پذیرنده در هر لینک، پرداخت‌های BTC در OrcaRail بسیار بیشتر شبیه یک پردازشگر پرداخت معمولی‌اند و کمتر شبیه حضانت:

  • هیچ طرف واحدی کنترل وجوه را ندارد.
  • بازیابی پرداخت‌کننده همیشه از طریق PSBT بازپرداخت از پیش امضاشده در دسترس است.
  • پلتفرم هرگز کلید خصوصی خام را روی هیچ سروری نمی‌بیند.

این موضوع داستان انطباق مقرراتی را در بیشتر حوزه‌های قضایی به‌طور قابل توجهی ساده می‌کند، اما الزامات ثبت را همه جا از بین نمی‌برد. با مشاور حقوقی محلی مشورت کنید.

همچنین ببینید​