إنتقل إلى المحتوى الرئيسي

المرحلة 5: بيتكوين، taproot اثنان من اثنين ونطاق صريح

· 5 دقائق قراءة
OrcaRail
OrcaRail
Crypto payment rails for web2 apps

20 أبريل 2026 — بيتكوين هي الشبكة التي يجب أن نكون فيها صريحين. فواجهة السكربت في الطبقة الأولى لا تملك القدرة التعبيرية لـ 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. هذا مفتاح واحد نتحكم به.

بعد المرحلة 5:

لا يستطيع أي طرف منفرد الإنفاق. ولا يحتفظ أي خادم بـ seed أحادي.

ما الذي سنطلقه​

  • محفظة واصفات لكل رابط: wsh(multi(2, merchant_pubkey, platform_pubkey)) أو مقابل taproot (tr(NUMS, {pk(m), pk(p)}) مع MuSig2 لمخرج يبدو كتوقيع منفرد، وهو أفضل للخصوصية والرسوم).
  • يوجد مفتاح التاجر في متصفح التاجر أو إضافة الهاتف. يطلب تدفق تسجيل التاجر xpub؛ وتُشتق مفاتيح كل رابط منه.
  • يوجد مفتاح المنصة خلف خدمة HSM أو MPC. لا يرى خادم API المادة السرية أبدًا.

2. PSBT استرداد موقّعة مسبقًا​

عند رصد إيداع:

  1. تجمع API معاملة PSBT تعيد الإيداع ناقص الغاز إلى عنوان الدافع (المسجَّل عند إنشاء رابط الدفع إذا كانت محفظة الدافع معروفة؛ وإلا تُطبق سياسة sendback).
  2. يوقّع الموقّعان PSBT الاسترداد فورًا وتُخزَّن (مشفّرة) في قاعدة البيانات.
  3. يمكن للتاجر بث الاسترداد في أي وقت بنقرة واحدة؛ دون الحاجة إلى توقيع إضافي.

هذا هو مقابل دالة refund() على السلسلة في BTC.

3. تدوير مفاتيح MPC​

  • تُدوَّر مفاتيح xpub الرئيسية لمفاتيح المنصة سنويًا.
  • تتبع كل المفاتيح المشتقة لكل رابط هذه التدويرات؛ وتستمر الروابط القديمة في العمل لأن توقيعها المتعدد موجود أصلًا على السلسلة بالمفتاح العام المحدد.
  • يُسجَّل التدوير في سجل التدقيق نفسه الخاص بعمليات نشر التوقيع المتعدد من المرحلة 0.

ما الذي لن نطلقه​

  • اشتراكات / خصم تلقائي على BTC. لا يوجد تصميم موثوق على الطبقة الأولى اليوم. يستثني توثيق الخصم التلقائي الحالي BTC أصلًا، ويبقى ذلك صحيحًا.
  • تقسيم ذري على السلسلة لـ BTC. يحدث التقسيم في PSBT التسوية التي يوقّعها التاجر. يبقى التقسيم حتميًا ومرئيًا في المعاملة المبثوثة، لكن السكربت لا يفرضه.
  • Fedimint أو statechains. بحث مثير للاهتمام؛ لكنه ليس ضمن هذه المرحلة.

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: يعودون حاليًا إلى توقيع متعدد للمنصة فقط، مع خطوة تسجيل إلزامية لإرفاق مفتاح التاجر خلال 30 يومًا. يحافظ ذلك على مسار الاسترداد ويتجنب تعطيل حجم BTC الحالي.

المخاطر ووسائل الحد منها​

  • فقدان التاجر لمفتاحه. الحل: يطلب تسجيل التاجر مفتاحَي xpub (أساسي + احتياطي)؛ والاحتياطي اختياري لكنه موصى به بشدة.
  • انقطاع HSM الخاص بالمنصة. الحل: الـ HSM مكرر عبر مناطق متعددة؛ واسترداد طارئ للمفاتيح عبر مراسم توقيع متعدد موثقة في دليل التشغيل.
  • اختراق مخزن PSBT الاسترداد. الحل: تُشفَّر PSBT الاسترداد أثناء التخزين بمفتاح KMS منفصل؛ كما أنها عديمة الفائدة دون إعادة توقيع التاجر لوجهة مختلفة (الوجهة ثابتة في PSBT الموقّعة مسبقًا).
  • نضج MuSig2. الحل: يصدر الإصدار الأول باثنين من اثنين صريح wsh(multi(...))؛ ويأتي MuSig2 لاحقًا بعد تدقيق الأدوات على نطاق واسع.
  • ارتفاعات سوق الرسوم. الحل: تتضمن PSBT التسوية خطاف CPFP يمكن للتاجر رفعه؛ ويراقب الـ keeper الـ mempool وينبّه التجار عندما يتجاوز غاز التسوية عتبة معينة.

قائمة الحالة​

  • إنهاء قالب واصف taproot
  • اختيار مزوّد HSM / MPC (Lit أم Turnkey أم HSM داخلي)
  • تدفق تسجيل xpub التاجر في لوحة التحكم
  • اشتقاق الواصفات لكل رابط وتخزينها
  • إنشاء PSBT استرداد موقّعة مسبقًا + تخزين مشفّر
  • واجهة التوقيع المشترك للتسوية (توقيع التاجر بنقرة واحدة)
  • دليل تشغيل لتبديل الـ HSM وفقدان مفتاح التاجر
  • مجموعة تجار تجريبية على BTC اثنان من اثنين

ما التالي​

لامركزية اختيارية للـ keeper عبر EigenLayer: المرحلة 6.

التوثيق المرجعي: حالة المرحلة 5 · اعتبارات بيتكوين · نموذج الأمان