撸毛研究院

#termmax @TermMax في اليوم الذي كنت فيه أرتّب مراكز الاستثمار الأسبوع الماضي، قمتُ بشكل عفوي بتفعيل سوق TermMax على سلسلتي BNB Chain وArbitrum في الوقت نفسه. وبالنسبة لنفس أصل USDC، ونفس مدة الثلاثين يومًا، ونفس قواعد البروتوكول، كانت الفارق في معدل العائد السنوي بين الجهتين أكبر من نقطة كاملة. كانت أول فكرة خطرت ببالي: “هل أنا أُخطئ في النظر؟” ثم قمت بتحديث لوحة الصفقات ثلاث مرات، وأخرجت سجل الصفقات الـ127 للأيام القريبة من الثلاثين يومًا، وأعدت فحص كل قيمة انزلاق على حدة، متأكدًا أنها ليست مشكلة ذاكرة مؤقتة—بل أن الفائدة نفسها كانت مختلفة فعلًا.

كانت الفكرة التي راودتني حينها: هذا غير ممكن… نفس البروتوكول ونفس المنتج، لماذا يختلف سعر الفائدة بمجرد تبديل السلسلة؟ بعدها بدأت أشك إن كنت قد فاتني شيء ما. ذهبتُ لأراجع الوثائق الرسمية، فوجدت أن TermMax حاليًا يعمل على 8 سلاسل: Ethereum وArbitrum وBNB Chain وBase وBerachain وغيرها. ولكل سلسلة تجمع سيولة يعمل بشكل مستقل، ووحدة التسعير لا تقوم بمزامنة البيانات عبر السلاسل. وبما أن صناع السوق والمقترضين على كل سلسلة يشكّلون علاقة مستقلة بين العرض والطلب، فمن الطبيعي أن ينتهي الأمر بمنحنيات فائدة مختلفة تمامًا. عندها فقط تنفست الصعداء: لم أكن أنا من أخطأت في الحساب، بل إن هذه البنية نفسها مصممة هكذا.

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

في نفس اليوم، نقلتُ 3000 دولار U كتجربة دون اللجوء إلى الجسر عبر السلاسل والذهاب والإياب. استخدمتُ مُجمِّع LI.FI لنقل الأموال مباشرة من BNB Chain إلى Arbitrum. بعد وصولها، ألقَيتُ نظرة: تم خصم رسوم الغاز بحوالي بضعة U، ثم أودعتُ الباقي بالكامل في السوق الأعلى عائدًا. لم أستخدم الرافعة، ولم ألمس العقود، فقط منطق “الادخار على السلسلة الأقل سعرًا، والاقتراض على السلسلة الأعلى سعرًا”. بعد إنهاء دورة كاملة، حسبتها فحصلت على عائد سنوي إضافي قريبًا من نقطة مئوية واحدة—ليس كثيرًا، لكنه ثابت، وبدون تحمل مخاطر عقود ذكية إضافية. كان الأمر ببساطة جني “عائد” من سوء تطابق العرض والطلب على السيولة بين سلسلتين.
معظم الناس لم ينتبهوا إلى أن سوء التسعير الناتج عن تجمعات سيولة مستقلة يمكن أن يظهر بهذه الطريقة. فهذه ليست ثغرة، بل هي انعكاس مباشر للعلاقات الحقيقية بين العرض والطلب على السيولة في كل سلسلة.

#dusk $DUSK @Dusk 大半夜睡不着翻白皮书看，翻到验证者KYC那一页，我人傻了。不是被内容震撼，是我突然想到一个问题——我敢不敢把钱放在一条完全匿名的链上？想了十秒钟，答案是不敢。然后我就意识到，那些管着几百亿的机构，他们大概率也跟我一样不敢。

我脑子里闪过一个画面，要是我真往一条匿名链上存了笔钱，第二天池子被掏空了，我对着那个钱包地址喊“把钱还我”，对方哪怕能回一句“我是匿名的”，我都算他有点礼貌了。然后呢？没有然后了。传统银行钱少了你能打电话、能去柜台拍桌子、能起诉。链上你只能盯着区块链浏览器看那个地址发呆。Dusk要求验证者实名，看起来是去中心化的倒退，但站在机构的鞋子里面想一下，他们要的根本不是匿名自由，是出了事能找着活人。

后来我想通了，Dusk要的不是纯匿名也不是完全公开，它要的是一个中间态——你能证明自己是谁，但不用把身份证贴在脸上。Citadel身份系统配合零知识证明就这么干，有点像进高级会所，门口保安知道你是谁，但里面的客人不用互相掏家底。配合MiCA和MiFID II那套监管框架，这套方案比我刚开始想的复杂不少，也务实不少。

2026年1月7号主网正式上线，六年开发周期总算落地了。DuskEVM同步跑起来，Solidity开发者可以直接往上搭东西，DEX和跨链桥这些核心组件也升级完了。网络要求超过三分之一的质押者守规矩，乱来的或者长期掉线的直接罚质押。区块时间10秒，对代币化资产来说这个速度够用了。

我以前看白皮书，验证者机制这种章节闭眼划过去，觉得跟自己没关系。Dusk这一页我翻来覆去看了好几遍，不是因为它写得多好，是它让我想明白一件事——判断一个项目好不好，不是看它口号喊得多响，是看它敢不敢替用户把“不敢”那件事提前解决掉。

#termmax @TermMax 白皮书第6节有个细节：对比固定利率撮合和浮动利率AMM，想证明“更稳”。但细读会发现，单期限池兑付安全性与清算效率死死绑在一起。

我们可以看到，LTV达阈值由Chainlink自动触发，设2小时开放窗口，任何清算人参与可得5%奖励。部分清算后剩余抵押品会退还给借款人；只有2小时窗口内未被完全清算时，才触发实物交割——FT持有者按比例获得抵押品。问题就出在2小时——极端行情下价格可能再砸穿一层，清算人若观望，坏账最终由全池用户买单。白皮书提“物理交割”兜底，但这本质是用 lenders 的收益换抵押物，并非无损。

就像生鲜店临期品打折窗口2小时，平稳时没问题，暴跌时要么不够要么浪费。TermMax踩的正是这个两难：窗口太短清算不充分，太长坏账累积，没有完美解。

白皮书说权限限于利率曲线、费用率等参数，清算由预言机和执行者决定。但参数即利益——清算罚金10%，5%给清算人、5%进协议储备金库。金库用途由TMX治理决定，这才是该盯的地方。好在协议设了制衡：关键参数更改须经时锁等待期（最短1天、最长30天），期间守护者可审查并撤销。但筹码集中时，治理方向仍可能向大户倾斜——制衡机制只能延缓，不能逆转。

如果你问我的看法，我的想法就是别被“固定利率”的数学公式唬住，每个参数设置都是利益分配。筹码分散，机制可接近无风险；筹码集中，就是镀金的隐性资金池。
DYOR，关注参数谁设、怎么调。清算窗口是给用户更稳保障，还是给大户留操作空间？评论区见。

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

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

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

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

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

#dusk $DUSK @Dusk 这几年看链上协议出问题，我养成了一个习惯：不太关心黑客有没有暴力破解，反而先看掌握网络共识安全的核心组件，到底靠什么机制把验证者死死按住了。见过太多节点作恶，根子不是算法被攻破，是共识设计从一开始就默认“验证者会老实听话”，这个默认只要失效一次，罚没机制就会沦为空谈。

最近拆解 Dusk 的 SA 共识与 Slashing 设计时，让我停下来的正是这一层。@Dusk

Dusk 的 Succinct Attestation（SA）共识采用委员会型 PoS 模型，通过确定性抽签算法选出出块者和投票委员会。它把恶意行为和过失行为分开处理，对应 Hard Slashing 和 Soft Slashing 两套机制。Soft Slashing 针对节点未出块这类非恶意过失——第一次警告，之后每次连续违规扣除 N×10% 的质押权益并从共识中移除 N 个 epoch，但罚没的 DUSK 不销毁，只是从活跃质押中移除，节点仍可提取。Hard Slashing 则针对明确恶意行为：生成无效区块扣 10% 质押并销毁，双重投票或双倍出块扣 20% 并销毁。这套设计让 Dusk 具备可追责性，但验证者一旦作恶代价极重。

我也不会把它捧上天。架构再精妙，如果验证者为了降低运维成本而集中托管节点，或者长期在线率低于 95% 触发 Soft Slashing 累积扣减，协议精心构建的安全边界就会面临真正考验。未来若为了省事把验证节点集中在少数几个实体手里，所谓的“去中心化”就只剩心理安慰。

在我看来 $DUSK 的价值最终看有多少验证者愿意为了安全牺牲便利。以后合规资产上链会越来越多，我更在意的不是收益率有多高，是谁能证明在巨大的利益诱惑面前，这套让作恶者付出真金白银代价的机制依然能被严格执行。

#termmax @TermMax 翻TermMax主网V2的链上交互日志时，最先让我停下来的不是TVL破亿的增长数据，是它把「资金归集」和「到期计息」拆成了两个完全独立的权限域。
入金进来的资产先落在公共Deposit Pool里，这是个仅支持充值、提现的中转账户，不能直接生成计息头寸。想参与固定收益策略得手动把指定金额划转进对应到期日的Term Segment分片，这步操作会自动触发链上时间锁校验，没有任何后门可以跳过。资金全程待在隔离的静态池，计息权限单独开了一道独立的执行门。
这套权限逻辑我在券商固收托管系统里见得很多，之前帮朋友做资管系统外包的时候，光资金隔离这块就改了三版需求，机构做大额资金管理，资金调拨和产品计息清算从来不会共用同一套密钥。但链上绝大多数借贷协议默认钱包地址等于全量操作权限，上个月群里还有个兄弟私钥漏了半仓USDC直接被转空，连申诉的地方都找不到。TermMax文档里标注的TBAC时间基访问控制，走的就是这个隔离思路，和Aave的全局统一权限体系完全不同，连治理多签都没有修改Term Segment到期参数的权限，让每一步操作只对应它该有的最小权限。
顺着这条线看它的固定到期原语架构，逻辑完全自洽。上层产品组合层开放接口，对接各类结构化收益工具做玩法延伸；底层清算层完全锚定Term Auction荷兰拍卖模块做最终链上执行。专业资金不用为了稳定收益牺牲资产隔离性，所有到期状态又能全节点可验证。
我觉得TermMax真正在解决的，对大额资金来说，缺的从来不是年化收益，是一套能完全信任的时间边界规则。
当然假如，极端行情下大量头寸同步到期时，系统能不能扛住集中清算的压力，还要再观察。但这个设计思路让我觉得，链上固收要承接更大体量的资金，从来不是单纯拼收益率这么简单。

#termmax @TermMax 翻完TermMax V2的技术文档，最戳我的其实是昨晚蹲在沙发上啃文档，半杯冰可乐洒在键盘上，擦屏幕的时候才扫到的那句很容易被划走的说明：TermMax本身不是一个借贷产品，只是个固定到期资产原语，真正的收益产品、结构化工具是外面接的那些。

我当时擦着可乐印盯着屏幕愣了半分钟，顺着往下读才明白，一笔固定期限的借贷合约一创建，到期时间、清算阈值、结算币种三样就直接锁死在链上，不是先存进去再动态调参数。等于说这个合约从生下来就知道自己哪天到期、怎么清算、用什么结算，跟以前Aave、Compound这类永续借贷“先存进去再说，利率随时变、清算线随时调”的路数完全不一样，去年我在Aave上存ETH半夜被插针清算走半仓的阴影瞬间就上来了，用户根本不用担心中途突然被插针清算或者利率暴跌。
行业数据说现在DeFi里90%以上的借贷都是浮动利率的永续模式，固定收益类占比不到10%，看完这套设计我大概能懂为什么之前固定收益一直做不起来——不是用户不需要，是底层原语就没做对。
拿它最近上线的阶梯收益结构化产品顺一遍就更好懂：USDC存进TermMax这边的90天固定期合约，状态在外部结构化协议那头变成分层收益凭证，优先级拿固定利息，劣后吃超额收益。到期自动本息结算，不用用户手动赎回；要是底层抵押品跌破清算线，合约会自动触发荷兰拍卖清算，全程不用治理投票，也不用人工干预。这套清算能做到这么顺滑，底子是它原生的时间锁+链上拍卖模块，把清算逻辑直接写进合约底层，比传统借贷靠第三方清算人抢跑的模式稳太多，Gas成本低60%以上，跟活期借贷那套实时喂价、实时清算的逻辑完全是两条路，别搞混了。
产品交给别人接”这个设计思路，才是它能不停长出新玩法、不用每次都重新造轮子的根本原因。

#dusk $DUSK @Dusk أول مرة رأيت Dusk يذكر Selective Disclosure (الإفصاح الانتقائي)، لم أكن أولي الأمر اهتمامًا كبيرًا. في ذلك الوقت كانت فهمي بسيطة: أليس بروتوكول الخصوصية هو إخفاء معلومات المعاملات؟ حماية المبالغ والعناوين وعلاقات المعاملات بحيث لا يستطيع الآخرون رؤيتها—أليس هذا وحده يحقق حماية الخصوصية؟

إلى أن قمت قبل أيام قليلة ب整理 ملاحظات ورقة Dusk البيضاء، حيث جمعت نموذج معاملات Phoenix مع سيناريوهات الأصول المتوافقة. عندما وصلت إلى جزء Selective Disclosure، توقفت. لأنني اكتشفت مشكلة كنت قد تجاهلتها سابقًا: إذا كان Phoenix قد أخفى حالة المعاملة بالفعل، فكيف يمكن للجهات المؤسسية وجهات التدقيق والجهات التنظيمية أن تتأكد من أن هذه الصفقة تلتزم بالقواعد؟

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

يعالج Phoenix خصوصية المعاملات نفسها. من خلال الملاحظات المشفَّرة (shielded notes) والأدلة صفرية المعرفة (zero-knowledge proofs)، يمكن للشبكة التحقق من صحة المعاملة دون الحاجة إلى نشر الرصيد الكامل والعلاقات بين المعاملات وحالة الأصول. لكن بالنسبة للأصول الخاضعة للتنظيم مثل الأوراق المالية وصناديق الاستثمار، فإن إخفاء المعلومات وحده لا يكفي؛ فالسوق المالي يحتاج إلى التدقيق والتأكد من تنفيذ القواعد، كما يحتاج إلى تقديم إثباتات في حالات محددة.

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

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

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

#termmax @TermMax قبل أسبوع كنت أتابع قائمة أرباح الإقراض على السلسلة، وبالصدفة صادفت TermMax. حينها كان TVL الخاص بها للتو يلامس 71 مليون. كنت أُمعن النظر في منحنى فائدة الإقراض لديها لمدة عشر دقائق تقريبًا، فشعرت أن منطق المنتج مترابط جدًا. لكن باعتبارها مشروعًا جديدًا، بدا لي دائمًا: "راقب أسبوعين إضافيين، إلى أن تستقر البيانات، ثم أدخل". فحفظت عنوان العقد يدويًا في محفظة المراقبة الخاصة بي، ثم التفت فورًا لأموري الأخرى.

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

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

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

الآن ما زلت أحدق في عنوان فبمحفظة المراقبة الفارغ، في حيرة: هل من الممكن أن يقول أحد اللاعبون القدامى حقيقة واضحة؟ هل ما زال الوقت مناسبًا للصعود على $TMX الآن؟ @TermMax

#dusk $DUSK في هذه السنوات الماضية، مع تعثر سلاسل الخصوصية واحدًا تلو الآخر، تكوّنت لدي عادة تدريجية: لا أولي اهتمامًا كبيرًا لما إذا كانت خوارزميات التشفير قد تم اختراقها؛ بل أركز أولاً على ما إذا كان الشخص الذي يحتفظ بنقاط وصول خلفية لأغراض الامتثال قد تم ضبطه بالفعل. رأيت الكثير من المشاريع الخاصة بالخصوصية تتعرض للانفجار؛ والجذر ليس اختراق برهان الصفر-المعرفي، بل تصميم الصلاحيات الذي افترض منذ البداية أن «الجهة المطوّرة لن تلمس بيانات المستخدمين بشكل عشوائي». ما دامت هذه الافتراضات لم تنطبق ولو مرة واحدة، فستصبح أصول المستخدمين وبيانات معاملاتهم مكشوفة عاجلاً أم آجلاً.
الشيء الذي أوقفني هو تفكيك@dusk_foundation لخط تنفيذ ZkKYC لإصدار RC على الشبكة الرئيسية. الأمر ليس مجرد إضافة كتلة امتثال لسلسلة الخصوصية؛ بل تحويل «من يحق له رؤية بياناتي» إلى قواعد صارمة يمكن التحقق منها مباشرة عبر دائرة تحقق من برهان الصفر-المعرفي. قبل منح المستخدم إذن تدقيق، تمر القواعد أولاً عبر الدائرة الخاصة بوحدة Citadel الأصلية؛ الشهادات الهوياتية تُحفظ محليًا، وحالة المعاملة تُشفّر بالتزام Pedersen؛ ومنطق التحقق معروض بالكامل على السلسلة. حتى الجهة المطوّرة لا يمكنها الالتفاف على الدائرة لاستخراج بيانات المستخدم مباشرة. يضمن برهان الصفر-المعرفي أن عملية التحقق من الصلاحيات نفسها لا يتم التلاعب بها؛ وإذا لم تكن طلبات التدقيق ضمن نطاق التفويض الذي حدده المستخدم، فلن يمكن طلب أي بيانات نصية على الإطلاق.
#dusk هذه الفكرة تشبه طلب إثبات أصول من البنك: لا يستطيع الموظف أن يطلع مباشرة على كشف حسابك الكامل، بل يقتصر على إصدار إثبات بالقدر الذي تطلبه وللغاية التي تذكرها، ولا يحصل على معلومات إضافية. لطالما افتقدت السلسلة إلى بوابة «التحقق من الخصوصية وتفويضها»؛ وما يهدف Dusk إلى إضافته ليس قوة الإخفاء بحد ذاتها، بل وضع حدود الخصوصية تحت سيطرة المستخدم.
لن أرفعها إلى مرتبة الكمال أيضًا. إذا فقد المستخدم أوراق/شهادة KYC المحلية فلن يتمكن من فتح إثبات تدقيق امتثال. وإذا كانت دائرة الصفر-المعرفي تحتوي على خلل منطقي، فستظهر ثغرات في التحقق من الصلاحيات كذلك. ما يجب التحقق منه ليس مدى جمال السرد، بل هل تستطيع هذه القيود الخصوصية الصمود عند تشغيل الأصول الحقيقية RWA على أرض الواقع.
في المستقبل ستوجد أصول امتثال على السلسلة أكثر فأكثر. ما يهمني ليس فقط ما إذا كانت يمكنها إجراء معاملات مجهولة، بل من يستطيع إثبات أن خصوصيتك لا تُحكم إلا بحسب ما تحدده أنت بنفسك@Dusk

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

Dusk يركّز على الخصوصية في سيناريوهات مالية عبر طبقة Layer1، ويقدّم آلية إجماع Succinct Attestation الخاصة به. باختصار: هو علاج مخصص لِكل تلك “الحفر” التي وطئتُ عليها مرات لا تُحصى في سلاسل PoS—احتكار كبار حَمَلة العملات لعملية إنتاج الكتل، سهولة التلاعب بمصدر العشوائية، وبطء تأكيد الكتل. يتحدثون عن “حسم حتمي خلال 3 ثوانٍ”، وأنه يتحمّل هجوم 51%، وألا يسمح بأن يمسك عددٌ قليل من كبار الحَمَلة حق إصدار الكتل فيتحكمون.

بصراحة، الكلام يبدو من غير عيب.

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

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

$DUSK من القيمة طويلة الأمد—وبدرجة ما—مرتبطة بإمكانية أن يعمل هذا آلية الإجماع فعلًا على أرض الواقع.

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

#dusk $DUSK في الليلة الماضية قمت بتحديث موقع Dusk الرسمي، وتم تغيير شريط التنقل بالكامل.

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

أولًا، DuskEVM—وهذا أكثر شيء أردت أن أشتكي منه، وفي نفس الوقت أكثر شيء أسعدني.

كنت دائمًا أعتقد أن خصوصية جهاز Rusk الافتراضي عالية جدًا، لكن عتبة تطوير عقود Rust الأصلية كانت مرتفعة للغاية. والنتيجة هذه المرة؟ DuskEVM سدّت الشكوى التي كنت أرددها سابقًا—فهو ليس جسرًا عبر السلاسل، بل يحتوي على مُترجم بايتكود مدمج. ماذا يعني ذلك؟ أضع عقد Solidity الأصلي بداخله، فيحوّله تلقائيًا إلى كود تنفيذ خاص يتوافق مع قيود دوائر PLONK، ولا داعي لأن أتتبع تفاصيل ZK من الأساس.

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

أما Dusk Trade فهو ثاني شيء فاجأني.

يعتمد على بنية Phoenix zkUTXO—بعد أن درستها فترة طويلة فهمت الصورة: يمكنك اعتبار أن كل معاملة عبارة عن تذكرة تشفير مستقلة، لا يمكن رؤية محتواها إلا لمن يملك المفتاح. لا توجد Mempool عامة، لذلك لا يستطيع روبوتات الالتقاط اللحاق بالركب. وفي الوقت نفسه يوجد واجهة مفاتيح «عرض موجّه» مدمجة؛ عندما تحتاج المؤسسات لتقديم تدقيق امتثال MiCA الخاص بالاتحاد الأوروبي لصناع السوق، يمكنها منح صلاحية عرض سجلات المعاملات بشكل موجّه. هكذا تحقق الامتثال والخصوصية دون خيارين متعارضين.

سير العمل الخاص بالسوق المتوافق يدمج KYC وفترة الحظر ضمن إثباتات ZK. عند إتمام المعاملة على السلسلة يتم التحقق تلقائيًا من الامتثال، وإلا من ناحية المراجعة اليدوية يتم الاستغناء عنها.

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

المشكلة الوحيدة هي—عندما تركت بناء تطبيق على السلسلة في ذلك الوقت بسبب ارتفاع عتبة التطوير، فمتى تخططون للعودة لبنائه؟ @Dusk

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

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

لم تُنشئ أي مفتاح “كلّه علني/كلّه مجهول” على طريقة الأبيض والأسود. بدلًا من ذلك، في طبقة إثباتات zk-SNARKs، نفذت تصميم “شهادة تشفير قابلة للتحقق” (VEP)، وباستخدام خوارزمية Plookup تم ضغط حجم نص الإثبات الفردي إلى أقل من 1KB. سلاسل ZK الخصوصية الأخرى التي تقدم إثباتات مشابهة تحتاج على الأقل لتوليد إثباتات بحجم 10KB أو أكثر، والتهيئة/التحقق يستغرق عشرات الثواني. أما التحقق على السلسلة في Dusk فيحتاج فقط إلى 2 ميلي ثانية: إذا كنت تريد إثبات أن الأموال جاءت من بورصة/تبادل شرعي، فأنت تولّد إثباتًا موجّهًا لهذه عملية الإيداع فقط، دون الحاجة إلى كشف العنوان الكامل أو إجمالي الرصيد أو أي سجلات معاملات أخرى. بل ولا حتى يلزم إخبارهم بعنوان الاستلام لديك. يومها كان الغاز الذي استهلكته أثناء توليد الإثبات 0.0003 DUSK فقط، أرخص من التحويل العادي. جهة التحقق تستطيع التحقق على السلسلة عبر استدعاء عقد (كونتراكت) للتحقق، وحتى خطوات رفع لقطات الشاشة استغنت عنها. وعند تصفح معرّف المعاملة في متصفح البلوكشين، سترى أن المعاملة تحتوي فقط على تجزئة الإثبات، ولا يوجد أي جزء بيانات بنص صريح.

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

#dusk $DUSK 老伙计深夜甩来两条60秒语音，语气跟当年喊我冲土狗一样急：Dusk主网上线，质押节点能跑了，隐私赛道头矿。

我心想跟Sui、Aptos那会儿差不多吧，装二进制挂着就行。结果三天通宵才啃明白。

第一天就卡壳。./dusk-node跑起来，ZK证明生成到87%必崩，终端吐一句"witness construction failed"，内存从4G顶到12G，风扇跟楼下夜宵摊抽油烟机似的。重装五次程序、重下三次快照，都没用。最后翻GitHub示例，一行注释小得差点漏过去："key expects BigInt, string will break witness construction."改完传参方式，重启，8秒证明生成。

静下心翻源码才懂。Dusk的隐私方案不是给EVM套层壳，而是Rusk这个原生隐私虚拟机直接把PLONK零知识证明电路、Poseidon哈希、BLS签名这些密码学组件内置进去。开发者写合约时不用手动处理加密逻辑，编译完就是零知识友好的WASM字节码。合约代码自动转成约束电路，多笔交易能递归聚合成一个批量证明，节点只验证明哈希，地址、金额全程不上链，但每笔交易的合规性都能被数学证明验证。

共识层是SBA（隔离拜占庭协议） 。验证者至少要锁1000枚$DUSK ，每轮出块不仅要打包交易，还得附一份证明出块行为合法的ZK证明。Dusk的罚没分两种：软罚没针对漏块，会暂时移出共识并降低有效质押额；硬罚没针对作恶——出无效块罚没10%，双签或双块罚没20%，直接销毁。硬件方面，官方建议4核CPU、8GB内存起步。

跑了三周，收益没营销号吹得夸张。但跑通那晚机箱风扇安静下来，回头看三天值了，不是赚多少，是把一条新链的底子从头啃了一遍。@Dusk

#baby $BABY في الليلة السابقة قمت بشيئًا واحدًا: اختبرتُ نصّ staking الخاص بـ Babylon باستخدام UTXO قمتُ أنا بإيداعه في شبكة الاختبار الخاصة بي.

أردتُ معرفة كيف تُنفَّذ طرق الخروج الثلاث تلك بالضبط.

أولًا جرّبتُ الأسهل—بعد انتهاء مدة الإيداع، استخدمتُ توقيعي أنا فقط لفكّ قفل الـUTXO، ثم بثثتُ المعاملة إلى شبكة اختبار بيتكوين. اجتازتها العقد، وتم تجميع المعاملة. لا حاجة لموافقة Finality Provider، ولا يلزم أن تكون سلسلة Babylon متصلة؛ توقيعي أنا وحده يكفي. في ذلك الوقت، فكرتُ أن هذا هو أبسط شعور بالأمان: طالما شبكة بيتكوين ما زالت تعمل، يمكن للمُرهِن أن يستعيد عملاته.

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

عند تجربة الطريقة الثالثة علقتُ. مسار الـ slashing يحتاج إلى ثلاث مفاتيح: توقيعي أنا، وتوقيع EOTS الخاص بـ Finality Provider، وتوقيع لجنة Covenant. وقتها تساءلت: لماذا يلزمني توقيعي أنا أصلًا في حال الـslashing؟ أليس هذا كأنه يجعلني مشاركًا في معاقبة نفسي؟

لاحقًا، عند مراجعة تقرير التدقيق، عرفت السبب. توقيع لجنة Covenant هو توقيع مُكيِّف (adapter signature)—يُشفّر ثم يشير إلى Finality Provider. لقد وقّعتُ مسبقًا مسار الـ slashing، لكن هذا التوقيع في الظروف العادية يكون “مُقفّلًا”. لا يتم فكّ تشفيره وتفعيله إلا عندما يستخدم الـFP نفس nonce (رقم عشوائي) لإنتاج توقيعات لنفس الارتفاع لبلوكين مختلفين؛ عندها تنكشف الخوارزمية السرية (يُكشف المفتاح الخاص) ويتم فكّ فعالية توقيع المُكيِّف.

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

لقد جرّبتُ طرق الخروج الثلاث كلها. أي مسار سأنتهي إليه لا يُحدده أحدٌ بالقرارات البشرية؛ كل شيء يعتمد على ما إذا كانت الشروط الثابتة داخل الـscript قد تم استيفاؤها.

@BabylonLabs_io

منذ فترة رأيت أن Babylon في مجتمع Aave قدّم اقتراحًا، وكانت أول ردة فعل لدي: أليس هذا هو نفس أسلوب تغليف البيتكوين مرة أخرى؟

WBTC وcbBTC وغيرها—في جوهرها تقوم بتسليم BTC إلى جهة أمينة مقابل استلام ERC-20 مختلف. على إيثيريوم سترى “BTC”، لكن BTC الحقيقي موجود خلف الكواليس في محافظ الآخرين. إذا هربَت/فشلَت الجهة الأمينة، تصبح “BTC” التي لديك مجرد هواء.

لذلك في البداية كنت رافضًا تمامًا لاقتراح Babylon في Aave. إلى أن قلبت الوثائق وفهمت أني كنت أفكر بالعكس.

VaultBTC من Babylon ليس أصلًا مُغلفًا إطلاقًا. إنها أداة محاسبة داخلية مع قيد تحويل: 1 vaultBTC يساوي 1 BTC، وهو متاح فقط للتفاعل مع عقود Aave المعتمدة. لا يمكنك تحويله إلى الآخرين، ولا يمكنك استخدامه في بروتوكولات أخرى؛ لا يمكن استخدامه إلا كضمان داخل Aave.

ما الفرق؟ الأصل المُغلف هو “تحويل BTC إلى ERC-20”، بينما vaultBTC هو “تسجيل قيد داخل عقد Aave”. BTC لم يغادر أصلًا شبكة البيتكوين الرئيسية؛ بل مُقفل في سكربت Taproot.

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

قام Babylon بنشر وحدتين على Aave v4: Babylon Core Lending Spoke للتعامل مع الإقراض والاقتراض، وBTC Vault Swap Spoke للتسوية بعد عمليات التصفية. بعد أن يقوم المستخدم بقفل BTC في مخزن TBV، يقوم مُكيّف Aave بصك عدد مماثل من vaultBTC بناءً على الدليل التشفيري، ثم يزوّده مباشرةً إلى Core Spoke. بعد ذلك يمكن للمستخدمين الاقتراض على Aave باستخدام USDC أو USDT أو WBTC. عند السداد، يتم إتلاف vaultBTC المقابل، مما يؤدي إلى تحرير BTC.

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

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

تجاوزت TVL الخاصة بـ Babylon 56,853 BTC. أخيرًا لم يعد حاملو BTC مضطرين للاختيار بين “العائد” و“الإدارة الذاتية”.

#BABY $BABY @BabylonLabs_io #baby $BABY

عندما كنت أطلع سابقًا على حلول توسيع شبكة BTC، كان لدي حكمٌ داخلي: المشكلة الكبرى في Bitcoin هي أن وظائفها قليلة جدًا.

لذلك كانت الانطباعات الأولى التي تكونت لدي عن مشاريع كثيرة في نظام BTC البيئي هي أنها تحاول إيجاد طرق لإضافة استخدامات إضافية إلى BTC. لكن بعد بحثي في «Babylon» و«Trustless Bitcoin Vaults (TBV)»، اكتشفت أن فهمي السابق كان خاطئًا قليلًا.

المشكلة الحقيقية ليست جعل BTC يمتلك وظائف أكثر، بل جعل Bitcoin—دون أن يكون على دراية بالعالم الخارجي—قادرًا على المشاركة بأمان في المزيد من السيناريوهات.

جاء هذا التحول في إدراكي من تفصيل رأيته أثناء بحثي في تصميم الـ Vault.

عند إنشاء TBV، يقوم المودِعون وجميع الأطراف المشاركة أولًا بإدراج جميع المخارج القانونية لـ BTC بالكامل—أي طريق سيتم في الاسترداد العادي، وأي طريق في حال تمّ التحدي، وأي طريق إذا تعثرت الأمور وحدثت حالة انسداد. ثم يتم رسم كل مسار مسبقًا كمعاملة كاملة، وتقوم كل جهة بالتوقيع على هذه المعاملة. بعد ذلك، يقوم برنامج Taproot النصي بتشفير هذه المسارات كأوراق إنفاق (spending leaves) مستقلة، ولا يتم تفعيل الـ Vault إلا بعد ذلك. وبعد التفعيل، لا يستطيع أي طرف إنشاء مسار إنفاق جديد.

هذا يعني أن الـ Vault ليس مجرد محفظة لتخزين BTC، بل هي مجموعة من قواعد الحالة. متى يمكن أن تتغير الأمور؟ وما هي الشروط التي يجب أن تتحقق؟ كل ذلك يلزم التحقق وفق المنطق المحدد مسبقًا—وهذه المنطقيات تم كتابتها في البرنامج النصي عند الإنشاء، ولا يملك أحد لاحقًا صلاحية تعديلها.

في النهاية، ما يتغير هو طريقة مشاركة BTC مع العالم الخارجي.

كنت أعتقد أن أكبر صعوبة في توسيع BTC هي «نقص التطبيقات»، لكن اتضح أن المشكلة الحقيقية هي «كيفية تأكيد الحالة الخارجية بشكل موثوق».

وهذا بالضبط ما جذَبني إلى Babylon. فـ TBV لا يضيف ببساطة بوابة استخدام جديدة لـ BTC، بل يحاول بناء طريقة اتصال جديدة: الحفاظ على أساس الأمان الأصلي لدى Bitcoin، وفي الوقت نفسه تمكين المزيد من سيناريوهات السلسلة (on-chain) من فهم هذه الميزة الأمنية والاستفادة منها.

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

وهذا هو سبب إعادة فهمي لـ Babylon. فهي لا تغيّر ما إذا كانت BTC تمتلك وظائف أكثر، بل تغيّر طريقة بناء علاقة الثقة بين BTC والعالم الخارجي. @BabylonLabs_io #baby $BABY

عملية رهن Babylon Euphrates على شبكة الاختبار، قلبت تمامًا قناعتي الراسخة السابقة حول رهن BTC.

الأسبوع الماضي كنت أراقب المكان لمدة نصف ساعة حتى استلمت BTC على شبكة الاختبار، وبعد أن أنهيت كامل عملية الرهن اكتشفت أنها لم تسلك الطريق التقليدي القديم لـ“تحويل الأصول إلى عقد حراسة”؛ بل قامت بتضمين قواعد الرهن مباشرةً في عقد ورقي مخصص ضمن Taproot scripts الخاص بالبتكوين، وذلك عبر بنية MAST لتقسيم شروط فكّ القفل إلى منطق مُخفي على مراحل. ولم يغادر BTC الأصلي شبكة البتكوين ولو لحظة واحدة.

تكمن الفكرة الأساسية في تصميم “مرساة التوثيق” الفريد من Babylon: في كل مرة تتغير فيها حالة الرهن، يتم توليد إثبات ZK-SNARK لامحته يتقلص إلى أقل من 1KB. ثم، عبر إجماع الاستطلاع BABE، يتم بعد تأكيد متعدد التواقيع بنسبة 2/3 داخل شبكة العقد، مزامنة هذه الأدلة مع جميع سلاسل Cosmos وEVM المتصلة.

في النظام البيئي الخارجي، لا تلمس العقود سوى التحقق من أدلة التوثيق الناتجة عن Babylon، دون المساس بـBTC الأصلي. يحمل المستخدم الإثبات ويمكنه المشاركة مباشرةً في إدرار BTC في DeFi على Cosmos أو داخل Binance ZK Rollup، دون الحاجة إلى أي تحويل أو تبادل لرموز خريطة للحراسة. يتم فرض منطق التحقق من الحالة بقوة من شبكة عقد Babylon؛ وحتى عقدة واحدة تسيء التصرف لا يمكنها توليد إثبات قانوني.

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

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

تحديث Euphrates هذه المرة هو نقطة الانطلاق الحقيقية لبدء إخراج قيمة البيتكوين إلى الخارج@BabylonLabs_io #baby $BABY

اسأل سؤالاً: إذا حدث شيء لجهة الحفظ الخاصة بـ wBTC، فهل ستتطابق الأصول وتقارير التدقيق مباشرةً؟ عندما تم اختراق جسر عبر السلاسل بقيمة 1.9 مليار دولار، قامت مجموعة من المؤسسات بإدخال كلمتَي «الجسر» في القائمة السوداء بشكل دائم. وبالنسبة للمؤسسات، فإن الامتثال ليس نقطة إيجابية إضافية، بل هو تذكرة للدخول.

ما الذي تفعله Babylon TBV في جوهره؟ إنها تعيد إصدار هذه التذكرة.

كيف تم ذلك؟ لا يغادر BTC شبكة البيتكوين طوال الوقت؛ بل يتم قفله داخل مخرجات Taproot. لا يوجد عبور عبر السلاسل (cross-chain)، ولا تغليف (encapsulation)، ولا التعامل مع أي طرف ثالث. يمكن للمدققين فتح متصفح السلسلة ورؤية ذلك فوراً: الأصول ما تزال في UTXO الأصلية، ولم تتغير مواقعها، ولا يقل المبلغ.

هناك عزل تام بين الخزائن؛ لا تختلط BTC الخاصة بك مع BTC الخاصة بالآخرين. لا يوجد إعادة رهن (re-hypothecation)، ولا يوجد تجمع أموال (fund pool). إذا حدثت مشكلة في القرض الذي اقترضته من Aave، فإن الأثر يطال مراكزك في Aave فقط، وليس BTC التي قفلتها على شبكة البيتكوين. ما يراه المدقق هو: انكشاف المخاطر واضح، وقابل للتتبع، وقابل للتدقيق.

كل عملية لديها دليل تشفير؛ الأمر ليس «نحن نضمن» بل «برهان رياضي». ما يحتاجه المدقق، تعطيه له السلسلة على الفور؛ دون البحث عن أي شخص لتوقيع الأوراق أو ختمها. من قفل BTC وحتى الاقتراض من Aave ثم الاسترداد النهائي—كل خطوة على السلسلة، ويمكن التحقق منها بشكل مستقل في كل خطوة.

هذه ليست نظرية. أصبحت BitGo مزوّداً مؤهلاً للحفظ لدى Babylon. تم إطلاق خدمة إيداع/رهان البيتكوين الخاصة بـ Babylon على منصة Kraken. قامت Ledger بتكامل دعم توقيعات TBV. استثمرت a16z 15 مليون دولار. لقد قامت Babylon بالفعل برهن أكثر من 56,000 BTC، ووصلت قيمة TVL إلى ذروة تجاوزت 6 مليارات دولار—وهذه الأرقام وراءها تصويت من مؤسسات باستخدام ذهبٍ حقيقي.

لكن تكامل Aave أهم. لقد قدمت Babylon بالفعل اقتراحاً إلى منتدى حوكمة Aave، تخطط لإدخال الاقتراض/الإقراض الأصلي المدعوم بضمان البيتكوين ضمن Aave V4. وقد أظهر مؤسس Aave Stani Kulechov دعماً علنياً. الأداة vaultBTC التي يتضمنها الاقتراح هي أصل محاسبي غير قابل للتحويل، ولا يمكنها إلا التفاعل مع عقود Aave—وبالتالي يفهمها المدققون فوراً؛ لن «تتجول» هذه الأشياء في غير مكانها.

في السابق كانت المؤسسات أمام خيارين: «العائد» أو «الامتثال». الآن لم يعد ذلك ضرورياً. عندما يستطيع المدققون الاطمئنان والتوقيع بأمان على التقارير، وعندما يستطيع الـCFO الاطمئنان والتقديم بالضمان، وعندما يتم استخدام بيتكوين بقيمة 2 تريليون دولار لأول مرة دون الحاجة إلى «تسليمها»—فإن هذا السوق لم يعد مجرد فرع من DeFi، بل إعادة تشكيل لـ DeFi نفسها.
@BabylonLabs_io #baby $BABY

وصلت القيمة السوقية للبيتكوين إلى ما يزيد عن تريليونَي دولار، لكن أقل من 1% منها يتم استغلاله فعليًا داخل DeFi. الأمر ليس أن أصحاب البيتكوين لا يريدون الربح—بل إن الحلول الحالية في جوهرها تجعلك في اختبار اختيار من متعدد: «من الذي تتحكم فيه في BTC؟»@BabylonLabs_io

ميزة Babylon’s Trustless Bitcoin Vaults (TBV) مختلفة: فهي تُزيل هذه المسألة برمتها.

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

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

ثانيًا، على جهة ETH، تقوم العقود فقط بقراءة حالة الخزنة، ولا تلمس جوهر BTC. عند السحب، يقوم النظام بإرجاع حدث الاسترداد على Ethereum إلى شبكة البيتكوين عبر الأوراكل (oracle)، ثم يتحقق عبر برهان صفري المعرفة (zero-knowledge proof) من أن هذا الأمر قد حدث بالفعل، ولا يتم تحرير BTC إلا بعد نجاح التحقق.

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

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

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

إضافة إلى ذلك، قامت Ledger مؤخرًا بتكامل ميزة Clear Signing. عند توقيع معاملات TBV، يتم عرض وجهة كل عملية ومحتواها على شاشة الجهاز الصلب مباشرة. تم سد مخاطر التوقيع الأعمى بالكامل
#baby $BABY