wz爱喝牛奶

我最近看 TermMax 的到期机制时，反而卡在一个很现实的问题上：既然借款利率和期限都提前定死了，为什么协议还要给借款人设计 Roll 的出口？

按固定期限借款的直觉，到了 maturity 就还钱，事情结束。

可现实里最麻烦的恰恰是这一天。

本金可能还在抵押资产里。

仓位也没有坏。

只是你手上的现金，刚好没准备好。

TermMax 的固定期限设计天然存在这个“到期悬崖”：借款人到期要么一次性偿还，要么寻找新的融资来源。官方和 Morpho 的集成方案，就是把再融资这条路提前接进来，让借款人在接近到期时可以退出原来的固定利率头寸，再寻找新的资金来源。

> 我觉得这里真正需要管理的，不是利率，而是“时间到了以后，谁来给本金续命”。

这对借款人很重要。

因为固定利率给了你可预测的成本，却没有自动保证你到期那一天刚好有足够现金。

所以 TermMax 这里出现了一个很有意思的取舍：

固定期限让融资计划更清楚。

但期限越明确，到期日也越像一道硬门槛。

提前准备好再融资，仓位可以继续运转。

没准备好，就可能被迫退出原来的融资结构。

我现在反而觉得，固定利率真正难的部分不是“锁住利率”，而是**怎么安全地走出这笔期限交易**。

如果你是借款人，你更愿意接受一个利率稍高、但可以灵活续上的融资方案，还是宁愿锁住更低的固定成本，自己承担到期前找下一笔钱的压力？@TermMax

#termmax

我最近看 Dusk 的受监管资产设计时，真正让我停下来的是一个很小的区别：为什么“这个钱包能签交易”，还不能直接等于“这个钱包有资格买这项资产”？

普通代币逻辑很简单。

有余额。

有签名。

交易就走。

但如果换成证券类资产，这套逻辑马上不够用了。Dusk 当前文档把 eligibility、身份、wallet binding 和 access control 单独放进资产工作流里。也就是说，链上要判断的不只是“谁在发起交易”，还包括“这个参与者是否符合这项资产的持有条件”。

> 我觉得这里真正被拆开的，是“控制钱包”和“拥有资格”这两件事。

站在投资者角度，这意味着一个地址即使掌握私钥，也不代表它天然可以接收所有受监管资产。

站在发行方角度，这反而是必要的。

因为证券上链以后，最怕的不是没人交易，而是资产被转给一个本来就不应该进入这个市场的地址。

Dusk 的 Citadel 作为身份与访问层，就是在处理这条边界，让资格和链上账户之间建立关系，同时又支持只披露必要的信息，而不是把整套身份资料摊在公网上。

代价也很明显。

普通代币只要钱包和签名没问题就能转。

受监管资产却多了一层资格判断。

体验没那么“无脑”。

但这恰恰可能是金融资产真正上链后逃不开的一笔账：

**开放的地址，不等于开放的资产资格。**

如果你是资产发行方，你会接受多一层身份和资格限制，换取资产真正进入合规市场；还是宁愿保持普通代币那种“谁有钱包，谁就能接”的简单规则？@Dusk

#dusk $DUSK

我看到 TermMax V2 有个设计，第一反应其实挺矛盾：一个主打“固定利率”的协议，为什么还要把没借出去的钱放进 Aave、Morpho、Venus 这种浮动利率市场？

按直觉，既然都来 TermMax 了，不应该把资金老老实实锁在固定收益里吗？

我把资金路径重新拆了一遍，才发现这其实是在解决一个很现实的 LP 问题。

固定利率订单最怕什么？

不是收益低。

而是**钱挂着，没人借。**

TermMax 的 Composable Base Yield 做的事情，就是让还没被匹配的资金先去底层收益协议产生基础收益，等固定利率订单真正成交，再回到 TermMax 的固定收益逻辑里。官方目前明确把 Aave、Morpho、Venus 作为这类底层收益来源。

> 我觉得这个设计真正解决的不是“收益更高”，而是把“等待成交”这段原本可能浪费掉的时间也拿来利用。

站在 LP 角度就很直观：

钱已经准备好了。

但借款人没出现。

如果只能干等，资本利用率天然被拖低。

TermMax 反过来把这段空档接到浮动收益市场上。

不过代价也很明确。

你追求固定收益，却不得不接受一部分资金在等待期间暴露于底层浮动利率和协议风险。

也就是说，TermMax 并没有消灭浮动利率，只是把它从“借款成本”挪成了“闲置资本的等待收益”。

这点我觉得比“固定利率”四个字本身有意思得多。

真正的问题变成：

**一个固定收益协议，到底该不该为了提高资金利用率，主动拥抱一点浮动收益风险？**

如果你是 LP，你会宁愿让资金躺着等固定订单，还是接受底层浮动收益，换取这段等待时间也不吃空窗期？@TermMax

#termmax

عندما نظرت هذه المرة إلى قواعد تحويل أصول Dusk، لفتني فعلٌ غير ملحوظ إلى حد كبير: لماذا تقوم أولًا بإجراء فحوصات ومحاكاة قبل أن يتم تقديم المعاملة فعليًا؟

في السابق، عندما كنت أتابع التحويلات على السلسلة، كان أسلوبي المعتاد هو التوقيع ثم الإرسال ثم انتظار النتيجة.

لكن الأصول الخاضعة للرقابة ليست بهذه الطريقة.

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

> برأيي، ما تحلّه هذه الخطوة فعليًا ليس عبارة “فشل المعاملة” نفسها، بل منع الأخطاء في التشغيل من أن تصبح حقيقة قائمة على السلسلة.

من منظور جهة الإصدار أو موقع التداول، يكون هذا الفرق كبيرًا جدًا.

المنطق التقليدي على السلسلة يشبه أكثر:

أولًا يتم الإرسال.

ثم تُعالَج المشكلة إن فشل.

أما Dusk فتريد أن تفعل:

أولًا يتم التحقق.

إذا لم تكن مطابقة للقواعد، تُمنع قدر الإمكان قبل التقديم.

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

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

وأعتقد أن هذا هو المكان الذي يجعل Dusk مثيرة للاهتمام فعلًا.

إنها لا تكتفي بنقل “الأوراق المالية” إلى السلسلة فحسب، بل تحاول أن تجعل “من يحق له التحويل، ومن يحق له الاستلام، ومتى يجب الرفض” جزءًا من قواعد تشغيل الأصول نفسها.

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

#dusk $DUSK

لقد شاهدت هذه المرة Atomic Order من TermMax V2، وكان انطباعي الأول في الواقع غير مريح قليلاً: لماذا يمكن لنفس دفعة USDC أن تُعلّق في عدة أسواق في نفس الوقت؟ يبدو الأمر كأنه يقوم بتضخيم السيولة من لا شيء.

وبالاستمرار في فهم الآلية، فإن النقطة المحورية ليست في “ظهورها المتزامن” بحد ذاته، بل في **ما الذي يحدث لها بعد إتمام الصفقة وكيف تختفي**.

تسمح Atomic Order في TermMax بأن تخدم نفس قطعة السيولة عدة أسواق في الوقت نفسه. لنفترض أن هناك Vault فيه مبلغ من المال؛ يمكن أن يظهر في أسواق إقراض مختلفة في آن واحد، لكن هذا المبلغ فعلياً لا يمكن أن يُنفَّذ عليه إلا مرة واحدة فقط. عندما يتناول أحد الأسواق جزءاً منه أولاً، سيتم في نفس المعاملة سحب/إلغاء السقوف (الحدود) المقابلة في بقية الأسواق بشكل متزامن. وقد صمّموا هذه المنطقية كعملية ذرّية (Atomic).

> القيمة الحقيقية ليست أن تبدو قطعة المال “أكبر”، بل أن البروتوكول يجرؤ على السماح لعدة أسواق بمشاركة نفس قطعة المال، مع منعها من أن تُصرف مرتين.

ومن منظور المقترض، فهذا يحل مشكلة الأوامر الكبيرة.

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

لكن الثمن أيضاً مباشر.

السيولة الظاهرة في الحساب للمستخدم لا تعني أن كل سوق يملك نسخة مستقلة من تلك الأموال. العمق الذي تراه هو في جوهره **حصة تنافسية من بركة مشتركة**.

وهذا يتطلب أن يكون التزامن الذري للبروتوكول موثوقاً فعلاً.

وإلا فإن “المشاركة بين عدة أسواق” ليست كفاءة رأسمالية، بل سيولة وهمية.

أعتقد أن هذا تصميم في TermMax V2 يسهل تجاهله: فهو لا يزيد الأموال ببساطة، بل يعيد تعريف لمن ينتمي “عمق السوق”.

إذا كنت مقترضاً بمبالغ كبيرة، هل تفضّل مواجهة دفتر أوامر يبدو أعمق، لكن الأموال مشتركة، أم سوق بعمق أقل، ولكن تكون أموال كل سوق مستقلة تماماً؟@TermMax

#termmax

عندما راجعتُ هذه المرة دورة حياة تداول Dusk، ما أوقفني حقًا هو أنها لا تتعامل مع “التأكيد” و“الاكتمال النهائي” باعتبارهما شيئًا واحدًا.

تشرح الوثائق الرسمية تفصيلًا واضحًا لمراحل أي عملية تداول: أولًا تُزال من mempool، ثم تدخل مرحلة confirmed، وأخيرًا عندما يصل الـ block إلى finality تصبح المعاملة في الحالة النهائية غير القابلة للعكس.

قد يبدو الأمر كأنها طبقة إضافية من الحالات.

لكن من منظور تسوية الأصول المالية، فإن هذا الفرق بالغ الأهمية.

في التحويلات العادية، عندما يرى المرء حالة confirmed، قد ينتقل مباشرة إلى الخطوة التالية.

لكن الأمر مختلف في الأوراق المالية والدفع وتسليم الأصول.

أنت لا تحتاج فعلًا إلى تأكيد مثل:

“على الأغلب أن هذه المعاملة لا توجد بها مشكلة.”

بل تحتاج إلى:

“هل يمكن اعتبار هذه الأصول الآن بالفعل نتيجة نهائية تُسجَّل في الدفاتر؟”

> بالنسبة للأسواق المالية، فإن “عدم العودة عن ذلك على الأرجح” ليس هو الشيء نفسه مثل “أنه أصبح غير قابل للعكس”.

يفصل تصميم Dusk بين المرحلتين، أي يجعل معالجة “رؤية النتيجة” منفصلة عن “تثبيت النتيجة نهائيًا”.

وهذا يترتب عليه تكلفة واقعية.

عند انتظار finality، لا يمكن للتطبيق أن يكتفي بمراقبة حالة التأكيد الأولى ثم يدفع كل الخطوات اللاحقة فورًا.

لكن المقابل هو حدود تسوية أكثر وضوحًا.

قد لا يكون هذا الفرق حادًا جدًا في التحويلات العادية على السلسلة.

أما في المعاملات التي يتم فيها دفع الساق الخاصة بالأوراق المالية المُرقمنة وساق الدفع وساق الأصول في الوقت نفسه، فإن تلاشي حدود التسوية يؤدي إلى فوضى في التسليم والقيود وتقييم الصلاحيات التي تليها.

لذلك أشعر الآن أكثر فأكثر أن Dusk التي تؤكد على deterministic settlement لا تهدف فقط إلى “السرعة”.

بل الأهم أنها تهتم بـ:

**متى يمكن فعليًا تحويل هذه المعاملة من “حدثت” إلى “تم اعتمادها نهائيًا”.**

إذا كنتَ تعمل في الجهة الخلفية لمؤسسة مالية، فهل تفضّل رؤية إتمام الصفقة تقريبًا فورًا، أم تفضّل الانتظار قليلًا أكثر للحصول على finality واضح، ثم تسجيل كامل الأصول رسميًا في الدفاتر؟@Dusk

#dusk $DUSK

بينما كنت أتفقد تصميم Vault في TermMax خلال اليومين الماضيين، شدّني قرار يبدو وكأنه “مناهض للمستخدمين” حقًا: بما أن سوق الفائدة الثابتة محدد بوضوح من حيث العوائد والآجال، فلماذا نُصِرّ على أن يقوم المستخدم بتسليم أمواله إلى Curator؟

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

لكن Vault في TermMax V2 يسلك طريقًا آخر: يقوم المستخدم بإيداع الأصول، ثم يقوم Curator بتوزيع الأموال وفقًا للاستراتيجية على عدة أسواق إقراض ذات آجال ثابتة.

وحتى أن الجهة الرسمية وضعت حاليًا سقفًا لسعة الـ Vault، بحيث لا يستطيع سوق واحد أن يبتلع الأموال بلا حدود.

> هذا في الحقيقة يعني أنه يتم التنازل عن جزء من “حق اتخاذ القرار بنفسي” مقابل خفض تكلفة التشغيل.

ومن منظور المودِع، سأقوم بعمل أقل في عملية التصفية.

لا حاجة للمراقبة يوميًا لمواعيد استحقاقات مختلفة.

لا حاجة لمقارنة عدة أسعار فائدة ثابتة.

ولا حاجة لإعادة ضبط المحفظة كل مرة تتغير ظروف السوق.

لكن التكاليف واضحة أيضًا:

تفوّت قرارك.

إذا أخطأ Curator في اختيار السوق، أو إذا كانت الاستراتيجية نفسها غير مناسبة لظروف بيئة الفائدة الحالية، فالمحصلة النهائية يتحملها المودِع.

لذلك أعتقد أن Vault في TermMax لا يبيع “التيسير” حقًا، بل يبيع**احتراف مهمة اختيار السوق الشاقة**.

وهذا هو الفرق الأبرز مع DeFi التقليدي.

سابقًا:

المال يُسلَّم إلى البروتوكول، والاستراتيجية هي التي تقوم بالعمل.

حاليًا:

المال يُسلَّم إلى الـ Vault، والاستراتيجية يقوم بها Curator.

وما يحاول TermMax إثباته فعلًا هو أمر آخر:

هل يمكن لعوائد Curator أن تغطي على المدى الطويل جزء المخاطر الذي يتحمله المستخدم بعد أن يتخلى عن قراراته المستقلة؟

إذا كنت أنت، هل تفضّل أن تختار بنفسك سوق فائدة ثابتة، أم تفضل أن تمنح Curator حق الاختيار مقابل مدخل عوائد ثابتة أكثر “بساطة”؟@TermMax

#termmax

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

في الوقت الحالي، يحتفظ Dusk في آنٍ واحد بـ DuskVM و DuskEVM: الأولى تعمل مباشرة على Dusk L1، وموجّهة لعقود Rust/WASM؛ أما الثانية فتوفّر Solidity وVyper وسلسلة أدوات EVM التي اعتاد عليها المطوّرون.

إجابة الجهة الرسمية للمطوّرين واضحة جدًا في جوهرها: المساران لا يعالجان المشكلة نفسها.

> يبدو الأمر كأنه تكرار للبناء، لكنه في الواقع هو مبادلة “سهولة التطوير” بـ “القدرة الأصليّة”.

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

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

الوثائق الرسمية تُميّز بوضوح بين هذين المسارين، بدلًا من إجبار جميع التطبيقات على اتباع طريق واحد.

وتكمُن المشكلة هنا.

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

لكن إذا كان الهدف هو مجرد التوافق مع EVM، فقد يقوم Dusk بحصر قدراته الأكثر تميّزًا داخل إطار تنفيذ عام.

وأنا الآن أشعر أكثر فأكثر أن Dusk لا “رهنت” فعلًا على مسألة: هل تريد التوافق مع Ethereum أم لا، بل على:

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

إذا كنت مطوّرًا، هل ستختار نشرًا سريعًا عبر EVM الأكثر ألفة، أم أنك—من أجل الخصوصية والقدرات الأصلية—مستعد لتحمّل تكلفة تعلّم بيئة تنفيذ جديدة؟@Dusk

#dusk $DUSK

عندما شاهدت إيداع Dusk لعقدة ما، لم يكن الذي أوقفني حقًا هو حدّ الإيداع الأدنى، بل سبب تقسيم مفتاح الـ Staking إلى نوعين: مفتاح الـ Consensus مسؤول عن مشاركة العقدة في الإجماع، ومفتاح الـ Owner مسؤول عن إلغاء الإيداع واسترداد الأموال.

للوهلة الأولى يبدو الأمر معقدًا.

ألا تكفي مفاتيح واحدة؟

لكن من منظور مشغّل العقدة، فإن هذا في الحقيقة يعالج مشكلة واقعية جدًا: **ليس من المفترض أن تكون نفس الشيء: “تمكين الآلة من توقيع الكتل” و“تمكين الأموال من أن تُؤخذ”.**

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

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

فكرة تقسيم Dusk واضحة وبسيطة:

مفتاح الـ Consensus يشغّل وحدة التشغيل.

مفتاح الـ Owner يدير الأصول.

الآلة تقوم بالعمل، وحق التحكم بالأموال يُترك لمجموعة صلاحيات أخرى.

وبالطبع، هذه التصميمات ليست “مجانية”.

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

لكنني أعتقد أن هذا بالضبط هو الفرق بين البنية التحتية والمحافظ العادية.

المستخدم العادي يخشى أساسًا ألا يتمكن من تذكر عبارة الاسترداد (seed phrase).

أما مشغلو العقد فيخافون أكثر من:

**آلة متصلة لفترة طويلة، تعمل بلا تروٍ وتحوّل أموالهم هم أيضًا إلى أصول “متصلة/عبر الإنترنت”.**

لذلك أنا الآن أكثر تركيزًا على سؤال واحد:

هل ستقبل ربط “حق توقيع الكتل” و“حق سحب الأموال” معًا من أجل تقليل خطوة تشغيلية واحدة، أم تفضّل إضافة شيء من تعقيد الصيانة، مع فصل الآلة والأموال تمامًا؟ @Dusk

#dusk $DUSK

عقدة Dusk عند الغسق، لا تعتمد على القدرة الحاسوبية بل على الرهن
لنحدث عن Dusk—الناس يتحدثون كثيرًا عن الخصوصية، لكن قليلين ينظرون إلى طريقة تشغيل عقده.

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

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

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

والأمر اللافت أن المستخدم العادي عندما يقوم برهن DUSK، فإن العائد لا يأتي من «المشاركة في الحوكمة»، بل لأن نظام السلسلة يتعامل مع عملتك كوسادة أمان. كلما احتاجت الشبكة إلى تحقق خصوصي أكبر، زادت متطلبات العقدة؛ وكلما زادت المتطلبات، قلّ عدد من يرغبون في تشغيل العقدة. فكيف إذن يأتي العائد؟ في البداية يعتمد على التضخم، وعلى المدى الطويل يجب أن يعتمد على رسوم معاملات الشبكة. إن لم ترتفع الرسوم، ستغادر العقد.

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

لذلك جاءت المسألة: هل أنت مستعد أن تأخذ DUSK وتقوم برهنها لتكسب عائدًا غير واضح الملامح، وفي الوقت نفسه تتحمل تكلفة معاملات الخصوصية في الشبكة كلها؟

أم أنك تفضّل الاحتفاظ بالعملة وعدم القيام بأي شيء—ولا أن تجعل نفسك ذلك الشخص «لا تعرف ما الذي تتحقق منه، ومع ذلك عليك أن تتحمل المسؤولية»؟@Dusk

#dusk $DUSK

خصوصيتك، لا توجد أزرار تشغيل/إيقاف بيدك
الأشخاص الذين يشترون عملات الخصوصية غالبًا يريدون شيئًا واحدًا: «لا أحد يمكنه التحقق مني». لكن في عقد XSC الخاص بـ Dusk، يمكن للجهة المُصدِرة أن تترك للجهة المُدقِّقة مفتاحًا. يبدو الأمر كأنه باب خلفي، لكنه في الواقع مكتوب حرفيًا في تصميمه على أنه «إفصاح امتثالي».

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

فما معنى ذلك؟ خصوصية معاملاتك ليست بيدك أنت، بل بيد الجهة المُصدِرة والجهة المُدقِّقة. أنت فقط تحتفظ بالعملات، لكن زر «من يحق له الاطلاع على دفتر حساباتك» لا تستطيع لمسه.

لماذا صُمم هذا رسميًا على هذا النحو؟ لأن الأصول المالية يجب أن تُسجَّل على السلسلة، والمؤسسات تحتاج إلى اجتياز متطلبات KYC/AML، والجهات التنظيمية تريد رؤية السجلات. السلاسل المجهولة بالكامل لا تجرؤ المؤسسات على دخولها، وقد يتم كذلك إدراج المخاطر وإزالة التراخيص من المنصات. رهان Dusk هو: استخدام جزء من خصوصية المستخدمين مقابل البقاء كأصل متوافق مع المتطلبات.

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

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

لن أختار لك، لكنني سأطرح على نفسي سؤالًا: إذا كان مفتاح تبديل خصوصية محفظتي بيد شخص آخر، فهل ما زلت أستطيع أن أنام بسلام؟
@Dusk

#dusk $DUSK

لقد عدت خلال اليومين الماضيين لمراجعة نموذج تداول Dusk، لكنني علقت عند تصميم بدا غير بديهي: لماذا لا يجعل كل التداولات معاملات “خصوصية”؟

الإجابة واقعية جدًا.

حاليًا يقوم Dusk بتفكيك تداول الأصول الأصلية إلى نموذجين: Moonlight و Phoenix. Moonlight: الحسابات، الرصيد، المرسل والمستقبل كلها تكون علنية. أما Phoenix فيضع الأموال داخل Note مشفر، ويتم التحقق من المعاملة عبر إثباتات معرفة صفرية، مع إخفاء المبلغ وعلاقة المعاملة، ويمكن عند الحاجة إجراء إفصاح انتقائي عبر viewing key.

> هذه ليست مسألة “هل الخصوصية قوية أم لا”، بل في الأسواق المالية، توجد معلومات لا يمكن إخفاؤها إلى الأبد.

التحويلات العادية، وبعض سيناريوهات إدارة الأموال الجزئية، تحتاج إلى قابلية التحقق.

تداولات المؤسسات، التي لا تريد كشف المراكز والأموال مباشرة على السلسلة.

المراجعة والرقابة، ولا يمكنها قبول “لا يمكن رؤية أي شيء”.

لذلك لم يسلك Dusk طريق “مجهول بالكامل للجميع”، بل دمج **التسوية العلنية والتسوية ذات الخصوصية داخل نفس الشبكة الأساسية**.

وأجد أكثر ما يثير الاهتمام هنا هو Trade-off.

كل شيء علني: المراجعة أسهل، لكن المؤسسات لا ترغب في تعليق تداول الأصول الحساسة كلها على السلسلة.

كل شيء خصوصي: المستخدمون يرتاحون، لكن الامتثال وإدارة الأصول سيُشلّان.

حل Dusk في الحقيقة صارم: السماح للمعاملات المختلفة باختيار مقدار المعلومات التي يجب كشفها.

وهذا يفسر أيضًا لماذا ظل يؤكد دائمًا على regulated onchain finance، بدلًا من مجرد بيع قصة “سلسلة خصوصية” واحدة. فمعمارية Dusk نفسها حاليًا تعمل حول تفكيك الوحدات المتعلقة بالتسوية والخصوصية والهوية والإفصاح الانتقائي.

والذي أود رؤيته هو سؤال آخر:

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

#dusk $DUSK

بالأمس، عندما أعدت النظر في آلية مشاركة التحقق في Babylon، كنت أتابع دورًا سهلًا أن يُغفل عنه: أولئك الذين يشغّلون العقد فعلًا ويدعمون أمن الشبكة.

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

فهم لا يواجهون سؤالًا مثل: "هل يجب أن أقفل جزءًا من BTC؟" بل السؤال هو:

عند الانضمام إلى منظومة أمان جديدة، هل سيؤدي ذلك إلى زيادة تكاليف التشغيل الخاصة بهم؟

أكثر ما يهتم به مشغّل عقدة أمر واقعي للغاية.

تكاليف الخوادم.

وقت الصيانة.

ضبط المخاطر.

وهل تغطي العوائد ما تم استثماره.

يهدف Babylon إلى ربط الأمان الاقتصادي لـ Bitcoin، لكن هذه التصميمات في النهاية تحتاج أيضًا إلى من يشارك في صيانة تشغيل الشبكة.

> في النهاية، تتفادى أي نماذج أمنية سؤالًا واحدًا: هل يوجد عدد كافٍ من الأشخاص على استعداد لتحمّل التكاليف على المدى الطويل؟

إذا كانت العوائد جذابة بدرجة كافية، سيدخل المزيد من المشاركين، ما يعزز أمن الشبكة.

لكن إذا ارتفعت العتبة التشغيلية، أو إذا لم تكن العوائد قادرة على تعويض التكاليف الفعلية، فقد ينخفض عدد المشاركين.

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

كلما كان الأمن أقوى، عادةً ما يعني ذلك المزيد من القواعد والمتطلبات.

وكلما زادت القواعد، قد ترتفع أيضًا تكلفة المشاركة.

أرى أن الجانب المثير للاهتمام في Babylon ليس فقط أنه يولّد سيناريوهات استخدام جديدة لـ BTC، بل إنه يحاول إعادة توزيع أدوار سوق الأمان داخل السلسلة.

في الماضي:

كانت أي سلسلة تحتاج إلى تنمية مُحقِّقيها بنفسها.

الآن:

يمكن للمحقِّقين المشاركة في منظومة أمان أوسع عبر طرق جديدة.

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

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

إذا توسّع نظام Babylon البيئي في المستقبل، برأيك ستكون المنافسة الأهم في جذب المزيد من BTC، أم جذب المزيد من الأشخاص المستعدين لتشغيل العقد على المدى الطويل؟

#baby $BABY

عندما كنت أتابع أمس حالة تكامل مشروع نظام Babylon البيئي، راودتني فكرة: بالنسبة لسلسلة جديدة يتم إطلاقها للتو، هل إن امتلاك Bitcoin Security يُعدّ مُسرِّعًا أم نوعًا جديدًا من الاعتماد؟

يواجه الكثير من المشاريع واقعًا مشتركًا قبل النشر.

يمكن تطوير الوظائف بسرعة.

ويمكن إصدار الرموز بسرعة.

لكن منظومة الأمان لا يمكن بناؤها عبر الدعاية.

عدد المُتحققين والحوافز الاقتصادية والصيانة طويلة الأمد… كلها تحتاج إلى تراكم عبر الزمن.

لذلك، بالنسبة لكثير من السلاسل الجديدة، فإن حلول أمان BTC التي تقدمها Babylon تبدو كاختصار.

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

ومن منظور فريق سلسلة جديدة، فإن الاستفادة من مصدر أمان ناضج يمكن أن يخفف ضغط التشغيل البارد في المراحل المبكرة.

لا يلزم تحمل ميزانية أمان ضخمة من البداية، ولا انتظار سنوات لبناء منظومة متحققين قوية بما يكفي.

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

إذا كانت سلسلة ما تعتمد بشكل متزايد على أمان خارجي، فهل سيستمر جهازها الخاص بالأمان في النمو؟

لا توجد إجابة بسيطة.

إذ إن بناء الأمان بشكل مستقل بالكامل ليس أمرًا مجانيًا.

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

تصميم Babylon، في الحقيقة، يعالج تناقضًا قائمًا منذ مدة طويلة:

السلاسل الصغيرة تحتاج إلى أمان، لكن الأمان بحد ذاته يحتاج إلى حجم.

لدى Bitcoin حجم.

تحتاج السلاسل الجديدة إلى حجم.

ومن ثم تنشأ علاقة اتصال بين الطرفين.

أعتقد أن الجزء الأكثر إثارة للاهتمام في Babylon ليس فقط إشراك BTC في الأمان، بل تغيير مسار بناء الثقة لدى السلاسل الجديدة.

سابقًا:

كان يتعين على سلسلة ما أن تُثبت أمانها ببطء من تلقاء نفسها.

في المستقبل:

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

لكن السؤال متروك أيضًا للسوق:

إذا بدأت سلسلة جديدة بالاعتماد على Bitcoin Security، فعندما تنمو، برأيك هل ينبغي أن تظل تعتمد على الأمان الخارجي، أم أن عليها في النهاية أن تُنشئ نظام أمان خاصًا بها بالكامل؟

#baby $BABY

في الآونة الأخيرة، تحدثت مع بعض أصدقائي الذين يشغّلون عقدًا، ولاحظت تغيرًا مثيرًا للاهتمام.

في السابق، عندما كان الجميع يناقشون سلسلة PoS، كان أكثر ما يهم هو: هل يمكن للعقد أن تكسب مكافآت؟

الآن، عندما يُذكر Babylon، يبدأ كثير من الناس في طرح سؤال آخر:

إذا شاركت الشبكات مستقبلًا بشكل متزايد في أمان Bitcoin، فعلى ماذا يمكن للعقد أن تبني قدرتها التنافسية؟

في السابق، كانت المنافسة بين العقد تعتمد على العتاد، والاستقرار، وقدرات التشغيل.

قد توجد هذه الفروقات، لكنها كانت — نسبيًا — واضحة القواعد.

لكن بمجرد أن تبدأ مصادر الأمان بالتغير، سيتغير دور العقد تدريجيًا.

لم يعد الأمان يعني فقط أن توفره أنت بنفسك.

غالبًا ما يحتاج العاملون على العقد إلى التفكير في:

كيف يتعاونون مع نظام أمان جديد بدلًا من تكرار الاستثمار.

أعتقد أن هذه نقطة قد يتجاهلها كثيرون بسهولة.

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

قد لا تختفي العقد تمامًا مع نضوج البنية التحتية.

الأرجح أن العقد ستُولي المزيد من اهتمامها لخدمات الشبكة، ومزامنة البيانات، وكفاءة التشغيل — تلك الأماكن التي تعكس القيمة فعلًا.

وهذا يختلف تمامًا عن الماضي عندما كان الجميع يكدّسون أحجام الرهن.

لذلك، وأنا الآن عندما أنظر إلى Babylon، لم أعد أركز فقط على TVL أو بيانات الرهن.

ما أود مراقبته أكثر هو:

هل سيقوم مشغّلو العقد بتعديل أدوارهم بشكل استباقي في المستقبل؟

إذا كانت الإجابة نعم، فلن يكون تأثير Babylon مقتصرًا على كفاءة استخدام أصول BTC.

قد يغيّر أيضًا طريقة تشغيل بعض شبكات PoS.

وما يستحق الاهتمام طويل الأمد ربما ليس فقط مقدار BTC الذي يدخل البروتوكول.

بل حقيقة أن عددًا متزايدًا من المشاركين في النظام البيئي بدأوا يعيدون تعريف مكانهم داخل الشبكة.

#baby $BABY

بالأمس، عندما كنت أبحث في آلية BTC Staking الخاصة بـ Babylon، لم أستمر في التعمق في التفاصيل التقنية، بل ركّزت على سؤال أكثر واقعية: لماذا قد يختار شخص يحمل BTC على المدى الطويل تغيير عادة الاحتفاظ لديه بشكلٍ فعّال؟

في الماضي، كانت أهم نقطة لدى كثير من حاملي BTC هي البساطة.

شراء.

نقل إلى محفظة باردة.

الانتظار.

هم يثقون في Bitcoin إلى حدّ كبير لأنه لا توجد فيه منافذ عائد معقّدة، ولا توجد الكثير من العمليات الإضافية.

لكن Babylon تريد القيام بشيء يغيّر هذه العادة بالذات.

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

> بمجرد أن يبدأ BTC في تحقيق عائد، لم يعد مجرد أصلٍ “مكتمل وضعه” فحسب، بل يصبح داخل سوقٍ يتطلب اتخاذ قرار معقّدًا بشأن المخاطر وتكلفة الفرصة.

بالنسبة للبروتوكول، يعني مشاركة المزيد من BTC أمانًا اقتصاديًا أقوى.

لكن بالنسبة للمستخدم، فهذا يخلق مشكلة جديدة:

ماذا لو ظهرت فرصة في السوق خلال فترة القفل؟

ماذا لو حدثت مشكلة في شبكات أخرى؟

ماذا لو لم تتمكن العوائد من تغطية المخاطر التي يتحملها المرء؟

هذه هي التحديات الحقيقية التي يجب أن يواجهها Babylon.

تقنيًا، جعل BTC يشارك في منظومة الأمان أمر واحد.

أما جعل أولئك الذين يثقون أكثر في القيمة البسيطة لـ BTC يغيّرون سلوكهم، فهذا أمرٌ آخر.

أعتقد أن المنافس الحقيقي لـ Babylon ليس مشاريع BTC أخرى، بل جدار الحماية النفسي لدى حاملي BTC أنفسهم.

لأن كثيرًا من الناس يشترون BTC ليس بحثًا عن المزيد من العمليات، بل لتقليل العمليات.

تقدم Babylon احتمالًا جديدًا:

تحويل BTC من أصل مخزَّن ثابت إلى رأس مال أمني على السلسلة.

لكن الثمن أيضًا واضح:

مع زيادة العوائد، تزيد تكلفة اتخاذ القرار.

في السابق كانت المشكلة تتلخص في:

“هل أشتري BTC أم لا؟”

وبعد ذلك قد تصبح:

“هل ينبغي أن يشارك BTC الخاص بي في أمن شبكات أخرى؟”

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

#baby $BABY

في الليلة الماضية، وأثناء إعادة قراءة ورقة Babylon البيضاء، علقت عند جملة واحدة: Bitcoin Security بدلًا من Bitcoin Consensus. الكلمتان تبدوان متقاربتين، لكن التصميم الكامن وراءهما ليس شيئًا واحدًا.

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

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

> ثم فهمت فجأة أن الأمر يشبه إلى حد ما إضافة تأمين إلى مبنى بدل تفكيك كامل للبنية الحاملة وإعادة بنائها.

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

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

كنت أعتقد دائمًا أن ابتكار Babylon مجرد “BTC يمكن رهنه”. أما الآن، عند النظر مرة أخرى، فالأهم أنها حوّلت البيتكوين من أصلٍ قابل للتداول إلى مورد أمان يمكن إعادة استخدامه.

إذا في المستقبل بدأت المزيد من سلاسل الكتل العامة في الاستفادة من Bitcoin Security، برأيك هل سيتحوّل BTC تدريجيًا من “مخزن قيمة” إلى طبقة الأمان الأساسية للعالم الكامل لـ PoS؟

#baby $BABY

عندما أعدت تصميم Babylon Genesis اليوم، كنت أحدّق في سؤال واحد: بما أن البروتوكول بأكمله يتمحور حول أمان BTC، فلماذا تصدر الجهة الرسمية BABY بشكل منفصل بدلًا من أن تتحمل BTC كل الوظائف مباشرة؟

تابعت القراءة، واكتشفت أن الجهة الرسمية منذ البداية لم تكن تنوي جعل BTC تتحول إلى “الأصل الشامل” داخل الشبكة.

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

دفع الـGas، التصويت على الحوكمة، والحوافز البيئية—هذه الإجراءات عالية التكرار يتولاها BABY.

لاحقًا فهمت أن هذا ليس مجرد اختيار تقني، بل هو تجنب متعمد لِتَنافٍ محتمل: جعل أصلٌ له طبيعة أقرب إلى “الحفظ بالقيمة” يتحمل أيضًا مهام تشغيل عالية التكرار.

إذا اعتمدت كل العمليات على BTC، فكل تفاعل داخل الشبكة سيرتبط مباشرة بأصل البيتكوين نفسه؛ وسينعكس ذلك على تجربة المستخدم وعلى تصميم الحوافز. اختارت Babylon إسناد طبقة التنفيذ إلى BABY، وترك طبقة الأمان لـ BTC. جوهر الفكرة هو أن يؤدي كل أصل أفضل ما يجيده بدل أن يحاول أحدهما أن يحل محل الآخر.

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

في السابق، كنت أعتقد أن ابتكار Babylon يتمثل فقط في “القدرة على الرهن الأصلي لـ BTC”. لكن الآن، اتضح أن ما تريده حقًا هو بناء بنية تفصل بين طبقة الأمان وطبقة التنفيذ، ووجود BABY هو حلقة مهمة تجعل هذا التقسيم قابلًا للدوران على المدى الطويل.

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

#baby $BABY

لقد تصفحت وثائق Babylon خلال اليومين الماضيين، وكنت أبحث باستمرار في دور Finality Provider. كثيرون أول ما يرونه يعتبرونه Validator، لكن الجهة الرسمية فصلت بين هذين الدورين، وأشعر أن هناك خطاً رئيسياً كامناً في قلب هذا البروتوكول.

في البداية ظننت أيضاً أن إضافة دور إضافي قد تجعل الأمور أكثر تعقيداً. لكن بعد متابعة قراءة تصميم البروتوكول أدركت أن Babylon يريد من BTC توفير “الأمان الاقتصادي”، وليس جعل عقد Bitcoin تشارك مباشرة في شبكة PoS لإصدار الكتل.

> Finality Provider يشبه أكثر جسراً يربط بين نموذجين للأمان. فهو يدمج الأمان الناتج عن رهن BTC داخل الشبكة للتأكيد النهائي، وليس بديلاً عن Validator لتنفيذ الإجماع.

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

يقوم Babylon بفصل Finality Provider عن Validator على نحو مستقل، وبهذا المعنى يفصل بين “تشغيل الشبكة” و“توفير الأمان النهائي” كأمرين مختلفين. يستمر Validator في مسؤولية تشغيل الشبكة، بينما يقوم Finality Provider بتوفير الحتمية النهائية بالاعتماد على رهن BTC. يتعاونان معاً لكنهما مستقلان عن بعضهما.

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

أشعر أكثر فأكثر أن Babylon لا يريد إخراج طريقة جديدة للرهن بقدر ما يريد إخراج قدرة أمان من Bitcoin يمكن مشاركتها عبر عدة شبكات PoS. برأيك، هل ستقبل المزيد من السلاسل العامة مستقبلاً هذا النوع من فصل “طبقة الأمان” عن “طبقة التنفيذ”، أم الاستمرار في حصر كل المسؤوليات داخل Validator؟

#baby $BABY

عقد تسوية حالة GRVT الخاص بـ L1 تم سحبه للتو إلى كتلة داخلية “ForcedWithdrawal: Locked”. وفي لحظة لامست فيها قيمة الـ Gwei في الشبكة الرئيسية عتبة 175 خلال ضربة بيع في منتصف الليل، فإن معلمة ProofSubmissionDelay التي يعمل ضمنها على ZK Stack Prividium قامت مباشرةً بتمديد دورة حزم جذر حالة L1 لمدة 3 ساعات كاملة. كنت وقتها متكئًا على لوح السرير في غرفتي أراقب سبعة أرقام تداول تحكّمية عبر واجهة API، وكانت سجلات الخلفية تومض بكثافة بكود استثناء 0x55d1—وهذا هو الفخّ النمطي الذي تسببه معمارية الطبقة السفلية للـ Validium. ولتجنّب دفع رسوم مرتفعة جدًا لتقديم إثباتات ZK على السلسلة عند ازدحام الشبكة الرئيسية، اتبعت المنصة استراتيجية تمديد نافذة نشر الحالة. يريد صغار المستثمرين استدعاء سحب إجباري طارئ من الواجهة الأمامية، لكن بسبب فجوة في أحدث بيانات حالة L1، تفشل عملية التحقق من الإثبات مباشرةً في الطبقة السفلية، ولا يستطيع المستخدمون إلا “الاستسلام” أحادي الاتجاه وتكبّد الحبس.

يتحول هذا العيب في تصميم آلية غير متناظرة، تحت تقلبات شديدة، إلى هجوم تصفية موجّه ضد صانعي الربح عبر عدة حسابات و”مُحصّلي الكوينات” (打金). يمكن لصنّاع السوق المدرجين ضمن القائمة البيضاء الاستفادة من RPC خاص وخطوط ائتمان بأولوية، لتختتم عمليات التحوط ضد المخاطر بشكل delta-neutral على DEX خارجي قبل تحديث جذر الحالة. أما عامة “متعددّي الحسابات” فلا يبقى لهم هامش أمان زمن الصفقات بسبب التأخير حتى يتم تفريغه بالكامل، فيتحملون أحادي الاتجاه فقط: انخفاضًا حادًا في كفاءة دوران الأصول و”تصفية” ظاهرية ناتجة عن تأخر حالة الحبس. نتيجة هذا المقايضة المعمارية هي أن صغار المستثمرين في نهاية الذيل يتحملون بشكل صارم حواف التآكل التقني على مستوى النظام، بينما تدفع كيانات صانعي السوق الكبار فرق تسوية غير متناظر مرتفعًا. الآن قوموا مباشرةً إلى وحدة التحكم وأدخلوا getForcedActionStatus لإجراء مطابقة عكسية، وانظروا في ForcedRedemptionLoss في الطبقة السفلية: كم عدد الـ Gwei التي سرقتموها كـ “مرور مجاني” من العقد المدرجة ضمن القائمة البيضاء الليلة الماضية. لا تشرحوا لي في قسم التعليقات عن “مستقبل ناعم” لتجميع التداول الموثوق ذاتيًا والمزج… اعرضوا فقط الأرقام الحقيقية التي تُعلّق/تحتجزها واجهات برمجتكم. @grvt_io

#grvt