Submarine Swap

تحتفظ آنا ببيتكوين في محفظة عادية، بينما يقدم المتجر فاتورة Lightning، أي طلب دفع. تتيح المبادلة العادية قفل بيتكوين على السلسلة وفق شروط متفق عليها، وتدفع الخدمة الفاتورة في المقابل. وإذا أرادت آنا نقل رصيد Lightning إلى عنوان على السلسلة، فإنها تحتاج إلى الاتجاه المعاكس: Reverse Submarine Swap، مثل Loop Out. ولا يلزم إغلاق قنوات الدفع الخاصة بها. لكن المبادلة لا تُنشئ مالًا، وما زالت دفعة Lightning تحتاج إلى مسار متاح. [1] [4]

تخيّل سرًا يمكن التحقق من بصمته الرقمية، لكن استنتاجه من البصمة غير ممكن عمليًا. تسمّى القيمة السرية هنا preimage، وبصمتها الرقمية هي hash، أي هاش يُحسب باستخدام SHA256. تجمع المدفوعات المشروطة HTLC بين البصمة ومهلة زمنية. في المبادلة العكسية، ينشئ تطبيق آنا السر. تُبقي الخدمة دفعتها عبر Lightning معلّقة وتقفل البيتكوين المقابل على السلسلة. وعندما تحصل آنا على الأموال بعملية claim، تكشف السر على السلسلة أو تقدمه إلى الخدمة خلال التعاون بينهما. تستطيع الخدمة حينئذ تسوية الدفعة المرتبطة. الانتظار لا يعني أن الدفع اكتمل. [1] [4]

إشعار الخدمة ليس هو الأموال في المحفظة المقصودة. توضح Boltz أن حالة invoice.settled في المبادلة العكسية قد تظهر بعد تسليم preimage وتسوية فاتورة Lightning. ولا تتابع الخدمة ما إذا كان تطبيق آنا قد بث معاملة claim فعلًا. لذلك يجب التحقق من المخرج المقصود، أي الجزء المحدد من البيتكوين المخصص لمحفظتها، ومن تأكيدات الكتل اللازمة. الكتلة مجموعة معاملات تُضاف إلى سلسلة الكتل. وإدراج المعاملة في كتلة يمنحها التأكيد الأول؛ ثم تضيف كل كتلة لاحقة تأكيدًا آخر. الحالة غير الواضحة ليست سببًا جيدًا لإرسال الدفعة نفسها فورًا مرة أخرى. [1] [2]

في المبادلة العادية، قد يكون بيتكوين آنا قد قُفل على السلسلة مع بقاء الفاتورة غير مدفوعة. عندئذ يتطلب الاسترداد، refund، معاملة يعدّها تطبيقها ويبثها. ومن دون تعاون الخدمة يجب انتظار timelock، الشرط الزمني المتفق عليه. أما دفعة Lightning غير المسوّاة في الاتجاه المعاكس، فقد تُلغى HTLC المعلّقة ويُحرر الرصيد من دون معاملة refund على السلسلة من آنا. لكن هذا لا يعني أن دفعة سُوّيت بالفعل ستعود تلقائيًا بعد كشف preimage. الاتجاه والمرحلة الحالية هما ما يحدد الإجراء. [1] [3]

تقارن آنا ما ترسله بما يصل فعلًا. قد يشمل الفرق رسوم الخدمة وتوجيه Lightning ومعاملات السلسلة. ويمكن أن تضيف المبادلة العادية الفاشلة رسوم معاملة الاسترداد. والوقت مهم أيضًا: نشر claim قد يكشف preimage قبل تأكيده في كتلة. تشير وثائق Loop إلى أن العميل قد يرفع، قرب timeout، رسوم sweep، أي معاملة جمع الأموال، فوق الحد الأصلي. لذلك لا يعد الارتباط التشفيري بمبادلة فورية أو مجانية أو خالية من المخاطر. [5] [6]

قد لا تعيد كلمات الاسترداد لمحفظة أخرى مبادلة قيد التنفيذ. وبحسب التطبيق، يلزم مفتاح refund أو rescue key وبيانات المبادلة نفسها، بما فيها المخرج المقفل والمهلة. تشتق Boltz Swap Restore المفاتيح من نسختها الاحتياطية وتبحث عن المبادلات المرتبطة. ويستخدم البحث xpub، المفتاح العام الموسّع: قد يكشف السجل، لكنه لا يوقّع ولا ينفق بمفرده. المفتاح الخاص قيمة سرية يستخدمها التطبيق لتوقيع معاملة وفق الشروط المعنية. وتبقى هذه المفاتيح في الجهاز. وينبغي أن تعرف ما الذي تعيده النسخة وأين تُحفظ قبل إرسال الأموال. [7] [3]

لا يُفترض أن يحسب المستخدم الشروط التشفيرية يدويًا، لكن يجب أن يتحقق منها التطبيق. لا تكفي الثقة بعنوان أعادته API، واجهة تبادل البيانات بين البرامج. يتحقق العميل من الشبكة والمبالغ والرسوم وhash والمفاتيح والمواعيد. ويجب أيضًا التحقق من السكربت، أي قواعد الإنفاق، أو شجرة هذه القواعد في Taproot، والعنوان المشتق منها. لا بد أن تطابق فاتورة Lightning البصمة والمبلغ المتفق عليهما. الآلية الصحيحة لا تنقذ برنامجًا يرسل الأموال إلى مكان آخر. [2]

تتيح Taproot للطرفين استخدام MuSig2 لإنتاج توقيع مشترك. قد يكون مسار key-path أقل تكلفة، ولا يحتاج إلى كشف شروط المبادلة علنًا. لكن التطبيق يحتاج أيضًا إلى script-path، الذي يستخدم تلك الشروط مباشرة إذا لم يتعاون الشريك: لعملية claim أو refund بحسب الاتجاه. إذا فشلت مبادلة عادية، فقد يعيد refund بتوقيع الطرفين الأموال في وقت أبكر. أما إذا أرادت آنا استردادها من دون تعاون الخدمة، فعليها الانتظار حتى يسمح timelock المتفق عليه بالاسترداد. كما أن تقليل البيانات الظاهرة على السلسلة لا يجعل المبادلة مجهولة أمام الخدمة التي رتبتها. [3] [4]