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