إنشاء نموذج أولي لتبادل البيتكوين مع "حمامات مظلمة" خاصة

• لم يتم نشر أو تدقيق كود النموذج الأولي بشكل مستقل بعد.
• يتم مطابقة الأوامر مباشرة بين المستخدمين من خلال هويات Nostr.

قدم مطور يُعرف باسم ian (@januszg_ على X) في 21 يوليو 2026، نموذجًا أوليًا لتبادل البيتكوين (BTC) مصمم للعمل كـ "حمام مظلم": سوق حيث تبقى المبالغ وعناوين المشاركين مخفية طوال العملية.

الهدف هو نقل البيتكوين من شخص إلى آخر دون ترك أثر على الشبكة، وفي نفس الوقت، دون أن تضطر أي من الطرفين (المشتري والبائع) إلى الثقة بشكل أعمى في الآخر.

لتحقيق ذلك، يتم دمج قطعتين تعملان بالتوازي وتتصلان من خلال هاش. من جانب البيتكوين، يستخدم النموذج الأولي statechains --- تقنية تسمح بإعادة تعيين مفتاح الإنفاق لــ UTXO دون الحاجة إلى معاملة على السلسلة --- ويعتمد، وفقًا للمؤلف، على بروتوكول Latch من Mercury Layer.

يقوم البائع بقفل موقعه داخل أمر، وينتج هذا الأمر هاش فريد، يعمل كخيط موصل لكل التبادل. نفس هذا الهاش هو الذي يدخل في اللعبة من الجانب الآخر من النظام: شبكة stablecoins.

من جانبه، يقوم المشتري بإيداع stablecoins الخاصة به (أو "أي عملة مشفرة أخرى غير موثوقة"، وفقًا لكلمات المؤلف نفسه) في عقد ضمان داخل شبكة بدوائر إثبات المعرفة الصفرية (zk)، وهي طريقة تشفيرية تسمح لطرف (المختبر) بإثبات لطرف آخر (المحقق) أن ادعاءً ما صحيح، دون الكشف عن أي معلومات إضافية حول الادعاء نفسه.

هذا العقد يحرر الأموال فقط إذا كشف شخص ما عن المفتاح الذي يتوافق مع الهاش الناتج عن أمر البائع، أو يعيدها تلقائيًا إلى المشتري إذا انقضت فترة محددة دون حدوث ذلك.

هنا يدخل العنصر الثالث في التصميم: موقع مشترك لا يشارك في التفاوض ولا يوقع أي شيء بمبادرة خاصة، بل يعمل فقط عندما يشير إليه الطرفان.

بمجرد أن يتحقق البائع من أن stablecoins تم إيداعها في العقد، يصرح للموقع المشترك بإكمال نقل البيتكوين؛ يقوم المشتري بنفس الشيء من الجانب الآخر.

مع كلا التأكيدين، يقوم الموقع المشترك بإعادة تعيين مفتاح الإنفاق للـ statechain إلى المشتري ويمسح النسخة التي كان يشاركها مع البائع.

فقط بعد هذا المسح يتم الكشف عن المفتاح الذي يسمح للبائع بالمطالبة بـ stablecoins. هنا يتم إكمال التبادل.

تترك هذه الخطوة الأخيرة شرط ثقة يعترف به المؤلف نفسه: يجب على المشتري أن يثق في أن الموقع المشترك قد حذف مفتاحه بالفعل بمجرد انتهاء العملية.

كل هذه الآلية للتبادل تحل مشكلة نقل الأصول دون أثر، لكنها لا تقول شيئًا بعد عن كيفية اتفاق شخصين على عملية. لهذا، بنى المطور فوق ذلك بروتوكول تسعير (RFQ) يعتمد على هويات Nostr.

كل مستخدم ينشئ هوية (npub) وينشر أوامر شراء أو بيع تظهر فقط تلك الهوية ومبلغ الأمر، دون الكشف عن عنوان البيتكوين الخاص به أو أي بيانات شخصية أخرى.

من المهم الإشارة إلى أنه، على عكس المبالغ والعناوين، فإن npub للمستخدم يبقى مرئيًا لبقية المشاركين في دفتر الأوامر: ما يخفيه التصميم هو عنوان البيتكوين والمعلومات الشخصية، وليس الهوية المستعارة في Nostr.

عندما يجد شخص ما عرضًا يناسبه، يرسل تسعيرة مشفرة بالمبلغ والسعر الدقيق، التي لا يمكن قراءتها إلا من قبل الطرف الآخر في تلك العملية المحددة.

النتيجة، وفقًا لوصف المؤلف، هي أنه من جانب البيتكوين لا توجد أي معاملة على السلسلة، بينما من جانب شبكة zk، الشيء الوحيد الذي يبقى في العلن هو الهاشات للمدخلات والمخرجات، دون أن يمكن تحديد حتى ما هو الأصل الذي تم تبادله.

وصف ian التصميم، في تقييمه الشخصي، بأنه يحافظ بشكل كبير على الخصوصية وأعلن أنه سيعمل على إصدارات أكثر تحسينًا من البروتوكول ويخطط لنشر الكود في المستقبل، دون تحديد تاريخ.

إخلاء مسؤولية: يُقدَّم هذا المحتوى لأغراض الترويج العام والمعلومات فقط، ولا يُعدّ نصيحة مالية أو استثمارية أو قانونية أو ضريبية. لا تُعتبر أي أحداث أو مكافآت أو فعاليات عبر الإنترنت أو معلومات ذات صلة مذكورة هنا توصيةً أو دعوةً لشراء أو بيع أو تداول أو التعامل بأي شكل من الأشكال في أي أصول مشفرة أو استخدام أي خدمات. الأصول المشفرة شديدة التقلب وقد تؤدي إلى الخسارة. قد لا تتوفر خدمات WEEX وفعالياتها عبر الإنترنت في جميع المناطق، وتخضع للقوانين واللوائح وشروط الأهلية المعمول بها. أنت مسؤول عن ضمان توافق استخدامك لخدمات WEEX مع القوانين المحلية، وعن تقييم المخاطر بعناية قبل المشاركة في أي أنشطة متعلقة بالعملات المشفرة.