HooRain_522

في الأمس، أثناء عالقي في زحمة سير، بدأت أتساءل بمدى عفوية استخدامنا لعبارة "بلوك تشين الخصوصية". لاحقًا في تلك الليلة، فتحت حزمة التشفير لدى Dusk لأرى كيف تتشابك أجزاؤها فعليًا—بدون مبالغة، فقط فضول.
لنواجه الأمر: إخفاء كل شيء هو النسخة السهلة من الخصوصية. النسخة الصعبة هي إثبات ما يحتاجه المنظم بالضبط، باستخدام BLS12-381 وJubJub وSchnorr وPoseidon وMerkle Trees تحت الغطاء، دون تسريب أي شيء آخر. تدعم هذه اللبنات أجزاء مختلفة من طبقات التشفير: من التواقيع والالتزامات إلى التجزئة وسلامة البيانات والتحقق. هذا ما تفعله PLONK بالفعل: تُثبت عبارة ما وتُتحقق منها وتُقبل، بينما تبقى البيانات الأساسية مختومة. يثبت مستثمر أهلية KYC لصفقة ما للأوراق المالية؛ لا يرى أحد ملفه. وXSC يدفع هذه المنطق نفسه إلى طبقة العقد للأصول المالية الحقيقية.
وهنا أعتقد أن الفرق مهم: الخصوصية لا يجب أن تعني العتمة. الهدف ليس أن لا أحد يستطيع رؤية أي شيء. الخصوصية عند الحاجة، والشفافية عندما تكون مفيدة، والإفصاح الانتقائي عند الضرورة. ينبغي للطرف الصحيح أن يتمكن من التحقق من الشيء الصحيح دون الحصول على وصول إلى كل ما يوجد خلفه.
لكن المتشكك بداخلي لن يترك هذا بسهولة. ما يزال الإفصاح الانتقائي يتطلب من يقرر قائمة السماح (whitelist) ويطبق القيود—وهذا هو الحوكمة، لا الرياضيات. والرياضيات نفسها ليست دليلًا على السلامة: يُقال إن Aegis أغلقت 39 اكتشافًا، سبعة منها حرجة، قبل شحن PLONK V3. هذا مهم لأن نقل التشفير القائم على ZK نحو البنية التحتية للإنتاج ليس فقط مسألة نظام الإثبات نفسه؛ بل يتطلب أيضًا تدقيقًا أمنيًا جادًا حول طريقة التنفيذ. وبهذا المعنى، تمثل أعمال PLONK V3 وAegis خطوة أوسع في تطور Dusk من التصميم التشفيري إلى بنية تحتية جاهزة للإنتاج.
فما الاختناق الحقيقي لثقة المؤسسات: علم التشفير أم من يمتلك مفاتيح القواعد؟

#dusk $DUSK @Dusk
$BTR
$BMT

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

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

هذا التمييز يهم أكثر مما يبدو. تعرّض DUSK ليس منصة تشغيلية. ومع تداول الرمز قرب 0.06 دولار، وبقيمة سوقية تقارب 31 مليون دولار، فإن تصفية مركز خزانة كبير تحت الضغط ستكون بطيئة ومكلفة.

لذا ربما أن التنويع ليس أمرًا سلبيًا بل هو بنية البقاء.
سؤالي: هل ينبغي لمؤسسة أن تُحسّن لتعظيم التوافق مع DUSK، أم لتحسين القدرة على العمل خلال الحدث غير المتوقع التالي دون المساس بالأصل الذي تبني عليه كل ما حوله؟

#dusk $DUSK @Dusk

$BMT

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

لأكون صريحًا، لطالما نسجت Dusk قصتها حول التشفير Citadel وامتثال ZK والخصوصية دون غموض. لكن هناك نقطة مهمة هنا. عندما ظهرت نشاطات غير معتادة على الجسر، واصلت DuskDS إنتاج الكتل كما هو مصمَّم. كانت المعالجة الفعلية، أي ظهور قائمة الحظر والتحذير، عند طبقة Web Wallet، وليس عند مستوى البروتوكول.

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

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

$TUT $PROM

#dusk $DUSK @Dusk
ظللت أعود إلى كلمة واحدة الليلة وأنا أقرأ عن آليات الإجماع: "احتمالية". معظم السلاسل لا تعدّ فعليًا بالنهائية، بل تقلّل المخاطر مع مرور الوقت فقط. بقي هذا التمييز معي مدة أطول مما توقعت.
بالنسبة للمستهلكين، فإن النهائية الاحتمالية مناسبة. انتظر بضع كتل، وامضِ. لكن بالنسبة للمؤسسات التي تسوّي ملايين في أصول مُرمّزة، فإن "نهائية على الأرجح" ليست جوابًا حقيقيًا. إن مخاطر إعادة التنظيم وحدها تمثل كسر الصفقات.
تتعامل Dusk مع ذلك بطريقة مختلفة عبر التعيين الحتمي لآلية الإثبات الموجزة (Succinct Attestation): تختار التعيينات الحتمية المزودين باستخدام توقيعات BLS، لتشكيل لجان التحقق والمصادقة دون تعدين أي شيء. وبالاقتران مع النهائية المتدحرجة، تصبح الكتلة غير قابلة للرجوع فعليًا خلال ثوانٍ، لا خلال وقتٍ أطول إلى أن تصبح غير قابلة للعكس.
كما أن ذلك يقتل بهدوء هجمات المدى الطويل وإعادة ترتيب MEV على الصفقات المعلقة، وهو ما لم أكن قد ربطته حتى قرأت هذا بتمعّن.
المقايضة هي زمن التوفر. المزودون غير المتصلين يبطئون التصويت، وتدخل آلية التعافي الطارئة. السرعة ليست هي الجزء الصعب هنا فعلًا.
الاختبار الحقيقي هو ما إذا ظلت هذه اللجان الصارمة لامركزية عندما يبدأ الحجم العالمي بالتصاعد فعليًا.

وأنا أنظر إلى الغسق، أعود دائمًا إلى سؤال واحد: ما المشكلة الحقيقية التي قد تجعل شخصًا يترك نظامه القائم وينتقل إلى الغسق؟

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

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

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

الخصوصية + الامتثال، وتحويلات مُتحكَّم بها، وخصوصية على مستوى المعاملات، مع الحفاظ في الوقت نفسه على قابلية التدقيق ربما تكون هذه هي الميزة الحقيقية.

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

لذلك بصراحة: ما نوع الاحتكاك برأيك الذي يحلّه الغسق ولا يمكن للأدوات/البنى الحالية حله ببساطة؟
#dusk $DUSK @Dusk

قضيتُ المساء في مقارنة لوحات معلومات مختلفة بدلًا من الاسترخاء بالنظر إلى بيانات TVL في تبويب واحد وبيانات التسوية في تبويب آخر. كان الفرق بين الرقمين يزعجني باستمرار.

تعرض TVL فقط مقدار القيمة أو عدد الأصول التي تم حجزها أو ترميزها. إنها لا تخبرنا ما إذا كانت هذه الأصول تتحرك فعلًا أو تُستخدم. فإذا كان لدى مشروع ما 500 مليون دولار من الأصول المُرمّزة لكن فقط 8 ملايين دولار في التسوية الشهرية، فقد يبدو هادئًا جدًا، شبه غير نشط. ومن ناحية أخرى، قد تكون الأصول بقيمة 150 مليون دولار مع تسوية متكررة قدرها 30 مليون دولار مؤشرًا أقوى على الاستخدام الحقيقي، حتى لو كان النطاق أصغر.

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

ثم هناك جانب الخصوصية. كنت أظن أن Dusk تعمل مثل Monero، مع إخفاء كامل للهوية. لكن يبدو أن نهج Hedger باستخدام ZK مختلف: يمكن أن تبقى المعلومات الحساسة خاصة بينما يظل النظام قابلًا للتدقيق. واقعة الجسر وقائمة حظر العناوين جعلتني أتساءل إذا كانت العناوين المعلَّمة يمكن تحديدها بعد كل شيء؛ هل صُممت خصوصية Dusk لتكون انتقائية؟

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

#dusk $DUSK @Dusk

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

عندما تفكر في الأمر، تصبح حدود الشفافية الكاملة واضحة تمامًا. إظهار كل الرصيد وكل طرفٍ مقابل لا ينجح فعلًا بالنسبة للمؤسسات التي تتعامل مع أموال حقيقية. لكن عدم الكشف الكامل عن الهوية له مشكلته أيضًا: فكيف يمكن للجهات التنظيمية الموافقة على شيء لا يمكنها أبدًا رؤيته أو فحصه؟

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

هنا تقوم إثباتات ZK بعمل مهم بصمت. يمكنها إثبات أن المعاملة تتبع القواعد دون كشف البيانات الأساسية للجميع.

همم... لكن هذا ما يزال يترك السؤال الأصعب: من يطّلع على ماذا، ومن يقرر ذلك؟

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

لذا أنا مهتم حقًا: هل يحقق “الإفصاح الانتقائي” المتطلبات التنظيمية عمليًا، أم أنه لا يزال إلى حد كبير غير مُختبَر على نطاق مؤسسي واقعي؟

#dusk $DUSK @Dusk

#dusk $DUSK @Dusk لا أزال أفكر في هذا: ماذا يحدث فعلاً بعد عملية التوكننة؟
كنت أظن أن الجزء الصعب هو فقط نقل أصل إلى بلوكتشين. لكن كلما تعمقت في Dusk أدركت أن العمل الحقيقي يبدأ مباشرة بعد ذلك.
التوكننة هي مجرد الخطوة الأولى. التحدي الحقيقي هو البنية التحتية المحيطة بها. مع Dusk Trade تصبح الأمور أكثر إثارة عملية إرشاد المستثمرين، ربط المحافظ، ضوابط التحويل، تنسيق المدفوعات...
ليس الأمر مجرد أنظمة منفصلة تم ربطها معًا. الإصدار، الإرشاد، التداول، التسوية—كلها جزء من دورة حياة واحدة مترابطة.
الجزء الذي علق في ذهني هو التسوية الحتمية. الأسواق المالية لا تريد فقط الوصول إلى التسوية، بل تريد تسوية يمكن الاعتماد عليها فعلًا لا شيئًا احتماليًا. أضف الخصوصية والإفصاح الانتقائي إلى المعادلة وستحصل على نظام يمكن أن تبقى فيه بيانات المستثمر خاصة، لكن يمكن للجهة التنظيمية التحقق منها عند الحاجة. يبدو هذا رائعًا على الورق، بصراحة.
لكن المشكلة هي: Dusk L1 يعمل بالفعل، وDuskEVM ما زال على شبكة الاختبار. وبما أن Moonlight وPhoenix تستخدمان نماذج معاملات مختلفة، فإن أي شخص يقوم بربط الأموال يحتاج أن يفهم بالفعل أي تمثيل يحملونه مكشوفًا أم مُحمى قبل أن يفعل أي شيء به.

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

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

$MUBARAK
$HEMI

#dusk $DUSK @Dusk Disclosure gap, still sitting with this one ....

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

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

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

لاحقًا، قدمت مشاركة ما بعد الحادث من Dusk تفاصيل إضافية: إذ تمكن مهاجم من الوصول غير المصرح به إلى محفظة توقيع الجسر وسحب DUSK عبر الجسر. كان الحادث مشكلة أمن تشغيلي متعلقة بالجسر وليس اختراقًا لـ DuskDS نفسه.

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

لذا فإن “هل تم اختراق Dusk؟” ليست أكثر الأسئلة إثارة للاهتمام.

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

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

لا أزال لا أعرف مقدار المعلومات التي يمكن أن تبقى سرّية قبل أن يتحول التحقق ببساطة إلى “صدقنا.”

$ALPINE
$ACE

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

ما لفت انتباهي هو تركيز Dusk على العقود الذكية السرّية ومعيار XSC. لذا فالتعمية هنا ليست مجرد إخفاء مبلغ. بل هي بناء الخصوصية داخل البنية التحتية المالية.

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

جعلني NPEX أفهم ذلك بشكل أوضح. فتوكنة أسهم شركة BV الهولندية لا تُقصي ببساطة العملية القانونية القائمة. يبدو أنها تتواجد إلى جانبها.

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

كما أن حقيقة أن Dusk Trade ما يزال على قائمة انتظار جعلتني أفكر في الأمر بشكل مختلف. ربما يتم بناء البنية التحتية المؤسسية قبل وقت طويل من بدء التداول الحقيقي.

ما زلت أحاول أن أفهم شيئًا واحدًا: مع ازدياد تعقيد هذه البنى، كيف تعمل السرّية والإنفاذ القانوني معًا فعليًا؟
@Dusk #dusk $DUSK
$TUT
$GPS

ضوء القمر ضد العنقاء، ما زلت أفكر في هذه… السؤال الذي بدأني هو: لماذا نجعل كل معاملة عامة أو كل معاملة خاصة، بينما التمويل يحتاج فعلاً إلى الاثنين معًا؟

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

أما Phoenix فيستخدم نموذج UTXO مع “notes” بدلًا من الأرصدة، والخصوصية مُدمجة في التصميم. وهو مناسب للتحويلات التي قد يكون فيها كشف المبلغ أو الطرف الآخر هو الخطر الحقيقي.

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

قد تميل التسوية المؤسسية أكثر إلى Moonlight، لأن الامتثال غالبًا ما يحتاج إلى أن تكون المعاملات مرئية وقابلة للتدقيق. من ناحية أخرى، تبدو التحويلات من نظير إلى نظير والمراكز الحساسة أنسب لـ Phoenix.

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

والآن فضولي يدفعني لمعرفة أي نموذج سينتهي به الأمر للتعامل مع حجم أكبر من المعاملات الواقعية على المدى الطويل.
@Dusk #dusk $DUSK
$DOLO
$AIO

كنت أعتقد أن رمز الأمان (Security Token) هو في الأساس عقد ERC-20 مع أوراق إضافية مرفقة، نفس منطق التحويل، نفس الوصول المفتوح، فقط مُسمّى بشكل مختلف لأسباب قانونية.
كلما بحثت أكثر فيما تتطلبه الأوراق المالية المُنظَّمة فعليًا، كلما بدا أن هذا الافتراض لا معنى له. تحمل الورقة المالية قيودًا لا علاقة لها بالشفرة إطلاقًا وبكل ما يتعلق بمن يُسمح له بحملها.
كيف يمكن أن تنتقل الملكية ومن ترافقها الإفصاحات مع ذلك الانتقال. أهلية المستثمر، وحدود الاختصاص القضائي، وظروف التحويل الخاضعة للرقابة ليست ميزات يمكنك إضافتها إلى الرمز لاحقًا، بل هي السلوك الحقيقي للأصل.
من هنا يبدو أن منطق مفهوم Dusk لـ XSC، "عقد الأوراق المالية السرّي" (Confidential Security Contract)، يستمد فكرته. بدلًا من التعامل مع الامتثال كقائمة تحقق خارجية تُفرض بواسطة وسطاء، فإنه يجعل الأهلية وقيود التحويل جزءًا من القواعد الداخلية للعقد نفسه، مع الاستمرار في استخدام آليات الخصوصية بحيث لا تكون تفاصيل الملكية مكشوفة بالكامل على السلسلة.
يضع Dusk XSC كمعيار للأوراق المالية المُرمّزة التي تتيح الخصوصية. هذا يحوّل المسؤولية بعيدًا عن أمناء الحفظ الذين يتحققون يدويًا من كل صفقة، نحو بنية تحتية تُطبق القاعدة تلقائيًا. المقابل هو أن ترميز التعقيد والدقة القانونية داخل عقد أصعب من ترميز تحويل رصيد بسيط.
هل يؤدي أتمتة الامتثال فعليًا إلى تقليل المخاطر أم أنه فقط ينقل مكان حدوث الأخطاء؟

@Dusk #dusk $DUSK

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

يتيح DuskEVM للمطوّرين كتابة Solidity واستخدام أدوات الإيثريوم المألوفة، مع توفير بيئة تنفيذ متوافقة مع EVM وتتمتع بتوافق مع OP Stack. وتحت هذه التجربة المطوّرة المألوفة، توفر DuskDS طبقة التسوية الأساسية.

هذا الفرق مهم أكثر مما قد يبدو أولًا. تبدو بيئة التنفيذ مألوفة لمطوّري الإيثريوم، لكن التسوية والنهائية الأساسية ترتبط ببنية Dusk الخاصة، بدلًا من ربطها بالطبقة الأساسية لإيثريوم.

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

أما المقابل فهو أن الألفة قد تُخفي الاختلافات الحقيقية في سلوك التسوية إذا افترض الناس أن التوافق مع EVM يعني أن كل شيء يعمل بالطريقة نفسها.

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

@Dusk #dusk $DUSK

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

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

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

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

ما رأيك: هل يجب أن تأتي السلامة أولًا أم الحرية المالية؟
#JapanRegulatorsUrgeCryptoWithdrawalLimits
$BTC #bitcoin @Bitcoin

$ACT
$HFT

على مرّ السنين، اعتقدت أن أقوى ما يتمتع به البيتكوين هو ببساطة الوجود بهدوء كمخزنٍ للقيمة—آمنٌ تحديدًا لأنه لا يفعل الكثير غير ذلك. كلما تعمّقت في تصميم بابيلون، بدأت هذه الفكرة تشعر بالنقص. يمكن لـ BTC المحفوظ ذاتيًا الآن أن تساهم بشكل مباشر في تأمين شبكات أخرى، دون مغادرة البيتكوين نفسها أبدًا.
في حين أن مكافآت التكديس تُعد حافزًا للمشاركين، فإن الهدف الأوسع لبابلون هو استخدام البيتكوين لتوفير أمنٍ اقتصادي للشبكات الخارجية المعتمدة على الإثبات بالمصلحة (Proof-of-Stake).
هنا يبدأ مفهوم الأمن بأن يصبح قابلاً لإعادة الاستخدام؛ بدلًا من أن تقوم كل سلسلة جديدة بإعداد مجموعة المدققين الخاصة بها وافتراضات الثقة من الصفر، يمكن لعدة منظومات الاستفادة من نفس أمن البيتكوين المدعوم في الوقت نفسه.
ما يجعل هذا يعمل هو أن البيتكوين لا يتحرك أبدًا—لا تغليف، ولا تسليم الحيازة عبر جسر. يتم تصدير الأمان بينما تبقى الأصول في مكانها تمامًا كما كانت دائمًا.
ليس لدى بابيلون نية لتغيير ماهية البيتكوين، بل لتوسيع ما يمكن للبيتكوين حمايته. إذا نجحت هذه المنظومة في التوسع واستمر التبنّي، فقد يصبح البيتكوين بنيةً تحتية أساسية تحت العديد من منظومات البلوك تشين بدلًا من البقاء مجرد أصلٍ سلبي يظل وحده.
لذا إذا انتهى الأمر بأن يؤمّن البيتكوين عشرات البيئات بهذه الطريقة، فهل يمكن أن يصبح ذلك واحدًا من أكبر استخداماته بعد، أكبر حتى من كونه مخزنًا للقيمة؟

@BabylonLabs_io #baby $BABY
$BTC

في البداية، افترضت أن الأمان المدعوم بالبيتكوين وحده كافٍ لجذب المطورين إلى نظام بيئي، وأن قوة الأمان كانت هي جوهر العرض.
لكن كلما نظرت إلى كيفية نمو الأنظمة البيئية فعليًا، بدا ذلك الافتراض ناقصًا. يختار المطورون بالفعل البنية التحتية الآمنة بدلًا من إعادة بناء الأمان من الصفر، ويُخفِّض بابيلون تلك التكلفة بشكل ملحوظ عبر السماح للسلاسل باستعارة أمن اقتصادي مشترك مدعوم بالبيتكوين بدلًا من التمهيد لمجموعة مُحدِّدين (validator) خاصة بها.
لكن الأمان لا يحل سوى نصف المشكلة. إذا كان معظم نشاط التداول ما يزال يحدث على منصات تداول مركزية، فإن النظام البيئي يظل يعتمد بشكل كبير على البنية التحتية خارج أسواقه داخل السلسلة.
هذه الفجوة تستحق المراقبة، إذ إن سيطرة حجم التداول في منصات CEX على نشاط DEX تشير إلى شيء غير مريح بشأن مدى واقعية التبني اللامركزي في الوقت الحالي.
الأرقام الحالية تجعل هذا التحدي أسهل في الرؤية.
وبعبارة أخرى، إذا ظل التداول عبر الجهات المركزية عند المستويات الحالية، فستحتاج أن ينمو نشاط DEX بنحو 7.7× تقريبًا قبل أن يحدث حوالي 30% من إجمالي التداول على السلسلة. وهذا يوضح مدى بدائية السيولة اللامركزية حتى الآن.
عندما تعمّق النظر في السيولة داخل السلسلة، فإنها تغيّر الصورة: انزلاق أقل، واكتشاف أفضل للأسعار، وتجربة لا يتعين على المستخدمين مغادرة السلسلة من أجلها. ولا تخدم السيولة المستخدمين فقط، بل تجعل البيئة بأكملها أكثر جاذبية للمطورين أيضًا، لأن التطبيقات تحتاج إلى سيولة موثوقة لتعمل بشكل جيد.
ينتهي الأمر بأن يعزز الأمان والسيولة بعضهما بعضًا: تبنّي المطورين يغذي السيولة، والسيولة تجذب المزيد من المطورين.
لذلك ربما لا تكون علامة بابيلون الفارقة الحقيقية هي عدد السلاسل أو أرقام الحجم، بل ما إذا كان يمكن للأمان المدعوم بالبيتكوين أن يستمر في النهاية في دعم اقتصاد داخل السلسلة الخاص به.
هل يمكن للأمان المدعوم بالبيتكوين في النهاية أن يُنشئ سيولة ذاتية الاستدامة، أم أن الأسواق العميقة ستعتمد دائمًا على الحوافز?

@BabylonLabs_io #baby $BABY

في البداية، اعتقدت أن بيتكوين ديفاي (DeFi) يعني عمليًا التفاف (Wrapping) البيتكوين (BTC) تقريبًا تلقائيًا، وأن ذلك بدا الطريقة الوحيدة لجعله قابلًا للاستخدام في أماكن أخرى. وكلما تعمقت أكثر في نهج بايبيليون (Babylon)، لم يعد هذا الافتراض منطقيًا. الالتفاف يطلب منك الثقة بوصي يحتفظ ببيتكوين حقيقي (BTC) بينما تتداول نسخة مُصنَّعة في مكان آخر؛ وهذا لا يزيل المخاطر بل يعيد توطينها فقط.

تبدأ بايبيليون من سؤال مختلف تمامًا: ماذا لو لم يكن بيتكوين الأصلي مضطرًا أبدًا إلى مغادرته في المقام الأول؟ هذا ما بُنيت عليه فعليًا خزائن بيتكوين بلا ثقة (Trustless Bitcoin Vaults): إبقاء BTC أصليًا مع الاستمرار في كونه ضمانًا (collateral) قابلًا للاستخدام، وذلك عبر التحقق باستخدام سكربتات بيتكوين نفسها بدلًا من عقد جسر. لا وجود لجسر يعني عدم وجود سطح استغلال جالس بين السلاسل (chains)، ولا وجود لرمز مُصنَّع تعتمد قيمته على ملاءة طرفٍ آخر.

وهذا يضع الأساس للتطبيقات المستقبلية المدعومة ببيتكوين مثل الإقراض والاقتراض والمنتجات المالية المُهيكلة (structured financial products)، وكلها مبنية مباشرة فوق الأمان الحقيقي لبيتكوين (BTC) بدلًا من مشتقٍ مُلتف (wrapped derivative). يبدو الأمر كأنه أساس مختلف بوضوح ليتطور منه BTCFi. وإذا ثبتت قابلية هذا النموذج للتوسع، فقد تتطور BTCFi لتدور حول بيتكوين الأصلي نفسه بدل الاعتماد على التمثيلات المُلتفة.

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

@BabylonLabs_io #baby $BABY
$BTC

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

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

يبقى Bitcoin الأصلي على سلاسله الخاصة، باستخدام برمجة (scripting) أصلية متوافقة مع Bitcoin، وقيود زمنية (timelocks)، وآليات تشفير تدعم نموذج الأمان الخاص بـ Babylon، بدلًا من الاعتماد على وعد طرف ثالث أو حيازته.

هنا، يقوم الأمان التشفيري بالعمل الفعلي، وليس الثقة في أي مؤسسة أو شخص. يحدث التحقق على السلسلة (on-chain)، وبطريقة قابلة للإثبات (provable)، دون أن يحتاج أي أحد إلى قبول كلام شخصٍ ما كما هو.

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

وجود عدد أقل من الأطراف التي يجب الوثوق بها يعني وجود أماكن أقل يمكن للنظام أن يتعطل فيها بصمت.

لذلك، إذا كانت تقليل الثقة هو الهدف الحقيقي، ألا يعني ذلك أن البنية/المعمار (architecture) يصبح مهمًا أكثر حتى من سمعة من يدير النظام؟

@BabylonLabs_io #baby $BABY
$BTC

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

الحقيقة هي أن $BTC and $BABY لا يقومان بنفس الدور. دور البيتكوين يقتصر على توفير الأمن الاقتصادي. إنه رأس المال الحقيقي الذي يحمي الشبكة، وإذا أراد مهاجم أن يفسد الإجماع، فعليه أن يضع نفس هذا رأس المال على المحك.

$BABY ، من ناحية أخرى، يتحمل مسؤوليات لم تكن البيتكوين مصممة لها من الأساس، خصوصًا الحوكمة. يجب أن تتم ترقيات البروتوكول، وتغييرات مختلف المعلمات، والقرارات المتعلقة بموفري الإنهاء (Finality Providers) بطريقة ما، وهذا يتطلب توكنًا لا يُبنى فقط كضمان، بل كأداة لتنسيق الشبكة واتخاذ القرار.

تسري الحوافز داخل الشبكة عبر #Baby بالطريقة نفسها. فهذا هو التوكن الذي يكافئ الرهان، والمشاركة، وتكاليف التشغيل اليومية لتشغيل هذا النظام عبر سلاسل بلوكشين متعددة. وبالإضافة إلى ذلك، فإنه يُبقي المشاركين المختلفين في النظام البيئي متوافقين من خلال إطار مشترك للحوكمة والحوافز.

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

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

لذا إذا كانت BTC تؤمّن النظام وBABY تحكمه، فمتى حدث خطأ—فأين تقع المسؤولية الفعلية؟

@BabylonLabs_io #baby
$BTC

في البداية، اعتقدت أن قصة بابل تبدأ وتنتهي بأمان أصلي من بيتكوين: بدون جسور، بدون أمناء حفظ، وبتحققٍ منغرس مباشرةً في بيتكوين بدلًا من الثقة بأصلٍ مُلتف.

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

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

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

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

@BabylonLabs_io #baby $BABY

$BTC