B A S I L KHAN

#dusk $DUSK @Dusk Today I went back through the NPEX/Dusk announcement history in order, instead of reading the most recent hype post first, and the actual timeline looks different once you line it up chronologically.
December 2025: Dusk and NPEX partner to launch what's described as Europe's first blockchain-powered securities exchange, with NPEX operating as a licensed Dutch MTF. February 2025: Cordial Systems joins as the custody layer. November 2025: Dusk and NPEX adopt Chainlink's CCIP and DataLink standards specifically so NPEX's official exchange data can be published on-chain. The Dusk Trade dApp itself is described as running on DuskEVM, starting with tokenized assets from NPEX, 21X, and other institutional players, with figures like €300M in assets referenced in earlier coverage.
That's a genuinely serious regulatory stack — MTF, Broker, ECSP licenses, with a DLT-TSS license described as forthcoming. This isn't a paper partnership; NPEX already runs a real, licensed secondary market for securities in the Netherlands.
But going through every source I could find dated in the last few months, I couldn't locate a single confirmed number for how many assets are actually live and tradable on Dusk Trade today, versus how many exist only as named partners in announcements. Every reference I found described capability, licensing, and integration work — not a current listings count. Treating "€300M in assets" as already tokenized and trading would be reading a target as a result, and I don't have evidence for that yet.
What I'm actually going to check going forward: whether Dusk Trade publishes a public, queryable listings count the way exchanges normally do, whether NPEX's own investor-facing site references live Dusk-based trading rather than the partnership itself, and whether the Chainlink DataLink feed is actually pushing live NPEX market data on-chain right now or is still in integration testing.

#dusk $DUSK @Dusk اليوم حاولت سحب الأرقام الحية مباشرةً من مستكشف شبكة اختبار DuskEVM بدلًا من الاعتماد على منشورات الإعلانات، وواجهت شيئًا غيّر ما كنت أبحث عنه بالفعل.
يعمل مستكشف شبكة الاختبار على Blockscout، والذي عادةً يوفّر البيانات عبر API قابل للاستعلام — لكن الصفحة نفسها تُعرَض من طرف العميل (client-side)، لذلك لم أستطع استخراج عدد المعاملات/العقود الحالي عبر جلب مباشر. هذه قيود حقيقية في التحقّق من هذا من خارج المتصفح، ولا أريد أن أذكر رقمًا لم أتحقق منه فعليًا.
لكن ما وجدته كان أكثر إثارة من مجرد رقم خام. أُطلقت شبكة اختبار DuskEVM العامة في 5 ديسمبر 2025، ووصفت في ذلك الوقت بأنها «الخطوة الأخيرة قبل إطلاق الشبكة الرئيسية». توجد بالفعل نسخة Blockscout منفصلة مخصّصة لـ DuskEVM Mainnet وتقوم بفهرسة البيانات اعتبارًا من اليوم. هذا الجدول الزمني أكثر إحكامًا مما توحي به صياغة «الخطوة الأخيرة قبل إطلاق الشبكة الرئيسية» منذ ثمانية أشهر — وحتى منشور موسوم بـ Dusk بتاريخ 10 أغسطس 2026 كان لا يزال يروّج لشبكة الاختبار لاختبارات Solidity/Hardhat، ما يثير سؤالًا حقيقيًا حول إلى أي بيئة يتم توجيه المطورين الآن.
كما لاحظت أن معمارية DuskEVM لديها اختلاف بنيوي يستحق الإشارة: فهي حاليًا تعمل بنمط «sequencer فقط» دون وجود mempool عام. هذا طبيعي في هذه المرحلة بالنسبة لعمليات OP Stack rollup، لكنه يعني أن «النشاط» هنا لا يُقاس بالطريقة نفسها مثل L1 — فعدد منخفض من معاملات شبكة الاختبار لا يعني بالضرورة اهتمامًا منخفضًا من المطورين، لأن سلاسل sequencer-only لا تُظهر نشاطًا معلقًا (pending) بالطريقة التي يفعلها mempool في Ethereum.
بدلًا من التخمين في رقم لا يمكنني التحقق منه، ما أتابعه فعليًا الآن: ما إذا كانت قنوات Dusk نفسها تبدأ في توجيه المطورين إلى مستكشف الشبكة الرئيسية بدلًا من شبكة الاختبار، وهل يتم إيقاف شبكة الاختبار رسميًا أو إبقاؤها تعمل بالتوازي، وما إذا كانت أعداد العقود المُتحقَّق منها على نسخة Blockscout الخاصة بالـ Mainnet ستبدأ بالارتفاع من عمليات نشر حقيقية لا من مجرد سكربتات اختبار.

#dusk $DUSK @Dusk اليوم انتقلت عبر المستودعات الفعلية على GitHub وراء Citadel بدلًا من الاكتفاء بقراءة صفحة الإعلان، وكانت الفجوة بين الاثنين أكبر مما توقعت.
قُدِّم Citadel رسميًا في يناير 2023 كبحث علمي كامل، وتصميم بروتوكول عملي، وأطراف محددة (المستخدم، مزوِّد الترخيص، مزوِّد الخدمة)، ونموذج NFT خاص بُني خصيصًا لحل مشكلة حقيقية كانت أنظمة SSI الأخرى تعاني منها: حتى عندما تُخفي إثباتات المعرفة الصفرية محتوى بيانات اعتماد ما، فإن بيانات الاعتماد نفسها عادةً ما تُخزَّن كقيمة عامة يمكن تتبُّعها على السلسلة. كانت مساهمة Citadel بأكملها معالجة هذا التسريب.
كما أن الأدوات موجودة كذلك — Moat، وCitadel SDK، تعمل على GitHub، وتتضمن واجهة CLI وواجهة وصول عن بُعد للبناء على البروتوكول، ما يتطلب تشغيل عقدة Rusk وربط محفظة. هذا ليس كلامًا مُجرّدًا؛ الكود حقيقي ومفتوح.
لكن عند مراجعة مركز التوثيق الحالي، وجدت ملاحظة أوقفتني: إن الـ SDK "موجود لكنه يحتاج إلى تحديثات للنموذج الحالي لـ Rusk". هذه فجوة ذات دلالة بين "تم تصميم البروتوكول ونشره" و"يتم صيانته فعليًا بما يتوافق مع تطبيق الشبكة الحالي". كون التصميم التشفيري عمره ثلاث سنوات ويبدو سليمًا تقنيًا لا يخبرك بما إذا كانت طبقة التكامل تحافظ على الوتيرة مع سلسلة مرّت منذ ذلك الحين بتحوّل معماري متعدد الطبقات.
لا أعتقد أن هذا يعني أن Citadel مهجور — غالبًا ما تبقى أدوات الخصوصية بمستوى الأبحاث خامدة بين دفعات أعمال التكامل، خصوصًا بينما كانت انتباه الفريق موجّهًا إلى DuskDS/DuskEVM/DuskVM. لكن هذا يعني أيضًا أن الاستشهاد بـ Citadel كدليل على "بنية امتثال حيّة" حاليًا يبالغ في حقيقة وضع الـ SDK على أرض الواقع.
ما أتابعه لاحقًا: ما إذا كان Moat سيحصل على تحديث عبر commit يطابق نموذج Rusk الحالي، وما إذا كانت أي مؤسسة مُسمّاة أو مزوِّد KYC ينشر Citadel فعلًا في الإنتاج بدلًا من الإشارة إليه كمجرد حالة استخدام، وما إذا تم إدراج Citadel صراحةً ضمن خريطة طريق DuskEVM/DuskVM أو بقي كأثر منفصل من عام 2023.

#dusk $DUSK @Dusk إذا قال لك أحدهم إن دفعة على Dusk «مؤكدة»، فهل ستُطلق البضائع بالفعل، أم توقّع عقدًا، أم ترسل تحويلًا بنكيًا اعتمادًا على تلك الكلمة؟
عدتُ إلى حالات الحسم بعد أن أدركت أنني كنت أتعامل مع «مؤكد» و«منجز» على أنهما متكافئان، وهذا ليس دقيقًا على هذه السلسلة.
يمرّ البلوك عبر أربع حالات منفصلة: Accepted (تم القبول)، Confirmed (تم التأكيد)، Stable (مستقر)، وFinal (نهائي). الحالة الوحيدة التي تكون حتمية ومضمونة بشكل تشفيري بأنها غير قابلة للعكس حقًا هي Final. أما Stable فهي الحالة التي تسبقها، وهي محددة صراحةً على أساس احتمالي وليست مطلقة. معناها أن البلوك مدفون بعمق كافٍ بحيث يصبح احتمال العكس شديد الانخفاض جدًا، لا أنه مستحيل رياضيًا.
تفرق هذه النقطة كثيرًا عندما تكون أموال حقيقية في الصورة. إذا كنت تقبل معاملة Stable ولكن لم تصل بعد إلى Final كتسوية تُطلق أصلًا، أو تؤكد صفقة، أو تعامل الأموال على أنها قد «تمت تصفيتها»، فأنت تقبل احتمالًا لا ضمانًا—even إذا لم يكن الفرق واضحًا تمامًا بمجرد قراءة ملصق حالة في محفظة أو على مستكشف.
كما أن عدد البلوكات اللازم للوصول فعليًا إلى حالة Final الحقيقي غير ثابت كذلك؛ إذ انتقلت Dusk إلى نموذج «finality متداول» حيث يتغير العدد من جولة إلى أخرى تبعًا لظروف الشبكة، مما يعني أنه لا توجد قاعدة واحدة مثل «انتظر X بلوكًا وستكون في أمان» يمكنك الاعتماد عليها بشكل أعمى.
@Dusk _Foundation لم أجد رقمًا منشورًا واضحًا يوضح أسوأ حالة بخصوص المدة التي يمكن أن يمتد فيها الفاصل بين Stable وFinal تحت ظروف شبكة واقعية، فكل ما وجدته أن الأمر متغير حسب التصميم.
إذا كنت تستخدم Dusk لأي شيء يتضمن تسوية فعلية، فهل تتحقق بالفعل من حالة Final قبل اعتبار الأموال آمنة، أم تكتفي بحالة Stable لأن الكلمة تبدو مكتملة بما يكفي؟

#dusk $DUSK @Dusk إذا قمت بإرسال DUSK عبر جسر DuskEVM، كيف تعرف فعليًا أن أموالك آمنة للإنفاق على الجهة الأخرى — وماذا يحدث إذا أخطأت في التقدير؟
بدأت بالبحث في ذلك بعد أن كدت أُجري افتراضًا كان من الممكن أن يكلّفني. كان انطباعي هو: بما أن الإدراج يظهر أنه تم تأكيده في مستكشف الكتل، إذن يجب أن تكون الأموال قابلة للاستخدام. اتضح أن هذا هو بالضبط التفكير الخاطئ.
توضح وثائق مطوري Dusk هذا الأمر بوضوح: الإدراج والتسوية مرحلتان منفصلتان، والتطبيقات التي تنقل القيمة بين طبقة DuskEVM وطبقة DuskDS طُلب منها صراحةً التحقق من حالة البروتوكول أو المحفظة مباشرةً — وليس استنتاج الحتمية النهائية فقط لأن مقدارًا من الوقت قد مر. يحدث إدراج المعاملات على DuskEVM بسرعة لأنه L2 قائم على المُجمِّع (sequencer)، لكن هذا ليس هو نفس لحظة تسوية أموالك فعليًا وضمان أمانها ضد الطبقة الأساسية.
إليك ما يعنيه ذلك عمليًا: إذا كنت تقوم بربط الأصول (bridging) وأرسلت أو أنفقت بناءً على "من المحتمل أن يكون قد اكتمل الآن"، فأنت تعتمد على تخمين يحذّر منه البروتوكول نفسه صراحةً. الفجوة بين "يبدو أنه تم إدراجه" و"تم تسويته فعليًا" هي بالضبط نوع النافذة التي يؤدي فيها التصرف مبكرًا إلى تعرّض حقيقي — باستخدام أموال قد لا تزال قابلة لإعادة التنظيم (reorganized) أو الإبطال (invalidated) قبل أن تصبح نهائية بالفعل.
@Dusk _Foundation — لم أجد رقمًا منشورًا عن متوسط مدة الانتظار المعتادة فعليًا بين إدراج DuskEVM وتسوية DuskDS ذات الحتمية النهائية في الظروف العادية للشبكة، فقط إرشادًا للتحقق من الحالة بدلًا من احتساب الوقت المنقضي.
إذا كان البروتوكول نفسه يقول لا تقدّر بناءً على الزمن المنقضي، فهل تُظهر معظم المحافظ وواجهات الربط (bridge UIs) بالفعل حالة التسوية الحقيقية للمستخدمين، أم أن الناس ما زالوا يراقبون مؤقتًا ويخمنون؟

#dusk $DUSK @Dusk اختبار مسارات إصدار الأصول على كلا الطبقتين جنبًا إلى جنب، لاحظت أن البروتوكولين لا يقدمان مجرد نفس الأداة بعد نقلها إلى سلاسل مختلفة — بل إنهما يعالجان الخصوصية بتشفير مختلف جذريًا من الأساس.
يعمل Zedger بشكل أصلي على DuskDS وهو قائم على UTXO، مما يعني أنه يمكنه تقديم إخفاء هوية كامل بطريقة يصعب هيكليًا نسخها على نظام قائم على الحسابات. بينما يعمل Hedger على DuskEVM بدلًا من ذلك، ومُصمم لتوفير توافق كامل مع EVM مع أدوات الإيثيريوم القياسية — لكن لأن نموذج الحسابات في EVM لا يمكنه دعم نفس مستوى الخصوصية الذي يتيحه Zedger، يسلك Hedger مسارًا تقنيًا مختلفًا تمامًا. فهو يجمع بين التشفير المتماثل (ElGamal فوق المنحنيات البيضوية) مع إثباتات المعرفة الصفرية؛ بحيث تظل الأرصدة والتحويلات مشفرة من طرف إلى طرف، ومع ذلك تبقى قابلة للحساب والتدقيق، بدلًا من أن تكون مخفية فقط.
الجزء الذي لم أتوقعه: إثباتات Hedger تُنتج على جهاز العميل، داخل المتصفح، في أقل من ثانيتين. هذه ليست مجرد عبارة تسويقية — إنها مطالبة حقيقية بالسهولة، بحيث لا يحتاج المستخدمون المؤسسيون إلى بنية تحتية مخصصة للإثبات كي يعاملوا بشكل خاص على جهة EVM.
لذا فاختيار Zedger مقابل Hedger ليس "أيّهما أكثر خصوصية". بل هو أي نموذج ثقة وأدوات يحتاجه مُصدر الأصل. يمنح Zedger خصوصية بمستوى UTXO لكنه يتطلب أدوات Dusk الأصلية. يمنح Hedger توافقًا كاملًا مع Ethereum وإثباتًا سريعًا داخل المتصفح، لكنه يتنازل عن نفس سقف الخصوصية بسبب نموذج الحساب الذي بُني عليه.
لم أرَ إجابة واضحة بعد حول كيفية أن يُفترض فعلًا أن يقرر المُصدر بين الخيارين عندما يحتاج إلى قابلية التراكيب مع EVM وخصوصية بمستوى Zedger في نفس الأصل — سواء كان ذلك ممكنًا اليوم أم لا، أو إذا كان ذلك يفرض مفاضلة لم يحلها أحد بالكامل بعد.

#dusk $DUSK @Dusk
كنت أجري توليد إثبات محليًا لأقارن أداء الدارات، ولاحظت شيئًا جعلني أعود وأقرأ كتابات فريق التشفير الخاصة بهم بدلًا من صفحات التسويق.
الأرقام الفعلية لدى PLONK هي ما يجعل ملف الامتثال يعمل، وليس مجرد زاوية الخصوصية. يبقى زمن التحقق حوالي 6-9 ميلي ثانية بغضّ النظر عن حجم الدارة — بينما يزداد زمن الإثبات تبعًا لتعقيد الدارة (تقريبًا 5.46 ثانية لدارة بعدد بوابات 2^16 على عتاد متواضع)، لكن يبقى جانب المُتحقق سريعًا وثابتًا. هذه المفارقة تهم أكثر في التمويل المُنظّم مما يظن الناس: فالمُدقق أو الطرف المقابل الذي يتحقق من الإثبات لا يحرق حوسبةً كبيرة كل مرة، حتى مع ازدياد تعقيد منطق المعاملة الأساسي.
وما لم أتوقعه أن أكتشف أن PLONK نفسه كان يحتوي على ثغرة مُفصَح عنها فعليًا، لا مجرد مخاطرة نظرية. وجد فريق أبحاث Dusk مشكلةً حرجة في كيفية تنفيذ تحويل Fiat-Shamir — الجزء الذي يحوّل البرهان التفاعلي إلى برهان غير تفاعلي عبر تجزئة التحديات بدلًا من قيام مُتحقق حي بإرسالها. لم تقم الإضافة الأصلية بتجزئة المُدخلات العامة في وقت مبكر بما يكفي، ما أضعف ضمانات السلامة (soundness). تنسّق Trail of Bits مع الإفصاح، وقام Dusk بإصلاحها قبل mainnet، ثم نشر الإصلاح علنًا بدلًا من تركه.
التفصيلة التي لا تزال عالقة في ذهني هي هذه — سلسلة مركّزة على الامتثال مبنية على نظام إثبات تشفير كانت لديها بالفعل علة سلامة في كود أقرب للإنتاج، تم رصدها وإصلاحها قبل أن تصبح مهمة. لا أعرف كم عدد التطبيقات الأخرى التي تستخدم PLONK في أماكن أخرى كانت ما تزال عرضة للخطر عندما أصبح ذلك معروفًا للعامة، أو كم استمر الفاصل الزمني بين الإفصاح ومشاريع أخرى تقوم بتحديث فروعها (forks) الخاصة بها.

#dusk $DUSK هل يمكن لسلسلة بلوك تشين أن تكون خاصة حقًا مع أن الجهات التنظيمية ما زالت قادرة على رؤية ما يلزمها قانونيًا؟
لم أتوقع أن تكون الإجابة معلقة على تشفير مفتاح بمفتاح آخر. معظم عملات الخصوصية تحل مشكلة الخصوصية عبر إزالة إمكانية الرؤية تمامًا، بحيث لا يرى أحد شيئًا على الإطلاق. تعمل @Dusk على فرضية مختلفة: الخصوصية ينبغي أن تكون انتقائية وليست مطلقة.
يتم تشفير حمولة معاملة المستخدم باستخدام مفتاح المستخدم، ثم يتم تشفير هذا المفتاح نفسه باستخدام مفتاح مدقق منفصل، بحيث لا يستطيع فك التشفير إلا مدقق مخول. تظل السلسلة محجوبة عن الجمهور، لكن براهين المعرفة الصفرية تُمكّن المستخدمين من إثبات أن مفتاح المدقق قد استُخدم بشكل صحيح، وأن الحمولة تتبع القواعد دون كشف المحتوى لأي شخص آخر. وهذا يختلف هيكليًا عن عدم الكشف عن الهوية: يمكن لشخص ما أن يرى، ضمن شروط محددة، حتى وإن كانت السلسلة العامة لا تفعل ذلك.
وينطبق ذلك أيضًا على الهوية. تتيح طبقة الهوية لدى Dusk، والمسمّاة Citadel، إتمام KYC مرة واحدة ثم إثبات الأهلية باستخدام براهين المعرفة الصفرية، دون إعادة تعريض البيانات الشخصية في كل مرة. كما أنها تعالج فجوة في أنظمة معرفات الخصوصية السابقة، حيث كانت حتى البراهين المقاومة للتسريب لا تزال مرتبطة بقيم على السلسلة العامة يمكن تتبعها.
وهنا التوتر الذي لم أرَ حله: الإفصاح الانتقائي لا يحميك إلا إذا لم يتم اختراق مفتاح المدقق أو إساءة استخدامه. لا تملك عملة خصوصية مثل هذا المفتاح، فمبدأ الضمان لديها هو أن لا أحد يرى شيئًا، إلى الأبد. تتخلى Dusk عن هذا الضمان المطلق مقابل قابلية الاستخدام التنظيمي، وهذا هو جوهر الأمر للمؤسسات، لكن خصوصيتها في النهاية تعتمد جزئيًا على مدى إحكام ضبط وصول المدققين، وليس على الرياضيات وحدها.
إذا كانت خصوصية Dusk تعتمد جزئيًا على من يحمل مفاتيح المدقق، فكم مقدار خصوصية تَقدّم الامتثال هي تشفير، وكم منها ثقة مؤسسية ترتدي ثوب برهان معرفة صفرية؟

#dusk $DUSK @Dusk هل يمكن أن تؤدي عملية ترحيل رموزك الخاصة بين السلاسل إلى تكلفة فعلية لك دون أي اختراق؟

قضيتُ مساءً كاملًا في مراجعة كود عقد ترحيل Dusk قبل كتابة هذا، لأن عبارة "native مقابل wrapped" غالبًا ما تُشرح وكأنها مجرد اختلاف تجميلي. ليست كذلك.
هذه التفاصيل التي لفتت انتباهي: Native DUSK يستخدم 9 منازل عشرية، بينما ERC20/BEP20 DUSK يستخدم 18. عقد الترحيل يقوم بالتحويل اعتمادًا على عامل ثابت، وإذا لم يكن مقدار الرموز التي تقوم بترحيلها مضاعفًا نظيفًا لـ 1 LUX، فإن العقد يقوم بالتقريب إلى الأسفل بصمت. إذا قمت بترحيل مقدار يحتوي على "فتات" أقل من ذلك الحد، فلن يعود إليك الفائض كـ native DUSK. إنه ببساطة مفقود، وهذا حسب التصميم، وليس بسبب خلل.
كما أن نموذج الثقة نفسه يستحق الذكر. Native DUSK على mainnet هو المصدر الحقيقي للحقائق عندما تقوم بعمل جسر لـ Native DUSK خارجًا إلى BEP20: يقوم البروتوكول بقفل رموز mainnet الخاصة بك أولًا، ثم لا يفعّل إلا بعد ذلك عملية سكّ (mint) على BSC. توكن BEP20 المُغلّف موجود فقط بسبب ذلك القفل؛ وليس مدعومًا بشكل مستقل. هذه مخاطرة مختلفة جوهريًا عن الاحتفاظ بـ Native DUSK مباشرة، حتى لو كان كلاهما يُظهر الرصيد نفسه في محفظتك.
ثم هناك جزء ليس مجرد مقايضة تصميم أصلًا، بل هو مخاطرة تشغيلية. جسر Native DUSK إلى BEP20 يتطلب إدخال عنوان BSC الخاص بالوجهة داخل حقل memo. إن أغفلت ذلك، أو أدخلته بشكل خاطئ، فالتوثيق واضح وصريح: يتجاهل الجسر المعاملة وتُفقد الأموال. لا يوجد تراجع (revert) من عقد ذكي، ولا يوجد استرداد تلقائي. مجرد فقدان، لأن عملية السك على الطرف الآخر لم يكن لديها مكان لتوجيهها.
لا أعتقد أن معظم حاملي الرموز يتحققون من أي نسخة هم في الواقع يحتفظون بها قبل نقل الأموال بين البورصات والمحافظ؛ هم فقط يرون "DUSK" ويفترضون أنه قابل للتبادل.

إذا كان Native DUSK هو المصدر الحقيقي للحقائق، والنسخ المُغلّفة لا توجد إلا بسبب قفل وإثبات سكّ (lock-and-mint)، فلماذا يجعل النظام البيئي الأمر بهذه السهولة بحيث يمكن خسارة الأموال بسبب مجرد حقل memo مفقود واحد؟

#dusk $DUSK @Dusk
ماذا يعني "بدون ثقة" فعليًا عندما يكون جسرٌ ينقل أصولك بين طبقتين مختلفتين للتنفيذ؟
كنت أعود باستمرار إلى هذه الأسئلة بعد قراءة كيفية ربط DuskDS بـ DuskEVM، لأن عبارة "جسر بدون ثقة" تُستخدم كجملة تسويقية في كل مكان تقريبًا، ونادرًا ما تصمد عند التدقيق القريب.
إليك ما يحدث فعليًا: DuskDS هي طبقة التسوية والإجماع؛ إنها المكان الذي تعيش فيه الحصيلة النهائية والأمان وتوافر البيانات. أما DuskEVM فهي تعلو فوق ذلك كبيئة تنفيذ منفصلة لعقود Solidity. إن نقل أصل بينهما ليس مثل نقله ضمن الحالة الخاصة بسلسلة واحدة فقط؛ بل يعني أن طبقة واحدة يجب أن تُثبت للأخرى أن تغيّرًا في الحالة حدث فعلاً، دون أن يكتفي أي طرف بكلمة الطرف الآخر.
الجزء "الـ native" هو ما يهم حقًا. فبدلًا من الاعتماد على مجموعة مُصدّقين خارجية أو حارس متعدد التوقيعات يمسك بأصولًا مُغلّفة، تصميم الجسر الكلاسيكي الذي تسبب في معظم استغلالات ما بين السلاسل في هذه الصناعة — يتم بناء الجسر مباشرة داخل ضمانات التسوية الخاصة بالبروتوكول ذاته. إن حصيلة نهائية DuskDS (حالة "Final" المضمونة تشفيريًا وغير قابلة للعكس) هي ما يستند إليه الجسر لتأكيد أن عملية النقل آمنة بالفعل للاعتراف بها على الجهة الأخرى.
إن هذا يقدّم نموذج ثقة مختلفًا بصورة جوهرية عن جسرٍ مؤمَّن بمجموعة منفصلة من المُوقّعين. لكن هذا أيضًا يعني أن أمان الجسر لا يكون أقوى من قوة افتراضات إجماع DuskDS نفسها — فإذا حدث يومًا سيناريو يتم فيه الطعن في الحصيلة النهائية المبنية على اللجان أو تأخيرها، فإن الجسر يرث عدم اليقين نفسه، وليس مجرد مخاطرة منفصلة.
لم أجد إجابة واضحة بعد: ما هو التأخر الفعلي بين وصول DuskDS إلى حالة "Final" وبين أن يصبح الأصل قابلًا للاستخدام على DuskEVM، وهل يخلق هذا الفارق أي نافذة يمكن لممثلٍ عقلاني استغلالها من خلال التوقيت بدلًا من كسر التشفير نفسه؟
هل يكون الجسر "بدون ثقة" بقدر ثقة طبقة التسوية التي تحته فقط، أم أن DuskEVM يضيف مخاطر مستقلة فوق ذلك أيضًا؟

#baby @BabylonLabs_io إذا تحول مُدقِّق إلى شخص خبيث، فهل يُعاقَب جميع من فوَّضوا إليه معًا، أم الأشخاص الذين يستهدفهم هو فقط؟
لم أتوقع أن تتضمن الإجابة حيلًا تشفيرية بدلًا من مجرد "نعم، الجميع يخسر حصته". وبشكل ساذج، افترضت أن الإيقاف/الاقتطاع (slashing) يعمل مثل معظم سلاسل إثبات الحصة (PoS): مُدقِّق سيّئ واحد، وعقوبة جماعية واحدة لكل من فوَّض إليه.
لكن بيبيلون (Babylon) يفعل شيئًا مختلفًا باستخدام تواقيع المُحوِّل (adaptor signatures). عندما يفوّض المُراهن (staker)، يوافق كلٌّ من المُراهن ولجنة العهد (covenant committee) مسبقًا على الترتيب، لكن توقيع المُدقِّق المُفوَّض إليه نفسه هو الشيء الوحيد اللازم لاحقًا لتفعيل الإيقاف/الاقتطاع فعليًا. ولمنع مُدقِّقًا مارقًا من اقتطاع أموال مُراهن بريء من جانب واحد، يقوم المُراهن بتشفير موافقته/اعتماده المسبق باستخدام مفتاح EOTS العام الخاص بالمُدقِّق. وهذا يعني أنه إذا حاول المُدقِّق لاحقًا استهداف هذا المُراهن بعينه بشكل خبيث، فإن فك تشفير التوقيع للقيام بذلك يُلزم المفتاح الخاص للمُدقِّق نفسه بالتسرّب — ما يجعل حصة المُدقِّق المُفوَّضة لنفسه بالكامل، وكذلك حصة كل مفوِّض آخر مرتبط به، قابلة للاقتطاع أيضًا.
بعبارة أخرى، مطاردة شخص واحد تُفضي إلى تعريض المُدقِّق نفسه للانكشاف عبر الجميع المرتبطين به. إنها ليست عزلًا بفعل السياسة، بل عزلًا يُفرض عبر جعل الهجوم مُدمِّرًا للذات بالنسبة للمهاجم.
ما لم أجد له جوابًا مقنعًا هو: هل يولّد هذا التصميم حافزًا مُلتويًا حيث يكون لدى المُدقِّق، بعد اختراقه، ما لا يَخسره ويصبح من الأفضل له تعظيم الضرر على كل المفوِّضين مرةً واحدة، بدلًا من استهداف شخص واحد فقط؟
إذا كان اقتطاع شخص واحد يمكن أن يمتد إلى الجميع تحت ذلك المُدقِّق على أي حال، فإلى أي مدى يَصمد توصيف "الاقتطاع المعزول" فعليًا في الممارسة؟
#baby $BABY

#baby $BABY كيف تقوم بفرض "القطع/السلخ" (slashing) على مُتحقق في بيتكوين عندما لا توجد لدى بيتكوين منطق slashing مدمج؟
استغرقني وقتًا أطول مما توقعت لفهم هذه المسألة فعليًا، لأن الإجابة ليست عقدًا ذكيًا بل مخطط تواقيع يقوم بشيء ذكي باستخدام الرياضيات بدلًا من الكود.
@BabylonLabs_io يستخدم ما يُسمّى بـ Extractable One-Time Signature (EOTS)، مبنيًا على تواقيع Schnorr الأصلية في بيتكوين. إليك الحيلة الأساسية: يقوم مزوّد/مُوفّر الإنهاء (finality provider) بتوليد زوج مفاتيح فريد لكل ارتفاع بلوك (block height) يقوم بالتصويت عليه. طالما أنهم يوقّعون بلوكًا واحدًا فقط لكل ارتفاع، تبقى التوقيعات آمنة تمامًا ولا يتسرّب أي شيء. لكن إذا وقّعوا بلوكين متعارضين في نفس الارتفاع، تنهار الرياضيات.
إعادة استخدام مفتاح ذلك الارتفاع لتوقيع رسالتين مختلفتين تكشف مفتاحهم الخاص مباشرةً، بسبب كيفية عمل رياضيات توقيع Schnorr عندما يُعاد استخدام nonce (قيمة عشوائية لمرة واحدة).
تتطلب جولة الإنهاء نفسها توقيعات من أكثر من ثلثي وزن BTC المُرهَن حتى يتمكن البلوك من الترسيم النهائي (finalize) فعليًا؛ وبالتالي فإن أي انتهاك للسلامة، بحكم التعريف، يتطلب أن يكون لدى أكثر من ثلث الرهن توقيعان مزدوجان. هذا ما يجعل ضمان "قابل للقطع بالكامل" (fully slashable) مفروضًا رياضيًا لا كتعهد سياساتي: بمجرد تسريب المفتاح، يمكن لأي شخص—ليس فقط Babylon ولا فقط المُتحقق—بناء معاملة slashing وإرسالها للبث. لا حاجة لتصويت لجنة في تلك المرحلة، ولا توجد إجراءات استئناف؛ فقط رياضيات مكشوفة.
ما لم أره جوابًا واضحًا بشأنه: هل توليد المفاتيح لكل ارتفاع بلوك يخلق عبئًا تشغيليًا مهمًا على مزوّدي الإنهاء الذين يعملون على عدة BSNs في وقتٍ واحد، وهل قد يصبح هذا العبء بدوره سطح هجوم، مثلًا إذا أعاد مزوّد تحت الضغط استخدام العشوائية عن طريق الخطأ بدلًا من سوء النية؟
هل أمان EOTS ضمان رياضي بحت، أم أنه يعتمد أيضًا—وبصمت—على امتلاك مزوّدي الإنهاء بنية تحتية قوية لإدارة المفاتيح؟
$BABY

#baby $BABY كنت أعتقد أن المعروض غير المستخدم من البيتكوين حدّ ثابت — أصلٌ دائمًا سيكون أكثر قيمة إذا ظلّ ساكنًا بدلًا من توظيفه. ثم نظرتُ إلى ما يعنيه «غير مستخدم» فعليًا على أرض الواقع.

حاليًا، يوجد أكثر من 99% من البيتكوين المتداوَل دون رهن إطلاقًا. هذا ليس مجرد خطأ تقريبي — بل هو أكبر تجمع لرأس مال خامد في سوق العملات المشفرة بالكامل، بقيمة اقتصادية تقارب تريليون دولار، يفعل شيئًا واحدًا فقط: الجلوس داخل المحافظ.

وهكذا أعاد هذا تشكيل فهمي: كل سلسلة رئيسية أخرى بَنَت أمنها من الصفر، وتنافست على رأس مال مرهون كان يجب إنشاؤه وتحفيزه ونماؤه من الصفر خلال سنوات. لا تواجه بيتكوين هذه المشكلة. رأس المال موجود بالفعل. وهو بالفعل أكثر مخزن قيمة موثوق في هذا المجال. القطعة المفقودة الوحيدة كانت آلية لتوظيفه دون المساس بضمانات الحفظ (custody) التي جعلته موثوقًا من الأساس.

هذه هي المقامرة الفعلية التي @BabylonLabs_io تقوم بها — ليس لأن البيتكوين يحتاج حالة استخدام جديدة، بل لأن حالة الاستخدام كانت موجودة هناك طوال الوقت دون استغلال، محبوسة بفجوة تقنية بدلًا من نقص الطلب.

لا أظن أن الأمر سيحدث بين ليلة وضحاها. يعتمد التبنّي الحقيقي على إطلاق عدد كافٍ من BSNs، وعلى إثبات مزودي الإنهاء (finality providers) أنهم موثوقون بما يكفي، وعلى أن يقوم المُفوّضون بالفعل بالتحقق والعناية اللازمة التي كنت أكتب عنها طوال فترة الحملة. الآلية تعمل بالفعل. وما إذا كانت ستتوسع إلى جزء ذي معنى من ذلك التريليون دولار لا يزال سؤالًا مفتوحًا، وليس نتيجة محسومة سلفًا.

ما أراقبه في المرحلة القادمة ليس العدد الإجمالي لإعلانات BSNs — بل نسبة ذلك الـ99% الخامل التي تبدأ فعليًا بالحركة.
$1000RATS $IDOL
@BabylonLabs_io #1000sats

#HedgeFundsAddBullishOilBets #OpenAIFindsMoreAgentsEscapedContainment #AmazonRaises2026CapexTo$220B

كم من البيتكوين الخامل سيتحرك إلى بابل؟

#baby $BABY @BabylonLabs_io

كنت أظن أن "التخزين/الـstaking" يعني تلقائيًا تسليم عملاتك إلى شخص آخر إلى أن تقوم بالسحب. ثم نظرت إلى ما يحدث فعليًا لـ BTC الخاص بي لحظة دخوله في معاملة staking ضمن Babylon.

إنه لا يغادر نطاق سيطرتي أبدًا.

يتم قفل الـ BTC مباشرة عبر سكربت أصيل داخل شبكة Bitcoin، دون وجود وسيط/أمين يمسك بالمفاتيح، ودون وجود توكن مُغلف يمثل الأصل الحقيقي، ودون عقد جسر يمكن استغلاله. يوجد القفل على سلسلة Bitcoin نفسها، ويتم فرضه بقواعد Bitcoin الخاصة، وهي القواعد نفسها التي تؤمّن بالفعل كل معاملة أجريتها من قبل.

ما يحدث فعليًا هو أن هناك سكربت Taproot يتضمن مسارين لإنفاق المخرجات. أحدهما يتيح لي استرداد BTC الخاص بي بمجرد انتهاء فترة الـ timelock. والآخر لا يتفعّل إلا إذا خالف المُحقق/المدقق الذي فوّضتُ له البروتوكول — وهذا هو مسار الـ slashing، وهو السيناريو الوحيد الذي تتحرك فيه أموالي خارج المسار الذي كنتُ أنويّه.

لا يعني هذا أن المخاطر معدومة. ما زال هناك "لجنة تعاهدات/شرطيات" (covenant committee) مشاركة في فرض بعض الشروط، والتفويض إلى مزوّد نهائية (finality provider) سيّئ لا يزال يحمل عواقب. لكن توجد فروق حقيقية بين "الثقة في شركة واحدة بمفاتيحك" و"الثقة في آلية محددة وقابلة للتدقيق يجري فرضها عبر سكربت Bitcoin". الـstaking بالتوكيل/الحفظ (custodial staking) يطلب منك تصديق وعد. أما هذا فيطلب منك التحقق من الكود.

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

@BabylonLabs_io كنت أقارن نموذج موفّر نهائية (Finality Provider) في Babylon بنظام التفويض المعتاد في إثبات الحصة (PoS)، ولفت انتباهي شيء واحد: هيكل الحوافز ليس متناسقًا بالشكل الذي يعتقده الناس.
في أغلب أنظمة PoS المفوّضة، إذا أساء المدقق السلوك، تشارك في العقوبة بحيث يتم خصم جزء من رهانك إلى جانب خصم رهانهم. هذه هي الفكرة كاملة: فهي تجبر المفوّضين على التحقق فعليًا من الشخص الذي يفوضون له. إعداد Babylon يحافظ على نفس الفكرة الأساسية بالنسبة للبيتكوين: يتم تعريض BTC الخاص بك لِخطر الإيقاف/الخصم (slashing) بناءً على موفّر النهائية الذي تختاره، حتى إنك لا تقوم فعليًا بتسليم السيطرة على العملات بنفسك.
لماذا هذا مهم: الحِفاظ على العملات ذاتيًا (self-custody) يُسوَّق عادةً على أنه "أمان"، بنهاية الأمر. لكن الحِفاظ الذاتي لا يزيل تعرّضك لسوء سلوك شخص آخر؛ فهو فقط يزيل خطر جهة حاضنة/وصاية (custodial risk) بشكل محدد. يمكنك الاحتفاظ بالتحكم الكامل في BTC الخاص بك ومع ذلك قد تفقده بسبب slashing إذا قمت بالتفويض بإهمال. هذا خطر مختلف بشكل ملموس عن "تم اختراق منصتي/بورصتي"، لكنه ليس معدوم المخاطر، وأعتقد أن الرسائل المتعلقة بـ Bitcoin staking أحيانًا تُمزج بين هذه الخطوط.
الصفقة/المقايضة التي تستحق التسمية: هذا يدفع إلى إجراء العناية الواجبة (due diligence) الحقيقي على عاتق من يقومون بالاستيثاق (stakers). اختيار Finality Provider ليس خيارًا تجميليًا؛ بل هو قرار نشط بخصوص المخاطر — الديمومة/التوفر (uptime)، وسلوك التوقيع (signing behavior)، والأمن التشغيلي (operational security) تصبح مسألة تهمك بالامتداد. كثير من حاملي BTC الذين يبدؤون الاستيثاق لأول مرة غير معتادين على التفكير بهذه الطريقة، لأن بيتكوين نفسها درّبت الناس على التفكير في مخاطر الحفظ (custody risk) فقط دون غيرها.
لذلك، تصميم الحوافز سليم على الورق — ومن المفترض نظريًا أن يخلق سوقًا يحصل فيه موفّروا النهائية الموثوقون على الثقة بينما يتم حرمان موفّري الجودة السيئة من التفويض. لكن ما إذا كان هذا السوق سيتشكل فعليًا يعتمد على قيام المفوّضين/الـ stakers بالعناية الواجبة التي يفترضها التصميم.#baby $BABY

قضيت وقتًا في @BabylonLabs_io من المستندات اليوم أحاول فهم ما الذي تفعله بالفعل مزوّدو الإنهاء (Finality Providers). إن الدور أقل وضوحًا مما قد يبدو للوهلة الأولى.

في سلسلة PoS عادية، يضع المدققون (validators) رهانًا على الرمز الأصلي للسلسلة بهدف اكتساب قوة تصويت. يقوم مزوّدو الإنهاء بشيء مختلف. فهم يتلقّون تفويضات من البيتكوين (BTC) من المراهنين (stakers)، ويستخدمون البيتكوين المُفوَّض كمصدر للوزن الاقتصادي خلف تصويتاتهم من أجل إنفاذ/إتمام نهائية كتل البيانات.

لا يقوم المراهن بنقل BTC أبدًا. لا تتحرك المفاتيح الخاصة. يبقى الـBTC محبوسًا داخل سكربت (script) مُحتفظ به ذاتيًا على بيتكوين. ما يتم تفويضه هو قوة التصويت التي يمثّلها الـBTC فحسب. يقوم مزوّد الإنهاء بالتصويت. وتدعم البيتكوين ذلك التصويت اقتصاديًا دون أن تغادر أبدًا سيطرة المراهن.

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

تُكمل زاوية “الـ slashing” الصورة. إذا قام مزوّد الإنهاء بالتوقيع المزدوج (double signs)، فإن EOTS يكشف مفتاحه الخاص (private key) وتُنفَّذ شروط الـ slashing تلقائيًا. قوة التصويت المُفوَّضة إليه كانت مصحوبة بعواقب حقيقية.

ما بقيتُ أفكر فيه هو وضع المراهن ضمن كل ذلك. أنت تُفوّض لمزوّد إنهاء لا يمكنك التحكم بسلوكه بشكل مباشر. إن التشفير يحمي “أصلَك/مبدؤك” (principal). لكن اختيارك لمزوّد الخدمة ما زال مهمًا لصحة الشبكات التي يتم تأمينها.
إذا تم تفويض قوة التصويت لكن الـBTC لا يتحرك أبدًا، فكيف تبدو “المحاسبة” فعليًا للمراهن الذي يختار إلى من يفوض؟

#baby $BABY

#baby $BABY / @BabylonLabs_io
قرأت اليوم وثائق بابل، وكنت أتوقف عند سؤال واحد باستمرار.

لا تحتوي بيتكوين على عقود ذكية. فكيف يُطبِّق بروتوكولٌ الإجراءَ التأديبي (slashing) على BTC التي لم تغادر سلسلة بيتكوين قط؟
لجنة العهد (Covenant Committee) هي الإجابة، لكن ليس بالطريقة التي افترضتها في البداية.

يتم مراجعة كل معاملةِ استيكينغ من قِبل اللجنة قبل أن تصبح فعّالة. يتحققون من أن شروط فكّ الالتزام (unbonding) والتأديب (slashing) مطابقة لقواعد بابل. إذا وصلوا إلى نصاب قانوني (quorum)، فإنهم يوقّعون مُسبقًا كلًّا من معاملة فكّ الالتزام ومعاملة التأديب هناك فورًا. توقيعاتهم موجودة مسبقًا قبل بدء فترة الاستيكينغ حتى.

تفصيلة التوقيع المُسبق غيّرت فهمي للنموذج بالكامل. ليست اللجنة تراقب سوء السلوك ثم تتصرف بناءً عليه. بل توقّع كل شيء مسبقًا. بعد ذلك، التوقيع الوحيد الناقص لتنفيذ التأديب هو توقيع مزوّد الإنهاء (Finality Provider) نفسه. ولا يصبح هذا التوقيع متاحًا إلا إذا قام المزوّد بالتوقيع المزدوج (double signs)، وهذا بالضبط ما صُمِّم EOTS لكشفه.

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

كنت أرى "الاستيثاق/الاستثمار في بيتكوين دون ثقة (trustless Bitcoin staking)" في كل مكان وأخذته على محمل الجد. ثم قرأت فعليًا مستندات كود الاستيثاق.

هناك لجنة عهد/شرط تعاقدي (covenant committee).

مجموعة من الأطراف التي تم إدراج مفاتيحها العامة للبيتكوين مباشرة داخل معاملة الاستيثاق. مهمتها: التوقيع المشترك على مسارات إنفاق معيّنة كي يتمكن البروتوكول من فرض الإلغاء/الخصم (slashing) وفكّ الربط (unbonding) دون الحاجة إلى توافق/إجماع on-chain في كل مرة.

بدونهم، لا يعمل كل هذا — لن يكون فكّ الربط سريعًا، ولن يكون من الممكن فرض الإلغاء بشكل فعّال.

لذلك هذا هو المقايضة/السِّلعة الفعلية التي لا يذكرها العنوان: بابل (Babylon) يزيل الوسيط/الوصي (custodian)، لكنه لا يزيل كل الأطراف الموثوقة. بل يقلّص مستوى الثقة إلى لجنة محددة بقيود تشفيرية بدل شركة واحدة مع دفتر حسابات لا يمكنك تدقيقه.

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

معظم من يقومون بالاستيثاق اليوم لن يتحققوا من هو موجود في تلك اللجنة، أو ما هو العتبة/النصاب (threshold) لعدد التواقيع اللازمة لتحريك الأموال.

أنا فعلت. ومن المفيد القيام بذلك قبل قفل BTC في أي شيء.

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

#baby $BABY @BabylonLabs_io

#baby $BABY اليوم تحقّقت من مستندات @BabylonLabs_io staking ووجدت تفصيلاً أعاد صياغة طريقة تفكيري حول ما يعنيه «الاستحقاق الأصلي» هنا.

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

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

الجزء المثير للاهتمام هو ما تفعله تلك الـ BTC أثناء كونها مقفلة. فهي تمنح أمانًا اقتصاديًا لشبكات إثبات الحصة عبر حصة مُفوَّضة خلف مزوّدي «النهائية» (Finality Providers). إذا قام مزوّد نهائية بالتوقيع المزدوج، يمكن توقيع/اقتطاع العقوبة على الحصة خلفه. وجود البيتكوين كضمان اقتصادي حقيقي هو ما يجعل هذا الأمان ذا مصداقية للشبكات التي تعتمد عليه.

تفصيل فك الارتباط (unbonding) بقي عالقًا في ذهني. السحب الافتراضي عند انتهاء مدة الـ timelock لا يتطلب أي تعاون من بابلون أو أي مشغّل خارجي على الإطلاق. أما فك الارتباط المبكر فيتطلب توقيعًا مشتركًا من «لجنة العهد» (Covenant Committee)، ثم انتظار 7 أيام قبل أن تصبح الأموال قابلة للسحب. يمكن للمُستَثمِر دائمًا الخروج عبر المسار الافتراضي حتى لو اختفت كل الأطراف الخارجية.

هذا الاستقلال هو الخاصية التي لا يمكن لمعظم نهج BTC المُلتف (wrapped) أن يكررها. مسار الخروج مُشفّر في سكربت البيتكوين عند إنشاء الخزنة (vault)، ولا يكون محتفظًا به في حيازة شخص آخر.

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

#baby $BABY
اطلعت اليوم على وثائق بابل، وظلّتني رقم واحد عن المضيّ قدماً. لا يُستخدم سوى 1% من البيتكوين في التمويل اللامركزي.

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

ما يَبنِي @BabylonLabs_io عليه ينطلق من نقطة مختلفة. البيتكوين لا يغادر البيتكوين أبداً. إنه يُقفل داخل سكربت Taproot يوقّع عليه المودِع بالتشارك عند إنشاء الخزنة. كل مسار إنفاقٍ شرعي يتم توقيعه مسبقاً قبل أن تصبح الخزنة فعّالة. بعد ذلك، لا يمكن لأي طرف ابتكار عملية إنفاق جديدة. لا يستطيع البروتوكول نقل البيتكوين خارجياً، أو إقراضه في مكان آخر، أو إعادة توظيفه. الضمانة لا تفعل إلا ما يسمح به السكربت.

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

الإطار الذي بقي معي هو ما تسميه بابل «الخزنة» بالمعنى الأصلي. ليست عقداً تُجمّع فيها رؤوس الأموال حيث يشارك العديد من المستخدمين المخاطر معاً. بل مخرَج بيتكوين منفصل ومملوك للمودِع. أقرب إلى حجرةٍ آمنة في بنك منها إلى حوض سيولة للتمويل اللامركزي.

إذا كانت نسبة 99% من البيتكوين خارج التمويل اللامركزي لأنها تتطلب التنازل عن شيءٍ ما عبر كل المسارات الموجودة، فكيف ستبدو المساحة إذا اختفت تكلفة الدخول هذه فعلاً؟؟؟