胖鸟

一开始看 @BabylonLabs_io 的时候，我关注点其实也放在了Staking这块，毕竟市场对于Babylon最直观的理解，就是让更多资产参与网络安全，但后面我发现真正有趣的是其实它为什么要设计Checkpoint。

很多项目在做跨链或者生态连接时，关注的通常是资产怎么转移、消息怎么传递。但我后来发现，真正难的问题其实不是怎么连接，而是如果一个网络的状态需要被另一个网络认可，靠什么证明这件事真的发生过？

这个问题其实比怎么连接更难，过去很多方案会引入额外的验证角色，让某个系统负责告诉大家这个状态是真的，但这样做之后，新的信任点也随之产生。

而#baby 中的Checkpoint让我比较关注的地方是它没有选择再增加一个新的验证层，而是尝试让状态本身变得更容易被确认。而在这个过程中，Finality Provider负责参与状态确认，EOTS则用来约束参与者行为。

其实这也是我觉得$BABY 比较特别的地方，它并不是单纯创造一种新的质押方式，也不是建立一个封闭生态，而是在尝试提供一种可以被不同网络使用的基础能力。简单来说，它关注的不只是谁来提供安全，还包括了这个安全结果如何被验证。

这其实是未来多链环境里一个很重要的问题，当越来越多网络开始互相连接，真正困难的可能不是让它们通信，而是让它们能够长期建立信任。一个网络今天运行正常并不代表未来一定可靠，过去发生的状态、历史记录，同样需要被确认。

当然，这个方向最终能不能跑出来还需要时间验证， 基础设施项目最难的地方，从来不是设计一个机制，而是让足够多的参与者愿意长期使用。

emm...我觉得它比较值得关注的一点是它没有只解决谁来提供安全这一单一问题，而是在尝试解决当越来越多网络开始连接，彼此之间的信任应该如何建立，这个问题可能才是Babylon真正想探索的方向。

前段时间看到@BabylonLabs_io 公布的生态数据变化时，我一直在思考为什么现在很多新链，真正难的不是开发，而是上线之后如何快速建立可信的安全基础？

Babylon上线以来已经有越来越多PoS网络开始关注共享安全模式，截至目前，Babylon生态已经连接了数十个区块链网络，BTC Staking参与规模也持续增长，越来越多资产开始进入这个安全市场。

这个变化让我觉得有意思。

因为过去很多项目关注的是如何吸引用户、提高TVL，但Babylon切入的是一个新网络如何降低建立安全体系的成本的问题。

刚开始研究Babylon时，我也把它理解成一个质押类协议，但深入了解它的机制后，我发现它真正想解决的，并不是简单增加一种收益方式，而是改变新网络建立安全的路径。

传统PoS网络需要自己培养验证者，需要设计自己的经济激励，然后慢慢积累安全性。

而Babylon提供的是另一种方案，通过共享安全机制，新网络可以接入Babylon提供的安全能力，不需要从零开始建立完整的安全体系。

其中让我比较关注的是Finality Provider这一层，很多人关注Babylon时，会把重点放在质押本身，但真正让安全能力传递到不同网络中的，是这些负责最终确认和验证的角色，它们连接了资产、安全资源和应用网络之间的关系。

这也是我觉得Babylon有意思的地方。

它不是单纯创造一个新的应用场景，而是在重新定义一个网络启动时需要什么。

Babylon探索的是安全本身也可以成为一种基础设施，当然，共享安全模式未来能否形成长期生态，还有很多问题需要观察，比如不同网络的激励设计、参与者规模以及长期可持续性。

未来区块链竞争可能不只是比谁拥有更多用户和流动性，也可能比谁能够更高效地建立可信基础，这或许才是Babylon真正想探索的方向。
#baby $BABY

يعتقد الكثير من الناس أن أصعب شيء في نسخ بيتكوين (BTC) هو ندرتها، لكن بعد دراسة @BabylonLabs_io مؤخرًا، اكتشفت أن الشيء الأصعب فعلًا هو استبدال الإجماع الأمني الذي تَشكَّل خلال أكثر من عشر سنوات من التشغيل.

وهذا هو السبب الذي جعلني أتابع $BABY مؤخرًا.

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

ما جعلني أغيّر رأيي بفضل Babylon هو أنها لا تركز على كيفية استهلاك سيولة BTC، بل على كيفية الاستفادة من القدرات الأمنية التي كوّنها Bitcoin بالفعل.

الفكرة الأساسية لـ #baby هي تمكين حائزي BTC، من خلال Trustless Bitcoin Vaults وآلية BTC Staking، من دعم شبكات PoS بشكل آمن مع الحفاظ على السيطرة على الأصول.

بكلمات بسيطة، لا تطلب Babylon من المستخدم تحويل BTC إلى نظام بيئي آخر أو الاعتماد على مؤسسات مركزية للوصاية، بل تريد الاستفادة من السمات الأمنية الأصلية في Bitcoin، بحيث يصبح BTC أساسًا أمنيًا يربط شبكات البلوكشين الأخرى.

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

أما Bitcoin فقد أثبتت أمانها عبر أكثر من عقد من الزمن؛ وإذا أمكن في المستقبل الاستفادة من هذه القدرة الأمنية من قبل المزيد من شبكات PoS، فقد تتغير أدوار BTC.

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

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

ربما في المستقبل، لن نهتم بـ Bitcoin فقط لأنه محدود للغاية في العرض،

هل فعلًا يوجد من يشارك؟ 1 نقطة مقابل استبدال 1u من Alpha، يبدو أنهم خسروا حتى سروالهم الداخلي، أليس كذلك

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

لاحقًا رأيت @NewtonProtocol تصميمًا صغيرًا جدًا، ففكرت فجأة في أنني لم أكن أولي اهتمامًا كافيًا لـ Authorization Receipt. كنت أعتقد أنها مجرد فاتورة/إيصال يُولَّد بعد اكتمال التنفيذ، شبيهة بسجلات التنفيذ وإشعارات الاستلام، وأن فائدتها الأساسية هي الحفظ والأرشفة. لكن كلما تابعت أكثر، أدركت أن مكان ظهورها غريب جدًا.

ليست موجودة في نهاية سير العمل، بل تأتي مع Authorization وPolicy وOperator، لتصبح جزءًا من عملية التنفيذ برمتها. ثم أعادت قراءة هذا المقطع عدة مرات، ولم أكتشف أن فهمي الأول كان منحرفًا. كانت أنظمة كثيرة تحفظ النتائج سابقًا: نجحّت المعاملة، وتم تحويل الأصول، وتم تحديث الحالة… وكلها تترك سجلات. لكن عندما تحدث مشكلة فعلًا، غالبًا ما يستمر الناس في التساؤل: من الذي وافق؟ وبأي قاعدة؟ هل تم القفز فوق خطوة ما؟ هذه المعلومات، كثيرًا ما لا يمكن الحصول عليها إلا عبر تجميعها شيئًا فشيئًا من السجلات.

يبدو أن Newton كان يعالج هذه المشكلة دائمًا. فـ Authorization Receipt لا يسجل فقط أنه تم التنفيذ. بل يربط سلسلة كاملة: ترخيص واحد، وPolicy المقابلة، وOperator الذي نفذها، والنتيجة التي انتهت إليها العملية.

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

عندما رأيت ذلك، أدركت فجأة أن Receipt في Newton لا يشبه “إيصالًا” كما في العادة، بل يشبه “سلسلة مسؤولية” لعملية تنفيذ.

لذلك، عندما أعود للنظر في Authorization Receipt الآن، أعتقد أن ما يتركه فعلًا ليس مجرد سجل.

إنه يترك كل الأدلة اللازمة لعملية تنفيذ كاملة—من الترخيص إلى الحكم ثم إلى الاكتمال. وربما ليس ما يمكن الوثوق به على المدى الطويل هو عقدة واحدة أو منصة بعينها، بل تلك العملية نفسها التي يمكن لأي شخص إعادة التحقق منها.
#newt $NEWT

مخيف فعلًا

في الشهر الأخير لم آخذ الـ #ALPHA من الإيردروب، هل صار الوضع لدرجة كذا؟ الليلة الساعة 19:00 هناك إيردروب علب/بَوْكس عشوائية مقابل 251 نقطة، صراحةً هذا مبالغ فيه

متضايق… لأن دورة واحدة لا يمكن أن آكل إلا واحدة

فيه تردد: هل أنتظر مشروع الأسبوع القادم #tge ولا آخذ الآن أولًا؟

يبدو أن هناك دفعة جديدة من الناس سيجنون أرباحًا كبيرة

إذا لم يحدث شيء غير متوقع، فمن المقرر أن يتم طرح مشروع TGE الذي طال غيابه يوم الثلاثاء المقبل

هذه المرة فإن #tge قد اعتمد قواعد جديدة، والطلب عليه ليس عاديًا إطلاقًا، بل في مستوى مرتفع جدًا

يا إخواني، هل أنتم مستعدون؟

وفقًا لسعر الحساب قبل التداول في GRVT Whales Market، فإن القيمة السوقية المتوقعة FDV حاليًا تقف تقريبًا عند 350 مليون دولار. بعد ذلك، القاعدة القديمة: سأشرح هذا المشروع ببساطة وبكلام واضح هل يستحق الضرب أم لا.

​من ناحية الأساسيات، فإن @grvt_io بالفعل يعالج نقاط الألم في القطاع. نظام One Balance الرائد لديه يضمن أن الهامش لم يعد “فلوسًا ميتة”، بل في وقت فتح الصفقة/المركز يمكنه بسلاسة الاستفادة الكاملة من أعلى عائد تلقائي يصل إلى 11% على مستوى الأصول. ومع السرد الهجين الذي يجمع بين سرعة CEX + إتاحة الحيازة الذاتية للأصول في DEX، إلى جانب خلفية الفريق من Goldman Sachs وMeta، فإن القاعدة الأساسية على المدى الطويل تبدو قوية جدًا.

لكن توجد أيضًا أسوأ “بطة سوداء” معروضة أمامنا بوضوح: هذه المرة قامت الجهة الرسمية بزيادة نسبة الإطلاق المخصصة للمجتمع مباشرة من 20% وصولًا إلى 28%! والأكثر خطورة أن حصص TGE في يومها لا تُجبر على الإغلاق/الاقفال. فإذا انسكبت تلك الكمية الهائلة البالغة 28% فجأة في السوق، فسيكون ذلك اختبارًا قاسيًا للغاية لقدرة الاستيعاب في سوق الدرجة الثانية.

ومع ذلك، برأيي الشخصي أنها لن تكون القمة فور الافتتاح، لأن خلفها حزمة موارد بمستوى “حاملة” من نظام zkSync البيئي. وباعتبار GRVT هي الرائد/المنصة الأساسية في نظام zkSync Hyperchain، فهي ليست مجرد بورصة؛ بل تعمل في الطبقة الأساسية كنقطة عقد مهمة لسيولة كامل المنظومة وكذلك كمرحلة تسليم للبيانات.

إذا استطاع صناع السوق امتصاص موجة البيع/الضغط الأولى بعد الافتتاح، وإذا بدأت بيانات التداول الفعلية بالانطلاق لاحقًا، فستبدأ حينها عجلة One Balance في إظهار قوتها. ستتدفق الأموال الكبيرة وLPs طويلة الأجل باستمرار من شبكة الإيثريوم الرئيسية $ETH بهدف التقاط ذلك العائد من 11% على الفائدة، ما يخلق “ثقبًا طبيعيًا لشفط السيولة”.

بشكل عام، الآلية في #grvt جيدة، لكن مع تقييم 350 مليون دولار قبل التداول، فمن المرجح أن السعر على المدى القصير لن يصمد أمام ضربة/تداعيات airdrop الضخمة بنسبة 28%. الأفضل غالبًا الانتظار حتى يستقر دفتر الأوامر وتكون الحصص على السلسلة قد تم “غسلها” إلى حدٍّ كبير قبل الدخول. سعرّي في ذهني هو أقل من $0.2.

يا إخوان، هل تعتقدون أن سعر ما قبل التداول عند $0.35 يمكنه الصمود؟ ما هو سعر الدخول الذي تعتبرون فيه خط دفاعكم النفسي؟ لا بأس إن أردتم أن نتحادث حول هذا.

لا تَعودي/لا تَتبعثِي/لا تنخدع بالوعود المُبهرة التي رُوّج لها مؤخرًا بقيمة ＄GRVT

هذا الشيء ليس بالودّ تجاه صغار المستثمرين كما تتخيل.

خلال اليومين الماضيين، راجعت وثائق التطوير الرسمية المتعلقة بـ @grvt_io ، وعند التوغل في بنية بيانات التسوية اكتشفت في النهاية زوجين من “venue” و“broker” قلّما يناقشهما أحد. وبعد تتبّع مسار التصفية/المقاصة على المستوى الأساسي، انتابني شعور قوي بالدهشة: الجميع يراقب كيفية لعب الشراء والبيع الظاهرة للعيان، لكنه يتجاهل أن النظام على المستوى السفلي يفتح مسارات خارجية (RFQ) مخصّصة للكبار والمؤسسات. صغار المستثمرين يلعبون مع نفس المشتقات التي يلعب بها الكبار، وبالتالي من الطبيعي أن يتلقّوا ضربة صامتة بسبب فارق المعلومات.

وجدت أنه داخل قاعدة البيانات التي تضم #grvt ، تتم معالجة التداولات العادية ثنائية الاتجاه عبر دفتر أوامر علني، لكن بمجرد أن تتضمن معاملات معقّدة من تركيبات الخيارات أو صفقات بمبالغ ضخمة جدًا، يقوم النظام فورًا بتقسيم هذه التدفقات المالية الكبيرة إلى جلسات استفسار RFQ مخصّصة. ثم يتم إجراء مطابقة سرية خارج السلسلة عبر وسطاء من الدرجة الأولى مثل CoinRoutes.

فما الذي يعنيه ذلك؟

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

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

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

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

$NEWT الورقة البيضاء ذكرت شيئًا اسمه بروتوكول مزامنة جدول القدرة الحوسبية متعدد السلاسل “المبني على معيار ELIP-008 الخاص بـ EigenLayer”. الاسم يبدو قويًا جدًا، أليس كذلك؟ في أول مرة قرأته ظننت أنه مجرد مصطلحات مُشدودة—لكن عندما فكّرت قليلًا أدركت أنه يحل في الحقيقة عقدةً شديدة القذارة في التمويل على السلسلة، والعقدة التي لم يقدر أحد من قبل على حلّها: كيف تجعل التطبيقات على سلاسل مختلفة تشارك “نفس” بطاقة أمان اقتصادية بمستوى إيثرِيم عالية الكثافة.

فكر في الأمر: عالم تعدد السلاسل اليوم متفتّت بشدة. إذا كان مشروع ستابل كوين أو RWA يريد إصدارًا على Ethereum وBase وArbitrum وOptimism معًا، فإن الطرق التقليدية تكون مؤلمة للغاية. إما أن تبحث في كل سلسلة عن عقد تحقق امتثال منفصلة، أو تستخدم نوعًا شديد الهشاشة من جسور السلاسل المتقاطعة الخارجية—وتظل طوال الوقت قلقًا منتظرًا أن يقوم قراصنة بتسميم النقل المتقاطع. والنتيجة أن المؤسسات الكبيرة ببساطة لا تجرؤ على ضخ مبالغ ضخمة في L2.

في السابق كان الجميع يتعاملون مع ذلك على أنه “عيب” لا يمكن إصلاحه. لكن Newton هذه المرة حلّه مباشرة في الطبقة الأساسية عبر التشفير. في منطق #newt ، شبكة القدرة الحوسبية اللامركزية لديه تحتاج فقط إلى التسجيل على الشبكة الرئيسية لإيثرِيم مرة واحدة ثم إجراء إعادة التعهيد عبر EigenLayer مرة واحدة أيضًا. بمجرد أن يتغير على إيثرِيم حالة أعضاء العقد أو أوزان التعهيد أو حالة العقوبة بسبب سوء التصرف، تقوم عقد Newton في الطبقة الأساسية بإخراج جماعي لجدول قدرة حوسبية مختوم بتوقيع BLS، على شكل جذر ميركل.

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

بعد أن فهمت مسار مزامنة القدرة الحوسبية عبر السلاسل الخاص بـ ELIP-008، أدركت أن المشروع لا يروي قصة امتثال عظيمة فحسب—بل إنه فعلاً قدّم مهارة تشفيرية صلبة لا يستطيع الآخرون نسخها. لقد وحّد القضبان الحديدية الخاصة بالامتثال متعددة السلاسل مباشرة في شبكة أمان واحدة سلسة.

يعتقد الكثيرون أن @NewtonProtocol مألوف، فيظنون أنه مجرد واحد من تلك الأجسام الهجينة في السوق من نوع ZK أو MPC أو التشفير المتماثل. لكن إذا قلبت صفحة الورقة البيضاء الخاصة به، ستجد أنه يضم العديد من النقاط المميزة والفريدة.

الوسم الأول يُسمّى Newton Rego. فالمشاريع الأخرى عندما تنفّذ سياسات إدارة المخاطر، لا تستطيع سوى استخدام مكتبة قواعد جاهزة لإجراء شروط حكم بسيطة. لكن $NEWT قام بتعديل مُعقّد لمُترجم Rego بمعيار مؤسسي، ثم قام بتركيبه بالقوة مع حزمة توسعة تشفير خاصة به داخل النظام.

وهذا يعني أنه عند كتابة نفس سطر كود تصريحي (Declarative) من قِبل موظفي الامتثال، لا يمكنهم فقط إجراء فحص تقليدي باستخدام القوائم السوداء، بل يمكنهم أيضًا استدعاء واجهات منخفضة المستوى لاستعادة توقيعات الهوية عبر السلاسل الخاصة بـ secp256k1 و Ed25519. إن هذه الصياغة التي تُحوّل حكم تعدد التواقيع خارج السلسلة والتحقق من الجذور المولّدة عبر السلاسل إلى ارتباط ذري (Atomic) معًا، هي صيغة فريدة من نوعها في Web3.

الوسم الثاني هو #newt ، مغلف الخصوصية الخاص بنيوتن. معظم المشاريع في السوق عندما تلعب بالخصوصية، تفعل ذلك أساسًا كلعبة “تشفير ثم إرسال” جاهزة بنمط تسليم المفتاح. لكن NPE هو بناء تشفير شديد التعقيد. فهو يستخدم التشفير بالمستوى العتبي (Threshold) وفي الوقت نفسه يُلزم المستخدم و DApp بإجراء تفويض بتوقيعين (Dual Signature Authorization). والأشد صعوبة هو أنه على مستوى “صيغة السلك” (wire format)، يقوم بتثبيت النص المشفر (ciphertext) بشكل صارم على عميل سياسة محدد وعلى نية معاملة واحدة فقط. لا يمكن لأي هاكر أو عقدة خبيثة مطلقًا إعادة تشغيل أو الاستيلاء على بيانات الخصوصية هذه في سياقات أخرى؛ ومن جذوره يقطع الطريق على هجمات الرجل في المنتصف.

أكثر ما يجعل القشعريرة ترتسم على الجلد هو آلية تحدّي “الزك/ ZK” الخاصة بالجزاء (penalty) لديه، وهي أيضًا الأقل قابلية لأن تُقلّدها المشاريع الأخرى. فبدلًا من أن يكتب الآخرون دوائر ZK يدوية ومخصصة لكل حالة عمل امتثال بعينها (وهذا مؤلم وغير قابل للتعميم)، فإن نيوتن يستفيد من خصائص لغة Rego كدوال صرفة وسمات رياضية قطعية. ثم ببساطة يضع مُفسّر لغة Rego كاملًا داخل جهاز افتراضي ZK مثل SP1 أو Risc0!

والنتيجة في هذا السيناريو هي أن أي موظف لإدارة المخاطر يمكنه كتابة سطر كود واحد، فيصبح في الأسفل تلقائيًا مزودًا بخصائص ZK قابلة للإثبات. أما المنافسون من الخارج، فإذا اكتشفوا أن العقدة تتصرف بسوء، فيمكنهم مباشرة استخدام هذا الدليل ZK العام لإسقاط عقدة الشر فورًا على EigenLayer، ما يؤدي إلى تشغيل العقوبة على السلسلة (slashing) لأصولها في لحظة. وحتى لتوافق مع هذا النوع من الحوسبة، يكفي أن تقوم العقدة بالرهان مرة واحدة على الشبكة الرئيسية للإيثيريوم، بحيث يمكن عبر شجرة ميركل بنمط BLS (BLS Merkle Tree) مزامنة أوزان القدرة الحاسوبية بأمان مع جميع شبكات L2 الرائجة.

最近我切了套高频脚本挂了 2000U 筹码在 @grvt_io 上尝试捕捉套利机会。单子进去了不少，但对账的时候我直接看傻了，几笔本该吃肉的单子，实际成交价比盘面公允价硬生生偏了几个基点。这趟实盘让我彻底醒，项目方标榜的链下隐私订单簿虽然防住了夹子，但在极端行情里我们其实在为这种看不见的隐私交隐形税。

#grvt 核心卖点之一是引进了由零知识技术驱动的加密隐私订单簿，它的底层逻辑是把全网用户的挂单、出价和深度在链下全部打乱加密，让主网上的三方夹子机器人和捕食者量化团队根本拿不到内存池的数据。这意味着什么？你在里面开单，理论上拥有极高的防猎杀隐私。

لكن泼盆冷水，这套系统在极端行情下却带来了另一个隐形硬伤，那就是流动性不透明引发的盲盒滑点。因为整个订单簿深度对市场而言是一个彻底的黑箱，普通交易者和第三方做市商根本无法像在传统交易所那样，实时观测到不同价位的真实挂单厚度。

昨晚市场踩踏时，链下加密网络里的真实深度其实已经严重分层，但前端由于数据隔离依然显示正常。我的买单一头撞进去直接在缺乏公开深度的真空带成交，导致本该止盈的单子吃到了的隐形价差，这种看不见盘口的被动在分秒必争的行情里极其致命。

不过反过来讲，刚吐槽完它的滑点迷雾，看着它的链上防作恶刚性清算又不得不承认它在资金底线上踩得很死。

传统平台最让人恶心的是拔网线和针对性定点爆破，它们的强平清算完全是在中心化服务器里跑的黑箱代码。但#grvt 把最核心的清算红线和账户状态验证死死扣在链上的智能合约里。是否需要被强制减仓全是由公开的智能代码自动跑出来的，平台方都不能干预去更改你的清算线。

总的来说#grvt 虽然牺牲了盘口的透明度，却也帮散户掐死了庄作恶这颗最毒的子弹。

Recently I found that @NewtonProtocol spent a lot of space discussing Attestation、Verification、Replay. At first, I actually didn’t quite understand, because in my understanding, as long as the final outcome is correct, the way it’s achieved in the middle doesn’t seem that important. Who the executor is, what happens during execution—these feel more like implementation details rather than things the protocol truly cares about.

直到后来我把整条执行流程重新顺了一遍，从 Transaction Intent 进入 Gateway，到 Policy Evaluation、Operator 执行，再到后面的 Attestation，我才发现自己一直的疑问在哪里。

$NEWT 真正关心的好像从来不是结果是不是正确，而是结果为什么值得相信，Transaction Intent 并不会因为进入系统就直接执行，而是先经过 Policy Evaluation；Operator 完成任务以后，也不会因为执行结束就直接成为最终结果，后面还需要 Attestation，必要时甚至可以 Replay。

往下看，我越发现，它们其实都在回答这次执行，到底是不是按照整个网络共同认可的规则完成的？

也是到这里我才意识到#Newt 真正记录的并不是一次执行的结果，而是一次执行的过程。后来我又仔细回想了一下，突然想到一个以前没有认真想过的问题。

为什么很多系统更关注证明结果，而 Newton 却花了这么多精力证明过程？

我越来越觉得这两种设计背后，其实代表的是两种完全不同的信任方式，如果只证明结果，最后你还是需要相信那个告诉你结果的人。可如果整个执行过程都能够被验证，那么真正需要相信的，就不再是某一个 Operator而是任何人都可以重复验证的那条执行路径。

所以我觉得Newton 真正想重构的并不是执行流程，它真正挑战的是一个存在很多年的默认假设，结果正确就足够了吗？

至少在 Newton 看来好像还不够
或许这才是 Attestation、Verification 和 Replay 真正存在的意义。它们保护的，从来不只是结果，而是结果之所以成立的整个过程。

في الأيام القليلة الماضية كنت أقلب مدونة @grvt_io باستمرار، وكان هناك مصطلح يظهر بشكل متكرر جدًا وهو Capital Productivity. في البداية لم أكن أتعامل معه بجدية؛ كنت أظن أنه مجرد مفهوم تسويقي. ففي النهاية، أليس ما تتنافس عليه البورصة هو السيولة والعمولات وسرعة التداول؟ منصة تداول واحدة تظل تتحدث عن كفاءة/إنتاجية رأس المال—يبدو ذلك إلى حد ما غير معتاد أن تقوله بورصة.

لذلك عندما رأيت لأول مرة One Balance وUnified Margin، كنت أفسر ذلك دائمًا في اتجاه تحسين تجربة المستخدم. لكن لاحقًا جمعت عدة مقالات معًا وأعدت قراءتها؛ في الأصل كنت فقط أريد أن أفهم بالضبط ما المشكلة التي يحلها Unified Margin، لكن كلما قرأت أكثر شعرت بالأمر أكثر غرابة.

لم تناقش الجهات الرسمية تقريبًا سرعة التداول، ولم تكن تؤكد باستمرار على Hybrid Exchange. بدلًا من ذلك، كانوا يكررون باستمرار Capital Productivity وCapital Drag، وحتى عند الحديث عن Yield Layer لاحقًا، كان النقاش دائمًا يدور حول الشيء نفسه.

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

بعد ذلك رجعت مرة أخرى إلى One Balance وUnified Margin وYield Layer، وفجأة شعرت بأنها تبدو كأنها ثلاث وظائف مختلفة، لكن في الحقيقة كانت جميعها تجيب باستمرار عن سؤال واحد: هل يمكن لحصة رأس المال نفسها أن لا تتوقف فقط بسبب تبديل الغرض؟

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

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

التداول والعائد والاستثمار والدفع ليست في الأصل أربع حصص مختلفة من رأس المال؛ بل ينبغي أن تكون نفس الحصة من رأس المال التي تتحمل مسؤوليات مختلفة في مراحل مختلفة.

لذلك الآن، عندما أنظر إلى Capital Productivity، أشعر بالعكس بأن ما يريد تحسينه ليس كفاءة التداول نفسها، بل طريقة تشغيل رأس المال داخل النظام المالي بأكمله.
#grvt

لم أَحضر TGE جديدًا منذ وقت طويل، و@grvt_io الذي تم إطلاقه مؤخرًا هو أيضًا فرصة كبيرة جدًا.

كما أطلقت @grvt_io فعالية Booster فائقة القيمة، حيث يمكن استبدال 2 نقاط بُقيمة 8u من الرموز، لا تفوّتوا ذلك أبدًا.

عندما بدأت بالاطلاع على بنية HEX الخاصة بـ @grvt_io ، كان لديّ سؤال: إذا حدثت عملية المطابقة/التقاص خارج السلسلة (off-chain)، فكيف تثق السلسلة (on-chain)؟

بحسب فهمي، أكبر قيمة في البلوكشين هي الحتمية (التأكد). فإذا غادرت العملية الأساسية للمطابقة السلسلة، فبماذا يختلف ذلك عن البورصات التقليدية؟ لذلك في البداية اعتقدت أن GRVT يقدّم مجرد تنازل بين الأداء واللامركزية. لكن بعد إعادة النظر في آلية التنفيذ، أدركت أن فهمي الأول كان خاطئًا.

#grvt لا يَحل المشكلة فقط عبر تحديد أين توضع المعاملات، بل في كيفية جعل حالات المعاملات الناتجة خارج السلسلة تُعترف بها نهائيًا على السلسلة. في تصميمه، تدخل الأوامر أولًا إلى Off-chain Matching Engine لإتمام المطابقة؛ وبهذا لا يحتاج التداول عالي التردد إلى انتظار تأكيد السلسلة، ما يتيح كفاءة تنفيذ قريبة من كفاءة البورصات التقليدية.

والأمر المثير للاهتمام هو أن إتمام الصفقة لا يعني أن الحالة تصبح نهائية تلقائيًا؛ إذ يجب تمرير نتيجة التداول عبر On-chain Settlement، حيث يتم التأكيد النهائي عبر قواعد السلسلة والعقود الذكية. أي أن خارج السلسلة مسؤول عن الحسابات عالية التردد، بينما السلسلة مسؤولة عن الحالة النهائية.

عند هذه النقطة فقط أدركت أن #grvt يحاول فصل الحدّ الفاصل بين “توليد الحالة” و“تعريف الحالة”. فـ Matching Engine مسؤول عن توليد نتائج التداول، وSettlement Layer مسؤول عن تأكيد حالة الأصول، بينما Smart Contract Vault يضمن ألا تعتمد أصول المستخدم بالكامل على دفتر الأستاذ المركزي.

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

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

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

لطالما اعتقدت أن أهم شيء في نظام الترخيص هو القواعد.

طالما أن Policy مكتوبة بدقة كافية، يمكن للنظام أن يحدد أي المعاملات يجب تنفيذها وأي المعاملات يجب رفضها. لذلك، عندما بدأت أقرأ الورقة البيضاء @NewtonProtocol ، كان اهتمامي منصبًّا باستمرار على Rego Policy وتدفق Authorization.

إلى أن عدت لاحقًا لإعادة قراءة جزء Data Provider، أدركت حينها أنني كنت أُغفل مشكلة أعمق: حتى لو كانت القواعد أدق ما يمكن، إذا كانت البيانات المُدخلة غير موثوقة، فلن يكون للحكم في النهاية أي معنى.

تقييم Policy الخاص بـ $NEWT لا يقوم بتشغيل القواعد مباشرة. يحتاج Operator إلى استدعاء بيانات خارج السلسلة مثل Oracle Price وSanctions Feed وRisk Score، ثم تمرير هذه المدخلات إلى Rego Policy لاتخاذ القرار. لكن هذه البيانات نفسها ليست موجودة أصلًا وبصورة طبيعية داخل السلسلة. عندها أدركت أن هذه تبدو مشكلة تواجهها تقريبًا كل أنظمة الأتمتة على السلسلة. الجميع يناقش ما إذا كانت العقود الذكية موثوقة، لكنهم نادرًا ما يسألون عن البيانات التي تراها الأنظمة عند اتخاذ قراراتها—هل هي فعلًا موثوقة؟

إذا كان حكم حالة العنوان خاطئًا، أو ظهرت انحرافات في تقييم المخاطر، أو كانت البيانات التي يحصل عليها عقدة ما لا تتطابق مع ما تحصل عليه عقدة أخرى، فقد تكون النتائج الصحيحة لاحقًا في Policy وAttestation وConsensus صحيحة فقط لأنها بُنيت على مدخلات غير صحيحة.

أما تصميم #newt لهذه المشكلة فمثير للاهتمام. فهو لم يختر ريلت يصبح المزود الوحيد للبيانات، بل جعل Data Provider عبارة عن وحدة قابلة للتبديل (Plug-in). يمكن للـ Operator تنفيذ WASM Data Provider بشكل مستقل، وجلب البيانات الخارجية داخل بيئة معزولة، ثم توليد ECDSA Attestation بناءً على البيانات التي يلاحظها، حتى تدخل البيانات نفسها ضمن نطاق التحقق.

عندما وصلت إلى هنا أدركت أنني كنت أفهم الأمر بشكل خاطئ سابقًا. كنت أعتقد دائمًا أن جوهر Newton هو جعل القواعد قابلة للتحقق، لكن في الواقع كان عليه أولًا أن يحل مشكلة أن القواعد عند تشغيلها تواجه الواقع نفسه الموثوق. فـ Policy يحدد كيف يحكم النظام، بينما Data Provider يحدد ما الذي يراه النظام.

الصعوبة الحقيقية لم تكن أبدًا في جعل الآلة تعمل وفقًا للقواعد، بل في ضمان أن العالم الذي تراه الآلة قبل اتخاذ القرار لم يتم تغييره بواسطة مدخلات خاطئة. وربما هذا هو معنى تصميم Data Provider Ecosystem لـ $NEWT .

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