Binance Square
扶摇直上118
515 منشورات

扶摇直上118

入圈很早,学费交了很多,到现在都还是一枚韭菜,爱好合约,最高的战绩1000u打到20万u!
74 تتابع
4.8K+ المتابعون
472 إعجاب
منشورات
الحافظة الاستثمارية
·
--
عرض الترجمة
我刚才发现Babylon官网有一段话被大多数人跳过了:TBV本身不是一个DeFi产品,只是个原语,真正的产品是外面接的那些。这句话我反复读了三遍才意识到分量。TBV是什么?是一套让BTC在不出主网不跨链不托管的前提下变成可编程资产的协议。但Babylon没打算自己拿着这套东西去做借贷做交易做衍生品。它的做法是:把TBV做成SDK轻客户端验证模块前端工具链,然后全部丢给开发者。@babylonlabs_io 等于说,Babylon在造的不是一栋楼,是一套预制板,谁想用BTC做抵押品,拎起这套板子就能开工,不用自己从头写比特币脚本不用自己搭轻节点验证。跟Aave的合作就是典型案例:Babylon只负责把BTC锁进Vault把状态证明传出去,怎么借贷怎么清算,全是Aave自己那套Core Lending Spoke和Vault Swap Spoke的事。 这个设计思路的精妙之处在于:它不用猜市场需要什么。开发者会用TBV做出它自己都没想到的东西。而BABY作为这个扳手工厂的治理代币,价值能不能起来,看的不是Babylon自己做了多少个产品,而是有多少开发者愿意拿起这把扳手。 #baby $BABY
我刚才发现Babylon官网有一段话被大多数人跳过了:TBV本身不是一个DeFi产品,只是个原语,真正的产品是外面接的那些。这句话我反复读了三遍才意识到分量。TBV是什么?是一套让BTC在不出主网不跨链不托管的前提下变成可编程资产的协议。但Babylon没打算自己拿着这套东西去做借贷做交易做衍生品。它的做法是:把TBV做成SDK轻客户端验证模块前端工具链,然后全部丢给开发者。@BabylonLabs_io

等于说,Babylon在造的不是一栋楼,是一套预制板,谁想用BTC做抵押品,拎起这套板子就能开工,不用自己从头写比特币脚本不用自己搭轻节点验证。跟Aave的合作就是典型案例:Babylon只负责把BTC锁进Vault把状态证明传出去,怎么借贷怎么清算,全是Aave自己那套Core Lending Spoke和Vault Swap Spoke的事。

这个设计思路的精妙之处在于:它不用猜市场需要什么。开发者会用TBV做出它自己都没想到的东西。而BABY作为这个扳手工厂的治理代币,价值能不能起来,看的不是Babylon自己做了多少个产品,而是有多少开发者愿意拿起这把扳手。
#baby $BABY
你们在BABY质押比特币感觉如何?
没钱质押毛线感觉
我什么时候能拥有1个大饼
7 ساعة (ساعات) مُتبقية
عندما كنت أقرأ الورقة البيضاء @babylonlabs_io أمس، اكتشفت أن Phase-3 هي الخطوة الأكثر جوهرية في خارطة طريق Babylon، وأيضًا الأصعب من الناحية التقنية. هدفها بسيط جدًا: جعل BTC المُرهن الواحد يوفر الحماية الأمنية لعدة سلاسل PoS في الوقت نفسه. يبدو الأمر جميلًا، أليس كذلك؟ لكن عندما بدأت أفكر بتمعّن في التنفيذ التقني، شعرت بالصداع. في نموذج Phase-1 وPhase-2 الحالي، كل BTC مُرهن يرتبط باحتياجات أمان سلسلة واحدة فقط. يقوم الرهّان بتفويض BTC إلى Finality Provider، وهذا المزود لا يقدّم خدمة التأكيد النهائي إلا لسلسلة واحدة. المنطق واضح. @babylonlabs_io أما في سيناريو تعدد الرهون، فـ BTC نفسه يجب أن يخدم N من السلاسل في الوقت ذاته. لكل سلسلة مجموعة مدققين خاصة بها، وقواعد عقوبة خاصة بها، ومعاملات إجماع خاصة بها. إذا أساء Finality Provider على إحدى السلاسل التصرف وتعرّض للعقوبة، فإن العقوبة تطال نفس BTC. وعندها ستتضرر أيضًا السلاسل الأخرى البريئة. هذا هو انتقال المخاطر. حل Babylon هو استخدام Babylon Genesis، وهي سلسلة مبنية على Cosmos SDK، كطبقة تنسيق. جميع حالات تعدد الرهون، وإشارات العقوبة، وتوزيع المكافآت تُوجَّه وتُدار عبر Genesis. المشكلة أن Genesis نفسها سلسلة PoS، ولديها مجموعة المدققين وآلية الإجماع الخاصة بها. وفي النهاية يعتمد أمان تعدد الرهون على ألا يحدث خلل في Genesis. وفي هذا شيء من الاستدلال الدائري: استخدام سلسلة PoS لإدارة الأمان الذي يقدمه البيتكوين لسلاسل PoS أخرى. تم إطلاق شبكة الاختبار الخاصة بـ Phase-3 في الربع الثالث من عام 2025، وكان من المقرر إطلاق الشبكة الرئيسية في الربع الرابع. وحتى الآن، في يوليو 2026، ما يزال الأمر متأخرًا. أعتقد أن التعقيد التقني أكبر بكثير مما توقعه الفريق. تزامن الحالة عبر عدة سلاسل، والاقتطاع عبر السلاسل بشكل ذري، والتوزيع العادل للمكافآت — كل واحد من هذه الأمور يمثل تحديًا كبيرًا.
عندما كنت أقرأ الورقة البيضاء @BabylonLabs_io أمس، اكتشفت أن Phase-3 هي الخطوة الأكثر جوهرية في خارطة طريق Babylon، وأيضًا الأصعب من الناحية التقنية. هدفها بسيط جدًا: جعل BTC المُرهن الواحد يوفر الحماية الأمنية لعدة سلاسل PoS في الوقت نفسه.

يبدو الأمر جميلًا، أليس كذلك؟ لكن عندما بدأت أفكر بتمعّن في التنفيذ التقني، شعرت بالصداع. في نموذج Phase-1 وPhase-2 الحالي، كل BTC مُرهن يرتبط باحتياجات أمان سلسلة واحدة فقط. يقوم الرهّان بتفويض BTC إلى Finality Provider، وهذا المزود لا يقدّم خدمة التأكيد النهائي إلا لسلسلة واحدة. المنطق واضح. @BabylonLabs_io

أما في سيناريو تعدد الرهون، فـ BTC نفسه يجب أن يخدم N من السلاسل في الوقت ذاته. لكل سلسلة مجموعة مدققين خاصة بها، وقواعد عقوبة خاصة بها، ومعاملات إجماع خاصة بها. إذا أساء Finality Provider على إحدى السلاسل التصرف وتعرّض للعقوبة، فإن العقوبة تطال نفس BTC. وعندها ستتضرر أيضًا السلاسل الأخرى البريئة. هذا هو انتقال المخاطر.

حل Babylon هو استخدام Babylon Genesis، وهي سلسلة مبنية على Cosmos SDK، كطبقة تنسيق. جميع حالات تعدد الرهون، وإشارات العقوبة، وتوزيع المكافآت تُوجَّه وتُدار عبر Genesis. المشكلة أن Genesis نفسها سلسلة PoS، ولديها مجموعة المدققين وآلية الإجماع الخاصة بها. وفي النهاية يعتمد أمان تعدد الرهون على ألا يحدث خلل في Genesis. وفي هذا شيء من الاستدلال الدائري: استخدام سلسلة PoS لإدارة الأمان الذي يقدمه البيتكوين لسلاسل PoS أخرى.

تم إطلاق شبكة الاختبار الخاصة بـ Phase-3 في الربع الثالث من عام 2025، وكان من المقرر إطلاق الشبكة الرئيسية في الربع الرابع. وحتى الآن، في يوليو 2026، ما يزال الأمر متأخرًا. أعتقد أن التعقيد التقني أكبر بكثير مما توقعه الفريق. تزامن الحالة عبر عدة سلاسل، والاقتطاع عبر السلاسل بشكل ذري، والتوزيع العادل للمكافآت — كل واحد من هذه الأمور يمثل تحديًا كبيرًا.
لقد اطلعت على تقرير البحث الأمني المتخصص لـ Babylon الذي نشرته OpenZeppelin في أبريل 2026. كشف التقرير بشكل مباشر وعملي عن أربعة ثغرات جوهرية في البروتوكول، جميعها تتركز في نقاط الضعف لدى حالات الانتقال عند الحدود. وهي نقاط مخاطر يسهل على المستخدمين العاديين والمطورين تجاهلها. الأولى هي ثغرة معالجة حالة التفويض. يقوم Babylon بتقسيم دورة تشغيل السلسلة إلى عدة مراحل، كما أن التحقق من تعديل صلاحيات الانضمام والخروج للعُقد سيتم تأجيله إلى حدود الدورة ليتم تحديثه بشكل موحّد. هذه اللحظة الزمنية تُطلق في الوقت نفسه عدة تغييرات على مستوى النظام. كما تجري في الوقت ذاته إعادة تعيين أوزان تصويت تبديل العُقد وتحديث المزامنة مع حالة الشبكة. ضغط حساب آلة الحالة على السلسلة يكون هائلًا جدًا، ما يجعل حدوث أخطاء منطقية وتشابك/تلاعب في البيانات أمرًا سهلًا. @babylonlabs_io ومن أكثر ما يستدعي الانتباه هو ثغرة الالتفاف على آلية المصادرة. فالبروتوكول نفسه يضع قواعد صارمة لإلزام المصادرة، لكن في بعض الحالات الحدّية الخاصة يمكن للمتطفلين/المدققين الخبثاء إيجاد مسار ثغري للتفادي من العقوبة. تنفيذ المصادرة في Babylon يعتمد بدرجة كبيرة على التحقق من توقيعات العتبة بواسطة اللجنة على السلسلة (off-chain/on-chain حسب السياق). كما توجد تأخيرات مزمنة بطبيعتها بين مكونات خارج السلسلة والبيانات على السلسلة. وهذه الفجوة الزمنية هي نافذة الهجوم التي يمكن استغلالها. في الحقيقة، هذه ليست المرة الأولى التي تُظهر فيها هذه الجهة مخاطر أمنية. ففي يناير 2026، تم الإعلان عن ثغرة في آلية توسيع التصويت لـ BLS. يمكن للمدققين الخبثاء أن يتعمدوا حذف حقل تجزئة الكتلة، مما يؤدي عند حدود الدورة إلى انهيار جماعي لمجموعة عقد التحقق على مستوى الشبكة بالكامل. ولحسن الحظ، قامت الفرق بإصلاح الثغرة في الوقت المناسب، دون التسبب في خسائر فعلية في الأصول. استعانت Babylon قبل وبعد ذلك بعدة جهات تدقيق احترافية، كما قامت بإطلاق برنامج مكافآت مقابل اكتشاف الثغرات. لكن التدقيق لا يمكنه أبدًا القضاء على جميع الثغرات الخفية. كما أن هذه المشكلات التي اكتشفها فريق القبعات البيضاء تكفي لإثبات أن طبقة أساس البروتوكول لا تزال تحتوي على العديد من العيوب الأمنية غير المكتشفة. #baby $BABY
لقد اطلعت على تقرير البحث الأمني المتخصص لـ Babylon الذي نشرته OpenZeppelin في أبريل 2026. كشف التقرير بشكل مباشر وعملي عن أربعة ثغرات جوهرية في البروتوكول، جميعها تتركز في نقاط الضعف لدى حالات الانتقال عند الحدود. وهي نقاط مخاطر يسهل على المستخدمين العاديين والمطورين تجاهلها.

الأولى هي ثغرة معالجة حالة التفويض. يقوم Babylon بتقسيم دورة تشغيل السلسلة إلى عدة مراحل، كما أن التحقق من تعديل صلاحيات الانضمام والخروج للعُقد سيتم تأجيله إلى حدود الدورة ليتم تحديثه بشكل موحّد. هذه اللحظة الزمنية تُطلق في الوقت نفسه عدة تغييرات على مستوى النظام. كما تجري في الوقت ذاته إعادة تعيين أوزان تصويت تبديل العُقد وتحديث المزامنة مع حالة الشبكة. ضغط حساب آلة الحالة على السلسلة يكون هائلًا جدًا، ما يجعل حدوث أخطاء منطقية وتشابك/تلاعب في البيانات أمرًا سهلًا.
@BabylonLabs_io
ومن أكثر ما يستدعي الانتباه هو ثغرة الالتفاف على آلية المصادرة. فالبروتوكول نفسه يضع قواعد صارمة لإلزام المصادرة، لكن في بعض الحالات الحدّية الخاصة يمكن للمتطفلين/المدققين الخبثاء إيجاد مسار ثغري للتفادي من العقوبة. تنفيذ المصادرة في Babylon يعتمد بدرجة كبيرة على التحقق من توقيعات العتبة بواسطة اللجنة على السلسلة (off-chain/on-chain حسب السياق). كما توجد تأخيرات مزمنة بطبيعتها بين مكونات خارج السلسلة والبيانات على السلسلة. وهذه الفجوة الزمنية هي نافذة الهجوم التي يمكن استغلالها.

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

استعانت Babylon قبل وبعد ذلك بعدة جهات تدقيق احترافية، كما قامت بإطلاق برنامج مكافآت مقابل اكتشاف الثغرات. لكن التدقيق لا يمكنه أبدًا القضاء على جميع الثغرات الخفية. كما أن هذه المشكلات التي اكتشفها فريق القبعات البيضاء تكفي لإثبات أن طبقة أساس البروتوكول لا تزال تحتوي على العديد من العيوب الأمنية غير المكتشفة.
#baby $BABY
·
--
صاعد
还有几天就要公布闪迪的财务报表了,这次它能起飞吗?这几天的波动是真的大,我就做短线都心里慌慌的,一下子就可能套我几刀,吓都会吓死我! 每天做个几单,赚点买菜钱也好啊,我还是很看好闪迪的啊,不要再跌了啊! #TradFi晒单
还有几天就要公布闪迪的财务报表了,这次它能起飞吗?这几天的波动是真的大,我就做短线都心里慌慌的,一下子就可能套我几刀,吓都会吓死我!
每天做个几单,赚点买菜钱也好啊,我还是很看好闪迪的啊,不要再跌了啊!
#TradFi晒单
·
--
صاعد
اكتشفت أن الخلفية المهنية لفريق مؤسسي Babylon تُعد قوية نسبيًا ضمن مشاريع التشفير. المؤسس David Tse هو أستاذ في جامعة ستانفورد، وعضو في الأكاديمية الوطنية للعلوم الهندسية بالولايات المتحدة. كما أن المؤسس المشارك Fisher Yu أيضًا خبير في أمن البلوك تشين والتشفير. تضم الفريق وجوهًا صينية كثيرة، لكن طبقة الإدارة الأساسية غالبًا ما تكون بخلفية دولية. الميزة في ريادة الأعمال الأكاديمية هي أن الأساس التقني يكون متينًا؛ والعيب هو أن الكثير من الأحيان لا يفهمون كيفية التواصل مع المستثمرين الأفراد. تلك المصطلحات الأكاديمية في مجال التشفير وتصميم البروتوكولات داخل الورقة البيضاء، لا يستطيع الشخص العادي أصلًا أن يتعمق فيها. وبالإضافة إلى ذلك، أنهت Babylon عدة جولات تمويل بإجمالي 96 مليون دولار. حجم التمويل @babylonlabs_io ليس صغيرًا في بيئة السوق لعام 2024. لكن كون مبلغ التمويل كبيرًا لا يعني بالضرورة أن المشروع سينجح. أعتقد أن الأهم هو أين تم إنفاق الأموال: تطوير التقنية، وبناء النظام البيئي، والتدقيق الأمني—وكل ذلك أعمال تتطلب حرق أموال. ولضمان الأمان، استعانت Babylon بفريقَي Coinspect وZellic لإجراء التدقيقات. أحدهما فريق متخصص في أمان سكربتات البيتكوين، والآخر لديه خلفية من قبيل هاكرين القبعات البيضاء. حتى مع إجراء تدقيقات الأمان، لا يزال من الممكن وجود ثغرات. مخاطر العقود الذكية ومخاطر فشل البروتوكول—هذه كلها مذكورة في الوثائق الرسمية. أما ما إذا كنت ستعترف بهذه المخاطر أو لا، فهذا شأنك أنت. #baby $BABY
اكتشفت أن الخلفية المهنية لفريق مؤسسي Babylon تُعد قوية نسبيًا ضمن مشاريع التشفير.
المؤسس David Tse هو أستاذ في جامعة ستانفورد، وعضو في الأكاديمية الوطنية للعلوم الهندسية بالولايات المتحدة. كما أن المؤسس المشارك Fisher Yu أيضًا خبير في أمن البلوك تشين والتشفير. تضم الفريق وجوهًا صينية كثيرة، لكن طبقة الإدارة الأساسية غالبًا ما تكون بخلفية دولية.

الميزة في ريادة الأعمال الأكاديمية هي أن الأساس التقني يكون متينًا؛ والعيب هو أن الكثير من الأحيان لا يفهمون كيفية التواصل مع المستثمرين الأفراد.

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

وبالإضافة إلى ذلك، أنهت Babylon عدة جولات تمويل بإجمالي 96 مليون دولار. حجم التمويل @BabylonLabs_io ليس صغيرًا في بيئة السوق لعام 2024. لكن كون مبلغ التمويل كبيرًا لا يعني بالضرورة أن المشروع سينجح. أعتقد أن الأهم هو أين تم إنفاق الأموال: تطوير التقنية، وبناء النظام البيئي، والتدقيق الأمني—وكل ذلك أعمال تتطلب حرق أموال.

ولضمان الأمان، استعانت Babylon بفريقَي Coinspect وZellic لإجراء التدقيقات. أحدهما فريق متخصص في أمان سكربتات البيتكوين، والآخر لديه خلفية من قبيل هاكرين القبعات البيضاء. حتى مع إجراء تدقيقات الأمان، لا يزال من الممكن وجود ثغرات. مخاطر العقود الذكية ومخاطر فشل البروتوكول—هذه كلها مذكورة في الوثائق الرسمية. أما ما إذا كنت ستعترف بهذه المخاطر أو لا، فهذا شأنك أنت.
#baby $BABY
كنت أتذكر من سنواتٍ خلت حين كنت أعمل على L2 Rollup الخاص بإيثيريوم، أن أكبر ما كان يزعجني هو فواتير Data Availability (DA) الباهظة. كنت أظن أن بروتوكول Babylon الخاص بوسم الطوابع الزمنية Timestamping للبتكوين ليس إلا مجرد لعبةٍ تشفيرية هدفها تزويد سلاسل PoS بالتحقق النهائي Finality، لكن بعد أن واصلت الغوص في وثائقها التقنية حتى Section 4 مرارًا وتكرارًا، أدركت أن الأمر ليس “وجبة مجانية”. بل هو في جوهره خدمة BTC DA ترتدي عباءةً تشفيرية، ولها هيكل تكاليف فريد جدًا. أعدتُ ترتيب المنطق: لكي تحصل سلسلة PoS على مستوى لا يمكن التلاعب به كما في بتكوين، يجب أن تكتب بياناتها الأساسية—مثل نقاط التحقق Checkpoint وتغيّرات مجموعة المدققين—عبر Babylon داخل OP RETURN على شبكة Bitcoin. ورد في الورقة البيضاء ذلك بصياغة خفيفة، لكنني حسبت رقمًا بسيطًا. عادةً يحتوي سكربت OP_RETURN على 80 بايت فقط. وإذا كانت سلسلة PoS للحفاظ على تجربة Fast Unbonding بنظام ثوانٍ تحتاج إلى ربط حالاتها بشكل متكرر، فهذا يعني أنها قد تضطر كل شهر إلى حجز آلافٍ وآلاف المَداخل الخاصة بـ OP_RETURN على شبكة BTC. هذا جعلني أشعر بأن النظر فقط إلى عدد السلاسل التي يتصل بها Babylon مقابل TVL ليس ذا فائدة؛ إنه مجرد سرد قصة. الشيء الوحيد الذي سأركز عليه كمؤشر صلب هو نسبة المبالغ التي تدفعها سلاسل PoS لعمال مناجم BTC في صورة رسوم Gas، إلى عائدات Babylon نفسها. إذا كانت رسوم Gas التي تولدها سلسلة PoS نفسها وقيمة رموزها—سواءً كانت لا تملك القدرة على تغطية الإيجار الخاص بـ DA الذي تدفعه للمواءمة مع توافق الشبكة على شبكة BTC—فإن هذا النموذج لن يكون مستدامًا على المدى الطويل. @babylonlabs_io يكمن طيْري في أن القيمة النهائية لـ BABY لا تعتمد على مقدار ما تُخرجه من “أمان”، بل على ما إذا كان بإمكانه إنشاء سوقٍ لتثبيت البيانات يكون منخفض التكلفة وعالي الكفاءة. إنه ليس أمنًا مجانيًا، بل فعلٌ تجاري يتطلب حساب تكلفة كل بايت من DA بدقة. وحتى يثبت هذا النظام أنه قابل للتطبيق اقتصاديًا، ما زلت أحافظ على قدرٍ من الوعي العقلاني. #baby $BABY
كنت أتذكر من سنواتٍ خلت حين كنت أعمل على L2 Rollup الخاص بإيثيريوم، أن أكبر ما كان يزعجني هو فواتير Data Availability (DA) الباهظة. كنت أظن أن بروتوكول Babylon الخاص بوسم الطوابع الزمنية Timestamping للبتكوين ليس إلا مجرد لعبةٍ تشفيرية هدفها تزويد سلاسل PoS بالتحقق النهائي Finality، لكن بعد أن واصلت الغوص في وثائقها التقنية حتى Section 4 مرارًا وتكرارًا، أدركت أن الأمر ليس “وجبة مجانية”. بل هو في جوهره خدمة BTC DA ترتدي عباءةً تشفيرية، ولها هيكل تكاليف فريد جدًا.

أعدتُ ترتيب المنطق: لكي تحصل سلسلة PoS على مستوى لا يمكن التلاعب به كما في بتكوين، يجب أن تكتب بياناتها الأساسية—مثل نقاط التحقق Checkpoint وتغيّرات مجموعة المدققين—عبر Babylon داخل OP RETURN على شبكة Bitcoin. ورد في الورقة البيضاء ذلك بصياغة خفيفة، لكنني حسبت رقمًا بسيطًا. عادةً يحتوي سكربت OP_RETURN على 80 بايت فقط. وإذا كانت سلسلة PoS للحفاظ على تجربة Fast Unbonding بنظام ثوانٍ تحتاج إلى ربط حالاتها بشكل متكرر، فهذا يعني أنها قد تضطر كل شهر إلى حجز آلافٍ وآلاف المَداخل الخاصة بـ OP_RETURN على شبكة BTC.
هذا جعلني أشعر بأن النظر فقط إلى عدد السلاسل التي يتصل بها Babylon مقابل TVL ليس ذا فائدة؛ إنه مجرد سرد قصة.
الشيء الوحيد الذي سأركز عليه كمؤشر صلب هو نسبة المبالغ التي تدفعها سلاسل PoS لعمال مناجم BTC في صورة رسوم Gas، إلى عائدات Babylon نفسها. إذا كانت رسوم Gas التي تولدها سلسلة PoS نفسها وقيمة رموزها—سواءً كانت لا تملك القدرة على تغطية الإيجار الخاص بـ DA الذي تدفعه للمواءمة مع توافق الشبكة على شبكة BTC—فإن هذا النموذج لن يكون مستدامًا على المدى الطويل. @BabylonLabs_io

يكمن طيْري في أن القيمة النهائية لـ BABY لا تعتمد على مقدار ما تُخرجه من “أمان”، بل على ما إذا كان بإمكانه إنشاء سوقٍ لتثبيت البيانات يكون منخفض التكلفة وعالي الكفاءة. إنه ليس أمنًا مجانيًا، بل فعلٌ تجاري يتطلب حساب تكلفة كل بايت من DA بدقة. وحتى يثبت هذا النظام أنه قابل للتطبيق اقتصاديًا، ما زلت أحافظ على قدرٍ من الوعي العقلاني. #baby $BABY
·
--
صاعد
من خلال السنوات الماضية، قرأت كثيرًا من “الورق الأصفر” التقنيّ الخاص بشتى السلاسل العامة، واستخرجت تدريجيًا بعض الخبايا. لا أهتم كثيرًا بمدى ارتفاع TPS النظري؛ بالعكس، أنظر أولًا إلى “مرساة الأمان” التي تُعرّفها: هل بُنيت على رموز تضخمية هشة؟ أم أنها تقفز على حساب قدرة حوسبة مطلقة لدى جهةٍ ما؟ رأيت الكثير من سلاسل جديدة تُقيم الأبراج بسرعة، لكن الجذر لم يكن أبدًا أن الإيكولوجية لم تُبنَ؛ بل إن “الإجماع” كان رخيصًا جدًا، وتكلفة الهجوم منخفضة إلى حدّ يمكن لأي “حوت” تقريبًا أن يجعل الشبكة تتعطل. عندها تصبح كل “الوسامة” في الأداء مجرد نكتة. عندما كنت أفكك طبقة خدمة أمان البيتكوين الخاصة بـ Babylon، كان ما أوقفني هو هذه الطبقة بالذات.@babylonlabs_io فهي ليست تستدرج استثمارات لسلاسل PoS أخرى، بل تحوّل قابلية البيتكوين القوية التي لا يمكن العبث بها—عبر بدائيات التشفير—إلى خدمة أمن “قابلة للإيجار”، وبتصنيف أمني عالٍ. لا تحتاج السلاسل الجديدة بعد الآن إلى تضخيم رموزها بشكل تضخمي عند البداية إلى مستوى يلتهم قدمينها؛ بل يمكنها تثبيت الحالة التاريخية مباشرة على الشبكة الرئيسية للبيتكوين عبر Babylon. تبدو هذه الفكرة شبيهة بخدمات النسخ الاحتياطي/التعافي من الكوارث “الموقعية” في مراكز بيانات كبيرة تمتد عبر مواقع مختلفة: يمكنها السعي إلى أقصى سرعة، لكن عندما يتعلق الأمر ببيانات ذات Finality نهائية، يجب مزامنتها في وقتٍ محدد مع مركز بيانات أساسي معزول ماديًا لا يُكسر. لطالما كانت السلاسل على السلسلة تفتقد إلى آلية سيولة أمان “سيادية” من هذا النوع. Babylon لا يحاول تعويض “السيولة”، بل يقدم لسلاسل PoS خيارًا للحصول على أمان من الدرجة العليا دون التضحية المفرطة بالنموذج الاقتصادي. ولن أُضخمه كأنه “خزنة أمان” مطلقة. ففي أوقات ازدحام BTC، لا تصل الطوابع الزمنية؛ وعندها ينخفض مستوى الحماية. وإذا أخطأ مرسلُ Babylon (الـ relay)، ستنقطع الإشارة بالطريقة نفسها. ما ينبغي النظر إليه ليس أن كل شيء مثالي نظريًا، بل: في ظل ظروف سوق شديدة التطرف، هل يمكن لبروتوكول إيجار الأمان هذا أن يصمد ويحافظ على “حدّ أدنى” لا يؤدي إلى افتراضات ثقة إضافية. أعتقد أن القيمة النهائية لـ$BABY تعتمد على مدى تغييره الجذري لنموذج تكلفة إطلاق السلاسل الجديدة. مستقبلاً، كلما زاد عدد السلاسل، سأهتم بدرجة أقل بما تحكيه السلاسل الجديدة من قصص؛ والأهم هو من يستطيع أن يبرهن أن تاريخها موجود فعليًا في دفتر البيتكوين، محفورًا كالنحت بالنحت والنحت. #baby $BABY
من خلال السنوات الماضية، قرأت كثيرًا من “الورق الأصفر” التقنيّ الخاص بشتى السلاسل العامة، واستخرجت تدريجيًا بعض الخبايا. لا أهتم كثيرًا بمدى ارتفاع TPS النظري؛ بالعكس، أنظر أولًا إلى “مرساة الأمان” التي تُعرّفها: هل بُنيت على رموز تضخمية هشة؟ أم أنها تقفز على حساب قدرة حوسبة مطلقة لدى جهةٍ ما؟ رأيت الكثير من سلاسل جديدة تُقيم الأبراج بسرعة، لكن الجذر لم يكن أبدًا أن الإيكولوجية لم تُبنَ؛ بل إن “الإجماع” كان رخيصًا جدًا، وتكلفة الهجوم منخفضة إلى حدّ يمكن لأي “حوت” تقريبًا أن يجعل الشبكة تتعطل. عندها تصبح كل “الوسامة” في الأداء مجرد نكتة.

عندما كنت أفكك طبقة خدمة أمان البيتكوين الخاصة بـ Babylon، كان ما أوقفني هو هذه الطبقة بالذات.@BabylonLabs_io فهي ليست تستدرج استثمارات لسلاسل PoS أخرى، بل تحوّل قابلية البيتكوين القوية التي لا يمكن العبث بها—عبر بدائيات التشفير—إلى خدمة أمن “قابلة للإيجار”، وبتصنيف أمني عالٍ.

لا تحتاج السلاسل الجديدة بعد الآن إلى تضخيم رموزها بشكل تضخمي عند البداية إلى مستوى يلتهم قدمينها؛ بل يمكنها تثبيت الحالة التاريخية مباشرة على الشبكة الرئيسية للبيتكوين عبر Babylon.

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

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

أعتقد أن القيمة النهائية لـ$BABY تعتمد على مدى تغييره الجذري لنموذج تكلفة إطلاق السلاسل الجديدة. مستقبلاً، كلما زاد عدد السلاسل، سأهتم بدرجة أقل بما تحكيه السلاسل الجديدة من قصص؛ والأهم هو من يستطيع أن يبرهن أن تاريخها موجود فعليًا في دفتر البيتكوين، محفورًا كالنحت بالنحت والنحت.
#baby $BABY
لقد درست نظام البيتكوين الإيكولوجي لوقت طويل، وتعمل أغلب المشاريع على محاولة إضافة خصائص حسابية إلى BTC. لكنني أعتقد أن المكان الذي يجعل BABY مبدِّلًا حقيقيًا للعبة لا يكمن في ذلك، بل في أنه يستخرج بعمق خصائص الوقت واليقين في البيتكوين، ويُشفِّرها تشفيرًا داخل بروتوكول إجماع PoS. يُكثر الحديث عن كيفية تنفيذ EOTS لآليات الإلزام/الخصم التلقائي (penalty slashing)؛ وهذا بالفعل ذكي ودقيق. لكنني أعتقد أن النواة التقنية الأكثر جوهرية والأكثر قابلية للتجاهل في الورقة البيضاء @babylonlabs_io هي تصميم قيودٍ صلبة على مستوى طبقة سكربت البيتكوين لحالة الرهن (staking) كـ«آلة حالة» State Machine. لنكشف الضباب عن الجوهر: لا توجد في سلسلة البيتكوين عقود ذكية تحافظ على حالات مثل: تم رهنه، جارٍ فك الرهن، وتم فك الرهن. إن براعة Babylon تكمن في أنه يستخدم خصائص سكربت UTXO الأصلية في البيتكوين، ويُجبر على محاكاة آلة حالة ديناميكية فوق سجلٍّ ثابت. عندما يبدأ المستخدم الرهن، يتم قفل BTC داخل UTXO محدد. إن شرط فتح (unlock) هذا الـUTXO ليس شرطًا واحدًا منفردًا، بل هو بوابة منطقية مركبة. والسرّ هنا أنه يربط فعل فك الرهن — على المستوى التشفيري — بشكل مُحكَمٍ مع نهائية الإجماع (finality) لسلسلة Babylon. تشرح الورقة البيضاء القسم 5 بالتفصيل هذه الآلية القابلة للملاحظة لفك الرهن. إذا كان المُتحقق (validator) صادقًا، فإن فك الرهن يتطلب المرور بفترة أمان يتم قفلها عبر CSV. وهذا يضمن أنه إذا كان قد ارتكب سوء تصرف في الماضي، فخلال فترة الأمان هذه يكون لدى مفاتيح EOTS الخاصة به وقت كافٍ للاستخراج والتنفيذ الفعلي لآلية الخصم. وهذا يعني أن «صلاحية فتح» BTC ليست بيد بروتوكول Babylon بحد ذاته، بل بيد حقائق رياضية/فيزيائية مؤكدة: الوقت وما إذا كان المُتحقق قد أساء التصرف. وتيقّني هو أن هذا التصميم، على الرغم من أنه يثق بالرياضيات بدرجة كبيرة، فإنه لا يثق بسرعة التنفيذ بدرجة كبيرة. فهذه المعمارية من أجل الأمان المطلق تُضحّي بكفاءة السيولة بشكل كبير. قد يؤدي طول دورة فك الرهن إلى أن يرى مُرهنو BTC — في ظل ظروف سوقية متطرفة — أصولهم لا يمكن نقلها. القيمة الأساسية لـ BABY ليست خلق عوائد مرتفعة، بل خلق UTXO «مدرك للإجماع». فهو يجعل الـUTXO في البيتكوين — الذي كان سابقًا جامدًا — قادرًا على إدراك حالة الإجماع الخاصة بسلسلة PoS الخارجية. وهذا أقرب إلى شيء أكثر صلابة من أي حل سلاسل جانبية أو عبر السلاسل رأيته؛ فهو ليس مجرد تكديس للكود، بل هو استخراجٌ لأقصى درجات الثقة في بدائيّات البيتكوين الأصلية، وبطريقة عنيفة بلا تهاون. #baby $BABY
لقد درست نظام البيتكوين الإيكولوجي لوقت طويل، وتعمل أغلب المشاريع على محاولة إضافة خصائص حسابية إلى BTC. لكنني أعتقد أن المكان الذي يجعل BABY مبدِّلًا حقيقيًا للعبة لا يكمن في ذلك، بل في أنه يستخرج بعمق خصائص الوقت واليقين في البيتكوين، ويُشفِّرها تشفيرًا داخل بروتوكول إجماع PoS.

يُكثر الحديث عن كيفية تنفيذ EOTS لآليات الإلزام/الخصم التلقائي (penalty slashing)؛ وهذا بالفعل ذكي ودقيق. لكنني أعتقد أن النواة التقنية الأكثر جوهرية والأكثر قابلية للتجاهل في الورقة البيضاء @BabylonLabs_io هي تصميم قيودٍ صلبة على مستوى طبقة سكربت البيتكوين لحالة الرهن (staking) كـ«آلة حالة» State Machine.

لنكشف الضباب عن الجوهر: لا توجد في سلسلة البيتكوين عقود ذكية تحافظ على حالات مثل: تم رهنه، جارٍ فك الرهن، وتم فك الرهن. إن براعة Babylon تكمن في أنه يستخدم خصائص سكربت UTXO الأصلية في البيتكوين، ويُجبر على محاكاة آلة حالة ديناميكية فوق سجلٍّ ثابت.

عندما يبدأ المستخدم الرهن، يتم قفل BTC داخل UTXO محدد. إن شرط فتح (unlock) هذا الـUTXO ليس شرطًا واحدًا منفردًا، بل هو بوابة منطقية مركبة. والسرّ هنا أنه يربط فعل فك الرهن — على المستوى التشفيري — بشكل مُحكَمٍ مع نهائية الإجماع (finality) لسلسلة Babylon.

تشرح الورقة البيضاء القسم 5 بالتفصيل هذه الآلية القابلة للملاحظة لفك الرهن. إذا كان المُتحقق (validator) صادقًا، فإن فك الرهن يتطلب المرور بفترة أمان يتم قفلها عبر CSV. وهذا يضمن أنه إذا كان قد ارتكب سوء تصرف في الماضي، فخلال فترة الأمان هذه يكون لدى مفاتيح EOTS الخاصة به وقت كافٍ للاستخراج والتنفيذ الفعلي لآلية الخصم. وهذا يعني أن «صلاحية فتح» BTC ليست بيد بروتوكول Babylon بحد ذاته، بل بيد حقائق رياضية/فيزيائية مؤكدة: الوقت وما إذا كان المُتحقق قد أساء التصرف.

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

القيمة الأساسية لـ BABY ليست خلق عوائد مرتفعة، بل خلق UTXO «مدرك للإجماع». فهو يجعل الـUTXO في البيتكوين — الذي كان سابقًا جامدًا — قادرًا على إدراك حالة الإجماع الخاصة بسلسلة PoS الخارجية. وهذا أقرب إلى شيء أكثر صلابة من أي حل سلاسل جانبية أو عبر السلاسل رأيته؛ فهو ليس مجرد تكديس للكود، بل هو استخراجٌ لأقصى درجات الثقة في بدائيّات البيتكوين الأصلية، وبطريقة عنيفة بلا تهاون.
#baby $BABY
لقد قلبتُ أمس وثائق نموذج الاقتصاد الخاص بـ @babylonlabs_io ، واكتشفت تفصيلاً مُحرجاً للغاية بخصوص آلية التقاط قيمة توكن BABY: وظيفته الأساسية الأهم، في الواقع، لا تحتاج إلى استهلاك التوكن نفسه. حالياً، التوقع الشائع لـ BABY هو أنه مثل Aave + EigenLayer ضمن نظام البيتكوين البيئي، أي بوابة لسلاسة سيولة تريليونات الـ BTC، وبالتالي يجب أن يكون التوكن ذا قيمة. كانت منطقية السرد السابقة: Babylon سلسلة، وبما أنها سلسلة فإصدار التوكن أمر بديهي، ولأن المستخدمين سيقومون بعمليات، فهم يحتاجون إلى دفع BABY كـ Gas. لكن المشكلة الواقعية هي أن العمل الأساسي لـ Babylon هو بيع أمان البيتكوين. حسبتُ الأمور بدقة. عندما تحتاج سلسلة PoS أو L2 إلى شراء خدمة أمان الطوابع الزمنية من Babylon، عادةً ما تكون الرسوم التي تدفعها عبارةً عن عائدات ناتجة من رهن توكنها الأصلي، أو تكون بالـ BTC. ومشغّل الـ BTC الذي يقفل الأصول يدفع رسوماً في شبكة البيتكوين الأصلية من نوع BTC بقيمة تقارب 2.66u، سواء لإنشاء المعاملة أو لاستردادها. وهذا يولّد مفارقة تقنية شديدة العبث: أكثر سلوك تجاري في المنظومة، والأكثر تكراراً، لا يحتاج في الواقع إلى استهلاك BABY. تقول الوثيقة ذلك بصياغة غير مباشرة: يتم استخدام BABY أساساً للحوكمة، وكذلك كحافز إضافي لـ Finality Provider. وهذا يعني أن BABY أقرب إلى توكن يمنح حقوقاً في توزيع الأرباح (dividend) وليس توكناً يُعدّ مخرجاً/مستمراً لوسيلة إنتاج. بالنسبة للجهات والمؤسسات والسلاسل التي تستخدم خدمة Babylon فعلاً، فليس هناك حاجة لديهم أساساً إلى تجميع BABY؛ يكفي أن يكون لديهم BTC أو عملاتهم الخاصة. هذا حتى دون احتساب ضغط التضخم على BABY. ولتحفيز Finality Provider على الالتحاق المبكر، يجب على البروتوكول صرف كميات كبيرة من BABY كدعم. توكن بلا سيناريو استهلاك Gas داخلي خاص به، لكنه يتعرض لضغط تضخم خارجي كبير، تكون قدرته على التقاط القيمة شديدة الهشاشة. إلا إذا فرض البروتوكول في المستقبل بشكل قسري أن FP يجب أن يَرهِن عدداً محدداً من BABY للحصول على صلاحية التحقق، فإن هذا الأمر من الناحية المنطقية يكون غير متسق للغاية. أعتقد أن الكبار قد لا يهتمون؛ إذ يمكنهم تعويض الأمر عبر كسب BABY من خلال رهن BTC، وربما هذا هو مسار خروج الـ VC. لكن بالنسبة للمستثمرين الأفراد إذا كانوا يقومون بتجميع BABY فقط بهدف المراهنة على ارتفاع قيمة التوكن، فستحتاج إلى التفكير بوضوح: في نظام تُستخدم فيه الأعمال كلها لتسوية المدفوعات باستخدام BTC، كم ستكون قيمة توكن حوكمة بحتة متبقية بعد انحسار “الموجة”. #baby $BABY
لقد قلبتُ أمس وثائق نموذج الاقتصاد الخاص بـ @BabylonLabs_io ، واكتشفت تفصيلاً مُحرجاً للغاية بخصوص آلية التقاط قيمة توكن BABY: وظيفته الأساسية الأهم، في الواقع، لا تحتاج إلى استهلاك التوكن نفسه.

حالياً، التوقع الشائع لـ BABY هو أنه مثل Aave + EigenLayer ضمن نظام البيتكوين البيئي، أي بوابة لسلاسة سيولة تريليونات الـ BTC، وبالتالي يجب أن يكون التوكن ذا قيمة. كانت منطقية السرد السابقة: Babylon سلسلة، وبما أنها سلسلة فإصدار التوكن أمر بديهي، ولأن المستخدمين سيقومون بعمليات، فهم يحتاجون إلى دفع BABY كـ Gas.
لكن المشكلة الواقعية هي أن العمل الأساسي لـ Babylon هو بيع أمان البيتكوين.

حسبتُ الأمور بدقة. عندما تحتاج سلسلة PoS أو L2 إلى شراء خدمة أمان الطوابع الزمنية من Babylon، عادةً ما تكون الرسوم التي تدفعها عبارةً عن عائدات ناتجة من رهن توكنها الأصلي، أو تكون بالـ BTC. ومشغّل الـ BTC الذي يقفل الأصول يدفع رسوماً في شبكة البيتكوين الأصلية من نوع BTC بقيمة تقارب 2.66u، سواء لإنشاء المعاملة أو لاستردادها.
وهذا يولّد مفارقة تقنية شديدة العبث: أكثر سلوك تجاري في المنظومة، والأكثر تكراراً، لا يحتاج في الواقع إلى استهلاك BABY.
تقول الوثيقة ذلك بصياغة غير مباشرة: يتم استخدام BABY أساساً للحوكمة، وكذلك كحافز إضافي لـ Finality Provider.
وهذا يعني أن BABY أقرب إلى توكن يمنح حقوقاً في توزيع الأرباح (dividend) وليس توكناً يُعدّ مخرجاً/مستمراً لوسيلة إنتاج. بالنسبة للجهات والمؤسسات والسلاسل التي تستخدم خدمة Babylon فعلاً، فليس هناك حاجة لديهم أساساً إلى تجميع BABY؛ يكفي أن يكون لديهم BTC أو عملاتهم الخاصة.
هذا حتى دون احتساب ضغط التضخم على BABY. ولتحفيز Finality Provider على الالتحاق المبكر، يجب على البروتوكول صرف كميات كبيرة من BABY كدعم. توكن بلا سيناريو استهلاك Gas داخلي خاص به، لكنه يتعرض لضغط تضخم خارجي كبير، تكون قدرته على التقاط القيمة شديدة الهشاشة. إلا إذا فرض البروتوكول في المستقبل بشكل قسري أن FP يجب أن يَرهِن عدداً محدداً من BABY للحصول على صلاحية التحقق، فإن هذا الأمر من الناحية المنطقية يكون غير متسق للغاية.

أعتقد أن الكبار قد لا يهتمون؛ إذ يمكنهم تعويض الأمر عبر كسب BABY من خلال رهن BTC، وربما هذا هو مسار خروج الـ VC. لكن بالنسبة للمستثمرين الأفراد إذا كانوا يقومون بتجميع BABY فقط بهدف المراهنة على ارتفاع قيمة التوكن، فستحتاج إلى التفكير بوضوح: في نظام تُستخدم فيه الأعمال كلها لتسوية المدفوعات باستخدام BTC، كم ستكون قيمة توكن حوكمة بحتة متبقية بعد انحسار “الموجة”.
#baby $BABY
الجميع يتحدث عن BabylonLabs وأن BTC الأصلية أصبحت تحقق عوائد، لكنني قلبت البيانات والإعلانات والـمجتمع، فوجدت أن الناس يتجنبون عمداً واحداً من أهم الكلمات في ورقة بيضاء: آلية Slashing (الخصم/العقوبة). اضطررت إلى كتابة هذا المقال لأُذكّر أولئك الذين يرون فقط أن البيتكوين بلا جسور، ولا حراسة، وUTXO أصلي، ثم يندفعون كمتداولين صغار: الأصلية لا تعني انعدام المخاطر. «الأصلية» تعني أنه إذا أخطأت، فإن بيتكوينك ستُخصم فعلياً وبشكل دائم. @babylonlabs_io آلية BABY هي كالتالي: يقوم مشارك/مُراهن BTC (staker) بتأمين الأصول داخل UTXO، ثم يُفوّض حقوق التحقق إلى مزوّد الإنهاء النهائي Finality Provider الذي يوفّر الإنهاء النهائي. إذا قام Finality Provider بسلوك أمني شديد مثل التوقيع المزدوج Double Signing، فسيتم slashing على الـBTC التي تم تفويضها لهم. هذا التصميم عبقري تقنياً، لأنه يقدّم لأول مرة لبيتكوين قدرة على فرض عقوبات اقتصادية بأسلوب PoS. لكن بالنسبة للمتداولين الصغار، فهو «صندوق أسود» من ناحية الثقة: لا يمكنك التحقق من الكفاءة التقنية للـFinality Provider. كيف يعرف المتداول الصغير أن المُتحقق/المدقق لن يقوم بالتوقيع المزدوج بسبب تعطل الخوادم أو خلل في الكود أو هجوم من قراصنة؟ بمجرد وقوع الحادثة، يتحمل المُتحقق خسارة في السمعة فقط، بينما خسارتك أنت هي بيتكوين حقيقية وقابلة للقياس. هذه هي عملية «الاستغلال» الثانية التي تقوم بها المؤسسات ضد المتداولين الصغار: لا يملك المتداول الصغير سوى بضع 0.1 BTC، ولا يملك أصلاً الأهلية لأن يصبح هو المدقق بنفسه. كل ما يستطيع فعله هو التفويض إلى بروتوكولات LST مثل Lombard أو PumpBTC أو غيرها من مؤسسات الحراسة. ووجدت أن هذا تحوّل إلى مشهد عبثي: كان من المفترض أن يُحل BABY مشكلة عدم وجود جسور وعدم وجود حراسة، لكن في النهاية يقوم المتداولون الصغار، من أجل كسب ذلك الـAPY، بتفويض صلاحية البيتكوين الأصلية نفسها إلى بروتوكول «وسيط». دعونا نحسبها: عائد APY الخاص بـ BTC الأصلية المرهونة ما يزال في مرحلة Cap حالياً، لذا العائد الرسمي غير محدد. لنفترض أنه 3%-5% مقابل مخاطر sloshing/الـslashing لـ 0.1 BTC. إذا حدث slashing، فقد تُخصم عملات BTC الخاصة بك مباشرة بنسبة 20% أو أكثر. وهذا يعني أنك تحتاج إلى تشغيل بدون أعطال لمدة 5-10 سنوات كي تعوض خسارة تلك الحادثة. برأيي الشخصي: مشاركة المتداولين الصغار في رهان BTC الخاص بـ BABY في جوهرها هي مقامرة على مخاطرة غير متكافئة. أنا أقول هذا لنفسي: إذا لم أكن أملك ما لا يقل عن 1 BTC، فلن أتعامل مع هذا النوع «الطِقْسِي/الأصيل بالكامل» من آلية slashing. أفضل التعامل مع حلول L2 التي لديها جسور لكن نموذج العوائد واضح، على الأقل أعرف أين تكمن المخاطر. #baby $BABY
الجميع يتحدث عن BabylonLabs وأن BTC الأصلية أصبحت تحقق عوائد، لكنني قلبت البيانات والإعلانات والـمجتمع، فوجدت أن الناس يتجنبون عمداً واحداً من أهم الكلمات في ورقة بيضاء: آلية Slashing (الخصم/العقوبة).

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

آلية BABY هي كالتالي: يقوم مشارك/مُراهن BTC (staker) بتأمين الأصول داخل UTXO، ثم يُفوّض حقوق التحقق إلى مزوّد الإنهاء النهائي Finality Provider الذي يوفّر الإنهاء النهائي.

إذا قام Finality Provider بسلوك أمني شديد مثل التوقيع المزدوج Double Signing، فسيتم slashing على الـBTC التي تم تفويضها لهم.

هذا التصميم عبقري تقنياً، لأنه يقدّم لأول مرة لبيتكوين قدرة على فرض عقوبات اقتصادية بأسلوب PoS. لكن بالنسبة للمتداولين الصغار، فهو «صندوق أسود» من ناحية الثقة:

لا يمكنك التحقق من الكفاءة التقنية للـFinality Provider. كيف يعرف المتداول الصغير أن المُتحقق/المدقق لن يقوم بالتوقيع المزدوج بسبب تعطل الخوادم أو خلل في الكود أو هجوم من قراصنة؟ بمجرد وقوع الحادثة، يتحمل المُتحقق خسارة في السمعة فقط، بينما خسارتك أنت هي بيتكوين حقيقية وقابلة للقياس.

هذه هي عملية «الاستغلال» الثانية التي تقوم بها المؤسسات ضد المتداولين الصغار: لا يملك المتداول الصغير سوى بضع 0.1 BTC، ولا يملك أصلاً الأهلية لأن يصبح هو المدقق بنفسه.

كل ما يستطيع فعله هو التفويض إلى بروتوكولات LST مثل Lombard أو PumpBTC أو غيرها من مؤسسات الحراسة.

ووجدت أن هذا تحوّل إلى مشهد عبثي: كان من المفترض أن يُحل BABY مشكلة عدم وجود جسور وعدم وجود حراسة، لكن في النهاية يقوم المتداولون الصغار، من أجل كسب ذلك الـAPY، بتفويض صلاحية البيتكوين الأصلية نفسها إلى بروتوكول «وسيط».

دعونا نحسبها: عائد APY الخاص بـ BTC الأصلية المرهونة ما يزال في مرحلة Cap حالياً، لذا العائد الرسمي غير محدد. لنفترض أنه 3%-5% مقابل مخاطر sloshing/الـslashing لـ 0.1 BTC.

إذا حدث slashing، فقد تُخصم عملات BTC الخاصة بك مباشرة بنسبة 20% أو أكثر.

وهذا يعني أنك تحتاج إلى تشغيل بدون أعطال لمدة 5-10 سنوات كي تعوض خسارة تلك الحادثة.

برأيي الشخصي: مشاركة المتداولين الصغار في رهان BTC الخاص بـ BABY في جوهرها هي مقامرة على مخاطرة غير متكافئة.

أنا أقول هذا لنفسي: إذا لم أكن أملك ما لا يقل عن 1 BTC، فلن أتعامل مع هذا النوع «الطِقْسِي/الأصيل بالكامل» من آلية slashing. أفضل التعامل مع حلول L2 التي لديها جسور لكن نموذج العوائد واضح، على الأقل أعرف أين تكمن المخاطر.
#baby $BABY
·
--
صاعد
عرض الترجمة
今天我吃饱了没事干,去翻了翻Babylon的白皮书,有几个觉得有意思的点想跟大家分享一下。 白皮书的核心主题是通过比特币增强去中心化世界的安全性。 里面有个概念我觉得挺有意思,比特币时间戳协议。 简单说就是利用比特币网络的时间戳功能来给其他链提供安全验证。 我不记得是第三章还是第四章来着,详细讲了那个可提取一次性签名技术。 这个技术逻辑是这样的:你质押BTC的时候不需要把币转到别的链上,币始终留在比特币网络里你自己控制。 但如果你试图作恶,比如搞双重支付,这个签名机制会自动暴露你的私钥,质押的BTC就会被罚没。@babylonlabs_io 等于是用密码学来约束行为,挺巧妙的。 白皮书里还提到Babylon的愿景是把比特币从被动价值储存变成可编程的信任底座。这个表述我印象挺深,比特币这么多年一直是数字黄金,如果能真正激活它的生产力属性,那想象空间确实大。 说句实在话,我个人觉得Babylon这套技术逻辑确实有独到之处,a16z投了1500万美元也不是没道理的。 但技术再牛也得有人用才行,现在生态还在早期,能不能真正把比特币持有者吸引进来参与质押和借贷,这才是关键。我会继续观察,短期不打算加仓也不打算卖。 #baby $BABY
今天我吃饱了没事干,去翻了翻Babylon的白皮书,有几个觉得有意思的点想跟大家分享一下。

白皮书的核心主题是通过比特币增强去中心化世界的安全性。
里面有个概念我觉得挺有意思,比特币时间戳协议。
简单说就是利用比特币网络的时间戳功能来给其他链提供安全验证。

我不记得是第三章还是第四章来着,详细讲了那个可提取一次性签名技术。
这个技术逻辑是这样的:你质押BTC的时候不需要把币转到别的链上,币始终留在比特币网络里你自己控制。
但如果你试图作恶,比如搞双重支付,这个签名机制会自动暴露你的私钥,质押的BTC就会被罚没。@BabylonLabs_io
等于是用密码学来约束行为,挺巧妙的。

白皮书里还提到Babylon的愿景是把比特币从被动价值储存变成可编程的信任底座。这个表述我印象挺深,比特币这么多年一直是数字黄金,如果能真正激活它的生产力属性,那想象空间确实大。

说句实在话,我个人觉得Babylon这套技术逻辑确实有独到之处,a16z投了1500万美元也不是没道理的。
但技术再牛也得有人用才行,现在生态还在早期,能不能真正把比特币持有者吸引进来参与质押和借贷,这才是关键。我会继续观察,短期不打算加仓也不打算卖。
#baby $BABY
مشروع نيوتن… راقبته قرابة شهرين. في 23 يونيو تم إطلاق شبكة بيتا الرئيسية، وتم ربط RedStone وCredora كأول شركاء للتكامل مع البيانات، كما تم دفع VaultKit SDK بالتزامن. يمكن للمطورين تحديد حد الإنفاق، ومتطلبات الضمان وغيرها من القواعد — يبدو فعلاً أنه شيء قابل للاستخدام. $NEWT لكن في داخلي دائمًا شوكة عالقة، وهي طبقة TEE. تغلف الورقة البيضاء TEE وكأنها جدار نحاس وجدار حديد — عزلٌ عتادي — مع ZKP، فهذه تركيبة مثالية. كنت على وشك أن أنخدع أيضًا. إلى أن رأيت على KuCoin شخصًا قال جملة جعلتني أفيق فورًا: «trust the chip is still trust, just wearing a different hat». الثقة في الشريحة والاعتماد على جهة المشروع في جوهره مجرد تفويض للثقة إلى شيء لا تستطيع التحكم فيه. الشريحة تبدو متقدمة أكثر فقط. #Newt ما جعلني أرتجف حقًا من الداخل هو حادثة أكتوبر 2025. فريق بحثي من معهد جورجيا للتكنولوجيا وجامعة بوردو طور هجوم قنوات جانبية يُسمى TEE.Fail بتكلفة أقل من 1000 دولار. يستطيع استخراج مفاتيح التشفير من أنظمة DDR5 الخاصة بـ Intel TDX و AMD SEV-SNP. وبمجرد الحصول على المفتاح، يمكن للمهاجم تزوير تقارير إثبات صادرة عبر التحقق الرسمي. هذا يعني أن وكيلًا تم العبث به ما يزال بإمكانه توليد «كل شيء على ما يرام» من الإثباتات عن بُعد، ويأخذ عقد السلسلة كل ما يلزم دون أن تلاحظ أن أحدًا قد عبث بالداخل. وهذا لا يزال على مستوى العتاد فقط. يعمل Newton في بيئة سحابية على Phala، وفي المرحلة الأولى تتولى المؤسسة الخادمات الخاصة بـ TEE. 10 مدققين يحملون 73% من الرهان — بضعة عقد فقط يمكنها تحديد مسار الشبكة بالكامل. وفي 24 يوليو توجد جولة أخرى لإطلاق الاستحقاق. @NewtonProtocol الاتجاه صحيح، لكن إذا لم يتم حل مشكلة الثقة العتادية الأساسية فلن ينخفض تركّز المدققين. لن أضع أموالًا حقيقية فيه قبل ذلك. عندما يتمكن من التحويل الفوري بين TEE من عدة شركات، وتكون نسبة المدققين من المجتمع تتجاوز النصف، عندها يمكن الكلام. في هذه المرحلة، سأراقب فقط، دون حركة. {future}(NEWTUSDT)
مشروع نيوتن… راقبته قرابة شهرين. في 23 يونيو تم إطلاق شبكة بيتا الرئيسية، وتم ربط RedStone وCredora كأول شركاء للتكامل مع البيانات، كما تم دفع VaultKit SDK بالتزامن. يمكن للمطورين تحديد حد الإنفاق، ومتطلبات الضمان وغيرها من القواعد — يبدو فعلاً أنه شيء قابل للاستخدام. $NEWT

لكن في داخلي دائمًا شوكة عالقة، وهي طبقة TEE.

تغلف الورقة البيضاء TEE وكأنها جدار نحاس وجدار حديد — عزلٌ عتادي — مع ZKP، فهذه تركيبة مثالية. كنت على وشك أن أنخدع أيضًا. إلى أن رأيت على KuCoin شخصًا قال جملة جعلتني أفيق فورًا: «trust the chip is still trust, just wearing a different hat».

الثقة في الشريحة والاعتماد على جهة المشروع في جوهره مجرد تفويض للثقة إلى شيء لا تستطيع التحكم فيه. الشريحة تبدو متقدمة أكثر فقط. #Newt

ما جعلني أرتجف حقًا من الداخل هو حادثة أكتوبر 2025. فريق بحثي من معهد جورجيا للتكنولوجيا وجامعة بوردو طور هجوم قنوات جانبية يُسمى TEE.Fail بتكلفة أقل من 1000 دولار. يستطيع استخراج مفاتيح التشفير من أنظمة DDR5 الخاصة بـ Intel TDX و AMD SEV-SNP.

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

هذا يعني أن وكيلًا تم العبث به ما يزال بإمكانه توليد «كل شيء على ما يرام» من الإثباتات عن بُعد، ويأخذ عقد السلسلة كل ما يلزم دون أن تلاحظ أن أحدًا قد عبث بالداخل.

وهذا لا يزال على مستوى العتاد فقط. يعمل Newton في بيئة سحابية على Phala، وفي المرحلة الأولى تتولى المؤسسة الخادمات الخاصة بـ TEE. 10 مدققين يحملون 73% من الرهان — بضعة عقد فقط يمكنها تحديد مسار الشبكة بالكامل. وفي 24 يوليو توجد جولة أخرى لإطلاق الاستحقاق. @NewtonProtocol

الاتجاه صحيح، لكن إذا لم يتم حل مشكلة الثقة العتادية الأساسية فلن ينخفض تركّز المدققين. لن أضع أموالًا حقيقية فيه قبل ذلك. عندما يتمكن من التحويل الفوري بين TEE من عدة شركات، وتكون نسبة المدققين من المجتمع تتجاوز النصف، عندها يمكن الكلام. في هذه المرحلة، سأراقب فقط، دون حركة.
مقالة
يبدو تفويض ما قبل التسوية في Newt رائعًا، لكن من يدفع ثمن بوابة العبور هذه؟في 23 يونيو، تم إطلاق بيتا الشبكة الرئيسية لـ Newton. في ذلك اليوم، قام RedStone بتوصيل بيانات الأسعار التي تم التحقق منها إلى طبقة التنفيذ الخاصة بسياسات Newton. كما تم إطلاق VaultKit SDK بشكل متزامن؛ ما يتيح للمطورين تحديد قواعد مثل حدود الإنفاق، ومتطلبات الضمان، وفحوصات الطرف المقابل. السرد التقني مكتمل للغاية——"طبقة تفويض معاملات السلسلة". إذ تمر المعاملة عبر غربال محرك الاستراتيجية قبل التسوية، ولا يُسمح بها إلا عند تحقق الامتثال. عندما تعالج Polymarket 3 مليارات دولار من حجم المعاملات في يوم واحد، تكون طبقة التنفيذ الاستراتيجية لدى Newton تعمل في الخلفية. وقد جمع Magic Labs ما يناهز 90 مليون دولار من التمويل التراكمي، مع دعم من PayPal Ventures وPolygon.

يبدو تفويض ما قبل التسوية في Newt رائعًا، لكن من يدفع ثمن بوابة العبور هذه؟

في 23 يونيو، تم إطلاق بيتا الشبكة الرئيسية لـ Newton. في ذلك اليوم، قام RedStone بتوصيل بيانات الأسعار التي تم التحقق منها إلى طبقة التنفيذ الخاصة بسياسات Newton. كما تم إطلاق VaultKit SDK بشكل متزامن؛ ما يتيح للمطورين تحديد قواعد مثل حدود الإنفاق، ومتطلبات الضمان، وفحوصات الطرف المقابل.
السرد التقني مكتمل للغاية——"طبقة تفويض معاملات السلسلة". إذ تمر المعاملة عبر غربال محرك الاستراتيجية قبل التسوية، ولا يُسمح بها إلا عند تحقق الامتثال. عندما تعالج Polymarket 3 مليارات دولار من حجم المعاملات في يوم واحد، تكون طبقة التنفيذ الاستراتيجية لدى Newton تعمل في الخلفية. وقد جمع Magic Labs ما يناهز 90 مليون دولار من التمويل التراكمي، مع دعم من PayPal Ventures وPolygon.
·
--
صاعد
كنت أعمل على التمرير عبر X عندما رأيت أن TGE الخاصة بـ GRVT محدد بتاريخ 21 يوليو. ظهر إشعار رسمي، ضغطت عليه وألقيت نظرة، ثم مررت بعيدًا. بصراحة، لم أشعر بأي حماس. ليس لأنني لا أهتم، لكنني كنت أنتظر كثيرًا لدرجة أن الأمور لم تعد تُثير أي رد فعل. ذكر في البداية أنها ستحدث في الربع الأول من 2026، ثم تم تعديلها إلى نهاية يونيو، وبعدها إلى يوليو، وأخيرًا تم تثبيتها في 21 يوليو. أربع مرات من التصريحات، وثلاثة إصدارات. كل مرة يتم تأجيلها يكون لها سبب: مثل تعديل الموعد، تحسين التوزيع، وتمديد الموسم الثاني… كل سبب وحده يبدو منطقيًا، لكن عندما نجمعها معًا، جعلتني أشعر بالاستياء قليلًا. عند أول تأجيل، كان في المجتمع من يعبّر عن فهمه. @grvt_io ثم في التأجيل الثاني، بدأت تظهر شكوك. في المرة الثالثة، لم يحدث تقريبًا أي ضجة في المجتمع. بل إنني أيضًا أجريت تفاعلات، وادخرت أموالًا، وكان لدي نقاط؛ حقًا لقد مللت من الانتظار! لكن خلال هذه الفترة، المشروع قام فعلًا بأشياء كثيرة. نسبة الـ Airdrop ارتفعت من 22% إلى 28%، وارتفع TVL من 11.30 مليون دولار إلى 107.1 مليون دولار، وتم إطلاق التداول الفوري على الشبكة الرئيسية، كما تم دمج بروتوكول الإقراض من Aave. المنتج يتطور، والبيانات ترتفع. كل هذا رأيته ولا أنكر ذلك. لكن المشكلة أن تطوير المنتج شيء، وTGE شيء آخر. امتلاك منتج جيد لا يعني أنه يمكنك تغيير موعد الإطلاق مرارًا وتكرارًا. كل تعديل هو بمثابة استهلاك لصبر الأشخاص الذين انتظروا نصف سنة. الآن كل ما آمله هو أن يتم إطلاقه بنجاح هذه المرة في 21. وإذا كان GRVT سيتحقق إطلاقه فعليًا، هل يمكن للسعر أن يصمد؟ أتمنى أن يكون هناك نوع من الرؤية الكبيرة! #grvt
كنت أعمل على التمرير عبر X عندما رأيت أن TGE الخاصة بـ GRVT محدد بتاريخ 21 يوليو. ظهر إشعار رسمي، ضغطت عليه وألقيت نظرة، ثم مررت بعيدًا.

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

عند أول تأجيل، كان في المجتمع من يعبّر عن فهمه. @grvt_io ثم في التأجيل الثاني، بدأت تظهر شكوك. في المرة الثالثة، لم يحدث تقريبًا أي ضجة في المجتمع. بل إنني أيضًا أجريت تفاعلات، وادخرت أموالًا، وكان لدي نقاط؛ حقًا لقد مللت من الانتظار!

لكن خلال هذه الفترة، المشروع قام فعلًا بأشياء كثيرة. نسبة الـ Airdrop ارتفعت من 22% إلى 28%، وارتفع TVL من 11.30 مليون دولار إلى 107.1 مليون دولار، وتم إطلاق التداول الفوري على الشبكة الرئيسية، كما تم دمج بروتوكول الإقراض من Aave. المنتج يتطور، والبيانات ترتفع. كل هذا رأيته ولا أنكر ذلك. لكن المشكلة أن تطوير المنتج شيء، وTGE شيء آخر. امتلاك منتج جيد لا يعني أنه يمكنك تغيير موعد الإطلاق مرارًا وتكرارًا. كل تعديل هو بمثابة استهلاك لصبر الأشخاص الذين انتظروا نصف سنة.

الآن كل ما آمله هو أن يتم إطلاقه بنجاح هذه المرة في 21. وإذا كان GRVT سيتحقق إطلاقه فعليًا، هل يمكن للسعر أن يصمد؟ أتمنى أن يكون هناك نوع من الرؤية الكبيرة!
#grvt
فعالية الذكرى التاسعة الناجحة تم فتحها بالكامل! والأصدقاء الذين لم ينهوا بعد، تفضلوا بسرعة! في الذكرى السنوية القادمة سأظل إلى جانب باينانس! #BinanceTurns9
فعالية الذكرى التاسعة الناجحة تم فتحها بالكامل! والأصدقاء الذين لم ينهوا بعد، تفضلوا بسرعة! في الذكرى السنوية القادمة سأظل إلى جانب باينانس!
#BinanceTurns9
عن مستخدمي Magic Labs الـ 57 مليونًا والمطورين البالغ عددهم 200 ألف، كنت أنا أيضًا على وشك أن ينخدع به الأمر في البداية. بعد ذلك، راجعت البيانات على السلسلة بعناية وحسبت الأرقام خطوة بخطوة، وتبين لي أن هذه الأرقام لا تتطابق. عدد مستخدمي المحافظ البالغ 57 مليونًا لدى Magic Labs هو إجمالي عدد المستخدمين الناتج عن قيام حزمة SDK الخاصة بها بالمحافظ المدمجة بالاندماج داخل مختلف التطبيقات. قد يكون هؤلاء المستخدمون يستخدمون تطبيقًا متكاملًا مع Magic Wallet، ومعظمهم لا يعرف حتى أنه يستخدم تقنية Magic، ناهيك عن معرفة اسم Newton Protocol. وينطبق الأمر نفسه على الـ 200 ألف مطور: فهي إجمالي عدد المطورين الذين قاموا بالتسجيل ضمن شبكة منتجات Magic Labs واستخدموا أي واحد من SDKs ضمن مصفوفة منتجاتها. وهذا لا يعني عدد المطورين الذين قاموا بالفعل بدمج Newton لتنفيذ طبقة الاستراتيجية بشكل نشط.@NewtonProtocol حجم مستخدمي الشركة الأم، ومعدل التبني الحقيقي لبروتوكول الفرع—لا توجد أي مادة منشورة بشكل علني توضح علاقة التحويل بين هذين الأمرين. أعلنت Magic Labs بالفعل في نوفمبر 2025 أنها ستدمج Newton SDK داخل شبكة مطوريها، لكن الفرق بين “الإعلان عن التكامل” و“المطورون يستخدمون بالفعل” يكمن في مرحلة تنفيذ كاملة كاملة. إن درجة التبني الحقيقية لـ Newton Protocol نفسها تعتمد على مؤشرين: عدد البروتوكولات المستقلة التي قامت بدمج طبقة استراتيجية Newton بشكل فعّال، وكمية الاستدعاءات الحقيقية على طبقة العقود الخاصة بـ Newton. هذان الرقمان ليسا لهما أي صلة مباشرة بحجم مستخدمي Magic Labs. منطق الطلب الذي بُنيت عليه $NEWT قائم على مستوى استخدام Newton Protocol نفسه، وليس على حجم العلامة التجارية الخاص بـ Magic Labs. إن 57 مليون مستخدم لدى Magic Labs هم مخزون سابق (عدد قائم)، أما ما الذي يمكن لـ Newton أن يستحوذ عليه فهو موضوع آخر. هل يمكن تحويل حجم “الأصل الأم” مباشرة إلى قيمة لبروتوكول الفرع؟ ما زلت أتابع البحث في هذه النقطة. ما رأيكم؟ #newt $NEWT
عن مستخدمي Magic Labs الـ 57 مليونًا والمطورين البالغ عددهم 200 ألف، كنت أنا أيضًا على وشك أن ينخدع به الأمر في البداية.

بعد ذلك، راجعت البيانات على السلسلة بعناية وحسبت الأرقام خطوة بخطوة، وتبين لي أن هذه الأرقام لا تتطابق. عدد مستخدمي المحافظ البالغ 57 مليونًا لدى Magic Labs هو إجمالي عدد المستخدمين الناتج عن قيام حزمة SDK الخاصة بها بالمحافظ المدمجة بالاندماج داخل مختلف التطبيقات. قد يكون هؤلاء المستخدمون يستخدمون تطبيقًا متكاملًا مع Magic Wallet، ومعظمهم لا يعرف حتى أنه يستخدم تقنية Magic، ناهيك عن معرفة اسم Newton Protocol.

وينطبق الأمر نفسه على الـ 200 ألف مطور: فهي إجمالي عدد المطورين الذين قاموا بالتسجيل ضمن شبكة منتجات Magic Labs واستخدموا أي واحد من SDKs ضمن مصفوفة منتجاتها. وهذا لا يعني عدد المطورين الذين قاموا بالفعل بدمج Newton لتنفيذ طبقة الاستراتيجية بشكل نشط.@NewtonProtocol

حجم مستخدمي الشركة الأم، ومعدل التبني الحقيقي لبروتوكول الفرع—لا توجد أي مادة منشورة بشكل علني توضح علاقة التحويل بين هذين الأمرين. أعلنت Magic Labs بالفعل في نوفمبر 2025 أنها ستدمج Newton SDK داخل شبكة مطوريها، لكن الفرق بين “الإعلان عن التكامل” و“المطورون يستخدمون بالفعل” يكمن في مرحلة تنفيذ كاملة كاملة.

إن درجة التبني الحقيقية لـ Newton Protocol نفسها تعتمد على مؤشرين: عدد البروتوكولات المستقلة التي قامت بدمج طبقة استراتيجية Newton بشكل فعّال، وكمية الاستدعاءات الحقيقية على طبقة العقود الخاصة بـ Newton. هذان الرقمان ليسا لهما أي صلة مباشرة بحجم مستخدمي Magic Labs. منطق الطلب الذي بُنيت عليه $NEWT قائم على مستوى استخدام Newton Protocol نفسه، وليس على حجم العلامة التجارية الخاص بـ Magic Labs. إن 57 مليون مستخدم لدى Magic Labs هم مخزون سابق (عدد قائم)، أما ما الذي يمكن لـ Newton أن يستحوذ عليه فهو موضوع آخر. هل يمكن تحويل حجم “الأصل الأم” مباشرة إلى قيمة لبروتوكول الفرع؟ ما زلت أتابع البحث في هذه النقطة.

ما رأيكم؟
#newt $NEWT
مقالة
سرد «الأتمتة الآلية» لـNewton: عندما يبدأ الكود بالتحكم فيك، من الذي يتكفّل بك؟في 23 يونيو، تم إطلاق بيتا للشبكة الرئيسية لـNewton. وفي اليوم نفسه، تم طرح VaultKit SDK بالتزامن؛ إذ يمكن للمطورين تحديد حدود الإنفاق ومتطلبات الضمان وفحوصات الطرف المقابل وغيرها من القواعد. وفي اليوم ذاته أيضاً، قام RedStone بتوصيل بيانات الأسعار التي تم التحقق منها إلى طبقة تنفيذ السياسات في Newton. السرد التقني مكتمل بالفعل—فالمعاملات تمر أولاً عبر «مصفاة» محرك الاستراتيجيات قبل التسوية، وكل تقييم يولّد إثباتاً موقّعاً، ما يكوّن سجلاً قابلاً للتدقيق. يغطي RedStone أكثر من 100 سلسلة، ولم تُبلَّغ حتى الآن عن أي حادثة خطأ تسعير. جمعت Magic Labs ما مجموعه 90 مليون دولار من التمويل، وتولّى كلّ من PayPal Ventures وPolygon دعمهما. يبدو الأمر كالإجابة القياسية لبنية تحتية امتثال على السلسلة.

سرد «الأتمتة الآلية» لـNewton: عندما يبدأ الكود بالتحكم فيك، من الذي يتكفّل بك؟

في 23 يونيو، تم إطلاق بيتا للشبكة الرئيسية لـNewton. وفي اليوم نفسه، تم طرح VaultKit SDK بالتزامن؛ إذ يمكن للمطورين تحديد حدود الإنفاق ومتطلبات الضمان وفحوصات الطرف المقابل وغيرها من القواعد. وفي اليوم ذاته أيضاً، قام RedStone بتوصيل بيانات الأسعار التي تم التحقق منها إلى طبقة تنفيذ السياسات في Newton.
السرد التقني مكتمل بالفعل—فالمعاملات تمر أولاً عبر «مصفاة» محرك الاستراتيجيات قبل التسوية، وكل تقييم يولّد إثباتاً موقّعاً، ما يكوّن سجلاً قابلاً للتدقيق. يغطي RedStone أكثر من 100 سلسلة، ولم تُبلَّغ حتى الآن عن أي حادثة خطأ تسعير. جمعت Magic Labs ما مجموعه 90 مليون دولار من التمويل، وتولّى كلّ من PayPal Ventures وPolygon دعمهما. يبدو الأمر كالإجابة القياسية لبنية تحتية امتثال على السلسلة.
·
--
صاعد
在翻 @grvt_io 的白皮书时,有个细节一直让我琢磨不透。绝大多数交易协议都把去中心化当成头号招牌,而 GRVT 的官方文档却翻来覆去地讲做市商准入规则、风险引擎参数和清算模型等。 一开始我以为只是受众不同,后来把 Hybrid Exchange 的架构图看了好几遍,才意识到它瞄准的根本不是散户市场。 我认为对于有持续对冲或套利需求的专业交易者来说,资产自托管只是基础门槛。他们更在意的是订单簿能不能接住大额单子、滑点能不能控制住、行情剧烈时系统会不会卡顿。 这些问题在传统 CEX 里靠中心化服务器解决,代价是交出私钥;在纯 DEX 里靠链上撮合,速度和深度却始终上不去。 我看了一下 GRVT 的做法是把这两层剥离开。撮合引擎放在链下,每秒处理上万笔订单,保证和中心化平台同级别的响应速度;每笔成交后,系统把交易数据压缩成零知识证明,提交到 ZKsync 的结算层。 任何第三方都能验证交易真实性,但没人能动用用户资产。 订单簿由专业做市商维护,普通用户也能享受到更窄的点差,速度交给高性能服务器,安全交给可验证的数学。 然而更让我意外的是它对合规的态度。大多数 DeFi 项目对监管避之不及,GRVT 却主动拿下了百慕大和立陶宛的牌照,还在推进更多司法管辖区的许可。 这不是为了应付检查,而是为了让做市商和机构资金敢放心进来,因为有监管背书,法币通道才能打通,流动性深度才能上去,而不是等出事再补救,这个也是正是我看好的一个重点。 所以 GRVT 最让我感兴趣的地方,不是它比谁更去中心化,也不是比谁更快,而是它把过去互斥的几个目标,效率、安全、合规、控制权——放进同一套系统里各自运转。 我觉得这条路能不能走通还得看后续表现,和 21 号上线后币价的表现!#grvt
在翻 @grvt_io 的白皮书时,有个细节一直让我琢磨不透。绝大多数交易协议都把去中心化当成头号招牌,而 GRVT 的官方文档却翻来覆去地讲做市商准入规则、风险引擎参数和清算模型等。
一开始我以为只是受众不同,后来把 Hybrid Exchange 的架构图看了好几遍,才意识到它瞄准的根本不是散户市场。

我认为对于有持续对冲或套利需求的专业交易者来说,资产自托管只是基础门槛。他们更在意的是订单簿能不能接住大额单子、滑点能不能控制住、行情剧烈时系统会不会卡顿。
这些问题在传统 CEX 里靠中心化服务器解决,代价是交出私钥;在纯 DEX 里靠链上撮合,速度和深度却始终上不去。

我看了一下 GRVT 的做法是把这两层剥离开。撮合引擎放在链下,每秒处理上万笔订单,保证和中心化平台同级别的响应速度;每笔成交后,系统把交易数据压缩成零知识证明,提交到 ZKsync 的结算层。
任何第三方都能验证交易真实性,但没人能动用用户资产。
订单簿由专业做市商维护,普通用户也能享受到更窄的点差,速度交给高性能服务器,安全交给可验证的数学。

然而更让我意外的是它对合规的态度。大多数 DeFi 项目对监管避之不及,GRVT 却主动拿下了百慕大和立陶宛的牌照,还在推进更多司法管辖区的许可。
这不是为了应付检查,而是为了让做市商和机构资金敢放心进来,因为有监管背书,法币通道才能打通,流动性深度才能上去,而不是等出事再补救,这个也是正是我看好的一个重点。

所以 GRVT 最让我感兴趣的地方,不是它比谁更去中心化,也不是比谁更快,而是它把过去互斥的几个目标,效率、安全、合规、控制权——放进同一套系统里各自运转。
我觉得这条路能不能走通还得看后续表现,和 21 号上线后币价的表现!#grvt
تم بناء Newton Protocol على أساس EigenLayer AVS، وهذا يتيح له عدم الاضطرار إلى إنشاء شبكة مدققين من الصفر، بل يَرِث مباشرةً الأمان الاقتصادي لإيثريوم. هذا الاختصار وفّر التكاليف، لكنه أيضًا ثبّت نقطة الارتكاز للمخاطر على ظهر سفينة EigenLayer. يعيش قطاع إعادة الرهن مرحلة «أزمة منتصف العمر» عميقة. فقد بدأ السوق يشكك بعمق في الجدوى التجارية ونُظم الاستقرار لنموذج «الأمان المشترك». تكمن المشكلة الأساسية في أن الأمان الاقتصادي عالي المستوى لم يتم «استخدامه بالضرورة». ورغم أن أبرز AVS قامت بتجميد كميات هائلة من ETH — أكثر من 4 ملايين لدى EigenDA، و3.49 ملايين لدى Cyber — فإن الأصول القابلة للعقاب بقيت لفترة طويلة عند الصفر، ولم تخضع ضمانات الأمان قط لاختبار هجوم حقيقي. نفس أصل الرهن يوفّر في الوقت نفسه دعم التحقق لعدة بروتوكولات، ما يؤدي إلى تآكل القدرة الفعلية لكل وحدة أصل على مقاومة الهجمات باستمرار. وبصفته @NewtonProtocol كـ AVS، فإن «الأمان» المشترك قد يكون في الظروف القصوى أضعف بكثير مما توحي به الأرقام على الورق. في يونيو 2025، تم العثور على خطأ قسمة على صفر في حساب مكافآت EigenLayer sidecar، وقد يؤدي ذلك إلى حجب الخدمة عن جميع AVS والمشغّلين. وإذا ظهرت ثغرة مماثلة في عقود restaking الأساسية، فإن التأثير سيتحوّل عبر سلسلة الاعتماد ليصل إلى #Newt . السلطة في عقد التحقق شديدة التركّز. فالعُقد الكبرى تحصل على أولوية في تعاون AVS بسبب العلامة التجارية ورأس المال، وتجاوزت حصة EigenCloud السوقية 60%. وإذا انسحب أحد كبار المشغلين في EigenLayer أو واجه مشكلة، فقد يزداد وقت تجميع الإجماع في Newton بشكل ملحوظ، كما ستزداد مباشرةً مهلة التحقق من السياسات. الـ Slashing (المصادرة/الجزاء) سلاح ذو حدين. فقد تم تفعيل slashing على الشبكة الرئيسية لـ EigenLayer في أبريل 2025، ويمكن لـ AVS معاقبة المشغلين المخالفين اقتصاديًا. لكن خطأ مدقق واحد قد يفعّل العقوبة على كل خدمة كان يضمنها. وإذا تعرّض المشغّل إلى slash في AVS أخرى، فإن قدرته على الرهن على Newton ستنخفض أيضًا. إن أمان $NEWT ليس مستقلًا عن منظومة EigenLayer، بل مرتبط بصحة نظام إعادة الرهن بأكمله. برأيي، كان اختيار EigenLayer restaking خطوة منطقية لبدء Newton بسرعة، لكن قاعدة الأمان مبنية فوق بروتوكول آخر معقّد، وهذا «safe» مشروط. Newton حاليًا ليس سوى AVS ضمن منظومة EigenLayer، وتتقلب قدرته الأمنية مع تقلب المنظومة ككل.
تم بناء Newton Protocol على أساس EigenLayer AVS، وهذا يتيح له عدم الاضطرار إلى إنشاء شبكة مدققين من الصفر، بل يَرِث مباشرةً الأمان الاقتصادي لإيثريوم. هذا الاختصار وفّر التكاليف، لكنه أيضًا ثبّت نقطة الارتكاز للمخاطر على ظهر سفينة EigenLayer.

يعيش قطاع إعادة الرهن مرحلة «أزمة منتصف العمر» عميقة. فقد بدأ السوق يشكك بعمق في الجدوى التجارية ونُظم الاستقرار لنموذج «الأمان المشترك». تكمن المشكلة الأساسية في أن الأمان الاقتصادي عالي المستوى لم يتم «استخدامه بالضرورة». ورغم أن أبرز AVS قامت بتجميد كميات هائلة من ETH — أكثر من 4 ملايين لدى EigenDA، و3.49 ملايين لدى Cyber — فإن الأصول القابلة للعقاب بقيت لفترة طويلة عند الصفر، ولم تخضع ضمانات الأمان قط لاختبار هجوم حقيقي.

نفس أصل الرهن يوفّر في الوقت نفسه دعم التحقق لعدة بروتوكولات، ما يؤدي إلى تآكل القدرة الفعلية لكل وحدة أصل على مقاومة الهجمات باستمرار. وبصفته @NewtonProtocol كـ AVS، فإن «الأمان» المشترك قد يكون في الظروف القصوى أضعف بكثير مما توحي به الأرقام على الورق.

في يونيو 2025، تم العثور على خطأ قسمة على صفر في حساب مكافآت EigenLayer sidecar، وقد يؤدي ذلك إلى حجب الخدمة عن جميع AVS والمشغّلين. وإذا ظهرت ثغرة مماثلة في عقود restaking الأساسية، فإن التأثير سيتحوّل عبر سلسلة الاعتماد ليصل إلى #Newt .

السلطة في عقد التحقق شديدة التركّز. فالعُقد الكبرى تحصل على أولوية في تعاون AVS بسبب العلامة التجارية ورأس المال، وتجاوزت حصة EigenCloud السوقية 60%. وإذا انسحب أحد كبار المشغلين في EigenLayer أو واجه مشكلة، فقد يزداد وقت تجميع الإجماع في Newton بشكل ملحوظ، كما ستزداد مباشرةً مهلة التحقق من السياسات.

الـ Slashing (المصادرة/الجزاء) سلاح ذو حدين. فقد تم تفعيل slashing على الشبكة الرئيسية لـ EigenLayer في أبريل 2025، ويمكن لـ AVS معاقبة المشغلين المخالفين اقتصاديًا. لكن خطأ مدقق واحد قد يفعّل العقوبة على كل خدمة كان يضمنها. وإذا تعرّض المشغّل إلى slash في AVS أخرى، فإن قدرته على الرهن على Newton ستنخفض أيضًا. إن أمان $NEWT ليس مستقلًا عن منظومة EigenLayer، بل مرتبط بصحة نظام إعادة الرهن بأكمله.

برأيي، كان اختيار EigenLayer restaking خطوة منطقية لبدء Newton بسرعة، لكن قاعدة الأمان مبنية فوق بروتوكول آخر معقّد، وهذا «safe» مشروط. Newton حاليًا ليس سوى AVS ضمن منظومة EigenLayer، وتتقلب قدرته الأمنية مع تقلب المنظومة ككل.
مقالة
البرهان جديد، والتهيئة قديمة—ثغرة أمان Newton ليست في المعرفة الصفريةالتهيئة تحدد الصلاحيات، لكن إذا أخطأت سطرًا واحدًا، فإن برهان ZK لن يفعل سوى “ختم” ذلك الخطأ لك. عند إطلاق بيتا الشبكة الرئيسية لـNewton، كان جوهر الرسائل الترويجية هو: “تفويض قابل للتحقق”. قبل أن ينفذ وكيل ذكاء اصطناعي أي إجراء، يجب أن يمر عبر التحقق من خلال محرك السياسات، وتنتج كل عملية تحقق برهانًا لا يمكن العبث به. يحدد المستخدمون حدود سلوك الوكلاء عبر zkPermissions، بما في ذلك حد الأموال، وقوائم العمليات المسموح بها، ومدّة الجلسة، وفترة التداول… عشرات المعلمات، ووثائق الـSDK تتجاوز 140 صفحة. منطق هذه المجموعة جميل فعلًا على الورق: قواعد الصلاحيات تُشفَّر إلى دائرة برهان معرفة صفرية، والنظام يفرضها إجباريًا، ويمكن تدقيقها لاحقًا. لا يحتاج المطورون لكتابة عقود ذكية؛ كل ما عليهم هو ضبط المعلمات.

البرهان جديد، والتهيئة قديمة—ثغرة أمان Newton ليست في المعرفة الصفرية

التهيئة تحدد الصلاحيات، لكن إذا أخطأت سطرًا واحدًا، فإن برهان ZK لن يفعل سوى “ختم” ذلك الخطأ لك.
عند إطلاق بيتا الشبكة الرئيسية لـNewton، كان جوهر الرسائل الترويجية هو: “تفويض قابل للتحقق”. قبل أن ينفذ وكيل ذكاء اصطناعي أي إجراء، يجب أن يمر عبر التحقق من خلال محرك السياسات، وتنتج كل عملية تحقق برهانًا لا يمكن العبث به. يحدد المستخدمون حدود سلوك الوكلاء عبر zkPermissions، بما في ذلك حد الأموال، وقوائم العمليات المسموح بها، ومدّة الجلسة، وفترة التداول… عشرات المعلمات، ووثائق الـSDK تتجاوز 140 صفحة.
منطق هذه المجموعة جميل فعلًا على الورق: قواعد الصلاحيات تُشفَّر إلى دائرة برهان معرفة صفرية، والنظام يفرضها إجباريًا، ويمكن تدقيقها لاحقًا. لا يحتاج المطورون لكتابة عقود ذكية؛ كل ما عليهم هو ضبط المعلمات.
سجّل الدخول لاستكشاف المزيد من المُحتوى
انضم إلى مُستخدمي العملات الرقمية حول العالم على Binance Square
⚡️ احصل على أحدث المعلومات المفيدة عن العملات الرقمية.
💬 موثوقة من قبل أكبر منصّة لتداول العملات الرقمية في العالم.
👍 اكتشف الرؤى الحقيقية من صنّاع المُحتوى الموثوقين.
البريد الإلكتروني / رقم الهاتف
خريطة الموقع
تفضيلات ملفات تعريف الارتباط
شروط وأحكام المنصّة