هو source routing متعدد المستويات: ينشئ المرسل trampoline onion داخلية تتضمن الوجهة والمبلغ وميزانية الرسوم وCLTV، وينقلها داخل onion عادية إلى أول trampoline node، فتحسب العقدة المسار الوسيط الفعلي إلى trampoline hop التالي أو المستلم؛ ولا تعرف كل عقدة مفوضة إلا جزءها من المهمة.
يفترض Lightning source routing العادي أن المرسل يعرف مخطط شبكة صالحاً ويختار كل hop بنفسه. وبالنسبة إلى هاتف يبقى offline كثيراً، يعني ذلك تنزيل channel gossip وتنقيته وحساب المسار قبل الدفع؛ ينقل Trampoline Routing هذا العمل إلى عقد تملك رؤية أحدث للشبكة، لا حفظ المفاتيح أو القنوات. [6]
يختار المرسل أول trampoline node، ويحدد المبلغ والوجهة النهائية وميزانيتي الرسوم وCLTV، ثم ينشئ trampoline onion. تنقل payment onion عادية هذه onion الأصغر إلى العقدة؛ فلا تكشف إلا تعليمة trampoline hop التالي، وتجد مساراً فعلياً عبر عقد عادية، ثم تعيد تغليف بقية onion للمقطع التالي. [1]
قد توجد عقد Lightning عادية لا تدعم الاقتراح بين اثنتين من trampoline nodes، وهي تعالج onion وHTLC قياسيين وفق BOLT #4. تملأ trampoline node الفجوة في المسار، لكنها لا تستطيع تغيير المبلغ أو شروط الزمن أو سر الدفع النهائي من دون أن يفشل تحقق لاحق. [2]
التفويض ليس حفظاً للأموال. لا تحصل trampoline node على seed أو مفتاح خاص أو حق منفرد في الإنفاق من القناة؛ لكنها تستطيع رفض الدفع أو تأخيره، واختيار مسار سيئ أو مكلف، ورؤية metadata لمقطعها. لذلك يجب أن تفرض المحفظة ميزانيتي الرسوم وCLTV وpayment secret ومعالجة الأخطاء المشفرة وإعادة المحاولة. [1]
في بداية أكتوبر 2026 ما يزال اقتراح BOLTs العام #836 مفتوحاً، بينما تشير Eclair وlightning-kmp بالفعل إلى تنفيذ الصيغة المقترحة الأحدث والانتقال من البروتوكول التجريبي الأقدم. يثبت ذلك وجود نشر فعلي، لا اكتمال التشغيل البيني في الشبكة كلها؛ كما يفصل إعداد Eclair الحالي بين تمكين المدفوعات العام وprototype feature flag. [5]
يحمي BOLT #4 محتوى طبقات onion ولا يكشف لأي hop إلا السابق واللاحق، لكنه لا يخفي كل metadata تلقائياً. قد يعرف مزود trampoline واحد العميل المرسل، وعند العبور إلى مستلم لا يدعم trampoline قد يعرف الوجهة أيضاً؛ ويمكن لعدة trampoline hops وblinded path توزيع هذه المعرفة، لكن التوقيت والمبلغ وتكرار الاستخدام تبقى إشارات للربط. [2]
يمكن جمع Route blinding مع trampoline بوضع outgoing_node_id بدلاً من outgoing_channel_id في البيانات المشفرة. لا تفك trampoline node إلا هوية العقدة التالية وتحسب المسار إليها؛ وبذلك يستطيع المستلم إخفاء مقطعه مع السماح للعقدة بإعادة البحث عند نقص السيولة المؤقت. [4]
يتطلب التحقق من محفظة بعينها فحص ما إذا كانت تقلل gossip فعلاً، وكيف تختار trampoline nodes، وأي feature bits وonion TLV تستخدم، وهل الصيغة قديمة أم مقترحة، وكيف تفرض ميزانيتي الرسوم وCLTV وتعالج الأخطاء وMPP، وهل تكشف الوجهة غير الداعمة للعقدة أكثر مما يتوقعه المستخدم. [3]
للحصول على صورة أوضح، اقرأ هذا المدخل مع Lightning Network, Lightning Routing, Lightning Service Provider, HTLC, Payment Channel, خصوصية Bitcoin.
01هل تستطيع trampoline node سرقة دفعة Lightning؟+
تفويض العثور على المسار وحده لا يمنحها مفاتيح خاصة ولا وسيلة لتجاوز شروط الدفع. لكنها تستطيع الرفض أو التأخير أو تجربة مسارات مكلفة أو جمع metadata. يجب أن تحد المحفظة الرسوم وCLTV، وتتحقق من onion وpayment secret، وتستطيع اختيار عقدة أو محاولة أخرى.
02هل Trampoline Routing هو نفسه LSP؟+
لا. LSP دور تشغيلي قد يوفر الاتصال والقناة والسيولة؛ أما trampoline node فتحسب مقطعاً مفوضاً من المسار. يمكن لمشغل واحد أداء الدورين، لكنهما مختلفان، وجمعهما في خدمة واحدة يزيد الاعتماد عليها في التوافر والخصوصية.