小饼的撸毛日记

朋友跑 Dusk 验证者，问我他节点连续错过出块被罚了，这算不算恶意。我一开始觉得罚没就是罚没，Cosmos 那套双签直接关小黑屋，没什么好辩的。

后来翻 Dusk 的罚没机制，发现它分两种。Soft Slashing，软惩罚，专门管非恶意过失，比如节点该出块时掉线、没在窗口期内广播，不涉及作恶，就是运维出问题。惩罚是每次连续违规扣 N 乘 10% 的质押权益，N 是连续违规次数，同时把节点从共识里踢出去 N 个 epoch，epoch 是 Dusk 的共识周期，每轮结束验证者集合轮换一次。罚掉的 DUSK 不销毁，从活跃质押里划走，节点能自己取回。

Hard Slashing，硬惩罚，管恶意行为。生成无效区块扣 10% 质押并销毁，双重投票或双重出块扣 20% 并销毁。销毁是真的没了，不是锁一阵再还。

我没想通为什么要分两种。后来看文档里关于可追责性的部分才明白。节点只是网络波动错过出块，你就重罚，验证者会把节点放最贵的云上，运维成本高，去中心化反而变差。Soft Slashing 的作用是把不靠谱的节点从活跃集合里挤出去，给机会恢复，每次罚一点，不会让诚实运维的人破产

真正让我改变判断的是 N 的设定。连续违规越多，扣的越多，踢出去时间越长。第一次掉线扣 10% 移除 1 个 epoch，第二次 20% 移除 2 个 epoch，指数级压力，节点要么恢复稳定，要么自动离场。Hard Slashing 留给明确作恶，一次销毁，没有恢复窗口

拿 Polkadot 比。Polkadot 的 Slashing 也分级，但惩罚比例更细，从 0.1% 到 100% 都有，罚款分给举报者。Dusk 这套更简单，要么过失要么恶意，比例固定，销毁不奖励举报。好处是验证者能预测犯错代价，不会因复杂规则不敢跑节点

朋友听完说这次 Soft Slashing 认了，家里网络掉了半小时。我也明白 Dusk 为什么把机制分这么清。没有分级惩罚，诚实节点和作恶节点一视同仁#dusk $DUSK @Dusk

قلبتُ ذات يوم وثائق عقد Dusk التابعة للعُقد، وفيها أن الحد الأدنى الرسمي لمتطلبات عقد Provisioner هو معالج ثنائي النواة (2 CPU) وذاكرة 4GB وتخزين 50GB. تبدو ليست عالية، أليس كذلك؟ أي خادم سحابي عادي قادر على تشغيلها.

لكنني بالمقابل بحثتُ في عقد Archive، فوجدت: 4 أنوية CPU و8GB ذاكرة و500GB تخزين. أما عقد Prover فبالأكثر مبالغة—عامل واحد (Worker) يحتاج 1 CPU مع 1GB ذاكرة، وأقل إعداد هو 4 أنوية و8GB.

استغربتُ: نفس الشبكة، فلماذا تختلف الأجهزة بين العقد بهذا القدر؟

بعدها اكتشفت تصميم إجماع Dusk، وأن SBA تقسم المشاركين إلى نوعين. أحدهما Block Generator، يتم اختيارُه عبر قرعة عشوائية عبر Proof-of-Blind-Bid، بحيث يضيف الكتلة بشكل مجهول. والآخر Provisioner، وهو مسؤول عن التحقق من التصويت وتثبيت الكتل. في كل مرة يتم فيها إصدار كتلة بنجاح، يحصل Block Generator واحد و192 Provisioner على المكافأة. يتم إعادة اختيار لجنة التصويت الخاصة بـ Provisioner في كل دورة عبر قرعة حتمية.

على Provisioner التحقق من شرعية الكتل، وفحص إثباتات ZK، وبث تصويتات موقّعـة بنظام BLS؛ وكل جولة تتطلب تشغيلًا كاملًا. بينما Block Generator هو من يُختار ليباشر العمل، أما Provisioner فيجب أن يكون جاهزًا دائمًا. عقد Archive لا يقتصر دوره على تشغيل الإجماع؛ بل عليه كذلك تخزين سجلّ التاريخ الكامل للسلسلة. أمّا عقد Prover فمهمته توليد إثباتات ZK تحديدًا، وهذه عملية حسابية كثيفة ومركزة على خيط واحد (Single-thread).

كنتُ أظن أن شبكات PoS كلها متشابهة، وأنه كلما زادت نسبة التزامك (staking) على DUSK يمكنك تشغيل العقد. لكن اتضح أن Dusk ليس كذلك إطلاقًا: متطلبات العتاد لكل عقد تختلف اختلافًا كبيرًا. يتم اختيار Generator عبر قرعة مجهولة، ويصوّت Provisioner كلجنة، ويقوم Prover بحسابات ZK الثقيلة، بينما يقوم Archive بتخزين السجلّ الكامل—وكل طبقة تستهلك موارد عتاد مختلفة.

لكن ما يقلقني أكثر هو أن Dusk حاليًا لديها 206 Provisioner نشطين، وأن أول 20 منهم يتحكمون بأكثر من 35% من إجمالي الالتزامات. بعد تقسيم متطلبات العتاد إلى طبقات، فإن من يستطيع تشغيل Archive وProver هم قلة من الناس—وغالبًا هؤلاء أيضًا الأكثر حيازة للرهان. ليست المسألة مشكلة توزيع الرموز فقط؛ فمستوى العتاد نفسه هو أول فِلتر. المواطنون العاديون (المستثمرون الصغار) لا يصلون حتى إلى باب المشاركة، لذلك يتعين عليهم التوجه إلى مسابح Hyperstaking لتسليم عملاتهم إلى الآخرين.

والآن وأنا أنظر إلى لا مركزية Dusk، أراها: نبدأ بالاطلاع على وثائق العقد، ثم نراجع العدد الفعلي لتشغيل الأنواع الثلاثة من العقد، ثم نراجع توزيع التزامات المدققين. البيانات الثلاثة لا تتطابق—فاللا مركزية تصبح مجرد مصطلح. #dusk $DUSK @Dusk

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

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

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

يجب أن يضمن Citadel خمس نقاط: أن يثبت أنك تملك ترخيصًا فعليًا دون كشف معلومات إضافية، وأن تكون الخدمة قادرة على الإلغاء لكن يظل الترخيص صالحًا حتى قبل الإلغاء، وأن لا تكون أنشطتك قابلة للتعقّب، وأن لا يمكن إعادة استخدام الترخيص، وأن يُكشف فقط الحد الأدنى الضروري من المعلومات. هذه السمات الخمس، بعد أن تم تغليفها في أدوات مطوّري SDK من Moat، تشكل جوهر طبقة هوية Dusk — وهي في مستوى DuskDS وDuskVM، وليست “خصوصية” مستقلة بذاتها، بل هي التي تحدد من يملك أهلية إجراء تداولات Moonlight العامة وتداولات Phoenix الخاصة.

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

在研究 Dusk 的时候，我第一眼盯的是 DuskEVM。过去看项目习惯了，先看执行环境——开发者进不进来，决定一条链有没有未来。

翻完资料我又回头看了一遍，这次真正让我停下来的，是 DuskDS。

我以前一直觉得金融上链最大的坎是速度和成本。但把 Dusk 的设计拆开之后，我发现真正麻烦的是另一件事：一笔交易执行完，谁来确认它已经是最终状态？

Dusk把执行和结算拆成了两层。DuskEVM跑应用，基于 OP Stack 搭建，Solidity 开发者用 Hardhat、MetaMask 那套工具就能直接部署。Sequencer 处理交易，batcher 把数据打包成 EIP-4844 blob 往 DuskDS 上传。DuskDS 不关心上面跑什么应用，只管共识、数据可用性和最终状态确认。

我盯着 DuskDS 那部分看了很久，才搞明白它到底在干什么。它跑的是 Succinct Attestation，一种基于委员会的 PoS 协议。每轮一个 Provisioner 提议区块，一个委员会验证，另一个委员会敲定。一旦敲定就是确定性终局性，不像比特币只有概率终局性，正常情况不存在用户能感知的重组。想成为 Provisioner 最低质押 1000 枚 DUSK，节点 7×24 在线，离线太久或作恶会被罚没。

研究到这里我才反应过来——以前觉得区块链最大的价值是让交易更快，但金融市场真正怕的不是慢，是不确定。一笔证券交易，资产转移完了但支付没同步，或者不同参与方看到的状态不一致，效率再高也没人敢用。

Dusk 的确定性结算，本质是在解决这个问题。最终性压到两到三秒，加上交付对支付的原生工作流——这套组合在金融结算场景里才有真正的实用价值。

当然，这套设计最终还需要生态验证。基础设施做好只是第一步，真正的价值还要看资产和应用愿不愿意进来。

但研究完 Dusk 之后，我最大的变化是：不再只关注一条链能处理多少交易，而是开始关注它能不能让金融参与者放心
#dusk $DUSK @Dusk

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

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

الذي أوقفني فعلًا هو <b>Succinct Attestation</b> لدى Dusk. فهي في طبقة الأساس <b>DuskDS</b> تستند إلى بروتوكول توافق <b>PoS</b> قائم على لجنة. يتم اقتراح الكتل والتحقق منها وتأكيدها بواسطة <b>Provisioner</b> يتم اختياره عشوائيًا. تمر كل دورة توافق بثلاث خطوات: مرحلة <b>Proposal</b>؛ حيث يقوم <b>Provisioner</b> مُختار بإنشاء الكتلة المرشحة وبثها؛ مرحلة <b>Validation</b>؛ حيث تتحقق لجنة من صحة الكتلة، ويلزم أن يوافق عليها <b>ثلثا الأعضاء بالأغلبية المطلقة</b>؛ ثم مرحلة <b>Ratification</b>؛ حيث تؤكد لجنة أخرى وتثبت الكتلة نهائيًا. بمجرد اجتياز مرحلة <b>Ratification</b>، تدخل الكتلة حالة نهائية حتمية ولا يمكن التراجع عنها.

راجعْت هذا التفصيل مرتين، لأن ما تقوله ليس «أمانًا مُرجّحًا»، بل «إن تم التأكيد، فهذا يعني حقًا أن الأمر انتهى».

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

أن يصبح المرء <b>Provisioner</b> ليس معقدًا. يلزم رهن ما لا يقل عن <b>1000 DUSK</b>، وتشغيل عقدة واحدة يكفي. يجب أن تكون العقدة متصلة طوال <b>24/7</b>، وبحد أدنى <b>معالج ثنائي نواة</b> و<b>4GB من الذاكرة</b> و<b>50GB من التخزين</b>. يصبح الرهن ناضجًا بعد حوالي <b>12 ساعة</b>، وبعدها يمكن المشاركة في التوافق. يتم اختيار <b>Provisioner</b> للجنة بشكل عشوائي عبر سحب بناءً على أوزان الرهن، وكل مرة تكون مختلفة.

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

لما بدأت أبحث في ميزة إجماع Dusk، جلست أتصفح ورقة الـWhitepaper مدة طويلة دون أن أفهم ما المقصود بالنهائية القطعية (deterministic finality). لا بد من ذلك، فاضطررت إلى رسم جدول مقارنة بثلاثة مخططات زمنية على الورق وأجتهد في فهمه.

في Ethereum، يستخدم Gasper نهائية احتمالية، حيث يجب تكديس البلوكات لعدة epochs حتى يمكن اعتبارها آمنة بشكل أساسي. كما أن Tower BFT في Solana يحتاج إلى عشرات الثواني لتأكيد الأمر. فماذا عن Succinct Attestation في Dusk؟ بمجرد الموافقة على البلوك، تكون تلك النهائية صلبة وحاسمة، ولا تعود إلى الوراء.

حينها كنت أحدق في هذه الخطوط الثلاثة على الورق مدة طويلة. قد لا تشعر بفارق بضعة ثوانٍ في المعاملات المشفرة، لكن الانتظار قليلاً أطول يصبح أمرًا مقبولاً. غير أن الحال مختلف تمامًا في سيناريو تسوية الأوراق المالية؛ فهذه الثواني تُقفل الأمان النهائي لأصول بمستوى مليارات. لقد بعت سهمًا في البورصة، ولا تتم التسوية إلا بعد T+2. فخلال يومين، من الذي تُحسب لديه الأصول فعليًا؟ إذا كان بالإمكان إرجاع السلسلة عند لحظة التسوية، فمن يجرؤ على وضع أصول حقيقية عليها؟ يكفي للمتداولين الأفراد قول إن الاسترجاع غير محتمل، لكن لا يمكن لجهات مؤسسية الاعتماد على عبارات مثل «غير محتمل». فعبارة «غير محتمل» لا تعني شيئًا على مستوى الضمانات القانونية والامتثال.

لاحقًا، رجعت إلى الوثائق الرسمية حتى فهمت أخيرًا كيف تعمل Succinct Attestation بالضبط. وبعد أن قرأت تلك الفقرة، شعرت براحة كبيرة، وحصلت أخيرًا على إجابة لسوء فهمي السابق. إنها بروتوكول إجماع PoS غير مُتصَف بالترخيص، ومبني على لجنة (committee). تختار العشوائية في النظام مجموعة من العقد تُسمى Provisioner لاقتراح البلوكات، وتقوم مجموعة أخرى من العقد بالتحقق، وفي النهاية تؤكد مجموعة اللجنة نتيجة التحقق وتُصدر الموافقة الرسمية على البلوك. بمجرد أن يمر البلوك بخطوة ratification، يصبح ذلك نهائية قطعية، ولا يحدث — في التشغيل الطبيعي — أي إعادة تنظيم للبيانات موجهة للمستخدم.

أطلقت الشبكة الرئيسية لـDusk رسميًا في 7 يناير 2026، ويمكنها معالجة أكثر من 20000 معاملة في الثانية. بعد ست سنوات من التطوير، انتقلنا أخيرًا من الشبكة التجريبية إلى مرحلة يمكنها تشغيل أصول حقيقية. في السابق كان فهمي لآليات الإجماع يتمثل في أن من يَخرج البلوك يأخذ المكافأة، وأن الأمر لا علاقة له بالمستخدمين العاديين. لكن Dusk أجبرني على النظر من زاوية مختلفة: إن اختيار آلية الإجماع في جوهره يجيب عن سؤال أساسي للغاية—إذا وضعت هذه الأموال هنا، هل يمكن فعلًا اعتبارها ذات قيمة أم لا؟ الإجابة التي تقدمها Succinct Attestation هي أنها نعم، ودون الحاجة لزيادة عبارة «احتمالية».

#dusk $DUSK @Dusk

في الأسبوع الماضي أنهيتُ عملية اقتراض بضمان ETH على شبكة الاختبار TermMax، ثم فتحت المحفظة وألقيت نظرة على الرصيد. ظهر شيء إضافي: NFT. بصراحة لا أتذكر أنني استلمت هذا الشيء. في ذلك الوقت كان رأسي فوضى؛ أول ما خطر لي هل المحفظة فيها فيروس أم أن شبكة الاختبار قامت بإلقاء شيء عشوائي على شكل Airdrop؟ أعدت التحديث ثلاث مرات وما زال موجودًا. بصراحة بدأت أتوتر قليلًا—لا أريد أن يختفي الـ ETH الذي وضعته كضمان.

ثم ذهبتُ إلى مراجعة الوثائق الرسمية، وقرأت فيها قرابة نصف ساعة، بل وتصفحت حتى منشورات النقاش المبكرة في المجتمع، إلى أن فهمت أن هذا هو GT الذي كنت قد تجاهلته من قبل قليلًا. هل تعرف ما منطقها الأساسي الأكثر أهمية؟ أنت تقترض مبلغًا، والبروتوكول مباشرةً يقوم بعمل Mint لـ NFT لك؛ داخل الـ NFT تُسجَّل كمية الأصول التي راهنتها، وكمية الـ FT التي اقترضتها، ومعلمات MLTV المقابلة للفترة/المدة. كل قرض هو عبارة عن NFT مستقل.

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

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

كنت أظن دائمًا أن GT مجرد وثيقة حقوق عادية، والآن فقط فهمت قيمته الحقيقية: أنه يحوّل ملكية قرضك بالكامل وبشكل كامل إلى المستخدم نفسه. أستعد لفتح عدة صفقات/مراكز مختلفة آجال على الشبكة الرئيسية بعد الإطلاق، وسأراقب خطوة بخطوة الأداء الكامل لـ GT عند سداد الاستحقاق لكل مركز على حدة. #termmax @TermMax

عندما كنت أطلع على سلاسل البلوكشين الخاصة بالخصوصية من قبل، كنت أعتقد دائمًا أن الإثباتات صفرية المعرفة كافية للتعامل مع معظم الاحتياجات التشفيرية؛ طالما تم إدراج معاملات التداول ضمن الإثبات، يتم تنفيذ المعاملة عبر ZK Virtual Machine. لكن بعد دراسة نموذج معاملات Phoenix الخاص بـ Dusk، تغيّر هذا التصور لدي. إن الصعوبة الحقيقية لا تتمثل في توليد معاملة مجهولة فحسب، بل في مواصلة صيانة قواعد صلاحيات الخصوصية تلك بشكل مستمر في بيئات معقدة ومتغيرة.

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

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

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

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

@TermMaxFi من قبل كنت أودع 30 يومًا في Aave بسعر فائدة ثابت، واصطدمت بوجود تشفير ثابت للمعاملات (hard coding) في المعلمات لم أستطع تغييره، فخسرت بضع مئات من الأرباح. لذلك فأنا شديد الحساسية تجاه الافتراضات الأساسية لمنتجات الفائدة الثابتة. عندما أقرأ ورقة TermMax البيضاء، رأيت جملة كان الفريق يتمسك بها دائمًا باعتبارها السردية الأساسية؛ وكلما قرأتها أكثر، شعرت أنها كعب أخيل مخبّأ في الظل: «تجزئة الاستحقاق عبر AMM هي أفضل مسار لتحقيق الفائدة الثابتة على السلسلة حاليًا». نقطة الانطلاق المنطقية واضحة جدًا—لا يمكن للفائدة المتغيرة أن تقوم بتسعير طويل الأجل، لذا نستخدم بركًا مُجزأة تُقفل العائد عند الاستحقاق.

لكن هناك صمتًا قاتلًا: الفريق في TermMax لم يناقش أبدًا، في سيناريو حسب تقديري الشخصي—ماذا لو حدث يومٌ ما دعمٌ أصلي من بروتوكولات الإقراض الرئيسية للفائدة الثابتة على شكل شرائح (slices)؟ ما مصير نظام AMM المُجزأ حسب الاستحقاق؟ الدعم الأصلي للشرائح يمكن أن يسمح لبركة الفائدة المتغيرة بتقسيم حيزات مستقلة للفائدة الثابتة دون الحاجة إلى نشر منظومة إضافية مستقلة لبركة الأموال حتى الاستحقاق. هذه القطعة هي «الكأس المقدسة» للتسعير طويل الأجل في نظر مجتمع الإقراض DeFi. بمجرد أن ينجز بروتوكول الإقراض الرئيسي ترقية كاملة، ستعود إلى الحياة فورًا خطط كانت لا تزال محاصرة لأن الإصدار الثابت يحتاج إلى بروتوكول مستقل. أي منتج تختار: واحدًا يمكنه فتح مراكز فائدة ثابتة مباشرة داخل بركة الإقراض الحالية دون نقل السيولة عبر البروتوكولات، أم واحدًا يجب عليه إنشاء صانع سوق مستقل، وكل صفقة فيه يجب مطابقتها مع طرف مقابل عند تاريخ الاستحقاق داخل بركة أموال مستقلة؟

كما كان الحال عندما وصلت الهواتف ذات الأزرار إلى أقصى درجة في تفاعل الأزرار؛ ثم جاءت الهواتف باللمس (الشاشة التي تعمل باللمس) فتسببت بضربة تقليل للبعد (decrease in dimension) مباشرة. AMM مُجزأ حسب الاستحقاق الآن هو هاتفٌ بآلية الأزرار—أكثر حل أنيق للتنازل عندما تكون قدرات الفائدة الأصلية على السلسلة محدودة. بمجرد أن تهبط شُرارة (قشة) «التجزئة الأصلية للفائدة الثابتة»، قد ينقلب السرد الحالي بين ليلة وضحاها.
$TMX؟ يقول TermMax إن التقاط القيمة لديه يعتمد على الاستخدام المستمر للصفقات ذات الفائدة الثابتة—صنع السوق يكون عبر إقفال الضمان بـ TMX، وتوزيع الرسوم يتم عبر رهن TMX، وإيرادات البروتوكول يتم حرق TMX بشكل مستمر. لكن عندما تولّد التجزئة الأصلية قدرة حقيقية أصلية للفائدة الثابتة، فمن سيظل يتفادى استخدام بركة الأموال المُجزأة للاستحقاق؟ إن النموذج الاقتصادي لـ TMX مبني على فرضية أن بروتوكول الإقراض العام لا يستطيع تقديم فائدة ثابتة؛ وإذا انقلبت هذه الفرضية، تتهاوى سردية الانكماش (الانكماش/الحرق)

موقفي: AMM المُجزأ هو حل أمثل موضعي ضمن القيود الحالية، لا تجعله حقيقة أبدية. طبقات بروتوكولات الإقراض الأساسية تتطور؛ العائق الذي يمنع الفائدة الثابتة طويلة الأجل اليوم يمكن تجاوزه غدًا بمجرد إصدار تحديث. هل يستطيع TermMax الانتقال من «شركة منتجات للفائدة الثابتة» إلى «طبقة البنية التحتية لأسعار الفائدة على السلسلة #termmax @TermMax »

أجريتُ مؤخرًا اختباراتٍ متوازية لعدة مجموعات من تدفقات المعاملات عبر حسابات متعددة على Dusk. كنتُ أظن أن سلاسل الخصوصية تتعامل أساسًا مع التشفير وإخفاء الهوية. ثم عندما وضعت معاملات حسابات EVM الشفافة ومعاملات حسابات ZK الخاصة بالخصوصية معًا وشغّلتها في الوقت نفسه، أدركت أن المشكلة الحقيقية ليست كيفية التشفير بقدر ما هي: عند صعود معاملة “شرعية” من الجانبين إلى السلسلة في الوقت نفسه، كيف يتعامل النظام مع التحقق دون أن يكشف النصّ الصريح (plain text). في السابق كنت أعتقد أن شبكة الخصوصية تكفي أن تُثبت صحة الدليل فقط، لكنني أزداد قناعة بأن التعامل مع تعارض المعاملات المتوازية هو التحدي الأساسي للطرح على أرض الواقع على المدى الطويل.

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

يجمع Dusk بين نموذج Phoenix لمدخلات/مخرجات الخصوصية (UTXO)، وطبقة Moonlight الشفافة لـ EVM، ووحدة إثباتات احتساب التكاليف Citadel، وآلية الإفصاح الموجّه (VEP). جوهر ذلك هو السماح للمستخدمين باختيار مستوى الخصوصية في المعاملة بأنفسهم. ميزة هذا الأمر واضحة: يمكن للمستخدمين العاديين استخدام حسابات الخصوصية لحماية مسارات الأصول، بينما يمكن للمستخدمين من المؤسسات استخدام الحسابات الشفافة لإنجاز التسويات الامتثالية دون أن يقيّدهم وضع خصوصية واحد. لكن تظهر مشكلة أيضًا: عندما تحتاج معاملة خصوصية واحدة إلى استدعاء عنوان عقد شفاف، وفي الوقت نفسه تحتاج معاملة شفافة أخرى إلى قراءة رصيد حساب الخصوصية، فكيف يقوم العقد/العُقد (النودات) بمزامنة الحالة دون كشف النصّ الصريح؟ لم تكن لدى كثير من سلاسل الخصوصية هذه المشكلة سابقًا، لأن السيناريو كان إما “كل شيء مجهول” أو “كل شيء شفاف”، ولا وجود أصلًا لمعاملات متوازية بنمطين.

الـ Trade-off الذي أراه الآن واضح جدًا. فبعد زيادة مرونة الخصوصية، يرتفع تعقيد التحقق من الحالة؛ فكلما زاد عدد حسابات وضع مزدوج (double-mode)، زادت تكلفة توليد إثباتات ZK؛ ومع تكرار المعاملات عبر الطبقات (cross-layer)، يصبح حدّ قياس الـ Gas وأيضًا حدود التدقيق وتتبع الأثر أكثر غموضًا. يمكن أن تعكس مؤشرات مثل تأخير المعاملات عبر الطبقات، ومعدل فشل التحقق من الأدلة، ووقت التحقق في الإفصاح الموجّه، نضج الطرح الفعلي لسلاسل الخصوصية العامة بدرجة أكبر من كونها تقيس TPS.

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

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

بالنسبة لطلب واحد بنفس معدل الفائدة الثابت، يتم التحقق المزدوج على السلسلة عبر Fixed-Term TimeLock Module مع مُخبر (Oracle) مستقل. وبعد اكتمال عملية المطابقة فقط يتم تسجيل الإثبات على السلسلة. النص الأصلي الرسمي يقول إن آلية التحقق الكاملة على طول السلسلة يجب أن تكون قد خرجت بالكامل من مرحلة اختبار/طرح الخدمة (public test) لكي تُعتبر مكتملة. أما الآن، ففي هذا التوقيت ما زالت تغطية كل مدد/فترات الأحواض تتم تدريجيًا، وليست متاحة بالكامل منذ اليوم الأول لإطلاقها على الشبكة الرئيسية. أما ضمانات صناع السوق (Market Makers)، فمطروحة في “حوض الضمانات المعزولة” الخاص بالبروتوكول. اختبرت ذلك: نافذة الخلاف تبلغ 24 ساعة. إذا تم بعد إتمام صفقة الطلب سحبٌ خبيث (malicious withdrawal)، أو جرى تعمّد الإبلاغ عن سعر فائدة غير صحيح بهدف إرباك السوق، ثم نجح تحدّي ذلك عبر عقد/عُقد التحكيم على السلسلة، فسيتم مصادرة هذه الضمانات مباشرة. هذا يُسمّى “مصادرة الضمان عند الإخلال” (违约罚没)، وتكلفة ارتكاب الشر لا تُدفع إلا بالمال الحقيقي؛ لا يمكن استردادها.

في المرة السابقة، كتبتُ $TMX ونظام الأمان هذا بشكل عام جدًا، ما قد يجعل البعض يظن أن ضمانات صناع السوق هي في الواقع TMX فقط. لكن هذا ليس الشيء نفسه. بالرجوع إلى مواد الإفصاح الرسمية عن التوكن (اطّلعت على الفصل الخاص بتوزيع التوكن رقم 17)، فإن دور TMX في المرحلة الحالية يتمثل في أربع نقاط: مكافآت التعدين لموفري السيولة، الرسوم البروتوكولية عند إنشاء الأوامر وتعليقها، ضمان TMX الذي يلتزم به صانع السوق عند تقديم الخدمة، إضافةً إلى حق التصويت في الحوكمة على معلمات الفائدة التي يتم الحصول عليها بعد الرهن. بينما تحويل TMX ليصبح “أساس الرسوم والرهْن” الأصلي للشبكة ككل—بحسب ما كتبه الرسمي—يتطلب انتظار التشغيل الكامل لحوض المدد عبر السلاسل في نسخة V2. وما زلنا لم نصل إلى تلك الخطوة بعد.

عند وضع خطّين زمنيّين جنبًا إلى جنب، يبدو أن الدائرة المغلقة الكاملة لمعدل الفائدة الثابت في هذا المشروع لا تزال تُركّب على مراحل. $TMX حاليًا يميل أكثر إلى الحوكمة والتحفيز المبكر، بينما العبء الحقيقي المتمثل في أمان سداد الأموال عبر الشبكة كاملة يتحمّله الآن عقد “الوقت المعزول” (隔离时间锁) في هذه الجهة. #termmax @TermMax

لقد علقت في سجلات عقد شبكة اختبار Dusk مدة تقارب ساعة بعد الظهر كاملة. كل مكعبات الثلج في قهوتي الأمريكية المثلجة على الطاولة ذابت تمامًا، والماء الذي تكاثف على جدار الكوب تسرّب إلى سجادة الماوس تاركًا حلقة رطبة. وضعت الماوس على قاعدة الشحن اللاسلكي وجلست متحيرًا خمس دقائق، وفجأة تذكرت مشكلة كانت عالقة بي دائمًا: يوجد الكثير من المشاريع التي تعمل على سلاسل بلوكشين خصوصية، فلماذا اختارت Dusk في النهاية آلة افتراضية Rusk أصلية للخصوصية، بدلًا من إضافة طبقة ملحق خصوصية ZK على EVM؟ في البداية اعتقدت أن الأمر مجرد اختيار لمسار تقني، لكن بعد أن قلبت موادهم الرسمية الخاصة بنموذج تداول Phoenix والخصوصية من طرف إلى طرف عدة مرات، أدركت أنني كنت أبسط الأمور أكثر من اللازم.

المكان الأكثر إلحاحًا في تطبيقات الخصوصية ليس بحد ذاته برهان الصفر-معرفة، بل هو خطر تسرب الحالة على طول السلسلة كاملة. إذا أضفت فقط «غلافًا» خصوصيًا على طبقة معاملات EVM، سيبقى في كل مكان أثر نصي واضح: في تخزين العقد، وفي مكدس التنفيذ، وفي سجلات الأحداث. يكفي تسرب أي جزء منها حتى تُصبح حماية الخصوصية التي وضعتها في المقدمة غير مجدية. بدأت Dusk بتصميم خصوصية أصلي من طبقة آلة Rusk الافتراضية، ثم استخدمت إثباتات PLONK العودية لربط الحالة (state anchoring). لا يستغرق التحقق من معاملة خصوصية واحدة على عقدة واحدة سوى 1.2 ثانية، أي أسرع بنحو 4 مرات من حلّ «تغليف» EVM بملحق ZK. وباختصار، كان الأمر اختيـارًا واعيًا بين عمق الخصوصية وكفاءة التطوير والأمان؛ وليس مجرد مطاردة تأثير سريع مثل: «التوافق مع EVM لبدء النظام البيئي بشكل أسرع».

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

خصوصية «من طرف إلى طرف» في النهاية هي مجرد عرض لميزة منتج. نموذج الثقة هذا—«العقد بلا وعي + المستخدم يتحكم في كل ما يخصه»—هو بالفعل ما يستحق التفكير عليه من قبل @dusk_foundation، والأصعب أيضًا في النسخ #dusk $DUSK @Dusk

أقوم مؤخرًا بإعادة التعمق في آلية AMM لسعر فائدة ثابتة التابعة لـ @TermMaxFi. الشيء الذي علّقني لعدة أيام كان سؤالًا غبيًا إلى حد ما: لكي تدخل قروض DeFi إلى سيناريوهات مالية أكثر شمولًا، هل ينقصنا عدد أكبر من أدوات الاقتراض، أم أننا نحتاج إلى طريقة تسعير لا يضطر فيها المستخدم لتحمّل مخاطر تقلب سعر الفائدة؟ بعد أن قرأت فصلَ “الورقة البيضاء” الرابع والبيانات الحقيقية للتداول على الموقع الرسمي عدة مرات جنبًا إلى جنب، أميل إلى الاعتقاد بأن TermMax لا يحاول حل مشكلة “ارتفاع/انخفاض” سعر الفائدة على السطح، بل بالأحرى كيف نجعل تكلفة رأس المال للاقتراض على السلسلة قابلة للتنبؤ.

في السابق، عندما كان DeFi يلعب دور الاقتراض، كانت المسارات في الأساس مبنية على نماذج أسعار فائدة متغيرة. عند الاقتراض كان بإمكانك رؤية الـ APY الحالي فقط، دون معرفة ما إذا كان معدل الفائدة بعد ثلاثة أيام سيتأثر بصفقات كبيرة ويقفز بشكل غير منطقي. سواء كان ذلك Compound أو Aave أو Morpho، تحسّنت كفاءة رأس المال بالفعل، لكن الثمن هو أن يتحمّل كل مشارك عدم اليقين الناتج عن تقلب أسعار الفائدة. زادت الأدوات المتاحة، لكن استقرار أهم عنصر—تكلفة التمويل—صار بدوره متغيرًا قد يتبدّل في أي وقت. جعلني TermMax أشعر أنه مختلف نوعًا ما، لأنه لم يقم أصلًا بإجراء تعديلات على نموذج الفائدة المتغيرة. وفقًا لما يذكره الموقع الرسمي، فإن كل مجمّع (صندوق) مرتبط بتاريخ استحقاق يمتلك منحنى منفصل لسعر فائدة ثابت، ويتم تقييد تكلفة الاقتراض لأجلٍ مختلف بشكل مُحكم مسبقًا عبر آليات مثل صناعة سوق AMM مع تصنيف الاستحقاقات وتسعير الطبقات حسب السيولة. منطق تسعير الفائدة لم يتغير من حيث المبدأ؛ الذي تغير هو مدى قابلية توقع المستخدمين لتكلفة التمويل في المستقبل.

أعتقد أن ما يجب أن ننقب عنه فعلًا هو “طبقة التسعير” ذاتها. لا يحتاج المستخدم إلى تخمين ما إذا كانت كتلة قادمة ستشهد اقتراضًا بمبالغ كبيرة يدفع الفائدة للانطلاق، ولا يحتاج أيضًا إلى الرهان على ما إذا كان البروتوكول سيقوم فجأة بتعديل المعلمات أو تغيير نموذج الفائدة. يعتمد TermMax على صناعة سوق آلية للاستحقاق المرحلي، ثم يضيف طبقة أخرى تتمثل في الاحتياطي/مخزون البروتوكول المتراكم من غرامات التصفية، ليحوّل معدلات الفائدة لأجل مختلف إلى “تكلفة ثابتة” يمكن للمستخدم قفلها مباشرةً. بصراحة، لا يمكنني الجزم الآن بما إذا كانت هذه المعلمات الأربعة: عمق السيولة (Liquidity depth)، ومعدل انحراف الفائدة (Interest deviation rate)، واحتياطي المخاطر (Risk reserve)، ستثبت فعاليتها دون مرور الوقت. لكن TermMax على الأقل لفت انتباهي إلى نقطة: بعد أن يصبح اقتراض DeFi متصلًا برأس مال أكثر شيوعًا في السوق، قد لا يكون من الضروري نسخ استراتيجية الفائدة المتغيرة حرفيًا؛ يمكن تجربة—مع الحفاظ على نموذج أمان لامركزي على السلسلة—أن يحصل المستخدمون أولًا على تكلفة تمويل محددة.
#termmax @TermMax

من قبل كنت أختار بروتوكولات DeFi وفقًا لمعيار بسيط وسريع الحسم: كلما كان TVL أكبر، كان ذلك أكثر أمانًا.

دعمت هذا المنطق لسنوات. بروتوكولات مثل Aave وMorpho، TVL لديها قد يصل إلى عشرات أو حتى مئات المليارات، والمال كله موجود هناك—فما الذي يمكن أن يحدث؟ لذلك عندما كان لدى TermMax “فقط” 90 مليون، لم أكن أنظر إليه بجدية.

الذي غيّر رأيي كان حديثًا عابرًا.

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

عدت بعدها ودرست TermMax بجدية، وفهمت أن المشكلة التي يحلها تختلف تمامًا عن Aave.

المنطق الأساسي في TermMax هو ترميز معدل الفائدة الثابت. يتم تقسيم رمز الدين إلى FT وXT؛ FT هو سند دين بدون فائدة، يُباع بسعر مخفّض قبل تاريخ الاستحقاق. أما XT فهو رمز الحقوق في العائد، ويقترب قيمته من الصفر كلما اقترب موعد الاستحقاق. في أي وقت: 1 FT + 1 XT = 1 رمز دين—هذا الثابت يضمن شفافية التسعير في سوق الفائدة الثابتة. أما GT فهو رمز رافعة (Leveraged Token) وفق معيار ERC-721، ويمثل وضع قرض مستقل. يقوم المقترض بقفل الأصول الضمانية داخل GT، ثم يقوم سكّ كمية مقابلة من FT وفقًا لنسبة القرض إلى القيمة القصوى التي يحددها السوق (MLTV). إذا انخفضت قيمة الضمان مما يؤدي إلى تجاوز نسبة القرض إلى القيمة (LTV) لـ MLTV، فسيتم تصفية هذا الوضع.

في المرة الأولى قرأت العلاقة بين FT وXT ولم ألاحظ شيئًا. وفي المرة الثانية فقط رأيت تلك الجملة—وعندما استوعبت الصورة، اتضح كامل المنطق.

هذه الآلية تحل مشكلة لم يستطع Aave حلها باستمرار—وهي اليقين في تكلفة التمويل.

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

TVL هو مؤشر على الحجم، والفائدة الثابتة هي مؤشر على اليقين. #termmax @TermMax

أُعلن عن هذه المرة إطلاق كتلة الامتثال (Compliance) الخاصة بشبكة Dusk الرئيسية على شبكة Citadel، كنت أصلًا أبحث عن تفاصيل التدقيق الأمني لدوائر إثباتات المعرفة الصفرية، لكنني حين رأيت قائمة أول دفعة من شركاء التعاون الذين قامت الجهة الرسمية بتسميتهم بالاسم، توقفت قليلًا—ليس شركة أمن تُجري تدقيقات في علم التشفير، بل بورصة رقمية مرخصة في هولندا NPEX، ومؤسسة استشارية للامتثال ضمن لوائح MiCA في الاتحاد الأوروبي DAC8
كانت ردّة فعلي الأولى: غريب. ماذا يفعل ذلك؟ فـ Dusk تُطوِّر سلسلة بلوكشين خصوصية طرف-إلى-طرف (end-to-end)، فكيف يكون الافتتاح/التعريف الرسمي لكتلة الامتثال بدعم من شركتين—مؤسسات خدمات مالية مرخصة—وليستا فريقًا أمنيًا متخصصًا في الهجوم/الدفاع التشفيري؟
قلبت عدة تدوينات تقنية رسمية إلى أن فهمت مقصود هذا الترتيب. جوهر كتلة zkUT للامتثال في Dusk هو «منفّذ تنفيذ» (executor) للمعاملات الخصوصية. حتى لو كانت دوائر ZK مكتوبة بدقة عالية، فإمكانية إنجاز المعاملة فعليًا بشكل قانوني لا تعتمد فقط على صحة الكود—بل في النهاية على ما إذا كانت البراهين التي يخرجها تلبي متطلبات الامتثال التنظيمي. مثلًا: في معاملة أسهم مُرقمنة/مُسعّرة على شكل توكنات، حتى لو كانت الخصوصية/إخفاء الهوية مثالية، فلن تحصل على ترخيص إصدار إذا لم تتوافق مع متطلبات MiCA الخاصة بـ«إمكانية التدقيق الموجه» (targeted auditability)؛ وبدون ذلك، لن تجرؤ أموال المؤسسات على الدخول. وبالمثل: في تحويل من مؤسسة ضمن القائمة البيضاء، مهما كانت الخصوصية ممتازة، إذا لم يكن هناك اعتماد لقائمة الهوية من مؤسسة مرخصة، فلن تستطيع التحويل ضمن منظومة السمسرة/الوساطة المرخصة والمتوافقة.
من خلال جعل هاتين المؤسستين «شريكي الإطلاق الأوّلين»، تعترف الجهة الرسمية ضمنيًا بشيء واحد: أن موثوقية كتلة الامتثال هذه في يومها الأول على الإطلاق ليست مسألة اعتماد على Dusk وحدها؛ نصفها يعتمد على دوائر ZK الخاصة بـ Dusk ومنطق «الرهان/الإيداع المجهول» في Citadel، والنصف الآخر يقع مباشرة على عاتق هذين الشريكين للامتثال.
هذا الاكتشاف جعلني أنظر من جديد إلى «الخصوصية طرف-إلى-طرف» التي تروّج لها. إثباتات PLONK التكرارية (recursive) مع نموذج معاملات الخصوصية من Phoenix يضمنان أن عملية تنفيذ المعاملة لا يتم العبث بها سلفًا، وأن حلقة الحساب والخصوصية تُجرى بثقة. لكن هل تقبلها الجهات الرقابية، وهل يمكن ربطها بالمنظومة المالية التقليدية؟ هذه طبقة أخرى تمامًا من متطلبات «القبول عند التطبيق» (deployment/acceptance) المستقلة. كود Dusk التقني لا يستطيع التحكم فيها وحده؛ لا بد من الاعتماد على شركاء امتثال مرخصين ليتحققوا من سجل تفويض كل معاملة امتثالية، بحيث يتم توقيعها كبراهين موجّهة قابلة للتحقق مع ختم زمني (timestamp) وربطها بسلسلة البلوكشين كي يرجع لها التنظيم لاحقًا.
كنت أظن أن موثوقية نظام الخصوصية هذه هي «حزمة واحدة»، لكن الآن اكتشفت أنها طبقتان من الثقة تتراكبان معًا. الثقة في الخصوصية على مستوى التقنية لا تعني بالضرورة الثقة في القبول من منظور الامتثال؛ يجب فصل الأمرين. بعد أن تَوضّحت هذه النقطة، أصبحت أحكم على إطلاق كتلة الامتثال في Dusk
#dusk $DUSK @Dusk

أمضيت قرابة بعد ظهر كامل وأنا أبحث في سجلات شبكة الاختبار حتى أصابتني الحيرة. ذابت كل مكعبات الثلج في القهوة الأمريكية المثلجة على الطاولة، وتكثف الماء على جدار الكوب فترك حلقة رطبة على بساط الفأرة. عندما وضعت الماوس مباشرة فوق قاعدة الشحن اللاسلكي، جلست مذهولًا خمس دقائق قبل أن أتذكر فجأة نقطة غير طبيعية: سجلات رهن/تثبيت (staking) التحقق في سلسلة PoS كلها منشورة على السلسلة علنًا. يكفي للمهاجم أن يتبع عناوين الرهن ليحصل على عناوين IP للعُقد. أما في سلاسل الخصوصية (privacy chains) فيُشفّر حتى مبلغ المعاملات، فكيف يمكن ألا نكشف هوية المُحقق نفسه؟ كنت سابقًا أفترض أن منطق رهن سلسلة الخصوصية يشبه إلى حد كبير PoS العادي، حتى وجدت في ورق/وثائق Dusk وحدة الرهن المجهولة Citadel، فتبين لي أنها لا تخفي فقط عنوان الرهن: بل إنها أيضًا تجعل هوية إصدار الكتل مجهولة عبر خصوصية طرف-بطرف.

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

آلية Citadel المبنية على إثباتات تكرارية (recursive proofs) باستخدام PLONK تتمثل فكرتها الأساسية في معالجة الثغرة التي لا يستطيع أي PoS تقريبًا تجاوزها—أي أن سجل الرهن يكون علنيًا. عند قيام المستخدم برهن DUSK، يقوم بقفل الرموز داخل تجمع رهن مجهول موحّد؛ يتم تعمية مبلغ الرهن وفترة القفل وربط العناوين بالكامل، وباقي العقد لا تحتاج سوى 8 ثوانٍ لإتمام عملية التحقق. وبهذا لا يمكن رؤية علاقة عنوان الرهن، ولا يمكن ربط توقيع إصدار الكتلة بعنوان محدد.

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

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

الموقع الجديد لا يكدّس الكلام التسويقي، بل يعرض التقنية من الأساسيات إلى الطبقات العليا بوضوح. أعمق طبقة هي DuskDS، وهي تتولى الإجماع والتسوية وتوافر البيانات. طبقة الإجماع تستخدم SBA، وهي آلية PoS قائمة على اللجان؛ يتم اختيار مُولّد الكتل بشكل مجهول عبر Proof-of-Blind-Bid، وقائمة المدققين تتغير كل دورة—والهدف من هذا التصميم هو منع تثبيت المدققين مسبقًا أو استهدافهم، وتفادي مشكلة “احتكار أصحاب المال الكبار” لحق توليد الكتل في PoS التقليدي. طبقة المعاملات تعتمد Phoenix، المبني على نموذج ملاحظات UTXO؛ يتم حفظ الأموال على شكل “notes” مشفّرة، مع استخدام التزامات Pedersen لإخفاء المبالغ، ومُبطِل-المعاملات لمنع الإنفاق المزدوج. العقدة لا تهتم إلا بالتحقق من صحة إثباتات المعرفة الصفرية. عندما كنت أختبر النظام في السابق وأضع بيانات نصية صريحة داخل المعاملات، تم رفضها مباشرة—وهذا ما جعلني أفهم أن هذه قاعدة صارمة “مُحكمة” حتى من طبقة الإجماع.

ثم انتقلت للأعلى. في طبقة Dusk Trade ظننت في البداية أنها مجرد DEX خصوصية بواجهات جاهزة، لكن عرض سير العمل في الموقع الرسمي اكتشف لي أنها تستدعي مباشرة قناة التسوية الأساسية. دفتر الأوامر يكون مشفّرًا افتراضيًا، ويستخدم تشفير ElGamal المتماثل؛ أي أن سعر الأوامر والكمية على السلسلة يكونان نصًّا مشفّرًا بالكامل. يقوم محرك المطابقة بالحساب على النص المشفّر، وبعد تحديد سعر التنفيذ والكمية يتم فك التشفير لإتمام الصفقة، وبذلك لا تُكشف تفاصيل الأوامر طوال العملية. ثم توجد طبقة أعلى وهي DuskEVM، طبقة تنفيذ مبنية عبر تعديل OP Stack؛ تقوم بالتسوية مباشرة على DuskDS. وعندما يتم ربط Sol بالأعلى، يمكنه وراثة قدرات الخصوصية على المستوى الأساسي دون إعادة بناء من الصفر. وفي الأعلى توجد سير عمل سوق ملتزم باللوائح التنظيمية: يتم تحويل Citadel إلى وحدة معيارية قابلة للاستدعاء من النظام؛ لا يحتاج المستخدم إلى إرسال صورة جواز سفر، بل يثبت عبر إثباتات المعرفة الصفرية أن “التحقق من الامتثال” قد تم إنجازه.

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

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

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

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

كان أكثر شيء يزعجني في سلاسل الخصوصية هو مشكلة KYC. العام الماضي استخدمت سلسلة خصوصية “مُلتزمة”؛ رفعت صورة جواز السفر عبر إضافة طرف ثالث، وفورًا تلقيت رسائل SMS قمامة عن استثمارات/منتجات مالية بالخارج. في Dusk، ZkKYC مُدمج داخل آلة Rusk الافتراضية: بيانات KYC تبقى محفوطة على جهازك محليًا. عند إجراء المعاملة، يتم فقط توليد إثبات بأنك “تستوفي متطلبات التنظيم”. حتى فريق المشروع لا يقدر يحصل على معلومات هويتك، وإذا فتح المنظمون عرض تدقيق فسيرون أيضًا فقط المعاملات المحددة.

الآن بعد أن دمجوا PR الخاص بإثباتات هجينة تجمع FRI مع PLONK، انخفض زمن التحقق للحصة الواحدة إلى 1.4 ميلي ثانية. تشغيل عقود سرية باستخدام Gas يكون أقل بنسبة 67% من EVM وهو يستخدم طبقة ZK. أنا نشرّت عقدًا تجريبيًا لِسندات ديْن، ولم يحتج حتى إلى أكثر من 20 سطر كود؛ وكانت تكلفة الـGas 0.28 $DUSK فقط.

سابقًا، خسرت قرابة ألفي U في سلاسل خصوصية قديمة بسبب “التسلسل/الحبس”. كنت أعتقد أن الخصوصية والامتثال هما خصمان طبيعيان: إما أن تكون الخصوصية مرتعًا للغسل الرمادي، أو أن تكون “سلسلة امتثال” تقوم بكشف خصوصية المستخدمين بالكامل. بعد أن أنهيت اختبار Dusk فهمت أن الخصوصية أصلًا لا ينبغي أن تكون غطاءً لعمليات رمادية؛ يجب أن تكون أصول المستخدمين وبيانات هويتهم بيدهم دائمًا. والامتثال أيضًا لا ينبغي أن يأتي على حساب التضحية بالخصوصية. Dusk حلّ هذا العقدة الملتبسة من الجذر—بعد نحو عشر سنوات—وقصّها بالكامل @Dusk
#dusk $DUSK

لم يعد هناك سيولة في سوق العملات المشفرة، مثل سوق الأسهم الصينية تمامًا#闪迪股价涨幅扩大至11%

في عطلة نهاية الأسبوع، تحت شرفة المقهى أسحب مكيفًا و«أفلت» لاختبار شبكة Dusk، ونسيت كلمة المرور ثلاث مرات متتالية حتى أخطأت—وبعد عناء لمدة نصف ساعة فقط انتهيت من تشغيل الصفقة رقم 21. طَرَقْت طويلاً في سجل تنفيذ جهاز Rusk الظاهري—كنت قد لعبت من قبل مع عدة سلاسل قديمة للخصوصية؛ إما تتعطل لساعات قبل أن تنتج كتل، أو تُنجز إخفاء الهوية بشكل يُلزم الامتثال بطريقة تجعل من المستحيل فتح صلاحيات التدقيق. في الأصل لم أعد أملك أي توقعات لما يسمى «سلسلة خصوصية»، لكن بعد أن وقعت فعليًا في الفخ فهمت أن الأمر ليس مجرد غطاء لترويج مفهوم.

أولًا، عندما كنت أؤدي دور عضو في توافق SBA، ظننت أنه مجرد PoS مُعاد تغليفه. وبعد أن قلبت قواعد العقد بالكامل، وكنت قد شغّلت محاكاة مزدوجة الصرف 10,000 مرة، أدركت الحقيقة: SBA (Segregated Byzantine Agreement، اتفاق بيزنطي معزول) يقسم العقد إلى طبقتين؛ طبقة مسؤولة عن إنتاج الكتل لتغليف المعاملات، وطبقة أخرى من المدققين الذين يقومون بمراجعة عشوائية عبر تدقيقات انتقائية. بذور الاختيار العشوائي تُولَّد عبر VDF (دالة تأخير قابلة للتحقق)، ولا يمكن لأحد التنبؤ مسبقًا بمن سيتم تدقيقه. أظهر متصفح الشبكة التجريبية أن لدينا 3 عقد تم تغريمها بمصادرة الضمانات بسبب إرسال كتل غير صالحة؛ اثنتان منها كانت «عقوبة لينة»—تسببت في تفويت عدة كتل، وتمت إزاحتهما مؤقتًا من قائمة توافق الإجماع، كما تم تقليص مقدار الضمان الفعّال. أما الثالثة فكانت «عقوبة قاسية»—تمت ملاحظة التوقيع المزدوج، فتم خصم توكنات الضمان مباشرة بنسبة 20% وإحالتها إلى الإتلاف. ترفع آلية العقوبات هذه تكلفة إساءة السلوك إلى مستويات عالية جدًا، وتكون تكلفة التجربة باهظة.

أثناء اختبار المعاملات، انزلقت بأحد الأصفار: ضغطت رقمًا زائدًا 0، فبلغ المبلغ مباشرة خارج نطاق Range Proof، فعادت المعاملة فورًا إلى الخلف، ولم يترك حتى أثرًا على السلسلة كمعاملة فاشلة. يقوم Phoenix Protocol بفرض نطاق مبلغ المعاملة بالـ Range Proof بشكل صارم، مع استخدام Pedersen commitments لتثبيت إجمالي أصول كل عملية بشكل لا يمكن التلاعب به؛ لذلك لا يمكن حدوث إصدار مجاني. وبالإضافة إلى ذلك، فإن Stealth Address أحادي الاستخدام—يتم استبدال العنوان تلقائيًا في كل معاملة—جعله مستحيلًا أن أربط على السلسلة بين الدفعات الخمس التي حولتُها من التوكنات التجريبية إلى حساب واحد. تم ضغط إثبات PLONK الخاص بالتجميع العودي إلى 287 بايتًا، ولم تتجاوز مدة التحقق لكل معاملة 1.8 مللي ثانية؛ كان كل شيء سلسًا للغاية، وحتى في ذروة الشبكة التجريبية لم نواجه ازدحامًا.

جهاز Rusk الظاهري مكتوب بالكامل من الصفر بلغة Rust، ويقدم دعمًا أصليًا لمعيار الأصول السرّية. عند نشر اختبار Token، لم أحتج لكتابة أكثر من 200 سطر كود خصوصية—وعمل الغاز في العقود كان أقل بنسبة 63% من وضع طبقة ZK فوق EVM. كما ترك مساحة لصلاحيات التدقيق للجهات المتوافقة، فلا نحتاج للاختيار بين الخصوصية والامتثال؛ يمكن الجمع بينهما معًا. في تلك الليلة بعد تشغيل الشبكة التجريبية، شعرت براحة أكبر من أي مشروع كنت قد استثمرت فيه سابقًا.
#dusk $DUSK @Dusk