AlizehAli
11.2k منشورات
AlizehAli
592 تتابع
24.3K+ المتابعون
8.2K+ إعجاب
منشورات
الكل
اقتباسات
Live
PINNED
@Dusk الدستور التأسيسي لأي بلد موجود لحظة نشوء البلد—لا أحد يُصوِّته ليُصبح قائمًا بعد وقوع الأمر؛ بل هو موجود منذ اليوم الأول، ويُبنى كل شيء آخر بالاستناد إليه.
عقود الجِنيسس (الإنشاء) الخاصة بـ Dusk تعمل بالطريقة نفسها. تُصفّ مواد معمارية Dusk نفسها عقدين: عقد الـ stake (الرهان) الذي يتتبع من يقومون بالـ staking، ويسجّل المكافآت، ويمكّن عمليات الـ stake وunstake وwithdraw للمكافآت؛ وعقد الـ transfer (التحويل) الذي يتعامل مع كلٍ من Moonlight (عام) وPhoenix (مخفى)، ويدفع رسوم الغاز، ويعمل كنقطة دخول لتنفيذ المعاملة مباشرةً على DuskDS.
يمتد هذا الدور التأسيسي إلى ما هو أبعد من DuskDS وحده، لكن الآلية الدقيقة تختلف بحسب الطبقة. DuskEVM، وفقًا لوثائق Dusk الخاصة، يُحرّك DUSK كرسوم غاز عبر جسـرها الخاص إلى Dusk's L1، ثم يعود في النهاية إلى DuskDS—وهو مسار ذو صلة لكنه مختلف عن الدور المباشر لعقد التحويل في معاملات DuskDS الأصلية. الطريقان يقودان إلى طبقة الأساس نفسها؛ لكنهما ليستا آليتين متطابقتين. #dusk
مراجعة ذاتية: تشبيه الدستور له حد حقيقي يستحق التسمية. يمكن تعديل دستور بلد ما رسميًا عبر عملية محددة. ما لم أجده موثقًا هو ما إذا كانت عقود الجِنيسس الخاصة بـ Dusk تتبع مسار تعديل مكافئًا ومعرّفًا بوضوح، أم إذا كان مفهوم "genesis" هنا يعني عمليًا أنه دائم ومصمم ليبقى كذلك—وهو سؤال حوكمة حقيقي بالنظر إلى مقدار ما يعتمد عليه الآن مكدس Dusk متعدد الطبقات المتوسع من هذين العقدين كي يظلا صحيحين. $DUSK
يجب تقييم DUSK على ما إذا كان سيُوضَّح هذا الغموض قبل أن تُصبح هذه العقود بحاجة إلى تحديث تحت ضغط حقيقي، وليس بعد.
#dusk $DUSK @Dusk
عقود الجِنيسس (الإنشاء) الخاصة بـ Dusk تعمل بالطريقة نفسها. تُصفّ مواد معمارية Dusk نفسها عقدين: عقد الـ stake (الرهان) الذي يتتبع من يقومون بالـ staking، ويسجّل المكافآت، ويمكّن عمليات الـ stake وunstake وwithdraw للمكافآت؛ وعقد الـ transfer (التحويل) الذي يتعامل مع كلٍ من Moonlight (عام) وPhoenix (مخفى)، ويدفع رسوم الغاز، ويعمل كنقطة دخول لتنفيذ المعاملة مباشرةً على DuskDS.
يمتد هذا الدور التأسيسي إلى ما هو أبعد من DuskDS وحده، لكن الآلية الدقيقة تختلف بحسب الطبقة. DuskEVM، وفقًا لوثائق Dusk الخاصة، يُحرّك DUSK كرسوم غاز عبر جسـرها الخاص إلى Dusk's L1، ثم يعود في النهاية إلى DuskDS—وهو مسار ذو صلة لكنه مختلف عن الدور المباشر لعقد التحويل في معاملات DuskDS الأصلية. الطريقان يقودان إلى طبقة الأساس نفسها؛ لكنهما ليستا آليتين متطابقتين. #dusk
مراجعة ذاتية: تشبيه الدستور له حد حقيقي يستحق التسمية. يمكن تعديل دستور بلد ما رسميًا عبر عملية محددة. ما لم أجده موثقًا هو ما إذا كانت عقود الجِنيسس الخاصة بـ Dusk تتبع مسار تعديل مكافئًا ومعرّفًا بوضوح، أم إذا كان مفهوم "genesis" هنا يعني عمليًا أنه دائم ومصمم ليبقى كذلك—وهو سؤال حوكمة حقيقي بالنظر إلى مقدار ما يعتمد عليه الآن مكدس Dusk متعدد الطبقات المتوسع من هذين العقدين كي يظلا صحيحين. $DUSK
يجب تقييم DUSK على ما إذا كان سيُوضَّح هذا الغموض قبل أن تُصبح هذه العقود بحاجة إلى تحديث تحت ضغط حقيقي، وليس بعد.
#dusk $DUSK @Dusk
Permanent by design
Should have amendment path
15 ساعة (ساعات) مُتبقية
PINNED
@TermMax افترضت أن ممارسة خيار مربح على TermMax Alpha ستعمل بطريقة واحدة ثابتة — وصول العائد إلى محفظتك، انتهى الأمر، مثل أي منصة خيارات استخدمتها من قبل. $BEAT
انكشف افتراضي هذا بمجرد أن قرأت أن TermMax يقدم مسارين متميزين للممارسة. Exercise-Net-Settle يغلق الصفقة ويدفع الربح الصافي مباشرة. أما Exercise-Delivery فيتم التسوية عبر تحويل الأصل الأساسي نفسه، وليس النقد — فتَنتهي فعليًا بامتلاك التوكن الذي بُنيت عليه صفقتك Long أو Short. #TermMax
يعيد هذا صياغة معنى "تحقيق الفوز" في صفقة الخيارات هنا. في معظم المنصات، تعني ممارسة الخيار ببساطة تحويل رقم إلى حسابك. على TermMax، قد تعني الممارسة الخروج بالأصل الحقيقي، وهذا مهم تحديدًا لإدراجات Binance Alpha المبكرة حيث قد تكون الحصول على تعرض حقيقي للتوكن — لا مجرد متابعة تحركات سعره — هو جوهر الصفقة. $TUT
ما لا توضحُه المستندات هو ما إذا كانت المفاضلة بين الخيارين متاحة دائمًا للمتداول، أم أنها تعتمد على إعدادات السوق المحددة وقت التسوية. $ENA
الاختبار الحقيقي لـ TMX هو ما إذا كان المتداولون يفهمون فعلًا أن هذا الاختيار موجود قبل أن يمارسوا، أم أنهم يتركون أنفسهم للخيار الذي يعرضه الواجهة أولًا.
هل استخدم أي شخص Exercise-Delivery بدل Net-Settle، ولماذا؟
#termmax @TermMax
انكشف افتراضي هذا بمجرد أن قرأت أن TermMax يقدم مسارين متميزين للممارسة. Exercise-Net-Settle يغلق الصفقة ويدفع الربح الصافي مباشرة. أما Exercise-Delivery فيتم التسوية عبر تحويل الأصل الأساسي نفسه، وليس النقد — فتَنتهي فعليًا بامتلاك التوكن الذي بُنيت عليه صفقتك Long أو Short. #TermMax
يعيد هذا صياغة معنى "تحقيق الفوز" في صفقة الخيارات هنا. في معظم المنصات، تعني ممارسة الخيار ببساطة تحويل رقم إلى حسابك. على TermMax، قد تعني الممارسة الخروج بالأصل الحقيقي، وهذا مهم تحديدًا لإدراجات Binance Alpha المبكرة حيث قد تكون الحصول على تعرض حقيقي للتوكن — لا مجرد متابعة تحركات سعره — هو جوهر الصفقة. $TUT
ما لا توضحُه المستندات هو ما إذا كانت المفاضلة بين الخيارين متاحة دائمًا للمتداول، أم أنها تعتمد على إعدادات السوق المحددة وقت التسوية. $ENA
الاختبار الحقيقي لـ TMX هو ما إذا كان المتداولون يفهمون فعلًا أن هذا الاختيار موجود قبل أن يمارسوا، أم أنهم يتركون أنفسهم للخيار الذي يعرضه الواجهة أولًا.
هل استخدم أي شخص Exercise-Delivery بدل Net-Settle، ولماذا؟
#termmax @TermMax
تمّ التحقق
@Dusk عُدتُ عبر إعلان داكس الخاص ببنيته من يونيو 2025، وقد تغيّر الإطار منذ التموضع الأسبق لداكس.
ثلاث طبقات، وفقًا لوثائق داكس الحالية: DuskDS في القاعدة، الإجماع والتسوية وإتاحة البيانات ونماذج المعاملات الأصلية. DuskEVM في الأعلى، مبني على OP Stack، وتوافق كامل مع Solidity. DuskVM إلى جانب ذلك، عقود Rust/WASM تعمل مباشرة على L1 للاستخدامات التي تتطلب خصوصية أصلية. #dusk
ما الذي تغيّر من إعلان التطور لعام 2025 الأصلي إلى ما هو عليه الآن: تم وصف DuskVM في ذلك الوقت على أنه "قادم". أما الوثائق الحالية فتصفه كبنية تحتية تعمل بالفعل، وليس كبند ضمن خريطة طريق. وبشكل منفصل، تصف تحديثات داكس لعام 2026 نفسها أن NPEX لتطبيقات الأوراق المالية المُنظَّمة يتم طرحه فعليًا على DuskEVM تحديدًا — وأريد أن أكون دقيقًا بأن هذا موصوف كطرح مستمر، وليس شيئًا يمكنني تأكيده كإطلاق مكتمل وجاهز بالكامل للتشغيل بعد. $DUSK
تفصيل واحد يربط الطبقات الثلاث معًا بشكل ملموس، بغض النظر عن حالة ذلك الطرح: رمز DUSK واحد يدعم كل طبقة، وجسر أصلي تُديره جهة مُتحقق (validator) ينقل القيمة بينها دون أصول مُغلّفة أو وسطاء حفظ.
ما يزال هذا نظامًا يتطور، وليس نظامًا نهائيًا. تؤكد وثائق داكس الخاصة بـ DuskEVM أنه يعمل حاليًا بوظيفة المُرسِل/المُسلسِل (sequencer) فقط، دون وجود mempool عام حتى الآن — قيدٌ محددٌ ومؤرَّخ يقع أسفل أي شيء يتم نشره بنشاط فوقه حاليًا.
إذا كان لدى أي شخص تتبّع لكيفية تقدم طرح NPEX فعليًا مقابل هذه البنية في الواقع، فسأرغب في مقارنة الملاحظات بما وجدته هنا.
#dusk $DUSK @Dusk
ثلاث طبقات، وفقًا لوثائق داكس الحالية: DuskDS في القاعدة، الإجماع والتسوية وإتاحة البيانات ونماذج المعاملات الأصلية. DuskEVM في الأعلى، مبني على OP Stack، وتوافق كامل مع Solidity. DuskVM إلى جانب ذلك، عقود Rust/WASM تعمل مباشرة على L1 للاستخدامات التي تتطلب خصوصية أصلية. #dusk
ما الذي تغيّر من إعلان التطور لعام 2025 الأصلي إلى ما هو عليه الآن: تم وصف DuskVM في ذلك الوقت على أنه "قادم". أما الوثائق الحالية فتصفه كبنية تحتية تعمل بالفعل، وليس كبند ضمن خريطة طريق. وبشكل منفصل، تصف تحديثات داكس لعام 2026 نفسها أن NPEX لتطبيقات الأوراق المالية المُنظَّمة يتم طرحه فعليًا على DuskEVM تحديدًا — وأريد أن أكون دقيقًا بأن هذا موصوف كطرح مستمر، وليس شيئًا يمكنني تأكيده كإطلاق مكتمل وجاهز بالكامل للتشغيل بعد. $DUSK
تفصيل واحد يربط الطبقات الثلاث معًا بشكل ملموس، بغض النظر عن حالة ذلك الطرح: رمز DUSK واحد يدعم كل طبقة، وجسر أصلي تُديره جهة مُتحقق (validator) ينقل القيمة بينها دون أصول مُغلّفة أو وسطاء حفظ.
ما يزال هذا نظامًا يتطور، وليس نظامًا نهائيًا. تؤكد وثائق داكس الخاصة بـ DuskEVM أنه يعمل حاليًا بوظيفة المُرسِل/المُسلسِل (sequencer) فقط، دون وجود mempool عام حتى الآن — قيدٌ محددٌ ومؤرَّخ يقع أسفل أي شيء يتم نشره بنشاط فوقه حاليًا.
إذا كان لدى أي شخص تتبّع لكيفية تقدم طرح NPEX فعليًا مقابل هذه البنية في الواقع، فسأرغب في مقارنة الملاحظات بما وجدته هنا.
#dusk $DUSK @Dusk
تمّ التحقق
@TermMax قضيت بعض الوقت في رسم آلية خيارات TermMax Alpha، متوقعًا ملف المخاطر المعتاد للخيارات ذات الطبيعة المفتوحة.
لم يكن هذا ما وجدته. يعني “Going Long” شراء Call، و“Short” يعني شراء Put، وكلاهما يتم ضد طرف مقابل تسميه المستندات “Dual Investment” — وهو بائع الخيار. يتم تعريف “Max Cost” بدقة على أنه القسط المدفوع، والمقوّم أساسًا بـ USDT. يتم تنفيذ التسوية عبر Exercise-Net-Settle أو Exercise-Delivery، وفي كلتا الحالتين تم تثبيت أقصى خسارة ممكنة لحظة فتح المركز.
لم تبدُ أي من هذه المصطلحات مهمة بشكل خاص في حد ذاتها. لكن سياق الإطلاق جعلني أتوقف. تم إطلاق TermMax Alpha على شبكة BNB Chain mainnet في 12 نوفمبر 2025، بواسطة Term Structure Labs، وبدعم من Cumberland DRW — وهي شركة تداول مؤسسية حقيقية، وليست مجرد حيلة إدراج توكن.
يهم هذا الدعم لأنه ما الذي يحله المنتج فعليًا. عندما تُدرج Binance Alpha توكنًا جديدًا، غالبًا ما ينتظر المتداولون أسابيع قبل أن تظهر عقود الدوام في أي مكان. يوجد TermMax Alpha تحديدًا لسد هذه الفجوة — تعرض مُرافَع بتكلفة محددة ومقفلة، متاح من اليوم الأول للإدراج بدلًا من الانتظار لأسابيع لاحقة. #TermMax
ما لفت انتباهي هو أن هذا يجعل TermMax Alpha فعليًا بنية تحتية حساسة للوقت — ترتبط أهميتها بمدى سرعة استمرار إدراجات Binance Alpha الجديدة، وليس بميزة ثابتة تبقى بلا حركة.
لم أتحقق بعد من عدد أسواق Alpha المباشرة النشطة حاليًا، أو مدى ضيق فروقات السعر على أحدث الإدراجات.
Long or Short?
#termmax @TermMax
لم يكن هذا ما وجدته. يعني “Going Long” شراء Call، و“Short” يعني شراء Put، وكلاهما يتم ضد طرف مقابل تسميه المستندات “Dual Investment” — وهو بائع الخيار. يتم تعريف “Max Cost” بدقة على أنه القسط المدفوع، والمقوّم أساسًا بـ USDT. يتم تنفيذ التسوية عبر Exercise-Net-Settle أو Exercise-Delivery، وفي كلتا الحالتين تم تثبيت أقصى خسارة ممكنة لحظة فتح المركز.
لم تبدُ أي من هذه المصطلحات مهمة بشكل خاص في حد ذاتها. لكن سياق الإطلاق جعلني أتوقف. تم إطلاق TermMax Alpha على شبكة BNB Chain mainnet في 12 نوفمبر 2025، بواسطة Term Structure Labs، وبدعم من Cumberland DRW — وهي شركة تداول مؤسسية حقيقية، وليست مجرد حيلة إدراج توكن.
يهم هذا الدعم لأنه ما الذي يحله المنتج فعليًا. عندما تُدرج Binance Alpha توكنًا جديدًا، غالبًا ما ينتظر المتداولون أسابيع قبل أن تظهر عقود الدوام في أي مكان. يوجد TermMax Alpha تحديدًا لسد هذه الفجوة — تعرض مُرافَع بتكلفة محددة ومقفلة، متاح من اليوم الأول للإدراج بدلًا من الانتظار لأسابيع لاحقة. #TermMax
ما لفت انتباهي هو أن هذا يجعل TermMax Alpha فعليًا بنية تحتية حساسة للوقت — ترتبط أهميتها بمدى سرعة استمرار إدراجات Binance Alpha الجديدة، وليس بميزة ثابتة تبقى بلا حركة.
لم أتحقق بعد من عدد أسواق Alpha المباشرة النشطة حاليًا، أو مدى ضيق فروقات السعر على أحدث الإدراجات.
Long or Short?
#termmax @TermMax
Long (call)
75%
Short (put)
0%
Neither, too risky
25%
4 الأصوات • تمّ إغلاق التصويت
·
--
🎙️ الآن من هو من، وما هو ما. ماذا تريد باينانس فعلاً 😂😂
إنهاء
01 ساعة 56 دقيقة 10 ثانية
431
0
دالة تجزئة صديقة للـSNARK مصممة بواسطة فريق Dusk الخاص بهم خصيصًا للتجزئة المقاومة للتصادم داخل دوائر المعرفة الصفرية.
Mohsin_Trader_King
·
--
كنت جالسًا مع سؤال: لا توضح وثائق Dusk مباشرةً بأرقام دقيقة—هل يمكن لِدفترين مختلفين من Phoenix أن ينتجا نفس قيمة المُبطِّل (nullifier)؟
ما أستطيع تأكيده بدقة: يذكر مستودع Phoenix الخاص بـ Dusk أن المُبطِّل يتم حسابه خصيصًا بحيث لا يستطيع مُراقب خارجي ربطه بالملاحظة التي جاء منها. يتم تجزئة كل ملاحظة (hashing) لتُضاف إلى أوراق (leaves) في شجرة ميركل للملاحظات، وإنفاق (spending) واحدة ينتج قيمة مُبطِّل حتمية مرتبطة ببيانات تلك الملاحظة بعينها.
أما التجزئة الكامنة وراء ذلك—عبر هيكل شجرة Merkle الخاص بـ Dusk والعمليات التشفيرية الأوسع—فتعمل على Poseidon، وهي دالة تجزئة صديقة لـ SNARK صُممت بواسطة فريق Dusk نفسه خصيصًا للتجزئة المقاومة للتصادم داخل دوائر إثبات المعرفة الصفرية (zero-knowledge circuits). هذا ليس مجرد تجزئة عامة مأخوذة جاهزًا؛ بل مُصمَّم لهذا النوع تحديدًا من أعمال الالتزام (commitment) المولّد لـ ZK.
لكن المقاومة للتصادم ليست هي نفسها ضمان عدم وقوع التصادم. أي دالة تجزئة، بما في ذلك Poseidon، تحمل احتمالًا نظريًا (صغيرًا جدًا بشكل فلكي) أن ينتج عن مدخلين مختلفين المخرَج نفسه—وهذا هو جوهر التجزئة ذاته، وليس ضعفًا خاصًا بـ Dusk.
ما لم أجدْه في المواد الصادرة عن Dusk هو أي رقم منشور لاحتمال التصادم خاص بمعلمات Poseidon لديهم تحديدًا، أو توثيقًا لاختبارات تصادم مخصصة تتجاوز الخصائص الأمنية العامة التي يرثها Poseidon بحكم تصميمه.
إذا كان لدى أي شخص تقرير تدقيق يتناول هذه الخاصية تحديدًا لِتنفيذ Dusk، فأود مقارنته بما هو موثق علنًا.
#dusk $DUSK @Dusk
ما أستطيع تأكيده بدقة: يذكر مستودع Phoenix الخاص بـ Dusk أن المُبطِّل يتم حسابه خصيصًا بحيث لا يستطيع مُراقب خارجي ربطه بالملاحظة التي جاء منها. يتم تجزئة كل ملاحظة (hashing) لتُضاف إلى أوراق (leaves) في شجرة ميركل للملاحظات، وإنفاق (spending) واحدة ينتج قيمة مُبطِّل حتمية مرتبطة ببيانات تلك الملاحظة بعينها.
أما التجزئة الكامنة وراء ذلك—عبر هيكل شجرة Merkle الخاص بـ Dusk والعمليات التشفيرية الأوسع—فتعمل على Poseidon، وهي دالة تجزئة صديقة لـ SNARK صُممت بواسطة فريق Dusk نفسه خصيصًا للتجزئة المقاومة للتصادم داخل دوائر إثبات المعرفة الصفرية (zero-knowledge circuits). هذا ليس مجرد تجزئة عامة مأخوذة جاهزًا؛ بل مُصمَّم لهذا النوع تحديدًا من أعمال الالتزام (commitment) المولّد لـ ZK.
لكن المقاومة للتصادم ليست هي نفسها ضمان عدم وقوع التصادم. أي دالة تجزئة، بما في ذلك Poseidon، تحمل احتمالًا نظريًا (صغيرًا جدًا بشكل فلكي) أن ينتج عن مدخلين مختلفين المخرَج نفسه—وهذا هو جوهر التجزئة ذاته، وليس ضعفًا خاصًا بـ Dusk.
ما لم أجدْه في المواد الصادرة عن Dusk هو أي رقم منشور لاحتمال التصادم خاص بمعلمات Poseidon لديهم تحديدًا، أو توثيقًا لاختبارات تصادم مخصصة تتجاوز الخصائص الأمنية العامة التي يرثها Poseidon بحكم تصميمه.
إذا كان لدى أي شخص تقرير تدقيق يتناول هذه الخاصية تحديدًا لِتنفيذ Dusk، فأود مقارنته بما هو موثق علنًا.
#dusk $DUSK @Dusk
يذهب 5% إلى المُصفّي كتعويض له مقابل تنفيذ عملية التصفية
Mohsin_Trader_King
·
--
عدت تحديدًا إلى مستندات تصفية TermMax لتتبع المكان الذي تنتهي إليه أموال الغرامة فعليًا.
الأمر بسيط: 10% من قيمة الدين المُصفّى، تُسحب من الضمان الخاص بالمقترض نفسه كلما حدثت عملية التصفية. والأقل وضوحًا هو التقسيم — ليس مبلغًا واحدًا تُمنحُه جهة واحدة. 5% تذهب إلى المُصفّي كمكافأة له مقابل تنفيذ عملية التصفية. أما الـ5% الأخرى فتتجه مباشرةً إلى الاحتياطي الخاص بالبروتوكول.
ما تغيّر بالنسبة لي هو إدراكي أن الأمر ليس مجرد رسوم عقوبة؛ بل هو هيكل حوافز من جزأين توثّقه المستندات صراحةً حول استقرار البروتوكول — مصمم للحفاظ على نسبة LTV المطلوبة على القروض، مع إعطاء المُصفّين سببًا حقيقيًا للتحرك بسرعة. تؤكد الصيغة أيضًا ترتيب الأولويات: يغطي الضمان المُصفّى أولًا مكافأة المُصفّي، ثم يُطبّق الباقي على غرامة البروتوكول، وكل ذلك مُقيَّد صراحةً بالمركز الفعلي للمقترض — بمعنى أن الغرامة رياضيًا لا يمكن أن تتجاوز ما يمكن أن يغطيه ضمان المقترض نفسه، بغض النظر عن كيفية سير الصيغة.
يجدر التنبيه: المستندات تُوضح التقسيم والسقف بوضوح، لكنها لا تذكر على ماذا يُنفق الاحتياطي عند تراكمه، أو ضمن أي ظروف يتم السحب منه.
الخطوة التالية التي سأتحقق منها: كم حجم هذا الاحتياطي الذي نما بالفعل مقارنةً بإجمالي حجم التصفية حتى الآن.
#termmax @TermMax $BTW
$RICE
$GPS
الأمر بسيط: 10% من قيمة الدين المُصفّى، تُسحب من الضمان الخاص بالمقترض نفسه كلما حدثت عملية التصفية. والأقل وضوحًا هو التقسيم — ليس مبلغًا واحدًا تُمنحُه جهة واحدة. 5% تذهب إلى المُصفّي كمكافأة له مقابل تنفيذ عملية التصفية. أما الـ5% الأخرى فتتجه مباشرةً إلى الاحتياطي الخاص بالبروتوكول.
ما تغيّر بالنسبة لي هو إدراكي أن الأمر ليس مجرد رسوم عقوبة؛ بل هو هيكل حوافز من جزأين توثّقه المستندات صراحةً حول استقرار البروتوكول — مصمم للحفاظ على نسبة LTV المطلوبة على القروض، مع إعطاء المُصفّين سببًا حقيقيًا للتحرك بسرعة. تؤكد الصيغة أيضًا ترتيب الأولويات: يغطي الضمان المُصفّى أولًا مكافأة المُصفّي، ثم يُطبّق الباقي على غرامة البروتوكول، وكل ذلك مُقيَّد صراحةً بالمركز الفعلي للمقترض — بمعنى أن الغرامة رياضيًا لا يمكن أن تتجاوز ما يمكن أن يغطيه ضمان المقترض نفسه، بغض النظر عن كيفية سير الصيغة.
يجدر التنبيه: المستندات تُوضح التقسيم والسقف بوضوح، لكنها لا تذكر على ماذا يُنفق الاحتياطي عند تراكمه، أو ضمن أي ظروف يتم السحب منه.
الخطوة التالية التي سأتحقق منها: كم حجم هذا الاحتياطي الذي نما بالفعل مقارنةً بإجمالي حجم التصفية حتى الآن.
#termmax @TermMax $BTW
$RICE
$GPS
تمّ التحقق
@Dusk بحثت عمّا يحدث فعليًا عندما تفشل عملية التحقق من برهان صِفر-معرفة (Zero-Knowledge) الخاص بـ Phoenix، لأن معظم الشروحات تتوقف عند "يتم التحقق من البرهان" فقط.
تؤكد بنية Dusk أنّ البرهان يجب أن يُظهر خصائص معيّنة معًا — ملكية الملاحظة التي يتم إنفاقها، سلامة الرصيد عبر المدخلات والمخرجات، وعدم وجود إنفاق مزدوج — وكل ذلك مُشفّر داخل البرهان نفسه، وليس مُتحققًا عبر فحوصات جانبية منفصلة. $DUSK
هذه هي النقطة التي تستحق التوقف عندها. إذا لم تتحقق أي واحدة من هذه الخصائص، يفشل البرهان بالكامل كوحدة واحدة. لا توجد مسار "جزئي" حيث تمر فحوصات الرصيد لكن تفشل الملكية بصمت.
تتبعت ما يعنيه ذلك عمليًا: يعني رفض البرهان أن المعاملة لا تُدرج أصلًا. وقت التشغيل لا يحاول إنقاذها أو معالجتها جزئيًا. ببساطة، المعاملة لا تحدث، ولا يتم تسجيل أي شيء عن المحاولة الفاشلة كتغيير في الحالة. #dusk
ما لم أتحقق منه من المواد الخاصة بـ Dusk هو ما إذا كان البرهان الفاشل يترك أي أثر في سجلات الـ mempool يمكن لمشغّل العقدة فحصه لاحقًا، أم أنه يُرفض دون أي سجل تشخيصي على الإطلاق.
الشيء التالي الذي سأتأكد منه: هل تُظهر أدوات محفظة Dusk الحالية سببًا محددًا لفشل البرهان، أم تكتفي برفض عام، لأن هذا الفرق مهم جدًا لأي شخص يحاول فعلًا تصحيح/إصلاح معاملة لم تمر.
#dusk $DUSK @Dusk
تؤكد بنية Dusk أنّ البرهان يجب أن يُظهر خصائص معيّنة معًا — ملكية الملاحظة التي يتم إنفاقها، سلامة الرصيد عبر المدخلات والمخرجات، وعدم وجود إنفاق مزدوج — وكل ذلك مُشفّر داخل البرهان نفسه، وليس مُتحققًا عبر فحوصات جانبية منفصلة. $DUSK
هذه هي النقطة التي تستحق التوقف عندها. إذا لم تتحقق أي واحدة من هذه الخصائص، يفشل البرهان بالكامل كوحدة واحدة. لا توجد مسار "جزئي" حيث تمر فحوصات الرصيد لكن تفشل الملكية بصمت.
تتبعت ما يعنيه ذلك عمليًا: يعني رفض البرهان أن المعاملة لا تُدرج أصلًا. وقت التشغيل لا يحاول إنقاذها أو معالجتها جزئيًا. ببساطة، المعاملة لا تحدث، ولا يتم تسجيل أي شيء عن المحاولة الفاشلة كتغيير في الحالة. #dusk
ما لم أتحقق منه من المواد الخاصة بـ Dusk هو ما إذا كان البرهان الفاشل يترك أي أثر في سجلات الـ mempool يمكن لمشغّل العقدة فحصه لاحقًا، أم أنه يُرفض دون أي سجل تشخيصي على الإطلاق.
الشيء التالي الذي سأتأكد منه: هل تُظهر أدوات محفظة Dusk الحالية سببًا محددًا لفشل البرهان، أم تكتفي برفض عام، لأن هذا الفرق مهم جدًا لأي شخص يحاول فعلًا تصحيح/إصلاح معاملة لم تمر.
#dusk $DUSK @Dusk
@TermMax قضيت بعض الوقت في رسم نموذج نظام الرموز الثلاثة الخاص بـ TermMax، وأعادت لي إحدى السطور في الوثائق صياغة الفكرة بالكامل: قيمة الضمان تساوي قيمة GT زائد قيمة القرض نفسها، حيث تُعرَّف قيمة GT بأنها الضمان ناقص قيمة الدين. الرموز ليست مجرد ثلاثة كائنات منفصلة؛ بل هي أجزاء من معادلة واحدة يجب أن تتوازن.
FT هو توكن ERC-20 يعمل كسند صفري القسيمة — 110 FT-USDC يُسترد بـ 110 USDC عند الاستحقاق، لذا فإن شرائه مقابل 100 USDC يثبّت عائدًا بنسبة 10% على مدة سنة واحدة. لكن الوثائق تحدد أن هذا الرقم يتدرّج مع مدة الاستحقاق، لا أنه ثابت؛ فـ FT لمدة 180 يومًا عند نفس الخصم يُحوَّل سنويًا إلى نحو 20%، وليس 10%. يُعرَّف XT بدقة أكثر مما توقعت أيضًا: ليس مجرد "النصف الآخر"، بل هو تحديدًا القيمة الحالية للفائدة التي يُبقيها المقترض مستحقة، مفصولة عن المبلغ الأصلي. GT هو غلاف المركز — ERC-721، يتتبع الضمان والدين كوحدة واحدة، ومحدود بـ MLTV.
ما شد انتباهي هو أن XT ليس مجرد حشو؛ بل هو أداة مالية مميزة تمثل مخاطر الفائدة بوحدها، ومُسعّرة بشكل منفصل عن مخاطر المبلغ الأصلي في FT. فصل المبلغ الأصلي عن الفائدة على مستوى التوكن هو ما يجعل معادلة النظام الصفرية التوازن — لا تظهر قيمة ولا تختفي في أي مكان على طول السلسلة. #TermMax
الجزء الناقص بالنسبة لي هو عمق السوق الثانوي الحقيقي لـ XT تحديدًا، لأن تسعيره يتعامل مع شيء ضيق مثل مخاطر الفائدة قصيرة الأجل وحدها.
"أي توكن يهمك أكثر؟"
#termmax
@TermMax
FT هو توكن ERC-20 يعمل كسند صفري القسيمة — 110 FT-USDC يُسترد بـ 110 USDC عند الاستحقاق، لذا فإن شرائه مقابل 100 USDC يثبّت عائدًا بنسبة 10% على مدة سنة واحدة. لكن الوثائق تحدد أن هذا الرقم يتدرّج مع مدة الاستحقاق، لا أنه ثابت؛ فـ FT لمدة 180 يومًا عند نفس الخصم يُحوَّل سنويًا إلى نحو 20%، وليس 10%. يُعرَّف XT بدقة أكثر مما توقعت أيضًا: ليس مجرد "النصف الآخر"، بل هو تحديدًا القيمة الحالية للفائدة التي يُبقيها المقترض مستحقة، مفصولة عن المبلغ الأصلي. GT هو غلاف المركز — ERC-721، يتتبع الضمان والدين كوحدة واحدة، ومحدود بـ MLTV.
ما شد انتباهي هو أن XT ليس مجرد حشو؛ بل هو أداة مالية مميزة تمثل مخاطر الفائدة بوحدها، ومُسعّرة بشكل منفصل عن مخاطر المبلغ الأصلي في FT. فصل المبلغ الأصلي عن الفائدة على مستوى التوكن هو ما يجعل معادلة النظام الصفرية التوازن — لا تظهر قيمة ولا تختفي في أي مكان على طول السلسلة. #TermMax
الجزء الناقص بالنسبة لي هو عمق السوق الثانوي الحقيقي لـ XT تحديدًا، لأن تسعيره يتعامل مع شيء ضيق مثل مخاطر الفائدة قصيرة الأجل وحدها.
"أي توكن يهمك أكثر؟"
#termmax
@TermMax
FT (fixed yield)
67%
XT (interest pricing)
33%
GT (leverage wrapper)
0%
All three together
0%
6 الأصوات • تمّ إغلاق التصويت
@TermMax افترضت أن التصفية في TermMax تعني الشيء نفسه كما هو الحال في كل مكان آخر استخدمته — عبور خط الخطر، خسارة كامل المركز في لقطة واحدة، بدون منطقة وسط.
انهار هذا الافتراض عندما قرأت الصيغة الفعلية. تؤدي التصفية إلى أحد مسارين: عندما يساوي LTV أو يتجاوز عتبة LLTV في السوق، أو عندما يفشل المقترض في سداد دفعة الاستحقاق الثابتة، وهو ما يفتح نافذة تصفية لمدة ساعتين بغض النظر عن السعر. $ACE
وهذه هي الأرقام التي أعادت تشكيل الصورة. إذا تجاوز الدين القائم 10,000 دولار، يتم تحديد عمال التصفية بنسبة 50% فقط من إجمالي قيمة الدين لكل حدث. يتم حساب الحد الأقصى من الضمان القابل للتصفية على أنه إجمالي الضمان مضروبًا في الدين المُصفّى، مقسومًا على إجمالي الدين — نسبة صُممت بحيث يتحسن LTV بعد كل تصفية بدل أن ينهار إلى الصفر. لا تحدث التصفية الكاملة إلا إذا انخفض الدين إلى الصفر تمامًا، وعندها يتم إرجاع أي ضمان متبقٍ تلقائيًا إلى المقترض.
العقوبة هي 10% من قيمة الدين المُصفّى، ويتم تقسيمها بالتساوي على نصفين — 5% إلى المُصفّي كمكافأة، و5% إلى محمية الاحتياطي في البروتوكول.
ما لا تقوله الوثائق هو ما نسبة المراكز الفعلية التي تتجاوز 10,000 دولار من الدين فعليًا مقابل تلك التي تبقى تحت هذا الخط، حيث لا يتم تطبيق السقف أصلًا. $CLO
الاختبار الحقيقي لـ TMX هو ما إذا كان هذا السقف بنسبة 50% يحمي المقترضين الكبار بشكل ملموس، أم أنه فقط يحوّل تصفية واحدة إلى تصفيتين أصغر خلفًا لإحدى الأخرى. $CYS
هل أحد يتابع أعداد التصفية الجزئية مقابل التصفية الكاملة على TermMax حتى الآن؟
#termmax @TermMax
انهار هذا الافتراض عندما قرأت الصيغة الفعلية. تؤدي التصفية إلى أحد مسارين: عندما يساوي LTV أو يتجاوز عتبة LLTV في السوق، أو عندما يفشل المقترض في سداد دفعة الاستحقاق الثابتة، وهو ما يفتح نافذة تصفية لمدة ساعتين بغض النظر عن السعر. $ACE
وهذه هي الأرقام التي أعادت تشكيل الصورة. إذا تجاوز الدين القائم 10,000 دولار، يتم تحديد عمال التصفية بنسبة 50% فقط من إجمالي قيمة الدين لكل حدث. يتم حساب الحد الأقصى من الضمان القابل للتصفية على أنه إجمالي الضمان مضروبًا في الدين المُصفّى، مقسومًا على إجمالي الدين — نسبة صُممت بحيث يتحسن LTV بعد كل تصفية بدل أن ينهار إلى الصفر. لا تحدث التصفية الكاملة إلا إذا انخفض الدين إلى الصفر تمامًا، وعندها يتم إرجاع أي ضمان متبقٍ تلقائيًا إلى المقترض.
العقوبة هي 10% من قيمة الدين المُصفّى، ويتم تقسيمها بالتساوي على نصفين — 5% إلى المُصفّي كمكافأة، و5% إلى محمية الاحتياطي في البروتوكول.
ما لا تقوله الوثائق هو ما نسبة المراكز الفعلية التي تتجاوز 10,000 دولار من الدين فعليًا مقابل تلك التي تبقى تحت هذا الخط، حيث لا يتم تطبيق السقف أصلًا. $CLO
الاختبار الحقيقي لـ TMX هو ما إذا كان هذا السقف بنسبة 50% يحمي المقترضين الكبار بشكل ملموس، أم أنه فقط يحوّل تصفية واحدة إلى تصفيتين أصغر خلفًا لإحدى الأخرى. $CYS
هل أحد يتابع أعداد التصفية الجزئية مقابل التصفية الكاملة على TermMax حتى الآن؟
#termmax @TermMax
تمّ التحقق
@Dusk تحققتُ من الطريقة التي يعرّف بها Dusk نفسه مقابل Ethereum تحديدًا، نظرًا لأن معظم المقارنات بين سلاسل الخصوصية تتجه عادةً إلى Zcash أو Monero بدلًا من ذلك.
يذكر موقع Dusk الحالي الصفحة الرئيسية بشكل مباشر: بنية تحتية للأصول الرقمية الخاضعة للتنظيم، سرّية افتراضيًا، مع إثباتات معرفة-صفرية ورؤية مُتحكم بها لأغراض التدقيق والإفصاح المُنظَّم. إن هذا التأطير أكثر حدّة بشكل ملحوظ من طرح Dusk العام السابق، الذي كان يركّز أكثر على الجمع بين معاملات Moonlight العامة ونموذج Phoenix المُحافظ على الخصوصية للتمويل المُنظَّم بشكل عام، دون المراهنة بقوة على مقارنة مباشرة مع شفافيات Ethereum.
ما الذي تغيّر بين هذين التأطيرين يستحق التوقف عنده. الافتراضي في Ethereum — كل رصيد، كل استدعاء، مرئي لأي شخص — يعمل جيدًا للتنسيق العام. أمّا DuskEVM لدى Dusk فيوفّر تكافؤًا كاملاً مع EVM باستخدام نفس الأدوات التي يعرفها مطورو Ethereum بالفعل، مع الحفاظ في الوقت نفسه على موقف Dusk المُبهم/المحمّي افتراضيًا «من تحت». نموذج التنفيذ لا يُرفض. الافتراضي من ناحية الرؤية هو. $DUSK
ويورد موقع Dusk نفسه الآن شركاء مُنظّمين داخل الاتحاد الأوروبي بشكل محدد، يعملون فعليًا انطلاقًا من هذا الطرح — موفّر مرخّص لبنية تحتية للأسواق ضمن نظام DLT Pilot Regime، إلى جانب منصة أوروبية مُنظّمة تستكشف الإصدار على السلسلة مباشرةً من خلال هذا التأطير.
هذا تحرّك مؤسسي حقيقي، وليس مجرد رسائل — لكن ما إذا كان يترجم إلى هجرة مطورين ذات مغزى بعيدًا عن الحزم التي تُبنى على Ethereum أولًا تحديدًا بسبب مشكلة الشفافية، فشيء لم أجد أرقام اعتماد تؤكد ذلك من أي جهة. #dusk
إذا كان أي شخص قد تتبّع بيانات هجرة فعلية مرتبطة تحديدًا بحجة الشفافية، بدلًا من الترويج الأوسع للامتثال الذي يقدمه Dusk، فكنت أرغب في مقارنتها بما تم تسميته علنًا ضمن قائمة شركاء Dusk الخاصة.
#dusk $DUSK @Dusk
يذكر موقع Dusk الحالي الصفحة الرئيسية بشكل مباشر: بنية تحتية للأصول الرقمية الخاضعة للتنظيم، سرّية افتراضيًا، مع إثباتات معرفة-صفرية ورؤية مُتحكم بها لأغراض التدقيق والإفصاح المُنظَّم. إن هذا التأطير أكثر حدّة بشكل ملحوظ من طرح Dusk العام السابق، الذي كان يركّز أكثر على الجمع بين معاملات Moonlight العامة ونموذج Phoenix المُحافظ على الخصوصية للتمويل المُنظَّم بشكل عام، دون المراهنة بقوة على مقارنة مباشرة مع شفافيات Ethereum.
ما الذي تغيّر بين هذين التأطيرين يستحق التوقف عنده. الافتراضي في Ethereum — كل رصيد، كل استدعاء، مرئي لأي شخص — يعمل جيدًا للتنسيق العام. أمّا DuskEVM لدى Dusk فيوفّر تكافؤًا كاملاً مع EVM باستخدام نفس الأدوات التي يعرفها مطورو Ethereum بالفعل، مع الحفاظ في الوقت نفسه على موقف Dusk المُبهم/المحمّي افتراضيًا «من تحت». نموذج التنفيذ لا يُرفض. الافتراضي من ناحية الرؤية هو. $DUSK
ويورد موقع Dusk نفسه الآن شركاء مُنظّمين داخل الاتحاد الأوروبي بشكل محدد، يعملون فعليًا انطلاقًا من هذا الطرح — موفّر مرخّص لبنية تحتية للأسواق ضمن نظام DLT Pilot Regime، إلى جانب منصة أوروبية مُنظّمة تستكشف الإصدار على السلسلة مباشرةً من خلال هذا التأطير.
هذا تحرّك مؤسسي حقيقي، وليس مجرد رسائل — لكن ما إذا كان يترجم إلى هجرة مطورين ذات مغزى بعيدًا عن الحزم التي تُبنى على Ethereum أولًا تحديدًا بسبب مشكلة الشفافية، فشيء لم أجد أرقام اعتماد تؤكد ذلك من أي جهة. #dusk
إذا كان أي شخص قد تتبّع بيانات هجرة فعلية مرتبطة تحديدًا بحجة الشفافية، بدلًا من الترويج الأوسع للامتثال الذي يقدمه Dusk، فكنت أرغب في مقارنتها بما تم تسميته علنًا ضمن قائمة شركاء Dusk الخاصة.
#dusk $DUSK @Dusk
@Dusk اعتدتُ افتراض وجود مُتحقّق على Dusk يلزم أن يرى تفاصيل المعاملة للتأكد من أنها شرعية.
هذا ليس ما يحدث مع Phoenix.
تتبّعتُ ما يتلقّاه المُتحقّق فعليًا بدلًا من البيانات الخام. تؤكد مواد Dusk الخاصة بالمعمارية أن Phoenix تستخدم إثباتات المعرفة الصفرية تحديدًا لإثبات ملكية المخرجات غير المنفقة ومنع الإنفاق المزدوج — يتحقق المُتحقّق من الإثبات، لا من المعاملة نفسها.
همم.
فما الذي يوجد داخل ذلك الإثبات فعليًا، ميكانيكيًا؟
جلستُ مع هذا لفترة. يُثبت المنفِّذ معرفة المسار إلى جذر شجرة ميركل، ومعرفة فتح الالتزام — وهذا يعني أن الإثبات يبرهن رياضيًا أن الملاحظة موجودة داخل الشجرة وأن المنفِّذ يعرف حقًا ما بداخلها، دون تعريض محتواها أو موقعها لأي شخص يراقب.
كما أن الإنفاق نفسه يتطلب مفتاحًا سريًا معروفًا حصريًا لمالك الملاحظة — لذا حتى خطوة توليد الإثبات لا يمكن أن تتم دون معلومة واحدة لا يملكها أحد غيره.
هذه ضمانة أغرب مما تبدو للوهلة الأولى. المُتحقّق لا يثق بكلام المُرسِل. ولا يثق أيضًا بطرف ثالث. إنه يؤكد عبارة رياضية — أن شرط انتماء الشجرة مع معرفة الالتزام — صحيح، دون أن يُعيد أبدًا بناء ما جعلها صحيحة.
ولستُ أقول إن ذلك فحصٌ أضعف. إن كان هناك شيء، فرفض النظر قد يكون هو الفكرة كاملة — إذ لا يمكن خداع المُتحقّق ببيانات لا يتلقاها أصلًا.
هل نظامٌ مُصمَّم للتحقق من انتماء شجرة ومعرفة مفتاح سري، دون رؤيته للمبالغ، يكتسب ثقة أكبر من نظام يتحقق عبر النظر مباشرةً إلى البيانات؟
@Dusk #dusk $DUSK
هذا ليس ما يحدث مع Phoenix.
تتبّعتُ ما يتلقّاه المُتحقّق فعليًا بدلًا من البيانات الخام. تؤكد مواد Dusk الخاصة بالمعمارية أن Phoenix تستخدم إثباتات المعرفة الصفرية تحديدًا لإثبات ملكية المخرجات غير المنفقة ومنع الإنفاق المزدوج — يتحقق المُتحقّق من الإثبات، لا من المعاملة نفسها.
همم.
فما الذي يوجد داخل ذلك الإثبات فعليًا، ميكانيكيًا؟
جلستُ مع هذا لفترة. يُثبت المنفِّذ معرفة المسار إلى جذر شجرة ميركل، ومعرفة فتح الالتزام — وهذا يعني أن الإثبات يبرهن رياضيًا أن الملاحظة موجودة داخل الشجرة وأن المنفِّذ يعرف حقًا ما بداخلها، دون تعريض محتواها أو موقعها لأي شخص يراقب.
كما أن الإنفاق نفسه يتطلب مفتاحًا سريًا معروفًا حصريًا لمالك الملاحظة — لذا حتى خطوة توليد الإثبات لا يمكن أن تتم دون معلومة واحدة لا يملكها أحد غيره.
هذه ضمانة أغرب مما تبدو للوهلة الأولى. المُتحقّق لا يثق بكلام المُرسِل. ولا يثق أيضًا بطرف ثالث. إنه يؤكد عبارة رياضية — أن شرط انتماء الشجرة مع معرفة الالتزام — صحيح، دون أن يُعيد أبدًا بناء ما جعلها صحيحة.
ولستُ أقول إن ذلك فحصٌ أضعف. إن كان هناك شيء، فرفض النظر قد يكون هو الفكرة كاملة — إذ لا يمكن خداع المُتحقّق ببيانات لا يتلقاها أصلًا.
هل نظامٌ مُصمَّم للتحقق من انتماء شجرة ومعرفة مفتاح سري، دون رؤيته للمبالغ، يكتسب ثقة أكبر من نظام يتحقق عبر النظر مباشرةً إلى البيانات؟
@Dusk #dusk $DUSK
@TermMax كنت أظن أن القرض يظهر فقط كرقم يجلس داخل رصيد حساب ما.
كلما نظرت أكثر إلى كيفية هيكلة TermMax للمراكز فعليًا، قلَّت صحة ذلك.
يقوم المقترض بتأمين ضمان. تصنع TermMax Token ربطًا (Gearing Token) ضده، وهو ERC-721، وليس قيدًا في دفتر الأستاذ. يتم تثبيت رمز الدين، ورمز الضمان، وتاريخ الاستحقاق كلها على مستوى السوق قبل أن يوجد ذلك الـ GT أصلاً.
الـ GT نفسه يسجل بالضبط شيئين. مقدار الضمان الموجود داخله. وكم عدد رموز Fixed-Rate (سعر ثابت) تم سكّه مقابل ذلك الضمان، مع سقف يحدده الحد الأقصى للقيمة مقابل القرض في السوق. فمثلاً MLTV بقيمة 0.8 يحوّل 1 ETH إلى ما يصل إلى 800 $USDC من ديْن قابل للسك. #TermMax
لا يوجد تجمع مشترك، ولا مقاصة صافية، ولا رقم ممزوج في أي مكان ضمن التصميم.
أعد قراءة جزء العزل مرتين. تدير TermMax أكثر من 100 سوق اعتبارًا من تحديث مارس 2026، كل واحدة منها معزولة عن الأخرى، بحيث لا ينتقل سعر ضمان سيئ في سوقٍ واحد إلى الـ GTs الموجودة في أي سوقٍ آخر. ليس مجرد تنظيم بالدفاتر. بل حدود.
سَدِّد باستخدام رموز الدين مباشرةً، أو اشترِ رموز الـ FTs في السوق المفتوحة وأعد تسليمها بدلًا من ذلك. في كلتا الحالتين يغلق الـ GT ويُفرج عن الضمان، لكنه لم يندمج أصلاً مع أرقام أي شخص آخر.
لذلك الاقتراض على TermMax ليس رقمًا واحدًا ينمو أو ينكمش. بل هو عدد الـ GTs بقدر ما فتحته، كل واحد يحمل ضمانه الخاص، ودينه الخاص، وتاريخ استحقاقه الخاص، وكل ذلك على حدة.
هل يجعل التتبع على مستوى كل قرض المخاطر أوضح، أم يجعل إدارتها على نطاق واسع أصعب؟
@TermMax #termmax
كلما نظرت أكثر إلى كيفية هيكلة TermMax للمراكز فعليًا، قلَّت صحة ذلك.
يقوم المقترض بتأمين ضمان. تصنع TermMax Token ربطًا (Gearing Token) ضده، وهو ERC-721، وليس قيدًا في دفتر الأستاذ. يتم تثبيت رمز الدين، ورمز الضمان، وتاريخ الاستحقاق كلها على مستوى السوق قبل أن يوجد ذلك الـ GT أصلاً.
الـ GT نفسه يسجل بالضبط شيئين. مقدار الضمان الموجود داخله. وكم عدد رموز Fixed-Rate (سعر ثابت) تم سكّه مقابل ذلك الضمان، مع سقف يحدده الحد الأقصى للقيمة مقابل القرض في السوق. فمثلاً MLTV بقيمة 0.8 يحوّل 1 ETH إلى ما يصل إلى 800 $USDC من ديْن قابل للسك. #TermMax
لا يوجد تجمع مشترك، ولا مقاصة صافية، ولا رقم ممزوج في أي مكان ضمن التصميم.
أعد قراءة جزء العزل مرتين. تدير TermMax أكثر من 100 سوق اعتبارًا من تحديث مارس 2026، كل واحدة منها معزولة عن الأخرى، بحيث لا ينتقل سعر ضمان سيئ في سوقٍ واحد إلى الـ GTs الموجودة في أي سوقٍ آخر. ليس مجرد تنظيم بالدفاتر. بل حدود.
سَدِّد باستخدام رموز الدين مباشرةً، أو اشترِ رموز الـ FTs في السوق المفتوحة وأعد تسليمها بدلًا من ذلك. في كلتا الحالتين يغلق الـ GT ويُفرج عن الضمان، لكنه لم يندمج أصلاً مع أرقام أي شخص آخر.
لذلك الاقتراض على TermMax ليس رقمًا واحدًا ينمو أو ينكمش. بل هو عدد الـ GTs بقدر ما فتحته، كل واحد يحمل ضمانه الخاص، ودينه الخاص، وتاريخ استحقاقه الخاص، وكل ذلك على حدة.
هل يجعل التتبع على مستوى كل قرض المخاطر أوضح، أم يجعل إدارتها على نطاق واسع أصعب؟
@TermMax #termmax
تمّ التحقق
@Dusk اعتقدت سابقًا أن "الإفصاح الانتقائي" مجرد صياغة ألين لكلمة "الشفافية".
جلست مع التصميم الحقيقي لدى Citadel فترة، واتضح أنه ليس كذلك.
الشفافية الكاملة، من النوع الذي يعترض عليه Dusk صراحةً، تعني أن كل مراقب يرى كل سمة مرتبطة بمعاملة أو هوية—سواء احتاجها أم لا. تقوم Citadel بشيء أضيق، وقد تتبعت الآليات الفعلية: ثلاث جهات مميزة، لا اثنتين. يقوم مستخدم بطلب ترخيص على السلسلة من مزود الترخيص. بمجرد إصداره، يتيح هذا الترخيص للمستخدم إنشاء اتصال خاص، خارج السلسلة، مع مزود الخدمة—والذي يتحقق من الادعاء باستخدام ما هو مُخزّن على السلسلة فقط، دون أن يتعلم أي هوية كامنة لدى المستخدم.
همم.
فما الذي يتعلمه مزود الخدمة فعلًا عندما تنجح عملية التحقق؟
فقط أن ادعاءً واحدًا صحيح—الإقامة، أو شريحة العمر، أو الاعتماد، أو أي شيء يغطيه الترخيص. ليس البيانات الأساسية وراء ذلك، ولا أي سمة أخرى يحملها المستخدم، ولا مُعرِّفًا مستمرًا يربط هذا التحقق بتَحقق مستقبلي.
هذا وعد أضيق بكثير من وعد الشفافية. النظام الشفاف بالكامل يخبر الجميع بكل شيء، بشكل دائم، سواء كان ذلك ذا صلة أم لا. البنية الثلاثية في Citadel تخبر مزود خدمة واحدًا شيئًا صحيحًا واحدًا، مُتحققًا مقابل سجل على السلسلة، دون أن يلمس مزود الخدمة هذا الملف الشخصي الكامل للمستخدم.
ليس قولي إن الشفافية خاطئة في كل مكان. التنسيق العام يستفيد فعلًا من أن يرى الجميع دفتر الأستاذ نفسه. لكن الإجراءات المقيدة بالهوية—إثبات الأهلية دون التنازل عن ملف كامل—تحتاج إلى بروتوكول بأدوار ثلاث منفصلة، لا دورين، كي تعمل فعليًا.
هل إثبات حقيقة واحدة عبر ثلاثة أدوار مفصولة ضمان خصوصية أقوى من شفافية "يرى الجميع كل شيء، لذا لا أحد يُخفي أي شيء"؟
@Dusk #dusk $DUSK
جلست مع التصميم الحقيقي لدى Citadel فترة، واتضح أنه ليس كذلك.
الشفافية الكاملة، من النوع الذي يعترض عليه Dusk صراحةً، تعني أن كل مراقب يرى كل سمة مرتبطة بمعاملة أو هوية—سواء احتاجها أم لا. تقوم Citadel بشيء أضيق، وقد تتبعت الآليات الفعلية: ثلاث جهات مميزة، لا اثنتين. يقوم مستخدم بطلب ترخيص على السلسلة من مزود الترخيص. بمجرد إصداره، يتيح هذا الترخيص للمستخدم إنشاء اتصال خاص، خارج السلسلة، مع مزود الخدمة—والذي يتحقق من الادعاء باستخدام ما هو مُخزّن على السلسلة فقط، دون أن يتعلم أي هوية كامنة لدى المستخدم.
همم.
فما الذي يتعلمه مزود الخدمة فعلًا عندما تنجح عملية التحقق؟
فقط أن ادعاءً واحدًا صحيح—الإقامة، أو شريحة العمر، أو الاعتماد، أو أي شيء يغطيه الترخيص. ليس البيانات الأساسية وراء ذلك، ولا أي سمة أخرى يحملها المستخدم، ولا مُعرِّفًا مستمرًا يربط هذا التحقق بتَحقق مستقبلي.
هذا وعد أضيق بكثير من وعد الشفافية. النظام الشفاف بالكامل يخبر الجميع بكل شيء، بشكل دائم، سواء كان ذلك ذا صلة أم لا. البنية الثلاثية في Citadel تخبر مزود خدمة واحدًا شيئًا صحيحًا واحدًا، مُتحققًا مقابل سجل على السلسلة، دون أن يلمس مزود الخدمة هذا الملف الشخصي الكامل للمستخدم.
ليس قولي إن الشفافية خاطئة في كل مكان. التنسيق العام يستفيد فعلًا من أن يرى الجميع دفتر الأستاذ نفسه. لكن الإجراءات المقيدة بالهوية—إثبات الأهلية دون التنازل عن ملف كامل—تحتاج إلى بروتوكول بأدوار ثلاث منفصلة، لا دورين، كي تعمل فعليًا.
هل إثبات حقيقة واحدة عبر ثلاثة أدوار مفصولة ضمان خصوصية أقوى من شفافية "يرى الجميع كل شيء، لذا لا أحد يُخفي أي شيء"؟
@Dusk #dusk $DUSK
Stronger guarantee
100%
Transparency is simpler
0%
4 الأصوات • تمّ إغلاق التصويت
يذكر مستودع Dusk الخاص أن مُبطِل الهوية (nullifier) يتم حسابه تحديدًا بحيث لا يمكن لمراقب خارجي ربطه بأي ملاحظة معينة.
precious Zarmalaa
·
--
ما الذي يمنعِه مُبطِل المعاملات (Nullifier) فعلًا من الحدوث مرتين
تحقّقتُ مما الذي يمنعه مُبطِل المعاملات تحديدًا على Dusk، لأن عبارة “يمنع الإنفاق المزدوج” تُقال غالبًا دون دقّة كافية.
إنه يمنع الملاحظة (note) المُشفّرة نفسها من أن تُنفق أكثر من مرة — لا شيء أوسع من ذلك.
تتبّعتُ كيف يحقق Dusk ذلك دون كشف أي ملاحظة تم إنفاقها. يذكر مستودع Dusk الخاص أن مُبطِل المعاملات يُحسب تحديدًا بحيث لا يستطيع مراقب خارجي ربطه بأي ملاحظة بعينها. لا تتحقق الشبكة من الملاحظة نفسها مقابل قائمة؛ بل تتحقق مما إذا كان مُبطِل المعاملات هذا نفسه قد ظهر من قبل.
أكدتُ أيضًا أن الملاحظة لا تُزال من أي مكان بمجرد إنفاقها. بل تبقى مسجّلة في شجرة Merkle الخاصة بالملاحظات لدى Dusk. لا يُضاف إلا مُبطِل المعاملات إلى سجلّ منفصل متزايد.
هذا الفرق مهم. لو كانت الملاحظات تُحذف عند الإنفاق، لكان من المتوقع أن يتسرّب ذلك بمعلومة توقيت لمجرد مراقبة حجم البنية وهي تنكمش. إن الإبقاء على كل الملاحظات في مكانها، سواء أُنفقت أم لا، يزيل هذه الإشارة تحديدًا.
بحثتُ لمعرفة ما إذا كان ذلك يخلق أي خطر تعارض — أن تنتج ملاحظتان مختلفتان بالصدفة نفس مُبطِل المعاملات. لم أجد حالة موثّقة على Dusk نفسه في المواد الخاصة به، رغم أن الضمان يعتمد على نفس الافتراضات التشفيرية الأساسية التي تعتمد عليها بقية المنظومة.
لذلك، فإن مُبطِل المعاملات على Dusk ليس “وسمًا” فعليًا للملاحظة كمنتهية الصرف بالمعنى المرئي. إنه يثبت أن عملية إنفاق قد حدثت، دون تحديد ما الذي تم إنفاقه.
هل يمنع الإنفاق المزدوج بهذه الطريقة خصوصيةً أكثر مما يستحق مقابل التخزين الدائم المتزايد باستمرار؟
@Dusk #dusk $DUSK #dusk
تحقّقتُ مما الذي يمنعه مُبطِل المعاملات تحديدًا على Dusk، لأن عبارة “يمنع الإنفاق المزدوج” تُقال غالبًا دون دقّة كافية.
إنه يمنع الملاحظة (note) المُشفّرة نفسها من أن تُنفق أكثر من مرة — لا شيء أوسع من ذلك.
تتبّعتُ كيف يحقق Dusk ذلك دون كشف أي ملاحظة تم إنفاقها. يذكر مستودع Dusk الخاص أن مُبطِل المعاملات يُحسب تحديدًا بحيث لا يستطيع مراقب خارجي ربطه بأي ملاحظة بعينها. لا تتحقق الشبكة من الملاحظة نفسها مقابل قائمة؛ بل تتحقق مما إذا كان مُبطِل المعاملات هذا نفسه قد ظهر من قبل.
أكدتُ أيضًا أن الملاحظة لا تُزال من أي مكان بمجرد إنفاقها. بل تبقى مسجّلة في شجرة Merkle الخاصة بالملاحظات لدى Dusk. لا يُضاف إلا مُبطِل المعاملات إلى سجلّ منفصل متزايد.
هذا الفرق مهم. لو كانت الملاحظات تُحذف عند الإنفاق، لكان من المتوقع أن يتسرّب ذلك بمعلومة توقيت لمجرد مراقبة حجم البنية وهي تنكمش. إن الإبقاء على كل الملاحظات في مكانها، سواء أُنفقت أم لا، يزيل هذه الإشارة تحديدًا.
بحثتُ لمعرفة ما إذا كان ذلك يخلق أي خطر تعارض — أن تنتج ملاحظتان مختلفتان بالصدفة نفس مُبطِل المعاملات. لم أجد حالة موثّقة على Dusk نفسه في المواد الخاصة به، رغم أن الضمان يعتمد على نفس الافتراضات التشفيرية الأساسية التي تعتمد عليها بقية المنظومة.
لذلك، فإن مُبطِل المعاملات على Dusk ليس “وسمًا” فعليًا للملاحظة كمنتهية الصرف بالمعنى المرئي. إنه يثبت أن عملية إنفاق قد حدثت، دون تحديد ما الذي تم إنفاقه.
هل يمنع الإنفاق المزدوج بهذه الطريقة خصوصيةً أكثر مما يستحق مقابل التخزين الدائم المتزايد باستمرار؟
@Dusk #dusk $DUSK #dusk
تمّ التحقق
@Dusk واصلت افتراض الأهلية في Dusk أنها شيء كنت تكسبه مرة واحدة وتحتفظ به، مثل شارة تُثبَّت وتبقى معلّقة.
لكنها في الحقيقة ثلاث آليات منفصلة تعمل معًا، ويمكن لأي واحدة منها أن تسحبها منك.
أولًا: الحد الأدنى للاستثمار. تأكدت أن موزّع/مقدّم Dusk يحتاج إلى 1000 DUSK مُقفلة، وبدون ذلك الحدّ، لا يهم أي شيء آخر بخصوص الاستثمار.
ثانيًا: النضج/الاكتمال. حتى لو كان الاستثمار فوق الحد الأدنى، يجب أن يبقى خلال عدد ثابت من الـ epochs قبل أن يتم احتسابه ضمن sortition الخاصة بـ Dusk على الإطلاق. $DUSK
ثالثًا، وهذه هي التي كدت أفلتها: العقوبة. وجدت أن الأخطاء المتكررة لا تُنقص المكافآت فقط — بل إن كل تعليق متتالٍ يحوّل نسبة متصاعدة من الاستثمار إلى “مجموعة المكافآت القابلة للمطالبة”، بدءًا من 10% ثم تصاعدًا بنسبة 10% مع كل انتهاك لاحق.
ثم تتبعت ما يحدث عندما تدفع هذه العقوبة استثمارًا إلى ما دون حد 1000 DUSK. لا يفقد فقط “الوزن” في الـ sortition. بل يتجمّد بالكامل — والطريق الوحيد للعودة إلى Dusk هو إلغاء إلغاء/سحب الجزء المتبقي المجمد ثم إعادة الاستثمار من جديد.
لذا فالأهلية ليست بوابة واحدة يمرّ منها المزوّد/المقدّم مرةً واحدة ثم ينتهي الأمر. إنها ثلاث آليات منفصلة — أرضية وحدّ أدنى، وساعة/مؤقت، وجدول عقوبات — وأي واحدة منها يمكن أن تُقصي بهدوء مزوّد Dusk ظنّ أنه ما زال نشطًا. #dusk
هل يجعل تكديس الأهلية عبر ثلاث آليات مستقلة Dusk أكثر مقاومة للتلاعب، أم أنه يجعل الأمر أسهل لمزوّدٍ صادق لفقد حالته دون أن يدرك على الفور لماذا؟
#dusk $DUSK @Dusk
لكنها في الحقيقة ثلاث آليات منفصلة تعمل معًا، ويمكن لأي واحدة منها أن تسحبها منك.
أولًا: الحد الأدنى للاستثمار. تأكدت أن موزّع/مقدّم Dusk يحتاج إلى 1000 DUSK مُقفلة، وبدون ذلك الحدّ، لا يهم أي شيء آخر بخصوص الاستثمار.
ثانيًا: النضج/الاكتمال. حتى لو كان الاستثمار فوق الحد الأدنى، يجب أن يبقى خلال عدد ثابت من الـ epochs قبل أن يتم احتسابه ضمن sortition الخاصة بـ Dusk على الإطلاق. $DUSK
ثالثًا، وهذه هي التي كدت أفلتها: العقوبة. وجدت أن الأخطاء المتكررة لا تُنقص المكافآت فقط — بل إن كل تعليق متتالٍ يحوّل نسبة متصاعدة من الاستثمار إلى “مجموعة المكافآت القابلة للمطالبة”، بدءًا من 10% ثم تصاعدًا بنسبة 10% مع كل انتهاك لاحق.
ثم تتبعت ما يحدث عندما تدفع هذه العقوبة استثمارًا إلى ما دون حد 1000 DUSK. لا يفقد فقط “الوزن” في الـ sortition. بل يتجمّد بالكامل — والطريق الوحيد للعودة إلى Dusk هو إلغاء إلغاء/سحب الجزء المتبقي المجمد ثم إعادة الاستثمار من جديد.
لذا فالأهلية ليست بوابة واحدة يمرّ منها المزوّد/المقدّم مرةً واحدة ثم ينتهي الأمر. إنها ثلاث آليات منفصلة — أرضية وحدّ أدنى، وساعة/مؤقت، وجدول عقوبات — وأي واحدة منها يمكن أن تُقصي بهدوء مزوّد Dusk ظنّ أنه ما زال نشطًا. #dusk
هل يجعل تكديس الأهلية عبر ثلاث آليات مستقلة Dusk أكثر مقاومة للتلاعب، أم أنه يجعل الأمر أسهل لمزوّدٍ صادق لفقد حالته دون أن يدرك على الفور لماذا؟
#dusk $DUSK @Dusk
More resistant
100%
Easy to lose status
0%
3 الأصوات • تمّ إغلاق التصويت
يحلّ الغسق مشكلةً تتشكّل حولها، إذ لا يمكن للسلاسل الشفافة للبلوك تشين دائمًا حلّها بكفاءة.
precious Zarmalaa
·
--
نمَوذَجَا دُوسك لِلمُعاملتين، ضوءُ القمر و”فينيكس“
كنتُ هذا المساء أختبر تدفّق تحويل بسيط على شبكة اختبار Dusk، مع التبديل بين عرض محفظة عامة وأخرى مُشفّرة لنفس مبلغ الاختبار. على الجانب العام ظهرت كل التفاصيل فورًا: المُرسِل، المُستلم، والمبلغ. أما الجانب المُشفّر فلم يُظهر تقريبًا شيئًا.
افترضتُ أن الأمر مجرد نمطين للعرض لنفس المعاملة الأساسية. بدا ذلك منطقيًا في البداية.
لكنني كنتُ مخطئًا. Moonlight نموذجٌ قائم على الحساب. تُعرض الأرصدة في العلن، ويكشف التحويل افتراضيًا المُرسِلَ والمُستلمَ والمبلغ. أما Phoenix فيعمل بشكل مختلف. تُخزَّن الأموال كملاحظات مُشفّرة بدلًا من ذلك. توجد برهانات عدم معرفة خلف ذلك تؤكد فقط أن المعاملة صحيحة، دون أن يُظهر أي شيء عن المبلغ أو المُرسِل أو حتى أي الملاحظات التي تم إنفاقها.
نموذجان مختلفان للمعاملات، وليس مجرد عرضين لنفس النموذج، وهذه التفرقة هي جوهر المقارنة بينهما من الأساس.
ما كنتُ أعود إليه باستمرار، بعد إغلاق الكمبيوتر المحمول ثم العودة إليه، هو أن كليهما يتسوى عبر نفس المكان في Dusk. DuskDS يتولى ذلك. يُقبل عقد التحويل أي نوع من الحمولة ويروّتها عبر منطق التحقق المطابق، مع الحفاظ على اتساق الحالة العامة للشبكة في كلتا الحالتين.
الاختيار بين Moonlight وPhoenix ليس متعلقًا بسلسلة بعينها. إنه اختيار يتم لكل معاملة على حدة، داخل طبقة تسوية واحدة، يحدد مقدار ما يمكن لبقية الشبكة رؤيته.
لا زلتُ لا أعرف كم مرة يختار المُنشئون النموذج الافتراضي واحدًا على الآخر عندما لا تتطلب سير العمل خصوصيةً بشكل صارم.
إذا كانت المحفظة تتيح لك الاختيار لكل معاملة، فأيّ نموذج ستلجأ إليه افتراضيًا؟
@Dusk #dusk $DUSK #dusk
كنتُ هذا المساء أختبر تدفّق تحويل بسيط على شبكة اختبار Dusk، مع التبديل بين عرض محفظة عامة وأخرى مُشفّرة لنفس مبلغ الاختبار. على الجانب العام ظهرت كل التفاصيل فورًا: المُرسِل، المُستلم، والمبلغ. أما الجانب المُشفّر فلم يُظهر تقريبًا شيئًا.
افترضتُ أن الأمر مجرد نمطين للعرض لنفس المعاملة الأساسية. بدا ذلك منطقيًا في البداية.
لكنني كنتُ مخطئًا. Moonlight نموذجٌ قائم على الحساب. تُعرض الأرصدة في العلن، ويكشف التحويل افتراضيًا المُرسِلَ والمُستلمَ والمبلغ. أما Phoenix فيعمل بشكل مختلف. تُخزَّن الأموال كملاحظات مُشفّرة بدلًا من ذلك. توجد برهانات عدم معرفة خلف ذلك تؤكد فقط أن المعاملة صحيحة، دون أن يُظهر أي شيء عن المبلغ أو المُرسِل أو حتى أي الملاحظات التي تم إنفاقها.
نموذجان مختلفان للمعاملات، وليس مجرد عرضين لنفس النموذج، وهذه التفرقة هي جوهر المقارنة بينهما من الأساس.
ما كنتُ أعود إليه باستمرار، بعد إغلاق الكمبيوتر المحمول ثم العودة إليه، هو أن كليهما يتسوى عبر نفس المكان في Dusk. DuskDS يتولى ذلك. يُقبل عقد التحويل أي نوع من الحمولة ويروّتها عبر منطق التحقق المطابق، مع الحفاظ على اتساق الحالة العامة للشبكة في كلتا الحالتين.
الاختيار بين Moonlight وPhoenix ليس متعلقًا بسلسلة بعينها. إنه اختيار يتم لكل معاملة على حدة، داخل طبقة تسوية واحدة، يحدد مقدار ما يمكن لبقية الشبكة رؤيته.
لا زلتُ لا أعرف كم مرة يختار المُنشئون النموذج الافتراضي واحدًا على الآخر عندما لا تتطلب سير العمل خصوصيةً بشكل صارم.
إذا كانت المحفظة تتيح لك الاختيار لكل معاملة، فأيّ نموذج ستلجأ إليه افتراضيًا؟
@Dusk #dusk $DUSK #dusk
تمّ التحقق
#dusk $DUSK
مقارنة DuskVM بـ DuskEVM على شبكة DUSK
@Dusk في البداية، اعتقدت أن الاختيار بين DuskVM وDuskEVM يعتمد على اللغة: Rust وWASM مقابل Solidity مع أدوات EVM التي اعتاد عليها الجميع بالفعل. أمضيت وقتًا أطول الليلة مما توقعت في ذلك، وضمن كل هذه التفاصيل توقفت المسألة عن أن تبدو كاختيار لغوي بحت.
يجلس DuskVM في قاعدة الشبكة مباشرةً، لذلك يحصل على وصول مباشر إلى خصائص الخصوصية وأشياء الإثباتات/المعرفة-الصفرية التي بُني Dusk حولها بالفعل. يشغّل DuskEVM عقود Solidity عبر أدوات EVM القياسية، لكنه ما يزال يستقر وينشر بياناته مرة أخرى عبر طبقة DuskDS نفسها، ويدفع الغاز بنفس رمز DUSK في كلتا الحالتين. هذه متناظرة غريبة أجد نفسي أعود إليها باستمرار: مسارات تنفيذ مختلفة، وتسوية واحدة، ونفس الرمز تحت كليهما.
اختيار DuskVM ليس مجرد اختيار لغة؛ إنه اختيار القرب من بدائيات الخصوصية نفسها. اختيار DuskEVM ليس مجرد الألفة؛ بل هو الابتعاد عن تلك البدائيات من منظور أدوات معظم المطورين يعرفونها بالفعل. هذه الاحتكاكية الدقيقة يتخطّاها معظم المقارنات بسهولة. #dusk
هناك طبقة ثالثة تحت كليهما أعود وأهبط إليها دائمًا. تؤكد وثائق Dusk أن DuskEVM يتيح لواجهات محافظ EVM الحالية والجسور والبورصات أن تعمل وتتصل بسهولة مع تغييرات شبه معدومة في التعليمات البرمجية، بسرعة أكبر مما تتطلبه عادةً التكامل الأصلي. لا يقدم DuskVM اختصارًا مكافئًا. يجب بناء الأدوات اللازمة له من الصفر، في كل مرة. $DUSK
تطابق الميزات بين الاثنين غير مضمون فقط لأن كليهما يستقر عبر نفس الطبقة ويتشارك رمز الغاز. ما يبدو كاختيار/مرونة على السطح هو في الحقيقة مراهنـتان مختلفتان حول مكان دفع التكلفة الفعلية: في وقت مبكر ضمن الأدوات، أو لاحقًا ضمن ما لا يستطيع بيئتك القيام به.
هل تقدم Dusk بالفعل للمُنشئين خيارًا هنا، أم أنها تقرر لهم فقط مكان ظهور الاحتكاك؟ @Dusk
مقارنة DuskVM بـ DuskEVM على شبكة DUSK
@Dusk في البداية، اعتقدت أن الاختيار بين DuskVM وDuskEVM يعتمد على اللغة: Rust وWASM مقابل Solidity مع أدوات EVM التي اعتاد عليها الجميع بالفعل. أمضيت وقتًا أطول الليلة مما توقعت في ذلك، وضمن كل هذه التفاصيل توقفت المسألة عن أن تبدو كاختيار لغوي بحت.
يجلس DuskVM في قاعدة الشبكة مباشرةً، لذلك يحصل على وصول مباشر إلى خصائص الخصوصية وأشياء الإثباتات/المعرفة-الصفرية التي بُني Dusk حولها بالفعل. يشغّل DuskEVM عقود Solidity عبر أدوات EVM القياسية، لكنه ما يزال يستقر وينشر بياناته مرة أخرى عبر طبقة DuskDS نفسها، ويدفع الغاز بنفس رمز DUSK في كلتا الحالتين. هذه متناظرة غريبة أجد نفسي أعود إليها باستمرار: مسارات تنفيذ مختلفة، وتسوية واحدة، ونفس الرمز تحت كليهما.
اختيار DuskVM ليس مجرد اختيار لغة؛ إنه اختيار القرب من بدائيات الخصوصية نفسها. اختيار DuskEVM ليس مجرد الألفة؛ بل هو الابتعاد عن تلك البدائيات من منظور أدوات معظم المطورين يعرفونها بالفعل. هذه الاحتكاكية الدقيقة يتخطّاها معظم المقارنات بسهولة. #dusk
هناك طبقة ثالثة تحت كليهما أعود وأهبط إليها دائمًا. تؤكد وثائق Dusk أن DuskEVM يتيح لواجهات محافظ EVM الحالية والجسور والبورصات أن تعمل وتتصل بسهولة مع تغييرات شبه معدومة في التعليمات البرمجية، بسرعة أكبر مما تتطلبه عادةً التكامل الأصلي. لا يقدم DuskVM اختصارًا مكافئًا. يجب بناء الأدوات اللازمة له من الصفر، في كل مرة. $DUSK
تطابق الميزات بين الاثنين غير مضمون فقط لأن كليهما يستقر عبر نفس الطبقة ويتشارك رمز الغاز. ما يبدو كاختيار/مرونة على السطح هو في الحقيقة مراهنـتان مختلفتان حول مكان دفع التكلفة الفعلية: في وقت مبكر ضمن الأدوات، أو لاحقًا ضمن ما لا يستطيع بيئتك القيام به.
هل تقدم Dusk بالفعل للمُنشئين خيارًا هنا، أم أنها تقرر لهم فقط مكان ظهور الاحتكاك؟ @Dusk
#dusk $DUSK
@Dusk كنت أفترض أن سلسلة الخصوصية تعني أن كل معاملة تكون مخفية افتراضيًا، دون أي استثناءات.
ثم قرأت ما تفعله Moonlight فعليًا على Dusk.
تقوم Dusk بتشغيل نموذجين أصليين للمعاملات على نفس طبقة التسوية. Moonlight مبني على الحسابات، علني، حيث تكون جهة الإرسال والجهة المستلمة والمبلغ مرئية بالكامل. Phoenix مبني على الملاحظات، ومشفّر، حيث تكون الأموال موجودة كملاحظات مشفّرة بدلًا من رصيد جارٍ، وهو أقرب إلى وحدات قابلة للإنفاق من كونه إجمالي حساب. #dusk
هنا هي عبارة "افتراضيًا" التي غيّرت الطريقة التي قرأت بها هذا، وعدت لأعيد قراءة هذا المقطع مرتين فقط لأتأكد.
التحويل الواحد يختار نموذجًا واحدًا أو الآخر، ولا يمزج بينهما. أرسل DUSK عبر Moonlight وسيصبح الأمر شفّافًا بالكامل، ومصممًا لتدفقات تحتاج إلى البقاء قابلة للملاحظة؛ مثل سيناريو خزينة أو تقارير، وهو النوع من الأمثلة التي تشير إليه الوثائق. أرسله عبر Phoenix وسيظل المبلغ والمرسل وأي ملاحظات محددة تم نقلها مخفية، مع إثبات صحة ذلك عبر إثباتات معرفة-صفرية بدلًا من عرضها صراحةً، رغم أن مفتاح مشاهدة يمكنه كشف تلك البيانات المخفية لمن يختاره المدقق لعرضها له. $DUSK
عقد تحويل واحد يتعامل مع كلا الخيارين، ويروج لكل حمولة إلى منطق التحقق الصحيح، مع الحفاظ على الاتساق في الحالة العامة في كلتا الحالتين.
لذا فالخصوصية هنا ليست ثنائية على مستوى البروتوكول أيضًا؛ إنها اختيار لكل تحويل، وحتى خيار الإخفاء المشفّر لديه طريقة موثقة ليصبح مرئيًا مرة أخرى عند الطلب.
هذا الاختيار يقع على عاتق المُرسل، وليس على البروتوكول.
a هل يمنح المستخدمين خيارًا علنيًا يقوض فكرة الخصوصية، أم أن الخصوصية الاختيارية القابلة للإلغاء هي التصميم الأكثر صدقًا للأسواق المُنظمة؟
هل الخصوصية الاختيارية ما زالت خصوصية؟
@Dusk كنت أفترض أن سلسلة الخصوصية تعني أن كل معاملة تكون مخفية افتراضيًا، دون أي استثناءات.
ثم قرأت ما تفعله Moonlight فعليًا على Dusk.
تقوم Dusk بتشغيل نموذجين أصليين للمعاملات على نفس طبقة التسوية. Moonlight مبني على الحسابات، علني، حيث تكون جهة الإرسال والجهة المستلمة والمبلغ مرئية بالكامل. Phoenix مبني على الملاحظات، ومشفّر، حيث تكون الأموال موجودة كملاحظات مشفّرة بدلًا من رصيد جارٍ، وهو أقرب إلى وحدات قابلة للإنفاق من كونه إجمالي حساب. #dusk
هنا هي عبارة "افتراضيًا" التي غيّرت الطريقة التي قرأت بها هذا، وعدت لأعيد قراءة هذا المقطع مرتين فقط لأتأكد.
التحويل الواحد يختار نموذجًا واحدًا أو الآخر، ولا يمزج بينهما. أرسل DUSK عبر Moonlight وسيصبح الأمر شفّافًا بالكامل، ومصممًا لتدفقات تحتاج إلى البقاء قابلة للملاحظة؛ مثل سيناريو خزينة أو تقارير، وهو النوع من الأمثلة التي تشير إليه الوثائق. أرسله عبر Phoenix وسيظل المبلغ والمرسل وأي ملاحظات محددة تم نقلها مخفية، مع إثبات صحة ذلك عبر إثباتات معرفة-صفرية بدلًا من عرضها صراحةً، رغم أن مفتاح مشاهدة يمكنه كشف تلك البيانات المخفية لمن يختاره المدقق لعرضها له. $DUSK
عقد تحويل واحد يتعامل مع كلا الخيارين، ويروج لكل حمولة إلى منطق التحقق الصحيح، مع الحفاظ على الاتساق في الحالة العامة في كلتا الحالتين.
لذا فالخصوصية هنا ليست ثنائية على مستوى البروتوكول أيضًا؛ إنها اختيار لكل تحويل، وحتى خيار الإخفاء المشفّر لديه طريقة موثقة ليصبح مرئيًا مرة أخرى عند الطلب.
هذا الاختيار يقع على عاتق المُرسل، وليس على البروتوكول.
a هل يمنح المستخدمين خيارًا علنيًا يقوض فكرة الخصوصية، أم أن الخصوصية الاختيارية القابلة للإلغاء هي التصميم الأكثر صدقًا للأسواق المُنظمة؟
هل الخصوصية الاختيارية ما زالت خصوصية؟
سجّل الدخول لاستكشاف المزيد من المُحتوى