BW_io

تموت معظم سلاسل الخصوصية لحظة أن يطرح المُنظِّم سؤالًا.

لقد شاهدت هذا النمط يتكرر مرات كافية لأميّزّه.

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

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

ولهذا يمكن لـ NPEX تشغيل الأوراق المالية المُمَثَّلة برموز على هذه السلسلة والبقاء ضمن اللوائح المالية الهولندية دون تعريض كل صفقة إلى السجلّ المفتوح.

بدأت أفكر أن معظم السلاسل تعتبر «الخصوصية» و«قابلية التدقيق» بمثابة مقايضة تخسر المال بسببها. تراهن Dusk أن المقايضة لم تكن حقيقية أصلًا—فقط لم تكن مُنفَّذة بعد.

هل يَحلّ الإفصاح الانتقائي فعلاً مشكلة الخصوصية مقابل الامتثال، أم أنه ينقل فقط من يَحصل على رؤية كل شيء؟

#dusk @Dusk $DUSK $PROM $PORTAL

كنت على وشك الاستسلام من إعادة تحميل/تحديث رصيدي مرتين قبل أن أفهم ما كنت أنتظرُه بالفعل.

الغسق لا يتعامل مع المعاملة المُجمَّرة كأنها لحظة واحدة. يتم إدراج المعاملة أولاً في كتلة L2 بواسطة المُسلسِل (sequencer)، ثم يقوم المُجمِّع (batcher) بنشر تلك البيانات مرةً أخرى إلى DuskDS، ولا تستقر عملية التحويل فعلياً إلا بعد أن يتم تثبيت الالتزامات بالحالة وإثباتات العيوب هناك.

وهذه هي النقطة التي غيّرت قراءتي لها: تقوم معظم تجميعات EVM بإجبارك على الانتظار خلال نافذة تحدٍّ تقارب سبعة أيام قبل أن تصبح عملية السحب نهائية حقاً، لأن شخصاً ما يجب أن يكون لديه وقت للاعتراض على حالة سيئة. أمّا DuskEVM فيسوي مباشرةً إلى DuskDS، بدون نافذة عيوب تمتد سبعة أيام. لذلك ليست الفجوة بين الإدراج والتسوية أياماً، بل شيئاً يمكنك أن تومض فيه وتفوتك. هذا خيار تصميمي حقيقي، وليس مجرد توصيلات.

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

أعجبني أن البروتوكول ما زال يحافظ على تمييز تلك الادعاءات حتى عندما تكون الفجوة بينهما صغيرة لدرجة يمكن تجاهلها.

فهل تقليص نافذة العيوب إلى شبه فورية يُعد ترقيةً حقيقية في المرونة مقارنةً بنموذج التجميع القياسي، أم أن إزالة الانتظار الطويل تزيل أيضاً الإشارة التي كانت تنبّه الناس إلى وجوب الحذر؟

#dusk @Dusk $DUSK $PENGU $TUT

لا توجد مؤقّت عدّ تنازلي. لا توجد عبارة: "المطالبة قبل أن تنتهي الصلاحية." وجدت مهمة creatorpad هناك، مفتوحة ومموّلة عبر شبكة تقوم بالفعل بتوجيه أموال حقيقية عبر مسارات مُنظّمة بدلًا من مجرد الوعد بأنها ستفعل ذلك يومًا ما.

أنا على ذلك لأن Dusk ليست سلسلة واحدة تتظاهر بأنها تؤدي ثلاث مهام. إنها حزمة: DuskDS يوفّر التسوية ويحافظ على الإجماع، وDuskVM يشغّل عقودًا تحافظ على الخصوصية مع إثباتات معرفة-صفرية، وDuskEVM يمنح مطوّري Solidity بيئة EVM مألوفة، وجسرٌ أصلي ينقل نفس توكن DUSK عبر جميع الأنظمة الثلاثة دون لفّه في شيء آخر.

Phoenix يحمي الأرصدة إلى ملاحظات لا يمكن لأحد قراءتها. Moonlight يجعلها شفافة للتدفقات التي يجب أن تكون قابلة للرصد. نفس البروتوكول، ونموذجان متعايشان.

لم يعد هذا الهيكل مجرّد نظرية بالنسبة لي؛ لقد عبرتُ خلاله بنفسي. NPEX، بورصة هولندية مرخّصة، نقلت مئات الملايين في الأوراق المالية المُرمّزة إلى ذلك. QuantozPay تُصدِر يوروًا رقميًا متوافقًا مع MiCA على نفس المسارات.

Chainlink يتولى الآن التسوية عبر السلاسل للأصول المُنظّمة التي تعيش هناك. أنا أستثمر في بنية تحتية تستخدمها المؤسسات بالفعل، وليس بنية تحتية تنتظر من يستخدمها.

تدفع المهمة ثمن ملاحظة أي جزء واحد من ذلك بوضوح وكتابته كما هو. لا حاجة للاستعجال. لم يكن الأمر ذاهبًا إلى أي مكان. أنا فقط وصلت إليه أولًا.

@Dusk #dusk $DUSK $PUMP $TUT

لقد نقلت DUSK إلى DuskEVM على افتراض أن هذا هو كل المطلوب.

الآن توجد الأموال، والمهمة اكتملت. بعد ذلك حاولت التفاعل مع عقد ولم يحدث شيء، لأن DUSK ليس مجرد أصل (asset) على DuskEVM، بل هو أيضًا رمز الغاز. إذا كان ما وصل إلى ذلك الجانب غير قابل للاستخدام للتنفيذ، فأنت تمتلك رصيدًا لا يمكنك فعليًا إنفاقه.

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

اتضح أنني لم أفعل ذلك. لقد عمل الجسر بشكل صحيح، لكنني لم أكن قد أخذت في الحسبان أن DUSK يؤدي دورًا مزدوجًا: أصل تسوية على جهة، وغاز على الجهة الأخرى—بنفس الرمز، لكن بمهمتين.

الطرح الكامل لـ Dusk هو أن التمويل المنظم يعمل على أدوات EVM قياسية، MetaMask، وHardhat، وما إلى ذلك. لا يصمد هذا الطرح إلا إذا كان الرمز الذي يؤدي الدورين يتصرف بالطريقة التي يتوقعها المطورون من أي سلسلة EVM أخرى بمجرد أن يصل.

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

@Dusk $DUSK #dusk $PROM $MAGMA

لقد دخلت إلى DuskEVM متوقعًا الشيء المعتاد: تؤكد المحفظة، تظهر الأموال، وتم كل شيء. وقد ظهرت بالفعل بسرعة، وهذا ما جعلني أنتبه. لأن «السرعة» ليست هي نفسها «التسوية»، والمحفظة لا ترسم لك هذا الخط حقًا.

يعمل DuskEVM كتجميعة (rollup) فوق DuskDS. يتم التقاط معاملتك بواسطة الـ sequencer وإدراجها في كتلة L2 تقريبًا فورًا—وهذه هي الجزء الذي تراه، والذي يجعلك تشعر بأنها لحظية.

لكن الإدراج ليس تسوية. ما زال على المُجمع (batcher) نشر تلك البيانات مرة أخرى إلى DuskDS، ولا بد أن تتم تثبيت التزامات الحالة (state commitments) هناك قبل أن تصبح نهائية فعلًا. مرحلتان مختلفتان، ضمانان مختلفان، وشاشة تأكيد واحدة لا تميّز بينهما.

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

يبدو الأمر كنوع الفجوة التي تكون غير مرئية حتى لا تكون كذلك في مرة واحدة.

@Dusk $DUSK #dusk $ONG $ACE

هناك ضريبة صامتة يدفعها كل مشغّل عقد: الانتظار بعد اكتمال الترحيل النهائي.

في أغلب السلاسل، يُملأ هذا الفارق بالانتظار، والترقّب، ومراقبة تكدّس التأكيدات مثل أكياس رملٍ أمام فيضانٍ قد لا يأتي. لم تُحسّن Dusk فترة الانتظار. بل أزالتها.

ولا يطلب إجماعها منك الانتظار حتى تتحول الاحتمالات إلى يقين؛ بل يمنحك نهائيةً حتميةً لحظيًا بمجرد استقرار الحالة، لأن البروتوكول كان قد استبعد بالفعل نتيجةً بديلة.

هذه ليست مجرد ميزة؛ إنها الفارق بين تشغيل بنية تحتية وتشغيل التزام.

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

عندما تُدخل NPEX أوراقًا ماليةً حقيقية عبر هذا المسار، فهي لا تختبر ميزةً، بل تختبر ما إذا كانت الإشاعة يمكن أن تصمد عند تماسها مع جهة تنظيمية. وحتى الآن، صمدت.

المشغّلون الذين يفهمون هذا الفرق، والذين يعتبرون التحقق من اللقطات وتوليد البراهين هو المنتج الحقيقي لا مجرد عبء صيانة، هم من يبنون شيئًا يتجاوز دورة الضجيج.

أما الآخرون، فما زالوا يكتفون بالأمل بأن توافق عقدتهم نفسها.

@Dusk $DUSK #dusk $HEMI $RE

كنت أفكر في الجزء من تشغيل عقدة Dusk الذي يتجاوزه معظم الناس: ماذا يحدث عندما تصل فعلاً طلبات إفصاح. لديك خياران للتعامل معها.

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

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

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

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

@Dusk $DUSK #dusk $ACE $ACM

لقد عملتُ مع بنية تحتية كافية لأعرف أن التكلفة الحقيقية ليست التوقف نفسه، بل ما الذي تفعله بعده.

عندما يتعطل عقدة Dusk أو تخرج عن المزامنة، فأنت أمام مسارين.

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

أنا أميل إلى المسار الثاني كل مرة، لأن الإنهاء الحتمي في Dusk يعني أن الحالة المُتحقَّق منها ليست تخمينًا؛ بل حقيقة مُستقرة اتفق عليها البروتوكول بالفعل.

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

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

إنها خطوة تشغيلية صغيرة، لكنها الفرق بين دقائق من التعطّل وساعاته.

@Dusk #dusk $DUSK $GPS $STAR

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

تقوم Zcash وMonero بتغليف كل شيء وقفل الجهات التنظيمية بالكامل، وهذا بالضبط هو السبب في أنني لم أرَ بنكًا أو جهة مرخّصة تتعامل معها على نطاق حقيقي.

يقلب Dusk هذا المنطق باستخدام Hedger، عبر استخدام براهين المعرفة الصفرية والإفصاح الانتقائي؛ بحيث تظل المعاملة غير شفافة للعامة مع بقائها قابلة للقراءة بالكامل لدى جهة تنظيمية تمتلك المفتاح الصحيح.

نتحدث هنا عن طبقة إجماع، Segregated Byzantine Agreement، التي بُنيت للجمهور نفسه، مع تفضيل الحسم الحتمي على الإنتاجية الخام؛ لأن التسوية الأمنية التي يمكن أن تُعكس ليست تسوية أمنية على الإطلاق.

أعتقد أن أوضح دليل على أن الأمر لم يكن نظريًا جاء عبر NPEX، وهي بورصة هولندية تحمل ترخيص MTF فعلي، استخدمت مسارات Dusk لنقل أوراق مالية تقليدية حقيقية على السلسلة بدلًا من غلافٍ اصطناعي يقوم مقام الأصل الحقيقي.

ثم أتاحت DuskEVM للبنية التحتية نفسها أن تتكلم Solidity، حتى لا يضطر البنّاؤون إلى التخلي عن أدواتهم الحالية فقط للوصول إلى طبقة تسوية متوافقة في الأسفل.

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

@Dusk #dusk $DUSK $PORTAL $QNTB

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

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

لفت انتباهي "داسك" بسبب ذلك.

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

المنظومة تتحقق من صحة البرهان دون أن تعرف أو تتعلم ما الذي يتضمنه البرهان. يتم تنفيذ الامتثال. وتبقى الاقتصاديات مختومة للجميع باستثناء الأطراف التي أختار تفويضها.

كان عليّ أن أقرأ هذا عدة مرات كي أصدق فعلًا ما كنت أراه.
هذه ليست خصوصية؛ بل سرّية قابلة للبرمجة، مع القدرة على تحديد الإفصاح على أساس كل حالة على حدة.

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

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

لم يتحقق هذا من قبل. هذا الإطار هو الأول الذي يوفّر التحقق المتزامن من الامتثال. لم يوجد ذلك في النظام المالي من قبل، لا في أي بلد. ثق بي، إن معظم النظام التنظيمي العالمي تم تطويره بعد حدوث ذلك؛ لأن الجميع اعتقد أن التحقق حدث رجعي.

أنا أنظر إلى التحقق الآن.

$DUSK @Dusk #dusk $HEMI $COW

أمس نشرتُ عن نموذج “الإفصاح الانتقائي” لدى Dusk. قضيتُ الليلة الماضية أفكّر فيما أخطأت فيه.

ليس التشفير. بل الصياغة.
وصفتُه بالبنية التحتية للخصوصية. هذا هو القراءة السطحية. ما الذي يقوم Dusk ببنائه فعليًا هو بنية تحتية للامتثال، تكون الخصوصية هي الحالة الافتراضية. تبدو الكلمتان متشابهتين. ليستا كذلك.

البنية التحتية للخصوصية تسأل كيف نحافظ على إخفاء المعاملات. بنية الامتثال تسأل كيف نجعل الإفصاح المُتحقق قابلًا للبرمجة. الأولى تنتج أدوات قد يحاربها المنظمون. الثانية تنتج أدوات قد يتبنّاها المنظمون.

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

هذا ليس تحسينًا تدريجيًا. بل هو إزالة طبقة كاملة من الاحتكاك المؤسسي التي تتطلب حاليًا فرقًا قانونية وأقسام امتثال وتأخيرات تسوية تُقاس بأيام.

الفجوة التي لا أستطيع سدّها: يجب على الجهات التنظيمية قبول التحقق من براهين ZK بوصفه مكافئًا قانونيًا لمسارات التدقيق التقليدية قبل أن يتوسع كل ذلك. الصلاحية التقنية وقبول التنظيم لديهما جداول زمنية مختلفة تمامًا. لقد أنهت هذه الفجوة بالفعل بنية تحتية جيدة.
مقتنعٌ أكثر بالمعمارية اليوم مما كنتُ عليه أمس.
وغير متأكد بالمقدار نفسه من التوقيت.
كلا الأمرين صحيحان في الوقت ذاته.

$DUSK @Dusk #dusk $ACE $VELVET

كل مؤسسة جادة تتعامل مع بنية تحتية بلوكتشين تواجه الجدار نفسه. السجلات العامة هي الميزة التي يحتفي بها التجزئة، وهي أيضًا سبب تردد المؤسسات. الشفافية الكاملة ليست حيادًا. بالنسبة لكيان مُنظَّم ينفّذ حجمًا ذا معنى، فإن السجل العام هو آلية إفصاح عن الالتزامات دون وجود زر إيقاف.

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

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

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

السؤال الذي لا أستطيع الإجابة عنه بعد: ما إذا كانت الهيئات التنظيمية الكبرى ستقبل تحقق إثباتات المعرفة الصفرية باعتباره مكافئًا قانونيًا للإفصاح التقليدي. التشفير سليم. الإطار القانوني غير محسوم بعد.

تلك الفجوة هي المكان الذي تعثرت فيه معظم البنية التحتية للبلوكشين المؤسسية بصمت من قبل.

$DUSK @Dusk #Dusk #dusk $EDEN $AKE

إنَّ الحتمية الاحتمالية رهانٌ على نزاهة البشر. أمّا الحتمية الموضوعية فهي رهانٌ على قدرة التجزئة—وقوة التجزئة لا تعيد التفاوض.

تقوم نقاط التحقق في بابلون (Babylon) بربط سلاسل المستهلك بالبيتكوين عبر توقيعات BLS متعددة مضمّنة في معاملات OP_RETURN—وكلٌّ منها يتّسع لـ 80 بايت. بعد التأكيد وعند بلوغ عمق checkpoint_finalization_timeout، يتطلّب تغيير السجلّ إعادة تنظيم السلسلة الكانونية للبيتكوين أولاً. وهذا يعني تجاوز أكثر من 800 إكساهاش من برهان العمل.

معظم السلاسل تبيع الحتمية الاحتمالية—ثق بأن عددًا كافيًا من المُدقِّقين سيظلّون أمناء. تستبدل بابلون ذلك بالحتمية الموضوعية: فالنقطة التحقق إمّا موجودة في سلسلة البيتكوين أو لا تكون. لا نقاش. وتُقاس كلفة العكس (الاسترجاع) بالقدرة الحسابية للتجزئة، لا بقرارات التصويت على الحوكمة.

تجزئات الكتل التقليدية عديمة الفائدة ضد الهجمات بعيدة المدى (long-range attacks). إنَّ نقاط التحقق متعددة التوقيع BLS في بابلون قابلة للتحقق من أي شخص، ما يثبت أن الحالة قد تمّ الالتزام بها من قِبل ما لا يقل عن ثلثي المُدقِّقين بالاستناد إلى إجمالي الحصة. وبمجرد تثبيت نقطة التحقق، فإنَّ إعادة كتابة بابلون تعني إعادة كتابة البيتكوين أولاً.

تؤكد مراجعات طرف ثالث: تُسعِّر بابلون تكلفة إعادة كتابة التاريخ في العملة الوحيدة التي لا يمكن طبعها. وقد قام البروتوكول بتأمين أكثر من 57,000 BTC دون جسور (bridges) أو أصول مُلتفّة (wrapped assets).

ما الذي أجلس معه: هل تُلغي الحتمية الموضوعية مخاطر الإجماع الاجتماعي، أم أنها فقط تنقل الثقة إلى من يتحكم في تقديم نقاط التحقق؟

@BabylonLabs_io #baby $BABY $HEI

لا يمكن لبيتكوين وحدها تطبيق قواعد الإِيداع (staking). لكن بابيلون يعالج ذلك عبر استخدام «نُصاب» (quorum). وبمجرد أن تنظر إلى ما الذي يتحكم فيه فعليًا هذا النُصاب، سترى أنه يفرض نوعًا مختلفًا تمامًا من الثقة عن تلك التي يتعامل معها سوق البروتوكول.

كنت أفترض سابقًا أن أمن بابيلون يَعيش بالكامل داخل التشفير، أي منطقًا ذاتي التنفيذ (self-executing) يعاقب على التوقيع المزدوج. ثم قرأت برنامج الـ staking نفسه، واكتشفت وجود نُصاب يقف تحت مسار سحب الأموال بالكامل.

كل معاملة «فك ارتباط مبكر» (early unbonding) في بابيلون تتطلب توقيعات من عتبة لجنة العهد (covenant committee)، وهي محددة بستة مفاتيح من أصل تسعة، قبل أن تتحرك BTC الخاصة بالمُراهن (staker). هذا ليس خيارًا احتياطيًا لسوء السلوك. بل هو المسار الافتراضي. يتيح لك انتهاء مهلة الـ timelock الخروج دون اللجنة. أما في أي وقت أبكر—وهو ما يحدث لمعظم عمليات السحب الواقعية—فيلزم وجود النُصاب لكي يوقّع المشاركون معًا.

هذه هي النقطة التي لم أكن قد فصلتها من قبل. الإيقاع/الخصم (slashing) يتم وفق حسابات لا يمكن لأحد إيقافها. أما الخروج المبكر العادي، فيتطلب موافقة أشخاص محددين بعينهم (ستة أشخاص) على التوقيع، في كل مرة.

وقد وصف باحثون مستقلون في مجال الأمان ذلك بوضوح في تدقيقهم لعمارة بابيلون: أن الامتثال لطرق إنفاق معينة يعتمد على توقيعات العتبة الخاصة بلجنة العهد خارج السلسلة (offchain). ليس الأمر بمثابة خط دفاع احتياطي. بل هو تبعية مدمجة في الحالة الأساسية.

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

@BabylonLabs_io #baby $BABY $CYS

التنويع يفترض الاستقلال. إعادة الرهن تفترض العكس. المخاطر المترابطة هي ما يحدث عندما تؤمّن جهة مزوّد واحدة خمس سلاسل في آنٍ واحد—تعرض مترابط لا يظهر في رقم العائد، بل يظهر فقط في حالات الفشل.

إليك ما تغيّر في قراءتي. إن مزوّد نهائية بيتكوين واحدة لا يؤمّن سلسلة واحدة. بل يؤمّن العديد، في الوقت ذاته، عبر كل شبكة «بيتكوين سوبر تشارجد» التي تختار الانضمام إلى تجمع المزوّد نفسه. وهذه هي الفكرة: رهان واحد على بيتكوين، ومعدّات عوائد متعددة، وبنية أمنية مشتركة.

لكن البنية المشتركة تعني فشلاً مشتركاً. إذا أخطأت جهة نهائية في الالتزام على إحدى شبكات BSN، فإن العقوبة/الخصم (slashing) سيطال كامل بيتكوين المرهون لديها، وليس فقط الجزء المخصّص لتلك السلسلة. يصبح كذب/عدم أمانة المزوّد على السلسلة A خسارة مترابطة لكل من يستثمرون ويعتمدون على ذلك المزوّد نفسه عبر السلاسل B و C، حتى لو لم يتعامل هؤلاء المستثمرون مباشرة مع السلسلة A.

لم يتحرك أي بيتكوين. ولم يختر أحد سلاسل أخرى. توجد هذه الارتباطات فقط لأن مجموع المزوّدين يتداخل.
ما لم يُنشر في أي مكان وجدته: مقدار تداخل مزوّدي النهائية فعلياً عبر شبكات BSN النشطة اليوم، أو ما إذا كان هذا التركّز مُتابَعاً على الإطلاق.

ما أنا مستقر عليه: هل تداخل المزوّدين هو كفاءة توسّعية، أم أنه نفس مشكلة الطرف المقابل المترابط التي تظهر دائماً في إعادة الرهن في النهاية، فقط مع ارتداء مصداقية بيتكوين بدل مصداقية إيثيريوم.

@BabylonLabs_io #BABY $BABY #baby $VIC

لا يختفي خطر الطرف المقابل لمجرد أن البروتوكول لامركزي. بايبيلون هي أحد أطراف المقابلة، موثقة وقابلة للتدقيق. أمّا الـLST الذي وجّه الـBTC لديك إلى هناك فهو طرف مقابل مختلف تمامًا — وبايلبيلون أخبرتك، في جملة واحدة، أنه ليس ضامن ذلك الطرف المقابل.

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

يذكر منشور المرحلة الأولى لبايبيلون بوضوح أن بروتوكولات المشتقات الخاصة بالتخزين السائل الرئيسية للسيولة (Major Liquid Staking Derivative) — Bedrock وSolv Protocol وLorenzo Protocol وpumpBTC وpStake وChakra — لعبت دورًا حاسمًا في توفير خيارات تخزين سهل الوصول إليها. وفي نفس الوثائق، تذكر بايبيلون الأمر بوضوح كذلك: فهي لا تقوم بمراجعة أو اعتماد الـLSTs أو كود الـLST أو أي منصة مشاركة أخرى.

هذه هي النقطة التي لم أكن قد فصلتها من قبل.

حصة معتبرة من الـBTC التي ملأت حدود بايبيلون وصلت مُغلّفة داخل منتجات LST من طرف ثالث، وليست مُخزّنة مباشرةً بواسطة حامل النهاية. تُسمّي بايبيلون تلك البروتوكولات كعناصر مركزية في سهولة الوصول، ثم تَنسحب من ذلك بالتصريح بأنها لا تراجع كودها. وهذا يعني أن المُخزّن الذي يختار "الطريق السهل" عبر LST إنما يثق بنظامين منفصلين: تصميم بروتوكول بايبيلون، موثق وقابل للتدقيق، وأيّ LST قام بتغليف الـBTC الخاص به كي يصل إلى هناك، وهو ما تقول بايبيلون إنها لم تراجعه.

ملء الحدود في غضون ساعات لا يفعل سوى أن يزيد الأمر وضوحًا: السرعة كافأت من لديه أفضل "مسارات" جاهزة للدخول، وبالنسبة لكثيرين كان ذلك يعني التوجيه عبر أحد هذه البروتوكولات الستة بدلًا من التخزين بشكل أصلي.

ما لم يُعالج هو مقدار الـTVL في المرحلة الأولى الذي وصل عبر LSTs مقابل التخزين الأصلي — فبايبيلون يبلّغ إجمالي كمية الـBTC المحتجزة، لا المسار الذي اتُّبع.

ما أنا واقف عليه: تسمية شركاء LST مع التنصل من مسؤولية المراجعة كتشفاف مسؤول — أو طريقة تسمح لأرقام التبنّي بأن تتضمن مخاطرة لم تكن بايبيلون قد تحمّلت مسؤوليتها أو تعهدت بها.

@BabylonLabs_io #BABY $BABY #baby $TAKE $BLESS

يعتقد معظم الناس أن أمان السلاسل المتقاطعة يعني الجسور والرموز الملتفة. هذا الافتراض خاطئ.

قضيت بعد ظهرٍ كاملًا في تتبّع بنية التحقق (checkpointing) لدى Babylon لفهم السبب. إن التحققات التقليدية مثل تجزئة الكتل ليست مفيدة ضد هجمات الامتداد طويل المدى — فهي لا تدعم الكشف لأن المدققين الخبثاء يمكنهم توليد سلاسل (forks) خاصة. حل Babylon أكثر أناقة مما كنت أتوقع.

إليك التفاصيل التقنية التي تعيد صياغة كل شيء. تقوم Babylon بالتحقق على Bitcoin عبر آلية “epoching” تُعطِّل تدوير مجموعة المدققين داخل كل حقبة. يقوم المدققون بتسجيل مفاتيح BLS العامة عند الاشتراك، وبالنسبة لكل كتلة تحتاج إلى تحقق، يستخدم كل مدقق مفتاحه الخاص بتقنية BLS لتوقيع تجزئة الالتزام (commit hash). تتجمع التواقيع من ما لا يقل عن ثلث المدققين في توقيع BLS متعدد واحد بحجم 48 بايتًا. ثم يَرِد هذا التوقيع، بالإضافة إلى بيانات وصفية (metadata)، داخل معاملة Bitcoin عبر OP_RETURN — وهي مخرَج خاص أقصى حجمه 80 بايتًا لا يُضخِّم مجموعة UTXO. شبكة “اليقظة” (vigilante network)، وهي مُرسِل مستقل يمكن لأي شخص تشغيله، تقوم بإرسال هذه التحققات إلى Bitcoin.

الجانب الاقتصادي هو ما جذب انتباهي. بمجرد التحقق، فإن إعادة كتابة تاريخ Babylon تعني أولًا إعادة كتابة تاريخ Bitcoin. لا يسيطر أي فاعل واحد على قوة تجزئة كافية للتغلب على 800 إكساهاش من إثبات العمل. ليست التكلفة مجرد باهظة. بل إنها وجودية.

تؤمّن معظم السلاسل تاريخها عبر الإجماع الاجتماعي — بأن يتفق المجتمع على أي fork هو الحقيقي. تستبدل Babylon ذلك بإثبات موضوعي مرتبط بأغلى طابع زمني (timestamp) على الأرض. ليس قرارًا اجتماعيًا. بل قرارًا تشفيريًا.

كل سلسلة أخرى تطلب منك الثقة في ذاكرة المجتمع. تطلب Babylon منك الثقة بالنهائية (finality) لدى Bitcoin. ونهائية Bitcoin لا تُعاد المساومة بشأنها.

@BabylonLabs_io #baby $BABY $HEI $BTC

كنت أظن أن نماذج الأمان ثنائية: إما أن يكون النظام آمنًا، أو لا يكون.

ثم تتبعت المسار القاطع الذي سلكته بابل ضد سيناريو لم يحذرني منه أحد: مُتحقق لا يقوم أبدًا بالتوقيع المزدوج، ولا يُصدر تناقضات، ومع ذلك يتم تجريده من الضمانات (slashed). ليس لأنهم كانوا غير أمناء.

بل لأن الشعبة (fork) التي قاموا بتثبيتها (finalized) خسرت، فأصبحت توقيعاتهم دليلًا على جريمة لم ينووا ارتكابها.

إليك التفصيل التقني الذي كدت أفوته. بروتوكول بابل لتوقيت بيتكوين (Bitcoin Timestamping Protocol) يُثبّت (checkpoints) العصور النهائية (finalized epochs) على بيتكوين.

إذا أعادت سلسلة لاحقة تنظيم (reorganizes) السلسلة خلف نقطة التحقق تلك، تصبح توقيعات مزوّد النهائية (finality provider) على الشعبة الخاسرة غير قابلة للتمييز تشفيريًا عن عدم الأمانة.

مسار التجريد من الضمانات لا ينطلق لأن المُتحقق سلك سلوكًا خاطئًا. بل لأنهم راهنوا على السلسلة الخاطئة.

أجريت المحاكاة مرتين. التواقيع نفسها. السلوك الصادق نفسه. شعبة فازت، وأخرى خسرت. في كلتا الحالتين، تصرف المُتحقق بحسن نية. في أحد الخطّين الزمنيّين، احتفظوا برصيدهم المربوط (bonded stake). وفي الخطّ الآخر، خسروا كل شيء. نفس الفعل. نتائج مختلفة. هذه ليست مساءلة. إنها مواءمة عبر الإبادة.

معظم السلاسل تعاقب الخداع المتعمَّد. بابل تعاقب الجانب الخاسر من الشعبة، بغضّ النظر عن النية. لا تسأل الجوانب الاقتصادية لماذا وقّعت. هي تسأل فقط: لأي سلسلة وقّعت.

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

@BabylonLabs_io #baby $BABY $AA $BTC

الصمت داخل قبو بابل ليس ميزة. إنه أعلى شيء سمعته على الإطلاق.

قضيت أربع ساعات في تتبّع آلية فكّ الارتباط مقابل وتيرة سعر محاكية على شكل ذيل (wick). أودِع مرة واحدة، فيُقفل الـBTC الخاص بك خلف مسار إنفاق مُوقَّع مسبقًا فوّضته قبل أن تعرف ما الذي سيفعله السوق غدًا. هذا المسار يقبع في mempool، منتظرًا أن يتجاوز سعر الأوراكل العتبة.

إليك التفاصيل التقنية التي كدت أفلت منها. يستخدم عقد قبو بابل لغة Bitcoin Script لفرض شروط الإنفاق. يحدد هيكل العهد (covenant) بدقة مخرجات المعاملات التي يمكن إنفاقها وتحت أي ظروف. يوجد مسار لفك الارتباط للسحوبات المبكرة، ويوجد مسار للتقميط (slashing) ليقوم به أعضاء مجموعة المدققين بالمطالبة بعملة الـBTC الخاصة بك إذا أبلغ الأوراكل عن سعر سيئ. كلا المسارين مُوقَّع مسبقًا. وكلاهما غير قابل للتغيير (immutable). ينفّذ القبو تمامًا ما فوّضته.

فترة فك الارتباط هي مهلة فعلية (timelock) داخل Bitcoin Script. إذا انتظرت المدة كاملة، يعود الـBTC الخاص بك بشكل نظيف. لكن إذا سحبت مبكرًا، فإن مسار التقميط يُفعَّل تمامًا كما وقّعت مسبقًا. هذا هو التصميم. لا فترة سماح. لا "هل أنت متأكد." لا يتحقق البروتوكول من حالتك العاطفية. إنه لا يفحص إلا أن التوقيع يطابق.

هذه هي النقطة التي لم أفصلها من قبل. بقيت الوصاية معي. لم تتحرك المفاتيح. لكنني كنت قد وقّعتُ بالفعل معاملة تُسلّم $BTC إلى مجموعة مدققين إذا أبلغ الأوراكل عن سعر سيئ. نفّذ قبو TBV ذلك بدقة. نقل المُحوِّل (adapter) البيانات بشكل نظيف. قدّم الأوراكل بالضبط ما منحها السوق. كان العقد الوحيد المعطوب في كامل المنظومة هو أنا—قبل ثلاثة أسابيع، حين ضغطت زر الإيداع.

لم تكن فترة فك الارتباط هي عنق الزجاجة. كان مسار التقميط المُوقَّع مسبقًا هو ذلك. وهذا المسار لا يعرف شيئًا عن إيجاري أو حذاء ابنتي. إنه لا يعرف سوى التوقيع الذي قدمته له.

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

@BabylonLabs_io #baby $BABY $COTI

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

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

جلست مع ذلك مدة طويلة.

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

هذا ليس فشلًا أمنيًا. بل شيء أصعب في تسميته وأصعب في الدفاع عنه.

كادت أن أغلق كل شيء تلك الليلة. ليس لأنني توقفت عن الإيمان بالكود. بل لأنني أدركت أن الكود يثق في نسختي السابقة أكثر مما يثق في نسختي الحالية.

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

كان أحدهم موقّعًا في يوم الإيداع. والآخر يُجدَّد في كل مرة ينتظر فيها شخص ما فعلًا الإجابة.

@BabylonLabs_io $BABY #baby $COTI $ON