مستثمر قديم في عالم العملات الرقمية منذ تسع سنوات، لا أتعامل بالصفقات، ولا أشارك في العقود، أستمتع بجني الأرباح بأمان، وسأشارك معلومات متنوعة حول استراتيجيات جني الأرباح على السلاسل في غرفة الدردشة، ومناقشة توقعات حدود الدخول في المنافسات التجارية، ودروس مختلفة على الهاتف المحمول لـ seeker. مرحبًا بك في منزل مياو مياو الخاص بـ西西斯~ في صفحة المحفظة، أدخل رمز الدعوة "XIXISI"، واستمتع بخصم 25% على رسوم معاملات المحفظة، بالنسبة للأصدقاء الذين يستخدمون المحفظة بشكل متكرر لإجراء المعاملات، فإن الخصم على الرسوم يمكن أن يقلل من التآكل مباشرة.
لقد قمتُ باختبار TBV على شبكة الاختبار أمس عبر الرقم @BabylonLabs_io ، وبمجرد أن أتممتُ كل الخطوات أدركتُ بعمق: لكي تحصل على ثقة مطلقة، عليك أن تدفع بالوقت. قفلتُ 0.05 BTC من شبكة الاختبار داخل النظام، وكانت العمليات في البداية سلسة للغاية؛ حتى أنني جهزتُ المحفظة، واخترتُ بروتوكول إقراض DeFi ضمن الطليعة، ثم وقّعتُ على سكربت Taproot، وانتهيت خلال ثلاث دقائق. لكن عندما حاولتُ محاكاة التصفية، جعلني التنبيه الذي ظهر أمامي أُفكر طويلًا: تأخير السحب قد يستغرق من عدة ساعات إلى يوم كامل أو يومين. هذا يعني أنه عندما تكون الضمانات على وشك التصفية القسرية، لا يعطيك النظام تصفية فورية، بل يسحب فعليًا “فترة تهدئة”. $BABY بعد أن قلبتُ صفحات وثائق Babylon لفهم التفاصيل، عرفتُ أن هذا التأخير مُصمم ليتماشى مع فترة تحدّي BitVM، ليوفّر للمُتحدّين الوقت كي يقدّموا أدلة احتيال. من الناحية التقنية كل شيء مثالي، لكن عند إسقاطه في سياق DeFi يصبح الأمر محرجًا جدًا. إذا حدث هبوط كارثي شديد في الإقراض بمعدل فائدة عائم، فحتى لو تأخرت التصفية لبضع ساعات، فإن $BTC والـ stablecoin كانا سينفصلان عن الوتيرة (脱锚) من زمان. لذلك لا عجب أن كبار القدماء في الدائرة يقولون إن TBV مناسب بطبيعته لمنتجات الفائدة الثابتة. فتتبعتُ الأمر: عدة DApps رئيسية في النظام البيئي تدفع بقوة نحو الإقراض بدورات ثابتة، وهذه المنطقية تُغلق الدائرة بالكامل. وهناك إعداد “مُحدد مُسبقًا للمُسحِب” (预设提款人) بحرفية عالية. عند إنشاء صندوق الخزينة (Vault)، يجب تثبيت عنوان يمكنه سحب العملات كتابةً بشكل صارم. هذا يوفّر أمانًا بمستوى هوسٍ قهري، لكنه يجعل السيولة جامدة كالحجر. تريد تغيير بروتوكول يقدم عائدًا أعلى؟ عليك أولًا سداد القرض، ثم إغلاق الخزنة، ثم إعادة إنشاء كل شيء من الصفر. كل خطوة من هذه الخطوات تستهلك Gas على شبكة Bitcoin! ومع ازدحام الشبكة، قد تصل التكلفة إلى عشرات الدولارات في المرة الواحدة، وهو ما لا يُطاق بالنسبة للاعبين برؤوس أموال صغيرة. #baby كثيرون ينتقدون أن TBV أبطأ بكثير من WBTC المُركزي. لكنني أعتقد أن Babylon لم يكن أصلًا يريد منافسة التداول عالي التردد؛ بل يعمل على “تقطيع” السوق بدقة. بالنسبة لهواة الاحتفاظ على المدى الطويل، فإن TBV هو ملاذ مثالي للامان. $RIVER أصول مستقرة تمامًا داخل سكربت مُوقّع من طرفك، دون أي مخاطرة بتفجر مؤسسي (بسبب انهيار جهة). ما يستهدفه هو تلك الأموال العاطلة التي تستقر لعشرات تريليونات الدولارات في محافظ باردة؛ هؤلاء الكبار لا يبالون بالانتظار يومًا إضافيًا، فهم يبالون أكثر بالأمان المطلق الذي تُمسك فيه مفتاحك الخاص بإحكام.
عندما تُشيَّد ناطحات السحاب، يحب الجميع أن يرفعوا أعينهم إلى القمم المبهرة، بينما لا يهتم إلا القليلون بما يكفي بعمق الأساسات التي تُدفن تحت الأرض. وينطبق الشيء نفسه على اللامركزية في عالم التشفير: إنها ليست محرّكًا دائمًا يعمل تلقائيًا لمجرد أن “يُبنى”. بل تحتاج إلى تدخل بشري حقيقي، وصيانة مستمرة على المدى الطويل. مؤخرًا كنت أقرأ الورقة البيضاء لمشروع @BabylonLabs_io ، وفي القسم التاسع حين تحدثت عن نشر متعدد السلاسل، ذكرت “عميل بيتكوين الخفيف” (light client) الذي يشبه جدار التحميل لهذه البناية. ما وظيفة هذا العميل الخفيف؟ لا يتعين عليه، مثل العقد الكاملة (full nodes)، أن يُحمِّل بشكل أحمق بيانات السجلّ الكامل بحجم مئات الجيجابايت. هو فقط يُزامن معلومات رؤوس الكتل (block headers)، ويستخدم إثبات ميركل (Merkl proof) للتأكد من أن $BTC الخاص بك موجود فعلًا ومُقيّد داخل الخزنة. فكلما أردتَ سكّ (mint) collBTC أو إنشاء عملة مستقرة، يجب أن تمر من خلاله هذه الخطوة. بدون أن يراقب هؤلاء العملاء الخفيفون بأنفسهم، تتحول إثباتات الأصول عبر السلاسل كلها إلى وعود فارغة—مجرد تسويف في صورة “شيكات بدون رصيد”. لكن الواقع قاسٍ: كلما انضمت سلسلة جديدة، يتطلب ذلك إنشاء والحفاظ على مجموعة جديدة من عقد العملاء الخفيفين. هذه العقد تستهلك الكهرباء وتتكبد تكاليف الخوادم؛ الاعتماد على “حبّ العمل” وحده لن يدوم طويلًا. عندها يأتي دور اقتصاديات توكن $BABY في القسم العاشر من الورقة البيضاء. في المراحل المبكرة للمشروع، فإن إرسال توكن BABY إلى هذه العقد، في جوهره، هو دعم تشغيلي (operational subsidy) تقدمه الجهة الرسمية. وبعد أن يزدهر النظام البيئي تمامًا، فإن الرسوم $ETH الناتجة عن البروتوكول نفسه ستتولى المهمة، لتحدث التحوّل الرائع من “حرق المال لجذب الضجيج” إلى “الاعتماد على الذات والربح والخسارة”. لذا لا تظن أبدًا أن العميل الخفيف مجرد مكوّن برمجي غير لافت. فحين يُنسَج مئات أو عشرات العملاء الخفيفين عبر عشرات السلاسل معًا، فإن ذلك يشكّل أعتى خندق أمني لـ Babylon. يسأل الجميع عن القيمة الفعلية لـ #baby ، والحقيقة أن ما يثبته هو تكلفة الجهد التي يبذلها هؤلاء المراقبون في الطبقات السفلية ليلًا ونهارًا. في هذا المجال، تقليل الاعتماد على الثقة ليس شيئًا مجانيًا. التوكن هو الفاتورة التي ندفعها مقابل الأمن.
منذ وقت قريب رأيت في ساحة Binance الكثير من المشاركات التي تناقش @BabylonLabs_io ، والجميع يصرخ بأن BTC يمكن أن يتم «Slashing». لكن كل من لديه فهم ولو بسيط لطبقة البيتكوين الأساسية سيطرح سؤالًا حتميًا: شبكة البيتكوين الأساسية أصلًا لا تحتوي على عقد PoS، كما أن المعدّنين لا يعرفون أساسًا أي قواعد «تأمين/إيداع» (staking). فبماذا يمكن لـ Babylon أن يقتطع فعليًا من محفظتك $BTC على أرض الواقع؟ في البداية ظننت أيضًا أن هذا يتم عبر لجنة متعددة التوقيعات (multisig) التي تفرض التنفيذ قسرًا، لكن بعد أن قرأت بعناية ورقة Babylon التأسيسية في التشفير، فهمت أن السر الحقيقي هو EOTS. هذه الآلية، ببساطة، تشبه وضع جهاز تفجير ذاتي داخل قفل الباب. عندما يقوم FinalityProvider بالتصويت على كل بلوك، فإنه يجب أن يودع أولًا رقمًا عشوائيًا. وإذا تم توقيع سلسلتين مختلفتين على نفس ارتفاع البلوك، فهذا يعني إعادة استخدام السر العشوائي نفسه. ونتيجةً لذلك تحدث المعجزة الرياضية: يتم كشف مفتاح/مفاتيح خاصة العقدة فورًا على الملأ. هذه الخطوة التحويلية هي الجزء الأكثر «قسوة»! لا يحتاج Babylon أصلًا إلى تغيير إجماع شبكة البيتكوين الرئيسية ليجعلها تفهم عقوبات PoS، بل يسبق ذلك ويُرسم مسارات معاملة العقوبة بالكامل داخل نص (Taproot) مسبقًا. عندما تتعرض المفاتيح الخاصة للعقدة $ETH للانكشاف الذاتي بعد التوقيع المزدوج، تكون معاملة العقوبة التي كانت ناقصة بسبب غياب المفتاح غير قابلة للإرسال؛ لكن عندها تتوافر شروط التوقيع فجأة. وعندما يتم بثها إلى شبكة البيتكوين الرئيسية، لا ينظر المعدّنون إلا إلى صحة تنسيق المعاملة، ليتم اقتطاع $BABY فعليًا من الأصول. لذلك نقول إن الاختراق الأساسي في Babylon هو ترجمة مخالفات PoS خارج السلسلة (off-chain) بذكاء إلى مفاتيح خاصة للتوقيع يمكن لشبكة البيتكوين الرئيسية فهمها. ومع ذلك، هذا التصميم العتيد «سلاح ذو حدّين»: أي خطأ بسيط في برنامج عقد FP قد يؤدي إلى توقيع مزدوج عن طريق الخطأ، فتُقتل المفاتيح الخاصة على الفور. وعلى المدى الطويل، ليس الأهم في Babylon هو ما إذا كان يمكنه معاقبة المذنبين، بل ما إذا كان هذا التحويل التشفيري سيعمل بثبات واستقرار في الاستخدام الفعلي على الشبكة. #baby
يبدو أن الجميع مؤخرًا يتحدث عن BTCFi، وكثيرون ينظرون إلى عملية الإيداع عند #baby عبر التوقيع/الرهان كأنها وديعة لأجل في بنك؛ يدخلون الأموال ليحصدوا العائد، وعندما يريدون الخروج فقط يضغطون على خيار إلغاء القفل. لكن مؤخرًا ركزت بجد على الوثائق التقنية الخاصة بـ Babylon، واكتشفت أن الحقيقة ليست بهذه البساطة إطلاقًا مثل «سحب بنقرة واحدة». آلية الخروج هي الاختبار الحقيقي لوعي المستثمرين الصغار. عندما تدخل $BTC إلى حالة Staking، فأنت في الواقع تُقفل داخل سكريبت Taproot. إذا كنت تريد المغادرة مبكرًا، يجب عليك بدء معاملة Unbonding. وهذا ليس قرارًا بيدك وحدك؛ لا بد أن يصل CovenantCommittee إلى حد التوقيعات المطلوبة، وبعد ذلك فقط ستنتقل عملات $BABY الخاصة بك إلى حالة UnbondingUTXO جديدة، ثم تتابع الصبر خلال فترة قفل زمنية طويلة. أخطر الفخ هو ألا تعتقد أنك بمجرد دخول فترة Unbonding قد نجوت تمامًا! هذا السيناريو/السكريبت يحتفظ أيضًا بشروط تفعيل Slashing. إذا قام عقد FinalityProvider الذي فوّضت له—بسوء نية—بإجراء توقيعين مزدوجين، فإن آلية EOTS في الطبقة الأساسية ستكشف مفتاحك الخاص $ETH مباشرة بسبب إعادة استخدام الرقم العشوائي. وحتى ذلك الحين، حتى لو كنت واقفًا في طابور الخروج، فـ BTC الخاصة بك ستتعرض للعقوبة بلا رحمة من النظام. لذلك، حين تفهم المنطق الداخلي لـ @BabylonLabs_io ستدرك أن البيتكوين الكبير/Btc (bigger bagel) أصلًا لا توجد فيه مثل هذه آليات العقوبة المعقدة التي تضيفها PoS بهذه التعقيدات. Babylon استطاعت فعلًا تجميع هذه القواعد عبر UTXO وقفل زمني وتوقيعات متعددة. وبالنسبة للاعب العادي، في المستقبل لا تكتفِ بمراقبة مدى سلاسة مدخل/بداية الرهن؛ الشيء الذي يجب أن تزنَه فعلًا هو: عندما تضغط زر الخروج، ما نوع المخاطر التي تتحملها تجاه الانتظار بالفعل.
عند مناقشة المنتجات ذات الفائدة الثابتة، غالبًا ما ينصب التركيز على ما يحصل عليه المقترض. يتمكن المموّل من معرفة مصروفات الفائدة خلال كامل مدة القرض مسبقًا، ما يؤدي بالفعل إلى تقليل ضغوط الميزانية. لكن هناك طرف آخر في الصفقة: المُقرِض. إذ يُضيّع المُقرِض فرصة إعادة التسعير عندما ترتفع الفائدة بعد أن يقوم بتثبيت أمواله في عقد ثابت. إذا ارتفعت أسعار الفائدة في السوق خلال مدة العقد، يستمر المقترض في الاستفادة من تكلفته الأصلية، بينما تُقفل أموال المُقرِض على عائد أقل؛ وإذا انخفضت أسعار الفائدة في السوق $ETH خلال فترة العقد، فقد يحصل المُقرِض على ميزة نسبية. لا تُلغي الفائدة الثابتة المخاطر، بل تعيد توزيع تقلبات الفائدة بين طرفي الصفقة. ولكي تتشكل مجموعة Aegis وBabylon إلى سوق مستقرة، يجب أن تجذب في الوقت نفسه سيولة من الجانبين $BTC . لا تكفي الحاجة إلى الاقتراض وحدها دون وجود مُقرِضين راغبين في تحمل مخاطر مدة الالتزام؛ وإلا ستصبح عمق الأسعار غير كافٍ. كما أنه إذا تركز المُقرِضون على آجال قليلة، فمن الصعب على المقترض الحصول على تمويل مستمر. أتطلع إلى رؤية إمداد سيولة عبر آجال مختلفة، وقواعد الخروج المبكر، وترتيبات السيولة في السوق الثانوية. إن كان بإمكان المُقرِض تحويل مراكزه، وكم تبلغ تكلفة الخروج المبكر، وكيف يتم تسوية الأموال عند الاستحقاق—كل ذلك سيؤثر على مدى توفر السوق الثابت فعليًا. لذلك، أعتقد $BABY أن المسألة لا تتعلق فقط بما إذا كانت المؤسسات قادرة على تثبيت تكلفة الاقتراض. #baby بل يجب أيضًا إثبات أن جهة الدخل الثابت تتمتع بجاذبية وسيولة كافيتين. @BabylonLabs_io وإذا تمكن الطرفان—المقرض والمقترض—من فهم مخاطر الأجل التي يتحملانها بوضوح، فلن يبقى السوق مقتصرًا على جانب واحد من الطلب.
افترض أن مشروعًا خارجيًا قام بالاتصال لأول مرة بخدمة الأمان في Babylon، فقد يحصل على دعم تقني أو حصص اختبار أو موارد من النظام البيئي. تبرز هذه الشراكة أن المنتج يستوفي شروط الاتصال، لكنها لا تستطيع وحدها أن توضّح ما إذا كان العميل على استعداد لتحمّل تكلفة الاستخدام$BTC على المدى الطويل. اللحظة الأكثر قيمة بالمعلومات هي بعد انتهاء دورة الخدمة الأولى. ما إذا كان الطرف الآخر سيواصل الشراء، وما إذا كان سيُوسّع نطاق التغطية، وما إذا كان يعتزم التحول من دعم النظام البيئي إلى ميزانيته الخاصة—كل ذلك يحدد إن كانت العلاقة مجرد اختبار مشترك أم عملًا مستقرًا. @BabylonLabs_io يمكنه تقسيم تقدم التعاون إلى: إثبات المفهوم، إنتاج صغير الحجم، شراء رسمي، ثم تجديد مع توسيع. المراحل الأربع تقابل شدة احتياجات مختلفة تمامًا. إن نشر اسم التعاون فقط سيضع المشاريع التي ما زالت قيد الاختبار والعملاء الذين يدفعون باستمرار تحت نفس المؤشر. بالنسبة للدورة الاقتصادية$BABY ، فإن تجديد العقود من جهة الطلب يعد مهمًا بشكل خاص. مقدار الخدمات التي يمكن للمتحقق تقديمها يعتمد على عدد المشاريع الخارجية التي ترغب في الشراء؛ ومدة مشاركة المستخدم أيضًا ترتبط بما إذا كانت إيرادات الخدمة ستستمر في التدفق. ميزانية العميل أقرب إلى القوة الشرائية الحقيقية من مجرد حرارة منصات التواصل$ETH . لذلك، أرى أن#baby لن يَعُدّ المشاركين في الفعالية أولًا، بل سيبحث عن سجل التجديدات. التعاون الأول يوضح أن الفريق مستعد للتجربة، والتعاون الثاني المدفوع هو ما يثبت أن الخدمة تستحق الاستمرار. ما إذا كان بإمكان الشبكة توليد دخل لا يتحدد بطقوس الاتصال، بل يتحدد بالفاتورة التالية للعميل.
في نظام السكك الحديدية، لا يمكن لقطارين أن يعتمدا فقط على تقدير السائق لتحديد ما إذا كان بالإمكان المرور عبر نفس المقطع من المسار. ستقوم الإشارات وأنظمة الترابط (Interlocking) أولاً بفحص التحويلات (الدواليب/المرابط)، واحتلال المقاطع، وتعارض المسارات. ولا يتم السماح بفتح إشارة المرور إلا إذا كانت جميع الشروط متوافقة. يمكن أن تكون السرعة أبطأ قليلاً، لكن لا يجوز أن يكون الوضع ملتبساً. يمكن أيضاً النظر إلى قيود الزمن لدى Babylon باعتبارها مجموعة من الترابط بين الحالات. لا يجوز أن تتجه المشاركة والانتظار والإلغاء ومعالجة الاستثناء $ETH في الوقت نفسه إلى نتائج متعارضة فيما بينها. لا ينبغي أن يحصل أي إجراء تالٍ على حق التنفيذ إلا عندما تستوفي الحالة الحالية الشروط المحددة مسبقاً. لا تتمحور هذه الفكرة حول «إبقاء القفل لمدة أطول»، بل حول منع تجاوز الخطوات في سير العمل. لا يجوز للمستخدم أن يغادر مبكراً قبل انتهاء مسؤوليته، ولا يجوز للنظام أن يستمر في الحساب وفق الحالة القديمة بعد تفعيل الإلغاء. ما دامت الخطوات ثابتة بعد تثبيت الترتيب، يصبح سجل $BTC أكثر اتساقاً. تأتي الاختبارات الحقيقية عندما تصل عدة طلبات في نفس الوقت. يدخل شخص، ويخرج آخر، ويقوم أحدهم بتغيير المزوّد، وفي الوقت نفسه توجد بعض الحالات وهي بصدد التحقق من صحة الاستثناءات. يجب على @BabylonLabs_io ضمان تنفيذ هذه الإجراءات وفق ترتيب موحّد، وليس جعل الواجهة الأمامية والسجلات الأساسية تقدم إجابتين مختلفتين. لذلك، أعتقد أن #baby سيهتم بوضوح إمكانية ملاحظة تحوّلات الحالة. إذا تمكنت آلية $BABY من جعل كل مرحلة تحمل وسمًا واضحًا، والحفاظ على الاتساق حتى عند تجمّع الطلبات، فلن يكون قفل الزمن مجرد أداة انتظار، بل نظام جدولة يمنع تعارض السجلات.
الذي يريد USDB إثباته فعليًا ليس أنه يمكن سكّه، بل أنه يمكن استرداده. عند تقييم ما إذا كانت الأصول المستقرة على السلسلة موثوقة، لا تنظر أولًا إلى الاسم أو العائد. اسأل ثلاثة أمور حقيقية: $BTC من الذي يحتفظ به، من الذي يتحقق من شروط الاسترداد، ومن الذي يتحمل الخسارة في الحالات القصوى. @BabylonLabs_io الشيء المثير للاهتمام في ورقة USDB البيضاء ليس أنها تضيف ببساطة استخدامًا لـBTC، بل إنها تحاول نقل أساس الثقة من وعود المؤسسات إلى آليات ضمان قابلة للتحقق وسداد قابل للتحقق. وفقًا لتصوّر الورقة البيضاء، يتم إيداع BTC الخاص بالمستخدم في صندوق حراسة ذاتية على شبكة بيتكوين (self-custody)، ومن جهة أخرى تقوم البروتوكولات بقراءة حالة القفل على السلسلة ثم سك USDB. عند الاسترداد، يقوم المستخدم أولًا بإتلاف USDB، ثم يقدّم الدليل/الإثبات المناسب لفتح القفل وإطلاق الضمان. تقلّل هذه المعمارية الحاجة إلى تسليم BTC إلى جهة حراسة واحدة، لكن «قلة الثقة» لا تعني «انعدام المخاطر»: فتعطل أي حلقة—مثل سكربتات الصندوق (vault)، أو نظام الإثباتات، أو مزامنة حالة عبر السلاسل، أو إدارة المفاتيح—قد يؤدي إلى تعذّر الاسترداد. الاستقرار في النهاية يجب أن يصمد أمام ضغوط التصفية. عند تقلبات حادة في السوق، قد تتزامن تأخيرات الأوركل (الـoracles) مع نقص سيولة التصفية وازدحام الشبكة. عندها لم يعد السؤال مجرد ما إذا كانت نسبة الضمان كافية، بل ما إذا كان التنفيذ سيتمكن من الإتمام قبل تشكّل الديون المعدومة (bad debt). لذلك أنا أكثر اهتمامًا بـ4 معايير: خصم التصفية، وخطة تدهور/بدائل مصادر السعر، وترتيب الاسترداد عند الازدحام، ومن الذي يتحمل $ETH بسبب الديون المعدومة. إن كانت خارطة الطريق مكتوبة بشكل كامل، فهذا لا يعني أن هذه المشكلات قد تم التحقق منها فعليًا على أرض الواقع. $BABY كذلك ينبغي التمييز بين «الآلية» و«النتيجة». في القسم 10 من الورقة البيضاء، إذا ولّدت البروتوكولات رسومًا، فيمكن تحويلها عبر المزاد إلى BABY ثم إتلافها؛ فقط عندما يَتكوّن USDB للاستخدام المستمر ومع رسوم حقيقية تصبح هذه المسار ذات معنى. تصميم الإتلاف بحد ذاته لا يضمن بالضرورة ارتفاع القيمة. بعد الإطلاق، ما يستحق المتابعة أكثر هو: حجم التداول (الكتلة المتداولة)، ونسبة التغطية بالضمان، وسجلات الاسترداد الفعلية، وأداء التصفية. يمكن مناقشة الابتكار أولًا، لكن موثوقيته لا تزال بحاجة إلى أن تجيب عنها بيانات السلسلة. #baby
تذكير: يا إخوة، مبدعي grvt الذين دخلوا القائمة، لا تنسوا بالتأكيد النقر على التحقق في صفحة booster. لديكم فقط هذا اليوم، وبعد كل هذا الجهد للدخول إلى القائمة، إذا نسيتم النقر على التحقق فلن تتمكنوا من استلام المكافأة، وستندمون كثيرًا #GRVT任务 #ALPHA🔥
يقال إن شخصًا فاز بالجائزة الكبرى المكونة من 99.99 قطعة BNB، وحالتي النفسية كما يظهر في صورة الغلاف. وبالمناسبة، هل يمكنني استلام جائزتي النهائية قبل موعد الغداء غدًا؟ إذا لم تصل، فسيتعين عليّ أن أجوع مرة أخرى #币安9周年
أعدتُ مشاهدة التصميم الحوْكمي لـ@NewtonProtocol الليلة الماضية، واكتشفت أن الشيء المثير للاهتمام فعلًا ليس اسم "الطبقتين"، بل من يملك القدرة على تغيير ماذا. تُسند معايير الاقتصاد مثل الرسوم والمكافآت إلى staked $NEWT للتصويت، بينما تُحدَّد منطق الـRollup والترقيات في آلية الإجماع بواسطة المُتحقّقين باختيار النسخة الجديدة. فالطبقة الأولى تغيّر كيفية توزيع $BTC ، والطبقة الثانية تغيّر وفق أي قواعد يعمل الشبكة؛ وفصل الصلاحيات هذين معًا هو أمر منطقي لعزل المخاطر. لكن فعالية الحوكمة لا يمكن قياسها فقط بوجود صفحة للتصويت. على مستوى المعايير يجب أن تكون العتبة لاقتراحات، وquorum، ونسبة القبول، ومدة دورة التصويت، وزمن التنفيذ بعده—على الأقل—معلنة للعموم، كما يلزم الكشف عن حقوق التصويت الفعّالة لأفضل 10 عناوين. وإلا فإن القواعد قد تكون مكتوبة على أنها "المجتمع يقرر"، لكن النتيجة الفعلية قد تظل مُهيمنة عليها فئة قليلة من المودعين/المُرهِنين. المفتاح ليس من يملك عملات أكثر، بل هل يمكن قياس درجة التركّز، وهل يمكن سحب التفويض، وهل لدى الأقلية المُعارِضة وقتٌ للإعداد. الترقية الأهم التي تستحق التدقيق هي "تكلفة الرفض". من الناحية النظرية يمكن للمُتحققين ألا يعتمدوا النسخة الجديدة، لكن إذا كان العميل والبنية التحتية وأساسًا معظم حركة المرور كلها مُنسَّقة من نفس الطرف، فقد يصبح رفض الترقية بمثابة الخروج من الشبكة. والتشعّب الصلب لا يتحول إلى توازن حقيقي إلا إذا كانت الكودات منشورة مسبقًا، ومصادر المُتحققين متوزعة بشكل كافٍ، وما يزال بإمكان سلسلة $ETH القديمة الاستمرار في العمل؛ وإلا فهو أقرب إلى إجراء تأكيد تقني، وليس طبقة حوكمة مستقلة. لذلك لن أنفي هذه البنية فقط لأن Newton ما يزال في مراحله المبكرة، ولن أتعجل اعتبارها DAO ناضجة. ما أود رؤيته الآن أكثر هو أن ينشر NewtonProtocol جدول معلمات الحوكمة، وتوزيع حقوق التصويت، وقفل/جدول التوقيت للترقيات، وسجلات اعتماد المُتحققين. بالنسبة إلى NEWT، فإن ما إذا كان الاقتراح الأول يمر أو لا ليس هو العلامة الأهم؛ الإشارة الحقيقية هي هل يستطيع المعارضون التعبير عن موقفهم، وهل يستطيع المُتحققون رفضه، وهل بعد الرفض ما تزال هناك خيارات قابلة للتطبيق.#Newt
مسابقة المشاركة في الأمان لـ NEWT: لا بد من إتمام خطوات العقوبة الأربعة الواقعية
أعدت أمس مشاهدة @NewtonProtocol من معمارية AVS. أولًا صححت خط الزمن: تم إطلاق Slashing على الشبكة الرئيسية الخاصة بـ EigenLayer في 17 أبريل 2025، وليس في 2026. هذا الترقية بالفعل جعل إعادة التّحقيـق (re-staking) من مجرد “وعد من العقدة بالالتزام بالقواعد” إلى “احتمال أن يؤدي سلوك مخالف معيّن إلى فقدان جزء من الرهن المخصّص لذلك”. لكن ظهور الإطار لا يعني أن Newton حصل تلقائيًا على القدرة الكاملة في فرض العقوبات. المشكلة الحقيقية ليست فيما إذا كانت “الأسنان قد رُكّبت”، بل هل يستطيع البروتوكول أن يحدد بدقة من يُعاقَب، وما هو الدليل، وما هو حجم العقوبة (المقياس) الواجب تطبيقه. أقوم بتفكيك مجموعة من عقوبات AVS التي ثبتت فعاليتها إلى 4 خطوات: أولًا، تحديد الأخطاء التي يمكن التحقق منها بشكل موضوعي، ثم تكوين أدلة يمكن لأي شخص إعادة فحصها، وبعدها إرجاع الخطأ إلى Operator بعينه، وأخيرًا تنفيذ العقوبة عبر نافذة التحدّي. نقص حلقة واحدة قد يؤدي إلى تشويه الصورة. على سبيل المثال، إذا قام Validator بالموافقة على معاملة لا تتوافق مع السياسة (Policy)، فهل وقّعها عمدًا بالخطأ، أم قرأ حالة قديمة (منتهية)، أم أن عقدًا مختلفة استخدمت إصدارات مختلفة من القواعد؟ وإذا كانت السياسة تعتمد على بيانات السعر أو الهوية، فيجب متابعة التحقق مما إذا كانت مصادر البيانات كانت متزامنة وقت حدوث الواقعة. لم تُكتب شروط العطل كمعايير حتمية؛ لذلك قد تظهر تفسيرات محتملان لنتيجة واحدة.
أعدتُ مشاهدة البنية الأمنية لـ@NewtonProtocol الليلة الماضية، واكتشفت أن EigenLayer أقرب إلى سوق جاهز مكوَّن من Operators. المزايا واضحة جدًا: لا يحتاج Newton إلى جمع المُصدِّقين من الصفر، ويمكن بدء التحقق عبر Policy بشكل أسرع. إن الأمان المُستأجر له أيضًا حدود؛ والسؤال الحقيقي ليس حجم الرهن فقط، بل عدد AVS التي تخدمها هذه العقد في الوقت نفسه.$RIVER إذا كانت عدة خدمات تشترك في مجموعة Operators نفسها، وموارد سحابية ونظام مراقبة واحد، فقد تكون على الورق شبكات متعددة، لكن مجالات الأعطال قد تتداخل. رفع الحوافز لـAVS معيّن عبر$SYN لا يعني بالضرورة أن العقد ستتخلى عن Newton، لكنه قد يغيّر جدولة تخصيص الموارد. البيانات الأكثر معنى من «معدل نجاح التحقق» هي تداخل Operators، ونسبة العقد من الفئة الأعلى، وسرعة التعافي بعد تعطل العقد المحورية.$NEWT يجب أيضًا توضيح حدود الـ slash. حدوث slash لدى AVS أخرى لا يعني حتمًا نقل الخسارة كما هي إلى Newton، لأن كل خدمة يمكنها ضبط شروط الـ slash الخاصة بها وتوزيع الرهن؛ لكن إذا تقلصت خدمةٌ ما لدى نفس الـ Operator بسبب مشكلات في الأجهزة أو التشغيل والصيانة، فقد يتحمل Newton ضغوطًا على التوافر. الخطر الجوهري ليس «إذا عوقب أحد، تُطبَّق العقوبة على الشبكة كلها»، بل أن عدة طبقات أمان قد تعتمد فعليًا على نفس مجموعة الجهات المنفِّذة.#Newt لذلك أرى أن EigenLayer خيار منطقي لمرحلة الإطلاق البارد لـNewton، لكنني لا أفسر «وراثة الأمان» على أنها «تفويض للمخاطر». في الخطوة التالية، أرغب أكثر في رؤية NewtonProtocol ينشر مدى تركّز الـ Operators، ونسبة البنية التحتية المستقلة، وخطط التبديل عند الأعطال. وإذا أمكن في المستقبل إدخال عقد مستقلة ومسارات تحقق احتياطية، عندها فقط ستتكوّن authorization layer تدريجيًا بموثوقية خاصة بها.
هل يستطيع Newton فعلًا تجاوز EVM؟ ليس أصعب ما في Chain-Agnostic هو توصيل سلسلة جديدة
في الليلة الماضية، أعادتُ مشاهدة @NewtonProtocol شرح دعم Non-EVM، وفجأة أدركت أن مصطلح “chain-agnostic” قد يُفهم بسهولة على أنه مجموعة كود يتم نشرها في كل مكان. لكن “عدم التقيّد بالسلسلة” الحقيقي يتكوّن على الأقل من 3 طبقات: هل يمكن للغة السياسات التعبير عن نفس القاعدة؟ وهل تستطيع سلاسل مختلفة تقديم حالة موثوقة؟ وهل يمكن ترسيخ صلاحيات التنفيذ بطرق مكافئة؟ مسار نيوتن الحالي ضمن بيئة EVM واضح نسبيًا، وكون Non-EVM ما يزال على خارطة الطريق أمر غير مستغرب؛ لكن السؤال الحقيقي الذي يستحق الطرح هو: ما الطبقة التي يستعد الفريق لتوحيدها، وأي الأجزاء يُسمح لها بالاختلاف باختلاف السلسلة. لنأخذ احتياطي الخزينة لدى الشركات كمثال: نفس العبارة “لن يتم تحويل أكثر من 2000 دولار خلال 24 ساعة”، على Base وSolana ليست مجرد تبديل RPC والانتهاء. $NVDAB دقة الأصول، وبنية الحسابات، وأوامر/تعليمات المعاملات، ومصادر الأسعار، وحتى كيفية احتساب “24 ساعة”—هل وفق توقيت الكتل أم وفق اليوم الميلادي—قد تختلف. يمكن لمحرك Policy Engine الحفاظ على دلالات موحّدة، لكن يجب أولًا ترجمة المعاملة الخام لكل سلسلة إلى إدخال معياري. إذا كانت طبقة الترجمة هذه بها انحراف، فقد تؤدي القاعدة نفسها إلى إجابات مختلفة على سلسلتين.
لقد قمت في شبكة الاختبار @grvt_io بإيداع نفس حساب الهامش عبر الضمان في نفس الوقت بأوامر شراء رافعة 5x على BTC وأوامر شراء رافعة 8x على ETH. كنت أريد التحقق مما إذا كان الهامش الموحد يمكن أن يحسن كفاءة استخدام رأس المال، لكن أكثر شيء يستحق التوثيق ليس سعر التفعيل نفسه، بل مقدار الوقت القصير الذي تتركه الحساب للسوق كي يتعافى بعد انتهاء أول معالجة للمخاطر. في الصفقات ذات الاتجاه نفسه التي تتشارك USDC، بمجرد أن ترتفع الترابطية فجأة، يصبح من السهل أن تتحول المراكز المتفرقة إلى مصدر خطر واحد. #grvt في محاكاة لسحب سريع للداخل بنسبة 8% عند سعر $BTC ، خفّض إصدار الاختبار المحدد الذي كنت أستخدمه أولاً عدد المراكز اللازمة لاستعادة هامش الاستمرار، ثم دخلت الأوامر المتبقية إلى دفتر الأوامر في انتظار تنفيذها. يجب أن أوضح هنا: توجد في الآونة الأخيرة محتويات منشورة تتحدث عن «تصفية كاملة» ضمن القواعد الحالية لـ GRVT، لذلك فإن نتائجي تمثل فقط إعدادات الاختبار في ذلك الوقت، ولا يمكن اعتبارها آلية رسمية حالية مباشرة. الاستنتاج القابل لإعادة الاستخدام الحقيقي هو أن المخاطر لم تنتهِ فورًا بعد التصفية. لم يكتمل أول تعامل خلال أقل من ثانيتين، بينما استمر تغذية السعر من الخارج بالانخفاض، فانخفضت حقوق ملكية الحساب مرة أخرى تحت العتبة. في هذه اللحظة، لم يكن الهامش المحرّر قد تكوّن لهامش أمان كافٍ بعد، كما أن عمق أوامر الشراء كان قد استُنزف للتو بواسطة أوامر الجولة السابقة، ما يجعل التفعيل الثاني أكثر احتمالًا. المشكلة ليست فقط في ارتفاع الرافعة، بل في حدوث اختلال في التزامن داخل نفس النافذة بين سرعة تحديث السعر وتكرار فحوصات المخاطر وسرعة إدخال أوامر دفتر الأوامر. هذا أعادني إلى فهم هامش عبر $ETH : فهو يدمج الأرصدة في ظروف السوق الهادئة، لكنه أيضًا يدفع عدة مراكز متجهة في نفس الاتجاه إلى حدود تصفية مشتركة. عند تقييم GRVT، لا ينبغي أن ننظر فقط إلى «هل حدثت تصفية أم لا»، بل يجب تسجيل الفاصل الزمني بين تفعيلين، ونسبة التنفيذ في أول مرة، ووقت استعادة العمق بنسبة 2%، وبقية حقوق الملكية بعد التعامل الثاني. فقط عندما تكون هذه البيانات كلها منشورة معًا، يمكن للمتداولين الحكم بدقة ما إذا كان الهامش الموحد يحسن الكفاءة فعلًا، أم أنه يقصر وقت التصحيح.