林木森Woody

#币安夏令营 冲呀

هذا الأسبوع أعدتُ مشاهدة tokenomics لـ @Dusk . كنت أذكر فقط: «سقف 1 مليار، تخفيض للنصف كل أربع سنوات». لكن بعد تتبع توزيع المكافآت اكتشفت أن مُصدر/مُنشئ الكتل لا يأخذ كل ما يُصدَر في كل كتلة. في الدورة الحالية الأولى، وبحسب الخطة، يتم إصدار نحو 19.8574 DUSK لكل كتلة، بالإضافة إلى رسوم المعاملات في تلك الكتلة. يحصل مُنشئ الكتلة الأساسي على 70%، ويمكنه حسب ما ورد في الشهادة إضافة ما يصل إلى 10% إضافية. صندوق التطوير يحصل على 10%، ولجنة التحقق ولجنة الاعتماد كلٌ منهما 5%. أما الجزء الذي لا يُوزَّع فيتم حرقه.

لا تهدف هذه التصميمات إلى حل APR واحد بعينه، بل إلى أن تكون إجراءات الإجماع الثلاثة: الاقتراح والتحقق والاعتماد، كلها لها دخل. لكن السؤال يتغير أيضًا: إذا كانت رسوم المعاملات على السلسلة منخفضة جدًا، فستعتمد ميزانية الأمان أساسًا على استمرار الإصدار. وإذا كانت جودة مشاركة العقد غير كافية، فلن تُستكمل المكافآت الإضافية، وبالتالي قد يكون المعروض الجديد أقل من المنحنى الاسمي. لذلك عند النظر إلى $DUSK لا يمكنك ضرب «19.8574 لكل كتلة» مباشرةً في عدد الكتل، واعتبارها إنتاجًا ثابتًا يحصل عليه الجميع.

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

أنا أرى أن #dusk يجب أن تركز على ثلاث نقاط معًا: الإصدارات الفعلية/المُقَلَّبة، نسبة التـحَدّي/الرهان النشطة، ونسبة رسوم المعاملات ضمن المكافآت. فقط عندما تنتقل ميزانية الأمان المُموَّلة من الإصدار تدريجيًا إلى الرسوم والاستخدام الحقيقي، يصبح تخفيض النصف ليس مجرد قطع دخل للعُقد. أنتم أكثر اهتمامًا بكتابة الحد الأقصى للمستقطب (الـmaximum supply) كما هو ثابت، أم بقدرة الشبكة على دفع تكلفة الأمان حتى بعد أن ينخفض معدل الإصدار؟

قمت بتفكيك بيان الشراكة الخاص بـ @Dusk وNPEX وChainlink، واكتشفت أن ما سيتم تطبيقه فعليًا ليس عبارة “RWA عبر السلاسل”، بل ثلاث قنوات مختلفة تمامًا للبيانات والأصول. يتولى CCIP إرسال الرسائل ونقل الأصول بين السلاسل، بينما يمنح CCT $DUSK من هذا النوع من الرموز مسار burn/mint مُتحكم به؛ يقوم DataLink بإرسال بيانات البورصة الرسمية الخاصة بـ NPEX إلى السلسلة، وتقوم Data Streams بمعالجة تحديثات الأسعار منخفضة التأخير.

لماذا تكون طبقة البيانات هذه أكثر تعقيدًا من “تحويل السندات إلى token”؟ لا يمكن للأصول الخاضعة للرقابة أن تكتفي بإثبات أن هناك سلاسل حصص داخل عقد ما. يجب أن يعرف السوق الثانوي من أين تأتي الأسعار، وما إذا كان المُصدِر لا يزال يحتفظ بالسيطرة، ومن يملك حدود معدل السرعة والسلطة الخاصة بالترقية عند التعامل عبر السلاسل، وكيفية إيقاف البيانات غير الطبيعية. يركز البيان على أن Dusk وNPEX يحتفظان بملكية عقود الرموز ويمكنهما ضبط rate limit ومسار الترقية—وهذا يعد قدرة للتحكم بالنسبة للمؤسسات، كما أنه ضروري أيضًا للمستخدمين العاديين لمتابعة صلاحيات الحوكمة.

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

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

الآن في هذين اليومين أعادَ رسمُتُ مكوّنات Core لـ @Dusk بالكامل، إلى أن تمكنت من فصل أسماء DuskVM وDuskEVM وDuskDS. في البداية اعتقدتُ أن الأمر مجرد «سلسلة واحدة متوافقة مع نوعين من الأجهزة الافتراضية»، لكن التقسيم الفعلي أقرب إلى ثلاث طبقات: DuskDS يختص بالإجماع والنهائية وإتاحة البيانات؛ DuskVM يجعل عقود Rust/WASM تعمل مباشرة على L1؛ وDuskEVM هو بيئة تنفيذ مكافئة لـ EVM مبنية على OP Stack، تسند التسوية ونشر البيانات إلى DuskDS.

وهذا يعني أن المطورين ليسوا مضطرين للاختيار «بدون تفكير» بين خيارين. إذا كانت لديك عقود Solidity موجودة بالفعل، وتعتمد على محافظ EVM وسلاسل الأدوات، فاختيار DuskEVM ستكون تكلفته أقل؛ أما إذا كنت ستتعامل مباشرة مع أصول L1، أو مع نموذج الخصوصية Phoenix، أو قدرات المعرفة الصفرية (zero-knowledge)، أو تريد تحكمًا أعمق على مستوى البروتوكول، فـ DuskVM هو المدخل الأصلي. المساران يشتركان في قاعدة التسوية، لكن هذا لا يعني أن الوظائف وافتراضات الأمان متطابقة تمامًا.

أنا متحفظ قليلًا تجاه مقولة: «EVM compatible = سيتحرك النظام البيئي تلقائيًا إلى الداخل». فالتوافق لا يُخفض سوى عتبة النشر، ولا يمكنه أن يُغني عن الاتصال بالمحافظ، أو RPC مستقر، أو مفهرِس (indexer)، أو السيولة، أو المستخدمين الحقيقيين. وبالمقابل، التركيز فقط على الأصالة في Rust/ZK غير كافٍ أيضًا؛ فالأدوات قد تكون قاسية جدًا، ولن يعيد المطورون كتابة منتجاتهم بالكامل من أجل النزاهة التقنية.

لذلك، عند النظر إلى التقدم التقني لـ $DUSK ، أراه سيُفكك المؤشرات: هل لدى DuskEVM تطبيقات Solidity من طرف ثالث؟ وهل لدى DuskVM عقود غير رسمية؟ وهل مسار التسوية إلى DuskDS في الجانبين مستقر؟ وإذا كانت الخندق الحصين لـ #dusk حقيقية بالفعل، فالمفترض أنها ستكون: «الناس المألوفون بالأدوات يمكنهم الدخول، وعند الحاجة إلى الخصوصية يمكنهم النزول إلى المستوى التالي»، وليس مجرد تكديس ثلاثة أسماء جديدة معًا. أنتم ستختارون أولًا التوافقية، أم القدرات الأصلية؟

كنت قد شاهدت @Dusk يتحدث عن Moonlight وPhoenix معًا، وظننت أنه مجرد وجود مجموعتين: «تحويل عادي» و«تحويل ذو خصوصية»، كل واحدة تقوم بوظائف متشابهة. عند قراءة وثيقة نموذج المعاملات مع تعليمات تكامل منصة التداول، أدركت أن وجود نموذجين ليس استعراضًا بقدر ما هو اعترافٌ مُتعمد داخل طبقة التسوية نفسها: بعض تدفقات الأموال يجب أن تكون علنية، وبعضها لا ينبغي كشف المبالغ والعلاقات الخاصة به أمام الجميع.

Moonlight هو نموذج حساب علني؛ حيث تكون الأرصدة والمرسلون والمستلمون والمبالغ كلها قابلة للرؤية، وهو ما يجعله أكثر ملاءمة لسيناريوهات مثل شحن منصة التداول، وخزينة الدولة، والحالات التي يلزم فيها تسوية/مطابقة علنية.

أما Phoenix فيضع الأموال داخل note مشفّر، ويستخدم إثباتات المعرفة الصفرية للتأكيد من عدم حدوث double-spend (الإنفاق المزدوج) وأن الرصيد كافٍ، دون نشر المبلغ المحدد و الـ note المطابقة للمتطفلين. وعند الحاجة إلى التدقيق، يمكن الإفصاح بشكل انتقائي عبر viewing key.

أكبر سوء فهم هنا هو: «بما أن هناك خصوصية، فالـ browser لا يرى شيئًا». المتصفح الرسمي ما يزال قادرًا على رؤية البيانات الواضحة مثل البلوك، ونوع المعاملة، والرسوم، وغاز (gas) وغيرها من البيانات الوصفية العلنية؛ ومدى ما يمكن رؤيته يعتمد على نموذج المعاملات والعقد. بالمقابل، لا يمكن لمنصة التداول أن تتعامل مع Phoenix كأنه Moonlight وتكتفي بالمسح المباشر: وثائق التكامل الرسمية توصي بأن تكون عملية إعادة الشحن عبر Moonlight، وأن يتم تحويل الرصيد ذي الخصوصية أولًا إلى حساب عام، لأن منطق الإيداع/التخزين والتفريغ والمسح مختلف تمامًا.

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

هذا الأسبوع رتّبت وثائق رهن @Dusk من حالة التفعيل إلى الخروج على طول الخط، ثم اكتشفت أن الجملتين «الحد الأدنى 1000 DUSK، ولا توجد فترة انتظار بموجب اتفاقية» هما الأكثر عرضة لسوء الفهم. الرهن المباشر ليس مجرد أن تضغط على العملة وتنتظر معدل فائدة ثابتًا؛ بل يتطلب تشغيل provisioner مستمر ومتصل بالإنترنت وبعمله بشكل طبيعي. العائد يعتمد على ما إذا تم اختيارك للمشاركة في التوافق (consensus) وعلى نسبة الرهن الفعّال، وليس وعدًا بعائد ثابت من البروتوكول.

هناك أيضًا تفاصيل ضمن الجدول الزمني. يبدأ الـ stake الجديد فعاليته فقط عند «الحدّ التالي للـ epoch وما بعده». التقدير الرسمي بناءً على زمن إصدار الكتل المستهدف عادةً يكون حوالي 6—12 ساعة، لكن الأَدق دائمًا هو ما يظهر في المحفظة تحت «active from block». أمّا الخروج نفسه فلا توجد له فترة قفل بروتوكولية، لكنّه لا يقوم تلقائيًا بسحب المكافآت المتراكمة معًا؛ عملية سحب مكافآت withdraw هي إجراء منفصل.

الأكثر لفتًا للانتباه بالعكس هو الرهن الإضافي (top-up): بعد أن تصبح الحصة الأصلية active، فإن الجزء المضاف من top-up يدخل بنسبة 90% مباشرة إلى active، بينما يبقى 10% مسجّلًا كـ locked stake. الجزء المُقفل يظل ملكك، لكنه لا يشارك في الـ consensus. ولإعادة أخذ الطرف المتبقي، قد تحتاج إلى إلغاء الرهن بالكامل (unstake) للحصة المتبقية. هذا التصميم ليس سيئًا في ذاته، لكنه قد يجعل من يركّز فقط على APR الظاهر على اللوحة يحسب كفاءة رأس المال بشكل خاطئ.

يمكن لِبرك الأطراف الثالثة أن تُزيل عتبة متطلبات التشغيل (الـ运维)، لكن الاستضافة (custody) والعقود وطريقة تشغيل الجهة المشغّلة وقواعد الخروج تتحول إلى مجموعة أخرى من المخاطر. لذلك عندما أرى أن $DUSK سيتم رهنها، فالأمر لن يكون مجرد سؤال «كم العائد؟»، بل أيضًا: من الذي يمتلك العقد (node)؟ وكيف تُقسَّم المكافآت؟ وكيف تُدار الأجزاء locked؟ أما المستخدم #dusk فربما يكون أكثر ملاءمة لتشغيل عقدته بنفسه، أم أنه يفضّل قبول طبقة مخاطر من وجود pool مقابل عمليات أبسط؟

我把 @TermMax 的 TMX 白皮书和激励文档放在一起看，发现一个比“空投有多少”更值得先问的问题：路线图写过的时间，能不能直接当成已经发生的 TGE？

答案至少从当前公开文件里还不能画等号。

2026 年 3 月版白皮书把 TMX 定义为治理和实用代币，总量固定 10 亿，初始流通预计约 20%。分配表写着生态 29%、投资人 28%、团队 15%、社区 15%，其余给流动性、基金会和顾问。路线图把 TGE、交易所流动性、分发和质押池放在 2026 年第二季度。

但同一份白皮书的参数栏，TGE 日期仍写着 To Be Announced。预挖文档只说，用户累积的是暂不可转让额度，等 TGE 后再按 1:1 申领。官方已列出以太坊和 BNB Chain 代币地址，这说明合约准备已公开，却不能单独证明生成、申领和流通全部完成。

这个差别很关键。合约部署是技术事件，TGE 是分发事件，交易所开放充提和交易又是市场事件。三件事可能连续，也可能隔很久。把“地址存在”“路线图到期”“页面有数字”揉成一句“已经上线”，信息就失真了。

我判断 TMX 进度只看四个信号：明确的 TGE 时间；正式申领页面与规则；区块浏览器里符合分配说明的流通；交易所自己的上币与充提公告。少任何一项，都应按实际阶段描述，不能替项目把后面的步骤补完。

风险点也不只日期。白皮书写明团队有 12 个月 cliff 后再线性释放，投资人同样有 12 个月 cliff、之后 24 个月归属。真正影响市场的不是 10 亿这个总数，而是每个窗口释放多少、由哪些地址承接、能否与公开表格对上。

所以我不会因为路线图的季度已经过去，就把 #TermMax 的 TMX 当成“理应完成”。路线图是计划，链上分发和官方公告才是状态。少猜一天进度，比多算一遍想象中的估值更有用。

لقد قمت بمقارنة @Dusk بمحفظة جديدة وتعليمات Dusk Connect بدقة، ثم أدركت أن ما أضافوه ليس “مجرد عمل غلاف جديد لمحفظة”، بل هو طبقة الربط التي كان dApp يفتقدها دائمًا. كانت محفظة الويب القديمة قادرة على التحويل والتخزين (الاستيثاق) بشكل منفصل، لكن التطبيق لم يستطع استخدام واجهة موحّدة لاكتشاف المحفظة وطلب الحسابات وتوقيع المعاملات وإرسالها؛ لذلك كان على المطورين أن يكيّفوا التطبيق حول كل محفظة على حدة.

ما فعله Dusk Connect يشبه إلى حد كبير توحيد “غراء” هذه العملية: فالمحفظة تعتمد فكرة EIP-6963 في الاكتشاف، وتتعامل RPC حسب مساحات الأسماء مع الحسابات والتوقيع والمعاملات وطلبات الشبكة، كما تجهّز للمطوّرين اختبارات اتساق جاهزة لتنفيذ المحفظة. ومنذ البداية تتوافق المحافظ الأولى الجديدة مع واجهة الـ provider هذه، لتغطي إضافة المتصفح والسطح المكتبي والجوال؛ وتُدرج عمليات التحويل العلني والخاص، وshield/unshield، والتخزين (الاستيثاق)، واستلام العوائد، وDRC-20 وDRC-721 كلها في مسار تفاعل واحد.

أكثر نقطة يمكن أن تُضلَّلها المواد الترويجية بسهولة هي اعتبار “إتاحة المستودع” مساويةً لـ“نضج المنتج” مباشرة. لا تزال الجهة الرسمية تعطيها حاليًا تصنيف developer preview. حفظ المفتاح محليًا، واستخدام PBKDF2 وAES-GCM لواجهة الإضافة (extension)، واستخدام Stronghold وArgon2 للجانب الأصلي—كل ذلك يشكّل أساسًا أمنيًا صحيحًا. لكن التجربة الحقيقية يحددها ما يلي: استعادة الاتصال عند الانقطاع، وتلميحات/تنبيهات الأذونات، واحتياطات/ملاحظات المعاملات الفاشلة، واتساق الحالة عبر أجهزة متعددة.

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

اطّلعت على توضيح إطلاق V2 الخاص بـ @TermMax ، ثم ذهبت لمراجعة ما سبق في V1. قد لا تكون المشكلة في بروتوكول الفائدة الثابتة هي عدم وجود عروض سعرية، بل أن الأموال تُقسَّم وتُعرض عبر أوامر مختلفة وأسواق وصفحات وسلاسل متعددة: رؤية معدل فائدة واحد لا يعني أن كامل المبلغ يمكن تنفيذه بهذا السعر.

في V1، يتم عرض أوامر range الخاصة بالمنسقين وأوامر limit للمستخدمين بشكل منفصل. إذا أردت الاقتراض بمبلغ أكبر قليلًا، فعليك المقارنة بين الأوامر واحدةً تلو الأخرى، ثم تتحمّل تغيّر السعر الناتج عن كل شريحة عمق. يمكن تسمية الفائدة “ثابتة”، لكن تكلفة الدخول قد لا تكون واضحة من النظرة الأولى.

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

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

لكن هناك حد لا يمكن محوه بسهولة. تقول النسخة الرسمية إن أسواق السلاسل المتقاطعة والكنز (vault) تُعرض وتُفلتر وتُقارن داخل واجهة واحدة، ولا يعني ذلك أن الأموال من سلاسل مختلفة تُدمج فعليًا في تجمع واحد. عمق الإيثيريوم لن ينتقل تلقائيًا ليتم تنفيذ صفقة لك عبر Base لمجرد أن بإمكانك رؤيته. تظل السيولة على السلسلة، وGas، ووقت انتظار أوامر limit، والكمية الفعلية القابلة للتنفيذ محسوبة كلٌّ في موضعه.

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

لذلك، ليست قيمة #TermMax في V2 مجرد أن الواجهة أصبحت أبسط، بل في فصل “تحديد الفائدة” عن “تحديد التنفيذ”. الأول يحدده FT وتاريخ الاستحقاق، أما الثاني فلا يزال يحتاج لإثباته عبر العمق. يمكن للواجهة أن ترسم الطريق بوضوح، لكن هل توجد سيارات كافية في الطريق أم لا—لا يزال يعتمد على التنفيذ الفعلي.
$BOME $BTC

خلال الأيام القليلة الماضية حلّلتُ الأمان الخاصة بـ AEGIS بخصوص @Dusk . في البداية حفظت فقط “39 إصلاحًا و7 حرِجة”. لكن بعد قراءة التفاصيل أدركت أن الأرقام الكبيرة ليست هي النقطة الأساسية. في النهاية تقلّصت 7 مشكلات خطيرة إلى 4 فئات من الأسباب الجذرية: مشكلة الأسماء المستعارة داخل VM Sandbox، عدم الأمان في إلغاء التسلسل من جهة المضيف، عدم وجود ربط كامل بين رسوم Phoenix والمبالغ المستردة، ومسار تزوير توقيعات BLS.

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

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

لذلك لن أستخدم عبارة “تم تدقيقه كثيرًا” كختم أمان مباشر لـ #dusk . والأكثر فائدة في الملاحظة هو: هل ستستمر الجولة القادمة في الكشف؟ وهل توجد اختبارات رجعية لحدود مماثلة؟ وهل يمكن للجهات المدققة الخارجية تغطية الكود بعد AEGIS؟ أنتم—هل تهتمون أكثر بأن المشروع لم يُكشف عنه أبدًا عن مشكلات كبيرة، أم بأن يتم الكشف عنها لاحقًا بحيث تُشرح الأسباب الجذرية والأثر وسلسلة الإصلاح بوضوح؟
$USELESS $BOME

لقد أعادتُ قراءة مستندات الفائدة الثابتة لـ @TermMax مرةً أخرى. لم يكن ما علّقني أولاً هو كيفية احتساب الفائدة، بل سؤال أبسط من ذلك: تكلفة الأموال في الإقراض والاقتراض على السلسلة تتغير يوميًا—فكيف تُثبت لسعر فائدة دينٍ بعينه مسبقًا إلى يوم الاستحقاق؟

إذا كان الجواب مجرد “البروتوكول لا يغيّر الالتزام”، فلن يكون لهذه الفائدة الثابتة شيء كثير يمكن دراسته. تابع القراءة لترى العلاقة بين FT وXT وGT، عندها تصبح الصورة كاملة.

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

أما GT فهو أقرب إلى “غلاف” للمركز. هو ERC-721 يسجل الضمان والديْن، وليس إعادة إنشاء “عملة عائد” قابلة للتداول بحرية. كل ما يلزم لمركز الرافعة—كمية الضمان المطلوبة، كم FT مستحقّة، ومتى يحين الاستحقاق—يُعبّأ كله في موضع واحد على السلسلة.

بعبارة أدق وبشكل حدسي: في حوض الفائدة العائمة العادي، تستمر التسمية/إعادة تسعير الدين بعد الاقتراض. بينما TermMax يفعل العكس: أولًا يحوّل “كم يجب سداده عند الاستحقاق” إلى سند دين قابل للتداول، ثم يترك للسوق أن يقرر اليوم كم يدفع لاستلامه. الفائدة الثابتة ليست أن “سعر الأصل” ثابت، ولا أن “الضمان” آمن دائمًا؛ الثابت فقط هو زمن وتكلفة هذه الديون بعد إبرام الصفقة.

وهناك أيضًا حدٌّ واضح يمكن للعبارات التسويقية أن تُخفيه بسهولة: الفائدة الثابتة لا تعني عدم حدوث التصفية. لا يزال مستند السوق الرسمي يضع MLTV وLLTV؛ فإذا انخفض سعر الضمان أو ارتفع تقييم أصل الدين، ليتجاوز LTV LLTV، فإن المركز سيدخل التصفية كما هو.

ما يلغيَه هو عدم اليقين الناتج عن قفز الفائدة فجأة، لكنه لا يلغي تقلب الضمان، ولا مخاطر الأوراكل، ولا مخاطر السداد عند الاستحقاق.

لذلك أنا الآن عندما أنظر إلى #TermMax لا أسأل أولًا هل APY مرتفع، بل أبحث أولًا في تاريخ استحقاق FT، وعمق الصفقة/السيولة عند التداول، ومدى بُعد GT عن خط التصفية. إن فهم “الفائدة الثابتة” على أنها “لن يحدث شيء” يؤدي بك إلى الاتجاه الخاطئ؛ فهي تثبت فقط الجزء الأصعب من التسعير داخل الدين.
$CLO $ETH

أعدتُ مؤخرًا (@Dusk ) مراجعة ما كُتب حول جسر السلاسل المتقاطعة لهذا العام مرة أخرى، وأفضل ما يُشاهَد ليس كلمتي “تمت سرقته”، بل أين حدث العطل بالضبط. في 16 يناير، كانت المشكلة في محفظة التوقيع التي يستخدمها الجسر: بعد أن حصل المهاجم على صلاحية الإقراض، نقل الأصول من جهة Dusk، ثم حوّل جزءًا منها إلى BSC. أوضحت الجهة الرسمية بشكل صريح أن الأمر ليس فشلًا في الإجماع، وليس اختراقًا/اختراقًا للبروتوكول على مستوى L1.

لكن هذا لا يعني أن السلسلة الأساسية بخير، وأن على المستخدم تجاهل مخاطر الجسر. في البنية القديمة، كانت عملية استلام الأحداث والتوقيع وإطلاق الأموال كلها مضغوطة في مسار واحد: السرعة كانت جيدة، لكن بمجرد أن يُخترق جانب التوقيع، تصبح الصلاحيات شديدة التركّز. أما إعادة التصميم لاحقًا ففصلت بين ثلاث مسائل: أولًا، تُسجَّل الأحداث كمهام؛ وثانيًا، يقوم الـ worker بمعالجتها وفقًا لآلة حالات (state machine)؛ وثالثًا، تُحفظ المعاملة الأصلية المُوقَّعة أولًا، وإذا فشلت تُعاد عملية الإرسال لنفس المعاملة. كما أن المحفظة الساخنة لا تحتفظ إلا برصيدٍ يلزم للمدة القريبة، وإذا انخفض عن حدّ معيّن تُوقَف العملية، وتُكمَّل يدويًا في المحفظة الباردة.

كنتُ أيضًا سابقًا أسهل من الوقوع في فكرة أن “الجسر ليس بروتوكولًا” كجملة تعفي من المسؤولية، لكنني الآن أميل لرؤية الأمر بالعكس: طالما اعتبر المستخدم الجسر بوابة للسيولة، فهذا يعني أن الجسر دخل بالفعل حدود الأمان الحقيقية لـ $DUSK . إن أمان الإجماع على السلسلة وأمان نقاط دخول/خروج الأصول هما ورقتان يجب أن يحصل فيهما كلاهما على حدّ النجاح.

اتجاه المعالجة هذه المرة صحيح، لكن نقاط المخاطرة لم تختفِ: هل سيستمر تنفيذ عزل المفاتيح على المدى الطويل؟ وهل العتبة منطقية؟ وهل يمكن تدقيق التوقف وعمليات إضافة الرصيد (التعويض)؟ يجب الاستمرار في مراقبة كل ذلك. المجتمع #dusk ينبغي ألا يسأل فقط “هل تم اختراق السلسلة؟”، بل “أي مفتاح ما زال يحتفظ بصلاحيات تتجاوز النطاق الضروري؟”. أنتم عندما تنظرون إلى الجسر عبر السلاسل: هل تبدأون بتدقيق الشيفرة، أم تبدأون بفهم كيفية قصّ صلاحيات التشغيل؟
$TREE $ETH

我今天顺着 @TermMax 文档里的FT、XT、GT画了一遍资金流，画到第三个箭头时就想笑：一笔固定期限借贷，怎么被拆成了三套代币？设计确实精巧，可普通用户到底该盯哪一个？

我先把逻辑捋直。FT像零息债券，到期能按面值换回债务资产；XT补上FT折价的那部分，协议定义里始终是1 FT加1 XT对应1份债务资产；GT则是ERC-721，装着抵押物和债务头寸。借款人锁抵押物、铸FT，再把FT拆成本金部分和利息部分去换XT，最后拼回想借的资产。纸面上闭环挺漂亮，我承认这比“利率凭空写在页面上”更可验证。

可我越往下看越犯嘀咕。FT价格会随剩余期限和市场曲线变化，XT到期价值归零，GT又承担清算风险。三个代币分别记期限、利息和抵押债务，TermMax把一笔贷款拆得很透明，也把用户需要理解的状态拆得更碎了。页面上一键成交，不代表链下脑子也能一键理解吧？

更关键的是，借款人可以直接拿债务资产还，也可以买折价FT还。听着灵活，可这意味着提前退出的成本不只看最初锁定的利率，还要看FT市场有没有深度、当时曲线给什么价格。固定利率解决的是合同确定性，退出价格仍然得跟市场谈。

我又对照了一下到期端。FT正常情况下按面值赎回，可借款人逾期、清算又没在窗口里处理干净，赎回池就可能混入抵押物。也就是说，FT像债券不假，信用保护却不是某个机构承诺兑付，而是抵押率、预言机、清算人和市场流动性一起接力。少看一棒，结论都可能跑偏。

所以我研究 #TermMax 后最想看的，不是再来一张“固定APY”海报，而是每个仓位把FT、XT、GT的变化和最差退出路径讲人话。复杂机制可以藏在一次点击后面，风险要是也跟着藏进去，那这层简化到底是在服务用户，还是只服务成交？
$PRL $CLO

تحدث قليلاً عن أشياء ليست بالضرورة مثيرة، لكنّها هي التي تحدد حقًا ما إذا كان بإمكان الشبكة أن تعمل على المدى الطويل: إصدار ورهن <b>$DUSK </b>. بعد قراءة أحدث وثائق <b>@Dusk </b>، لاحظت أن كثيرًا من النقاشات تركز فقط على "الحد الأقصى للمعروض 1 مليار"، لكنها تتجاهل أن هذه الـ1 مليار لا تدخل السوق دفعة واحدة.

نموذج Dusk هو أن يكون هناك 500 مليون كمصدر أولي، ثم يتم إطلاق الـ500 مليون الأخرى على مدار 36 عامًا كـمكافآت للشبكة، مع تناقص الانبعاثات وفق إيقاع هندسي بنصف كل أربع سنوات. استخدام التوكنات حاليًا مباشر: دفع Gas، والمشاركة في الرهن وحماية الإجماع. لكي تصبح Provisioner مباشرة تحتاج إلى رهن ما لا يقل عن 1000 DUSK، بالإضافة إلى إبقاء العقدة متصلة باستمرار ومزامنة؛ إعدادات الأساس التي يذكرها الموقع ليست مبالغًا فيها، لكن المكافآت تتولد بناءً على المشاركة في الإجماع واحتمالية الرهن الفعّال، وليست بمجرد الإيداع تحصل على عائد ثابت.

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

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

لذلك، ألاحظ أن <b>#dusk </b> لن ينظر فقط إلى كون نسبة الرهن مرتفعة، بل سيجمع بين ثلاثة مؤشرات معًا: هل Provisioner النشطون موزعون أم لا، ونسبة الرسوم الفعلية من المكافآت، وما إذا كانت العقدة قادرة بعد الترقية على البقاء متصلة بثبات. مجرد النظر إلى كمية القفل قد يبدو جميلًا، لكن إذا لم يكن هناك استخدام، فهذا مجرد إخفاء للسيولة ولا يثبت وجود طلب.

ما رأيك: في المراحل المبكرة لأي شبكة جديدة، هل ينبغي إعطاء الأولوية لزيادة مشاركة الرهن، أم العمل أولاً على بناء الرسوم الحقيقية؟ اترك ترتيبك.
<b>$ETH </b> <b>$RED </b>

أعدتُ النظر في آلية سعر الفائدة الثابتة الخاصة بـ @TermMax مرةً أخرى، وكلما قرأت أكثر شعرت أن كلمتي «ثابت» قد تُرخي الانتباه بسهولة. صحيح أن سعر الفائدة يمكنه قفلها عند إتمام الصفقة، لكن هل النتيجة النهائية لدي أيضًا أصبحت «ثابتة»؟

أولًا، سأتحدث عن الاقتراض. يحدد TermMax لكل سوق في البداية أصول الدين المترتبة والضمان وتاريخ الاستحقاق، ثم يقوم المقترض بقفل الضمان في GT، وبعدها يتم إصدار FT الذي يمثل ديون الاستحقاق. التكاليف لا تقفز عشوائيًا مع معدل الاستخدام، وهذا أقر به؛ على الأقل لن أضطر للسهر والحدق في أسعار الاقتراض المتغيرة. لكن ما إن يصل LTV إلى LLTV، ستدخل المراكز تلقائيًا في مسار التصفية. ما يتم «تثبيته» هو سعر الأموال، وليس سعر الضمان، ولا سلامة رأس المال. وهذه الأمور الثلاثة عندما تُخلط في التسويق، أجدها قد تُضلل بسهولة.

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

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

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

لذلك عند النظر إلى #TermMax ، لا يكفي أن تسأل فقط إن كان APY في الصفحة «مقفلًا». بل يجب أن تسأل: ما نوع الضمان؟ وأين يقع LLTV؟ ومن المسؤول عن السداد عند الاستحقاق؟ وماذا سأستلم بعد التسليم الفعلي؟ تم تثبيت الفائدة، لكن المخاطر لم تُثبَّت في مكانها، أليس كذلك؟
$GPS $ETH

لقد أعدتُ قراءة دليل ترحيل الشبكة الرئيسيّة لـ @Dusk ، وهناك تفصيلٌ سهل أن يُتَغاضى عنه: الضغط على Approve داخل المحفظة لا يعني أن $DUSK قد تمّت بالفعل ترقيتها إلى شبكة Dusk الرئيسية. إنّ ما يُفعّل عملية الترحيل فعليًا هو Execute transaction في الخطوة التالية. بين الخطوتين، أي انقطاع قد يجعل المستخدم يظن أن الأصول “عالقة”.

تتم العملية الرسمية عبر قفل توكن DUSK من نوع ERC-20 على الإيثيريوم أو BEP-20 على BNB Chain داخل عقد الترحيل، ثم إصدار/صرف العملة الأصلية المطابقة إلى حساب شبكة Dusk الرئيسيّة المحدد. يجب تجهيز محفظة EVM ذاتية الإشراف، وحساب Dusk، ودفع رسوم السلسلة المصدر بالـ ETH أو BNB. بعد تأكيد تنفيذ المعاملة، غالبًا ستحتاج أيضًا إلى انتظار المعالجة. حسابات البورصات عادةً لا يمكنها إتمام هذه العملية مباشرة عبر WalletConnect، بل يلزم أولًا تحويل/توجيه الأمر إلى محفظة يسيطر عليها المستخدم بنفسه.

الآلية نفسها ليست صعبة، لكن المشكلات الحقيقية تكمن في حدود التنفيذ. أولًا: التفويض (authorization) هو مجرد منح السعة/الحد للعقد، ولا يقوم تلقائيًا بتحويل الأموال. ثانيًا: توكنات السلسلة المصدر لديها 18 رقمًا عشريًا، بينما DUSK على الشبكة الرئيسية لديه 9 أرقام عشرية؛ لذلك يتم تقريب/تطبيع مبلغ الترحيل للأسفل إلى أصغر وحدة LUX. أي بقايا أقل من 1 LUX ستبقى في المحفظة الأصلية. ثالثًا: إذا لم يصل الرصيد بعد، فعليك أولًا التحقق مما إذا كانت معاملة Execute قد نجحت، بدلًا من إعادة التفويض.

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

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

عند ترحيل الأصول، ما أسوأ خطوة تخشاها: التفويض؟ اختيار الشبكة الخاطئة؟ أم عدم وضوح حالة وصول الأموال؟ أخبرني بما منعتك/وقع لك من فخ ضمن العملية.
$ACE $BTC

在完整对照了 @Dusk 的开发文档之后，我才发现它现在最值得看的并不是某个 TPS 口号，而是把开发入口拆成 DuskVM 和 DuskEVM 两套环境。看起来像重复造轮子，背后其实是在解决“原生隐私能力”和“现成开发生态”无法同时一步到位的问题。

DuskVM 让 Rust/WASM 合约直接跑在 L1，更靠近 Phoenix：屏蔽交易、零知识能力和原生资产模型；DuskEVM 则基于 OP Stack，开发者能继续用 Solidity、Hardhat、Foundry 和熟悉的钱包工具，执行结果再通过 DuskDS 完成结算与数据可用性。简单说，前者像专用实验室，能力深但学习门槛高；后者像标准接口，接入快，却要处理跨层协同。

这条路线确实务实。很多隐私链技术做得很重，最后卡在没人会开发；普通 EVM 链工具齐全，又很难原生处理受监管资产需要的保密和选择性披露。Dusk 把两类开发者都留下，至少避免了“技术正确、生态空白”的老问题。

但双环境不是白送的红利。合约放在哪层、资产怎么跨层、故障时由哪层负责，都会增加工程复杂度。尤其 DuskEVM 依赖 DuskDS 结算和数据可用性，用户看到的是熟悉的 EVM 界面，底下却不是一条普通以太坊侧链。如果文档、浏览器和跨层状态提示跟不上，兼容性反而会制造新的理解成本。

我现在不会仅凭“支持 Solidity”就给 #dusk 的开发者增长下结论。接下来更值得盯的是：主网上真实合约数量、跨层资产路径是否顺畅、Hedger 这类保密能力何时形成可复用组件。$DUSK 作为两套环境里的 Gas 与安全资产，价值最终也要靠实际调用量证明，不靠架构图自我循环。

你觉得双执行环境是聪明分工，还是把维护难度放大了？欢迎留下判断。
$BTW $ETH

أعدتُ قراءة مراجعة جسر السلسلة عبر السلاسل (Cross-chain) التي حدثت في مارس من هذا العام @Dusk ، وأهم ما ينبغي تذكره ليس أن “توافق الشبكة الرئيسية لم يكن به خلل”، بل حقيقة أكثر إيلامًا: صلاحيات محفظة موقّعة واحدة كانت في السابق كبيرة بما يكفي لتجرّ الجسر كله إلى القاع.

في 16 يناير، حصل المهاجم على صلاحيات محفظة Dusk الموقّعة لخدمة الجسر. قام أولًا بتحويل الأموال من جهة Dusk، ثم أرسل جزءًا منها إلى BSC. ضمن التسلسل الذي أعلنته الجهة الرسمية، تم سرقة 9,000 و89,700 و2,743,310 و8,068,000 من $DUSK ؛ كما كانت هناك عمليتان نجحتا في عبور الجسر، بينما فشلت آخر محاولة بعد إيقاف التشغيل، وكانت كمية المحاولة 8,910,000.

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

أما التعديلات بعد المراجعة فكانت على صواب: تم فصل التوقيع عن معالجة الأحداث؛ تُسجَّل الأحداث أولًا كمهام ثم تُنفَّذ بواسطة worker مستقل؛ كما تم تقسيم حالة المعاملة إلى seen وsubmitted وcompleted وfailed وstuck. وباختصار: تحويل “طريق واحد يمر حتى النهاية” إلى عدة بوابات اعتراضية.

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

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

لذلك لا تسألوا بعد الآن سؤالًا كبيرًا وبلا معنى مثل “هل Dusk آمن؟”. السؤال الحقيقي هو: أين توجد أصولك الآن، وعلى أي طبقة، ومن الذي يوقّعها، وأي بوابة سيسقط من خلالها الأمر ليتسبب في تحريك الأموال؟ هل أصبح الجسر أكثر تعقيدًا، وهل تم فعلاً تقطيع الثقة إلى أجزاء؟ اكملوا التفكيك في قسم التعليقات.
$BTC

وجدت صفحة اقتصاديات توكن @Dusk ، والشيء الذي أوقفني لم يكن حدّ 10 مليارات، بل قاعدة تبدو غير ملفتة للنظر: الحد الأدنى للـتكديس (الرهان) على العقدة هو 1,000 قطعة $DUSK ، لكن الحد الأقصى غير محدد.

لنحسب الأمور أولاً بدقة. الإمداد الابتدائي لـ Dusk هو 500 مليون، وخطة الإفراج الإضافي تتضمن 500 مليون أخرى على مدار 36 عاماً؛ في السنوات الأربع الأولى يضاف تقريباً 19.8574 قطعة لكل بلوك، وبعد ذلك ينخفض المعدل إلى النصف تقريباً كل أربع سنوات. ضمن مكافأة البلوك: يأخذ المُصدر 70%، ويمكنه أيضاً الحصول على حتى 10% إضافية بناءً على credits الموجودة في الشهادات. صندوق التطوير 10%، ولجنة التحقق 5%، ولجنة الموافقة 5%، والجزء غير الموزع سيتم حرقه.

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

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

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

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

لا تترجم حدّ الإمداد الأقصى مباشرةً إلى ندرة، ولا تترجم عوائد الرهان مباشرةً إلى أمان. في النهاية، وزن العقد بدون حد أقصى: هل هو مكافأة للاستثمار طويل الأجل، أم أنه ببطء يحوّل اللجنة العشوائية إلى مقاعد زبائن دائمين للأثرياء؟ تعالِ نفكها في الساحة.
$VELVET $SNXXB

لقد قرأت وثيقة نموذج المعاملات الخاصة بـ @Dusk مرتين. والأكثر لفتًا للانتباه ليس كلمتَي “الخصوصية”، بل حقيقة أن نفس السلسلة تحمل دفْترين في آنٍ واحد: Moonlight مُعلن، وPhoenix مختفٍ.

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

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

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

فما دور $DUSK هنا؟ كلتا طريقتَي التحويل تستخدمه في الدفع، والتنفيذ التعاقدي لا يستغني عنه أيضًا. ليس مجرد شعار ملصق على قصة “الخصوصية”، بل هو الوقود المشترك بين دفْترين. لكن هل يحتاج الوقود إلى شيء؟ في النهاية يعتمد ذلك على ما إذا كانت المحفظة والبورصة والتطبيق مستعدة بالفعل لاستخراج Phoenix بشكل حقيقي، وليس فقط كتابةً جميلة في الوثائق.

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

لذا لا تنخدع فقط بعبارة “خصوصية قابلة للاختيار”. فثنائي المسارين Moonlight وPhoenix سيجعل المستخدمين يختارون الطريق في النهاية—أم أن غالبية المداخل ستفتح فقط المسار الشفاف الأسهل؟ تابعوا النقاش في قسم التعليقات.
$AKE $ACU