Crypto Bounty Hunter-1

这几天圈里最扎眼的新闻，恐怕是 ColdCard 硬件钱包被掏空这件事。一个五年前埋下的编译开关，悄悄关掉了硬件随机数发生器，种子直接退化成一个几乎能被预测的伪随机数，上亿美元比特币被一锅端。

看完我只有一句感慨：随机一旦能被提前算出来，就不再随机了。
这让我想起 @Dusk 在共识里反复较真的一个环节：怎么选下一个出块的人？

你可能会问，这事能有多难？要公平，随机结果得人人能验证；要安全，又得没人能提前猜到。这俩要求撞在一起，其实是拧巴的。Dusk 用的确定性抽签，简称 DS，想同时要这两样。

它没搞什么花哨的随机源，#dusk 就是把有资格的质押者排成一队，用当前这轮的“分数”挨个过一遍，谁权重够谁中签。分数怎么来？用 SHA3 把上一区块的种子、轮次、步骤一起哈希出来，结果唯一、可复现，谁都能自己重算核对一遍。

这里头的门道，全在“种子”上。每个新区块，出块者都要拿自己的签名在上一区块种子上再签一次，作为下一轮种子。这就像摇号机——规则公开、人人可复核，可下一期摇出谁，谁也没法提前知道。

$DUSK 在这里就是抽签的权重筹码：质押越多，权重越高，被抽中的概率越大；但每中一次权重减一，防止大户包圆委员会。

我琢磨着，这设计妙就妙在，它没把“随机”交给中心化摇号机，而是用公开可验的规则加上不可预测的种子，把公平和安全焊在一起。当然，前提是种子真不可预测、质押真分散，这些还得看后续数据。DUSK 这个币，功课得自己做，别只听我这一嘴。

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

في سلسلة الكتل، يسمّون ذلك “النهائية”، ويقصدون الفترة الفاصلة بين اللحظة التي تبدو فيها معاملة ما “نجحت” وبين لحظة أن تصبح “مُثبتة رسميًا على الورق” ولا يمكن التراجع عنها.

خلال الفترة الأخيرة، اطلعت على مشروع @Dusk . فهو يستخدم آلية إجماع تُسمّى Succinct Attestation، باختصار SA. هدفه ضغط هذه الفجوة إلى مستوى الثواني. فبماذا يمكنه أن يكون سريعًا؟ ليس عبر جعل الجميع ينضم معًا في نفس الوقت، بل عبر اختيار عدد صغير جدًا من أصحاب المصلحة/المُراهنين بشكل عشوائي في كل مرة لتشكيل لجنة. تمر هذه المجموعة بسرعة عبر خطوات «اقتراح، تحقق، اعتماد»، ثم يتم استخدام توقيعات BLS المجمّعة لتلخيص تصويت الجميع في “إثبات” واحد صغير.

هذا الإثبات يُسمّى attestation، ومعناها الحرفي “إثبات”. فهو يضغط فكرة: «وافق عليه عدد كافٍ من الناس» إلى مستند خفيف يمكن لأي شخص التحقق منه بسرعة. لأن اللجنة صغيرة، والإثبات صغير، والتحقق سريع—ترتفع السرعة تلقائيًا. #dusk

أعتقد أن الجزء الذكي في هذا التصميم هو أنه لم يجعـل الجميع يجتمعون واحدًا تلو الآخر ليُهدروا الوقت في نقاشات بطيئة؛ بل استبدل ذلك بـ«لجنة صغيرة عشوائية + إثبات مُجمّع واحد» لتحقيق السرعة. بالطبع، شرط الأمان بالنسبة للتعيين العشوائي واللجنة يجب أن يكون مقنعًا أيضًا؛ وحتى لو كان سريعًا، ما يزال ينبغي التأكد أولًا من أنه آمن ومستقر. إن هذه العملة $DUSK يحتاج إجراء البحث عنها بنفسك؛ لا تكتفِ بمجرد الكلام الذي أقولُه لك.

من فترة قريبة انتقلت إلى مكان جديد، فوجدتُ كومة من الصور القديمة. أردتُ التبسيط، فالتقطتُ الصور واحدةً تلو الأخرى بهاتفي وحفظتها في الألبوم، وكنتُ أظن أن هذا يكفي لتحويلها إلى صيغة رقمية. لكن لاحقًا اكتشفتُ أن «الصور الإلكترونية» هذه لا تستطيع فعل شيء سوى العرض—لا يمكن تكبيرها أو تعديلها، ولا يمكن إرسالها بسهولة. اتضح أن التصوير لم يكن سوى تغليف الأشياء القديمة بطبقة؛ ولم يجعلها حقًا شيئًا مولودًا رقميا.

ثم لاحقًا صادفتُ مشروع @Dusk ، ولاحظتُ أنه في موضوع الأصول الواقعية (RWA) يقسم المسار إلى نوعين، بشكل يشبه الفرق بين التقاط الصور والتحديث/التحويل إلى رقمية أصلية.

إحدى الطرق هي «توريق» الأصول (tokenization)، وبصراحة يعني ذلك «التصوير». فمثلًا العقارات، والسندات، وحصص الصناديق—هذه الأصول ما زالت موجودة أصلًا في الأنظمة التقليدية؛ وعلى السلسلة يتم إصدار توكن مطابق لها فقط، كأنه مرآة. أما مراحل التوثيق الرسمي (تأكيد الملكية/التحقق)، والتصفية، وتوزيع الأرباح—فلا تزال تتطلب العودة إلى العمل خارج السلسلة والقيام به تدريجيًا.

والطريقة الثانية هي «الإصدار الأصلي» (native issuance)، وهو ما يعادل «التحويل إلى رقمية مباشرة». الأصول منذ يوم ميلادها تقع على السلسلة؛ إصدارها وتسجيلها ونقلها ودفع العائد عليها واستردادها—قدر الإمكان—يتم إنجاز معظمها على السلسلة. كلما طال السلسلة، زاد ما يمكن للسلسلة أن تتولى إدارته، وبالتالي تقلّ أيضًا الحلقات/الوسائط. مثلًا يمكن أن يتم دفع الفوائد وتوزيع الأرباح تلقائيًا وفق الحصص على السلسلة، دون الحاجة إلى انتظار جهة الحفظ لتطابق الحسابات دفعةً تلو الأخرى. إن #dusk يهدف إلى توفير البنية التحتية التي تحمل مسار الإصدار الأصلي هذا، طبعًا بشرط أن تمتلك المؤسسة وأماكن التداول التراخيص وإعدادات المنتج المناسبة.

تأملتُ الأمر: ما يبدو عليه توريق الأصول هو طريق لا مفر منه على المدى القصير، لكنه على المدى الطويل أشبه بحل انتقالي. أما الإصدار الأصلي فهو النهاية (الحل النهائي)، لكنه ينقل مشاكل التنظيم والقانون والتصفية القديمة كلها دفعة واحدة إلى السلسلة، لذا تكون الصعوبة أكبر بطبيعة الحال. أنا متفائل بالاتجاه على المدى الطويل، لكن لا تتوقع أن يتحقق كل شيء فجأة على المدى القصير. أما العملة $DUSK —فعليك أن تقوم بالدراسة بنفسك، ولا تعتمد فقط على كلامي من طرف واحد.

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

مؤخرًا صادفت مشروع @Dusk ، واكتشفت أن ما ينوون فعله يقع بالضبط ضمن هذا النوع من القصة. في الورقة البيضاء يصرّون على تحقيق الخصوصية والامتثال وقابلية التوسع الثلاثة معًا. يبدو الأمر كأنهم يحاولون مجابهة مثلثًا مستحيلاً، لكنه فعلاً يلمس نقطة الخلل التي عجزت عنها السلاسل المالية التقليدية.

سجلات إيثيريوم وبيتكوين العامة شفافة بالفعل. لكن بمجرد نقل الأعمال المالية إلى السلسلة، تصبح مراكزك، وطرفك المقابل، وسير التحويلات كلها مكشوفة تحت شمس واضحة، وتتحول الأسرار التجارية عمليًا إلى عري تام. أما Zcash وMonero فهما يخفيا بشكل عميق، لكنهما يخفيا كثيرًا لدرجة أن قدرات التدقيق والامتثال لا تلحق بالركب؛ فتخاف المؤسسات من المخاطر، وبالتالي لا تُقبل على الاستخدام الحقيقي. في النهاية، يتوقف الجميع عند نقطة واحدة: إما الشفافية التي لا تترك أي سر، أو الخصوصية التي تصل إلى حد الانقطاع عن إمكانية التحقق. والفراغ بينهما هو بالضبط ما ينقص—حالة يمكن فيها إعطاء المعلومات للجهات الرقابية دون الحاجة إلى بثّها للعالم كله.

فكرة $DUSK ليست أن تجبرك على خيارين، بل أن تزوّد دفتر الأستاذ بمجموعة من الصلاحيات متعددة المستويات. الشخص العادي عندما ينظر يرى ضبابًا، بينما جهة التدقيق أو جهة التنظيم التي تمتلك المفاتيح يمكنها فتح الجزء الذي ينبغي أن يُفحص. وعلى مستوى التنفيذ، لم يكتفِ بالأمر نظريًا؛ بل وضع نموذجين للمعاملات: Moonlight للـحسابات الشفافة، وPhoenix للخصوصية. ومن يناسب أي نموذج يتركه لاختيار المستخدم. يسمّون ذلك “الخصوصية القابلة للبرمجة + الإفصاح الانتقائي”، وبصراحة: الخصوصية والشفافية كلاهما يُفعَّلان عند الحاجة.

#dusk هذه المنطق ألتهمه كثيرًا. جعلني للمرة الأولى أشعر أن الامتثال والخصوصية لا يلزمان بالضرورة أن يكونا في مواجهة مباشرة؛ بل أشبه بكونهما طرفين في الطريق نفسه. أليس هذا هو اللغز الذي كانت الصناعة المالية التقليدية تفتقده طوال الوقت؟ ومع ذلك، بصرف النظر عن مدى جمال الفكرة، لا بد أن نمرّ بواقع التطبيق. هل ستدفع المؤسسات التكلفة؟ وهل سيوافق المنظمون؟ وهل ستعمل فعلاً بسلاسة عند التشغيل؟ كل ذلك يحتاج إلى أن تختبره الأيام ببطء. وبالنسبة لعملة DUSK، لا تتصرف بحماس لمجرد شعار؛ ما زال عليك أن تقوم بالبحث بنفسك.

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

تتكرر في ورقة السيّدة/البياض (white paper) رقم @BabylonLabs_io كلمة واحدة مرارًا: "price oracle"، أي «أوراكل/مُتنبّئ الأسعار». في جدول المقارنة ضمن القسم 4، السطر الأول يقول: "كل الحلول تعتمد على أوراكل أسعار موثوق — وهو طلبٌ لا مفرّ منه للاقتراض مقابل الرهن". استخدمت الورقة كلمتين لوصفه: "trusted" و"unavoidable"؛ موثوق، ولا مفرّ منه. ثم تقفز إلى الفقرة التالية، كأنها اجتازت غرفة لا ترغب في البقاء فيها.

إن مشكلة الأوراكل ليست فقط أنه يمكن استهدافه — فهذا نقاش دار بالفعل بما يكفي. المشكلة الحقيقية في أنه «يلحم» معًا «الحقائق الموضوعية» و«الحكم البشري». عندما ينخفض سعر BTC إلى ما دون 50,000 دولار، يتم التصفية— يبدو ذلك شرطًا موضوعيًا يمكن التحقق منه، وينفَّذ بطريقة ميكانيكية. لكن عبارة «سعر BTC» نفسها هي حزمة كاملة من أحكام القيمة: أي بورصة؟ متوسط مُرجّح بالحجم أم مُرجّح بالزمن؟ هل نُدرج التقلب الضمني في سوق المشتقات؟ هل تُحسب انهيارات الفلاش؟ إن الأوراكل لا يقدّم حقيقة موضوعية، بل منتجًا من البيانات تمت معالجته بمنهجية معيّنة.

تنفيذ المعاملة مُسبقة التوقيع في الخزنة يتم تفعيله عند تحقق «شرط السعر»، لكنه لا يميّز ما إذا كان هذا السعر ناتجًا عن متوسط مُرجّح لــ 20 بورصة، أم عن اقتباس لحظي صادر من بورصة صغيرة جفّت سيولتها. يشير القسم 5 إلى أن «المُصفّي يراقب سعر التغذية وحالة الخزنة» — وفعل «المراقبة» ذاته يتضمن حكمًا. المُصفّي ليس آلة؛ فهو يختار أي مصدر بيانات يثق به ومتى يتصرف. حتى نظام مُصمّم ليكون «تنفيذًا ميكانيكيًا»، يبقى المنفّذ في الخطوة الأخيرة إنسانًا. #baby

$BABY في دور الحوكمة، ما يجب تعريفه حقًا ليس المعلمات التقنية، بل «حدود الحقيقة والحكم». قواعد اختيار الأوراكل، والتعامل مع الأسعار غير الاعتيادية، ونافذة المراجعة اليدوية بعد تفعيل التصفية— كلها عقبات صعبة على الحوكمة أن تعالجها. ينفّذ الكود التصفية، لكن الكود لا يعرف معنى «السعر المعقول». DYOR.

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

@BabylonLabs_io توجد في ورقة «البياض» جملة هادئة مستلقية هناك لا يكاد أحد يقرأها للمرة الثانية: «يرتبط كل صندوق (Vault) بـ UTXO واحد». المعنى التقني واضح جدًا—لم تدخل بيتكوينك إلى الحوض العام، بل تم حبسها داخل مخرجات معاملة يمكن تحديدها بدقة على دفتر حسابات بيتكوين. لكن المعنى الاقتصادي أعمق بكثير: هذا الصندوق هو أصل مشترك بينك وبين الطرف المقابل، إلا أن «إثبات الملكية» له على السلسلة حاسم لا لبس فيه—إما لم تُصرف بعد، أو تم صرفها. أمّا علاقات المشاركة المعقّدة بين الأطراف، فلا يمكن رؤيتها على السلسلة.

وهذا يخلق مشكلة. تشاجر Bob وLarry أثناء تشغيل الصندوق—ليس خلافًا خبيثًا يحتاج إلى تفعيل آلية تحدّي، بل احتكاك بسيط على مستوى النزاع المدني: Bob يريد سداد الدفعة مبكرًا، لكن Larry لا يوافق؛ Larry يريد تحويل المطالبة إلى طرف ثالث، لكن Bob لا يعترف بذلك الطرف المحال إليه. لا يتضمن ذلك الاحتيال، ولم تكن هذه السيناريوهات مُدمجة كمسارات بديلة في المعاملات المُوقَّعة مسبقًا، ولا توجد آلية مُصالحة على سلسلة بيتكوين. لا يمكن لهذين الطرفين إلا أن يتفاوضا سريًا. وإن لم تنجح المفاوضات؟ يصبح الصندوق قفصًا لا يمكن فتحه.#baby

$BABY في الحوكمة الموصوفة في الورقة البيضاء، على المدى البعيد يمكن بناء طبقة تنسيق «مرنة» هنا—مثل إدخال قوالب تحكيم مُعيارية، أو قائمة بيضاء لتحويل المطالبات، أو منح الصندوق فترة تشاور وتروٍ. لكن هذه أمور ليست عظامًا يمكن للخصوصية/التشفير أن «يمضغها»—إنها بناء مؤسسي. منح UTXO الصندوق إحكامًا ذريًا ونظيفًا وحاسمًا، لكنه في المقابل قطع أيضًا بحدّ واحد المساحة الرمادية الضرورية للأصول المشتركة.

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

هل سبق أن فقدت ولاعة السجائر التي تُستخدم مرة واحدة؟ ليس لأنها سُرقت، بل لأنك استخدمتها ثم تركتها أينما كان بطريق الخطأ. منذ يوم خُصِّصت من المصنع، كان قدرها أن تكفي لإشعال بضع عشرات من السجائر فقط، ثم تتحول إلى قطعة قمامة بلاستيكية. وفي عالم التشفير يوجد شيء من نوع “الاستخدام مرة واحدة” أيضًا، لكن الفرق أنه صُمِّم عمدًا ليكون كذلك.
@BabylonLabs_io عندما كان يشرح سير تحدّيٍ ما، أشار عرضًا إلى تفصيل يبدو تقنيًا بحتًا: على الطرف المُتحدّى تقديم “توقيع لامبورت” للرد. توقيع لامبورت هو أحد أقدم مخططات التوقيع الرقمية لما بعد التشفير في علم التشفير، لكنه يتمتع بطبع مميز جدًا—زوج مفاتيح يُستخدم مرة واحدة فقط. بعد توقيع مرة واحدة، تصبح المفاتيح غير صالحة، وتنعدم السلامة الأمنية عند إعادة الاستخدام إلى الصفر. الورقة البيضاء تستخدمه كأداة للتحقق في التحدّي، لكنها، دون أن تقصد، تضع عدادًا خفيًا داخل نظام الخزائن.

فماذا يعني ذلك؟ يعني أن كل مرة يُتَحدّى فيها Bob أو Larry، وكل مرة يُجبر فيها على تقديم ردّ/دعوى، يتم إتلاف مجموعة من مواد مفاتيح مخصصة للاستخدام لمرة واحدة فقط. هذه المفاتيح ليست تُنشأ بشكل مؤقت، بل تُحسب مُسبقًا وتُخزَّن عند إنشاء الخزينة. فإذا شارك شخص في عدة خزائن، أو إذا كانت الخزينة نفسها تُستهدف بتحديات متكررة وكأنها تُقلب رأسًا على عقب، سينفد مخزون مفاتيحه تدريجيًا. ماذا يحدث إذا استُهلك؟ الورقة البيضاء لا تقدم إجابة. هل تُجمَّد الخزينة؟ هل يتم إغلاقها قسرًا؟ أم يتم التحويل تلقائيًا إلى خطة بديلة؟ هذه ديْنٌ تقني يتم تجاوزه بصمت.

$BABY ، في المقابل، يمكن أن يُستفاد منه هنا. فلكل خزينة عدد محدد مسبقًا من مجموعات مفاتيح Lamport، وما هي خطة الطوارئ عند الاستنزاف، وهل يمكن في حالة الطوارئ إجبار حلّ القفل عبر التصويت على مستوى الحوكمة—كلها أسئلة سيُضطر طبقة الحوكمة في النهاية إلى الإجابة عنها. لكن المشكلة أن سرعة استهلاك توقيعات لامبورت تعتمد على مدى جنون التحديات الخبيثة، بينما لا يمكن التنبؤ أصلًا بتكرار هذه التحديات. خزينة قد يتم استهدافها والمضايقة عليها حتى الموت قد تستنزف كل مخزون مفاتيحها في غضون بضع ساعات. #baby

إن هشاشة أنظمة عدم الثقة أحيانًا لا تكمن في الشرايين الرئيسية، بل في أطراف إدارة الموارد. توقيع لامبورت هو واحد من تلك “الأطراف”—صغير الحجم لدرجة أنه لا يذكر عادة، وعندما يُستهلك بالفعل، يصبح الأمر كارثيًا. DYOR.

يُبدي عالم التشفير نوعًا من الولع الغامض بحرف «حوض»—أحواض السيولة، وأحواض الإقراض، وأحواض الرهن. وبعد أن تسمع ذلك طويلًا، من السهل أن يتولّد لديك وهمٌ بأن المال إذا أُلقِي في الحوض فسوف يذوب تلقائيًا في سائلٍ متجانس يمكن سكبه في أي مكان. لكن خزائن البيتكوين ليست أحواضًا؛ بل هي خزائن تأمين. فـ«حوض ماء» و«صف خزائن تأمين» شيآن مختلفان تمامًا.

@BabylonLabs_io عندما يشرح «الورق الأبيض» تصميم خزائن الإقراض، يتسلّل سطرٌ يسهل تجاوزه جدًا: «يتطلب إنشاء الخزينة توقيعًا مشتركًا من مُصفّين بعدد k-of-n». للوهلة الأولى يبدو مجرد معطى تقني، لكنه في الحقيقة يعرّف خلسةً الشكل المادي الكامل للنظام—ليس فمًا كبيرًا مليئًا بالسيولة، بل n خزائن تأمين مستقلة، وعلى كل خزانةٍ تُعلّق n أقفال، بحيث يكفي تجميع أي k منها لفتحها. وهذا يدفعك تلقائيًا للتفكير خطوة إضافية: هل الأقفال على الخزائن المختلفة مملوكة لنفس الدفعة من الأشخاص؟

إذا كانت نفس المجموعة من المُصفّين تدير جميع الخزائن، فجوهر النظام يظل «حوضًا»—حيث تتركّز مخاطر التصفية في أشخاصٍ بعينهم. أما إذا كانت كل خزانة تُدار بواسطة تركيبة مختلفة من المُصفّين، فكيف سيتناسق هؤلاء فيما بينهم؟ يضيف الورق الأبيض عبارة: «يمكن للمُساهمين الكبار أيضًا المشاركة في التوقيع»، لكنه لا يُجيب عن سؤال عملي أكثر إلحاحًا: عندما تُفعّل خزانةٌ شرط التصفية، من بين الـ k الذين يمسكون بالمفاتيح، من الذي سينفّذ فعليًا؟ هل الشخص الأول الذي يحصل على الفرصة يأخذ كل شيء لنفسه، أم يتم توزيع التنفيذ بنسبة؟ إن كان الأول، تتحول التصفية إلى لعبة سباق—الذين يتأخرون لن يحصلوا على أي «حصة»، ومع الوقت لن يبقى أحدٌ يريد المشاركة. وإن كان الثاني، فسيحتاج الأمر إلى قواعد توزيع: من يكتبها؟ وكيف يتم فرضها؟ #baby

$BABY وظيفة الحوكمة، في جوهرها، تحل عقدة التنسيق هذه. كيف يسجّل المُصفّون، وكيف تتم عملية التناوب، وكيف تُقسّم العوائد، وكيف نمنع سباق الانطلاق المبكر—كل ذلك ليس موجودًا في المعاملات المُوقَّعة مسبقًا الخاصة بالخزانة؛ بل مختبئ داخل معلمات الحوكمة. الخزانة تهتم فقط ببنية الأقفال الشكلية، أما من يدير المفاتيح، وكيف تُرتّب مواعيد العمل بين من يحملون المفاتيح—فهذه الأسئلة يقوم الورق الأبيض بتغليفها وضغطها بحرفين: «k-of-n».

اللامركزية لم تكن يومًا تعني كسر قفلٍ كبير إلى مجموعة أقفال صغيرة ثم التوقف عند ذلك. العائق الحقيقي هو: كيف يتم مواءمة القفل مع المفتاح. DYOR.

你有没有盯着自动售货机的出货口干等过？投币，按键，听见里头哐当一声闷响——然后，卡住了。货没掉下来，钱已经扣了。你拍机器、找客服、填工单，折腾半天不是心疼那几块钱，是不服气。流程跑了一半卡在中间状态，比根本没跑更让人窝火。

@BabylonLabs_io 白皮书把金库的快乐路径画得清清爽爽：存款、铸币、提款、销毁，首尾衔接，跟地铁线路图似的。可它没展开一个所有跨链系统都绕不开的幽灵——跨步确认失败。讲借款人把金库 UTXO 信息发给合约链，轻客户端验证通过后铸出 collBTC，描述是一步到位的、顺序的。但现实中这是两张异步网络的握手：比特币出块平均十分钟，合约链可能几秒一个块。信息到达的时间差里，金库的状态在两条链上是割裂的。

铸币交易甩出去了，比特币那边偏偏在这当口触发了一笔意外花费呢？轻客户端因为短暂分叉，同步到了一个错的区块头呢？这些不是攻击，是网络层面的正常喘气。可金库的预签名逻辑假设世界是铁板一块的——你锁了就是锁了，铸了就是铸了。中间那层灰蒙蒙的、悬而未决的、需要人肉判断的状态，全被白皮书压进了箭头与箭头之间的空白地带。#baby

$BABY 待在这里的位置，不是技术性的，是治理性的。当中间状态真的砸下来、系统没给你预备任何自动化处理路径的时候，谁来拍板仲裁？白皮书里的治理框架，说穿了就是给这些代码罩不住的例外留一道后门。可问题在于，治理响应是按天甚至按周算的，而链上状态的漂移是按秒跑的。等你这头投完票，那头黄花菜都凉透了。

这不是 Babylon 一家要面对的困局。所有想在异步网络上搭出同步逻辑的系统，都得跟这个幽灵同床共枕。白皮书不写它，不是因为它不存在，是因为它根本写不进白皮书里。DYOR。

هناك قواعد غير مكتوبة في الكازينو: إذا كنت تربح كثيرًا على التوالي، يحق للكازينو أن يطلب منك المغادرة. ليس لأنهم قبضوا عليك وأثبتوا أنك تلعب بالغش، بل لأنك أفسدت نموذج الاحتمالات. وهذا ما ذكّرني بكتاب الـ“بياض” @BabylonLabs_io : تصميمٌ شديد الدقة — “فشل التحدي، وإلغاء أهلية السحب المستقبلية”.

تشرح ورقة الـBabylon الـبيضاء بالتفصيل عملية تحدي BitVM3؛ الكلام فيها واضح إلى حد ما: إذا بادر Larry إلى تحدٍّ خبيث، وخلط الدوائر بحيث ينكشف الأمر، فسيأخذ Bob السر فورًا — لكنه لن يخسر فقط مبلغ التأمين، بل أيضًا “سيفقد الحق في السحب المستقبلي عبر التحديات”. هذه العبارة مدمجة بين كمٍّ من الوصف التقني، ولا تبدو بارزة، لكنها هي جدار الحمل الخفي الذي يحمل نظام اللعبة كله.

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

ومع ذلك، يطلّ على السطح نوعٌ جديد من المشاكل أيضًا: ماذا لو حدث سوء تقدير حسن النية؟ إذا أطلق المهاجم تحديًا بسبب تأخر الأوراكل، أو انحرافات في مزامنة البيانات، أو حتى لأنه ببساطة ضغط زرًا خاطئًا في آلة الحساب؛ تحدٍّ يبدو صادقًا لكنه تقنيًا “انقلب” — فهل يُستبعد نهائيًا أيضًا؟ لا تفرّق الورقة البيضاء بين “الخبث” و“سوء التقدير”. طبقة التنفيذ تنظر إلى النتيجة فقط. هذا يعني تحويل منطقة رمادية يملك القاضي فيها مساحة تقدير إلى مفتاح ثنائي بارد—يضربه بضربة واحدة.

#baby

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

في المحكمة يوجد دور يُسمّى “الشاهد الخبير” — لا يقف مع المدّعي ولا مع المدّعى عليه، لكن ما إن يتكلم حتى يميل ميزان الحكم معه. وفي عالم التشفير، يوجد أيضًا واحدٌ من هذا النوع، غير أن أغلب الناس لم يلقوا عليه نظرة جدّية. تعيد ورقةٌ بيضاء لفّها مرارًا وتكرارًا، لكنها لا تزال تُغلفه دائمًا بقشرة من المصطلحات التقنية، دون أن تكشف منطق القوة بداخله.

@BabylonLabs_io القسم الخامس من الورقة البيضاء يتحدث عن الاقتراض والإقراض، والقسم السادس عن العملات المستقرة، والقسم السابع عن العقود الدائمة. ثلاثة مشاهد لا علاقة بينها من حيث الظاهر، ومع ذلك تشترك كلها في جملة واحدة: “يلزم مُنبئ أسعار موثوق.” تدبّروا هذا الوصف — “موثوق”. كل هيكل “الخزنة” يصارع من أجل تقليل الثقة إلى أدنى حدّ: Bob لا يحتاج إلى الثقة بـ Larry، وLarry لا يحتاج إلى الثقة بـ Bob، والمُصفِّي مُكبَّل ببنية المراهنة، والمتحدّي مُحاط بقيود التأمين/الوديعة الاقتصادية. وحده المُنبئ للأسعار، تعترف به الورقة البيضاء مرة واحدة على أنه “لا مفرّ منه”، ثم تترك الكلام عند هذا الحد.

مهمة المُنبئ بسيطة إلى أبعد حد: يُخبر الخزنة كم تساوي BTC في الوقت الحالي. إذا اخترقت الأسعار خطّ التصفية، يتمّ تفعيل التصفية؛ وإذا عادت الأسعار ببطء إلى ما كانت عليه، يعود كل شيء كما كان. لكن هذا فعل “الإخبار” وحده — في كامل المنظومة — هو نقطة القوة الوحيدة التي لا يمكن حلّها بإثباتات المعرفة الصفرية أو بتشويش الدوائر. أي سعر يُطعمه المُنبئ إلى الخزنة، تنفّذ الخزنة بناءً عليه النتيجة حرفيًا. لا حاجة لأن يسرق مفاتيحك الخاصة؛ كل ما يحتاجه هو لحظة مصيرية واحدة، أن يعطي “سعرًا مصيريًا”: زيادة بمئة دولار أو نقصان بمئة دولار تكفي لتقرر ما إذا كانت بيتكوينك ستبقى مطمئنّة وآمنة، أم ستُسحب إلى مقصلة التصفية بقرار واحد حاسم. #baby

$BABY وفي موضع هذا “الثقب الأسود” من القوة، يشير القسم العاشر ضمنيًا — دون أن يُفصح — إلى: الحوكمة. أي من المُنبئات للأسعار نختار؟ من هو البديل؟ كم مدى تأخير تغذية السعر يُحسب شذوذًا؟ إن حدث الشذوذ، هل يتم إيقاف التصفية أم التحويل إلى مصدر بيانات احتياطي؟ كل ذلك لا يُكتب في كود الخزنة بشكل صلب، بل يُضمَّن في معاملات الحوكمة. من يملك زمام BABY إنما يحيط فجوة الثقة الوحيدة تلك بسياج من طبقات متعاقبة.

سقف أمان لنظام قائم على عدم الثقة، نهايته يَستقر على ذلك المكوّن الذي لا يثق به النظام أقلّ ما يمكن. المُنبئ للأسعار، هو ذلك المكوّن. مهما كان بناء الخزنة جميلًا، فهو في النهاية يعمل لخدمة المُنبئ. DYOR.

تُعدّ “وديعة الإيجار” شيئًا… عند تسليمها يكون كل شيء سلسًا، أمّا عند استردادها فتبدأ المتاعب. فغالبًا ما يستطيع المالك دائمًا إيجاد سبب لاقتطاع جزءٍ منك: تقشّرٌ في جدار، صنبورٌ مرتخٍ، أو شفاطٌ لم يُنظَّف جيدًا. تكون الوديعة بين يديه، وسلطة تفسير “لماذا” تتمركز في فمه. وهذا ما جعلني أتذكّر فجأة تفصيلًا عابرًا لكنه مُخيف للغاية في القسم 3 من الورقة البيضاء: “bond” الخزنة—وهو مبلغ الوديعة الذي يُقفل مسبقًا لمنع الغش—حيث لم يترك فريق المشروع سوى جملة واحدة: “سيتم استردادها بعد إغلاق الخزنة”.

“سيتم استردادها”. من الذي سيسترد؟ كيف يتم الاسترداد؟ وكم سيتم استرداده؟ هذه الأسئلة الثلاثة لم تتوسع الورقة البيضاء في شرحها، لكنها أصابت بالضبط أكثر الأعصاب هشاشة في نظام الخزنة.

لنعد إلى تصميم الآلية في القسم 3 من ورقة @BabylonLabs_io البيضاء: يدفع Bob وLarry كلٌ منهما مبلغًا على السلسلة كغرامة عند فشل التحدّي. النية الأصلية واضحة وبسيطة—كبح التحديات الخبيثة؛ إذا أثيرت المشكلات بشكل عشوائي وخسرت، ستدفع ثمنها. لكن ماذا عن السيناريو المعاكس؟ إذا التزم الطرفان ببنود العقد بشكل صحيح، وأغلقت الخزنة في وقتها بصورة طبيعية، فكيف تعود الوديعة إلى أصلها؟ هل ترتد تلقائيًا؟ أم يجب أن يوقّع الطرفان مرةً أخرى معًا؟ وإذا كان الخيار الأخير، فإن استرداد الوديعة نفسه يتحول إلى جولة تفاوض جديدة: قد يقوم أحدهما بتعمد التأخير في التوقيع لابتزاز تنازل الطرف الآخر عبر تكاليف الوقت. كانت الوديعة موجودة للقضاء على حالة المساومة، لتُنتج بدلًا من ذلك جولة مساومة جديدة عند الاسترداد.

$BABY يتموضع في هذا الزاوية الحرجة بشكل دقيق جدًا. يضع القسم 10 هذا ضمن “رمز الحوكمة”، بينما تكون “قاعدة استرداد الوديعة” في الوقت نفسه مثالًا نموذجيًا لمسألة حوكمة بامتياز—كم يُحدَّد مبلغ الوديعة؟ ما مدة المهلة عند الاسترداد؟ وهل توجد آلية إطلاق قسرية إذا لم يلتزم أحد الطرفين بالتوقيع؟ بمجرد أن تُشفَر هذه المعايير في الكود تصبح قوانين لا رجعة فيها، لكن قبل أن تُشفَر، كانت نتاج تصويت حاملي الرموز. لا تستطيع BABY ضبط تلك النزعات الصغيرة بين Bob وLarry، لكنها تُغلق حدود قواعد اللعبة. #baby

أكثر ما تخشاه أنظمة ما بعد انعدام الثقة ليس أن يكون هناك أشرار يسوّون الشر علنًا، بل أن يتم—ببطء—ضغط الأخيار في ثغرات القواعد حتى يتحولوا إلى سيئين. وفعل استرداد الوديعة بالذات هو تلك الثغرة. DYOR.

عند إطلاق الصواريخ، ليس الأكثر استهلاكًا للوقود هو “التحويم في الفضاء” على الإطلاق، بل تلك الثواني القليلة التي تُجبر فيها على الاندفاع من سطح الأرض للأعلى—الجاذبية فيها هي الأثقل، وكل غرام وزن لا بد أن يُستبدل بقوة دفع تُقاس بالأطنان. وهذا يذكّرني بركنٍ صامت شبه مهمل في “الورقة البيضاء”: مشكلة “التمهيد البارد” لنظام يَهدف إلى تقليل الثقة إلى أدنى حد.

@BabylonLabs_io تعترف الورقة البيضاء، في القسم 1 حرفيًا دون مواربة، بأن الجسور الحالية للبتكوين تحتاج إلى “مجلس موقّعين، ومجموعة مُشغّلين، ومجموعة تحدّيين” — بحيث تقيّد الأطراف الثلاثة بعضها بعضًا، ولا تتحرك الجسر إلا حينها. منطق خفض الثقة لدى “الخزنة” أكثر قسوة، إذ يَقطع الطريق على الطرفين الأولين ويترك فقط “التحدّيين”. لكن المشكلة هنا: عندما يبدأ النظام من الصفر، من الذي يخطو أولًا تلك الخطوة؟

القسم 3 يجيب بصراحة شديدة. BitVM3 يطلب من Bob وLarry أن يُنشئ كلٌ منهما للآخر دائرة تشويش بحجم 43GB—لكن شرط إنشاء الدائرة هو أن الطرفين يثق كلٌ منهما بالآخر مسبقًا بأنه سيتعاون لإنجاز الإعداد على نحو صحيح. عليك تبادل المفاتيح مع الطرف الخصم، والتحقق المتبادل من أن الدوائر صحيحة، والتوقيع المسبق المشترك للمعاملة. هذه الخطوة لا يمكن تجاوزها، وبالتالي لا يمكن بناء الخزنة أصلًا. بصراحة: إن بناء منظومة “لا تتطلب الثقة في أي أحد” يحتاج، في المقابل، إلى طقسٍ قصيرٍ ومكثفٍ من الثقة. #baby

هذا التناقض بحد ذاته ليس ثغرة، لكنه يصنع مشكلة اقتصادية صعبة: من الذي سيدفع تكلفة بدء التشغيل؟ المُشغّل يحرق وقت وحدة المعالجة المركزية لينتج الدوائر شغلًا شاقًا، والمُصفّي يَضطر إلى حجز ضمانات للمشاركة في التوقيع المسبق. كل ذلك—قبل أن يبدأ النظام البيئي بالعمل فعليًا—لن يجلب أي عائد نقدي مباشر. خطة الحوافز في الورقة البيضاء، القسم 10، $BABY ، في جوهرها هي ضخ “سرعة هروب” داخل مرحلة التمهيد البارد. تعويضات الرمز تُسَدّ فجوة الثقة من الصفر إلى واحد قسرًا—عندما لا يملك النظام دخلًا، تكون الرموز بمثابة محرك الجاذبية؛ وعندما يبدأ النظام في توليد دخلٍ لنفسه، تتحول آلية التدمير من وضع “المحرك” إلى مضخة شفط.

نظامٌ يَزعم التخلص من الثقة، لكنه عند ولادته يحتاج بدلًا من ذلك إلى حوافز مبكرة لدفع مجموعة من الناس إلى تحمّل تكلفة الثقة المؤقتة. هذا التناقض ليس مخجلًا؛ إنه ببساطة صادق. كل الشبكات اللامركزية تتعثر وتكبر على هذا النحو، مع أن عددًا قليلًا جدًا من الناس يرغب في كتابتها في الورقة البيضاء حرفيًا. DYOR.