Web3天命人-阿明

#dusk $DUSK
@Dusk
في الآونة الأخيرة، أصبحت Dusk هي الأكثر جدارة بالمشاهدة—وليس بسبب “إضافة محفظة أخرى”، بل لأن مدخل الواجهة الأمامية لـ DuskDS بدأ يتعرض للمعايير. يتيح Dusk Connect، الذي فُتح في أبريل لمعاينة المطورين، لـ dApp أن يكتشف محافظ متوافقة بشكل موحّد، ويطلب الحسابات، ويوقّع، ويُطلق المعاملات؛ ما يقلل الاحتكاك الناتج عن تخصيص عمليات الربط حول محفظة واحدة لكل تطبيق.

كما تغطي محفظة Dusk الجديدة عمليات التحويل العامة/الخصوصية، Shield/Unshield، والـ Staking (الرهان) واستلام المكافآت. يتيح Moonlight رؤية الرصيد والتحويلات، وهو مناسب للخطوات التي تتطلب تدقيقًا؛ بينما يحمي Phoenix المبالغ وربط المعاملات باستخدام براهين المعرفة الصفرية. يتعاون المساران في النهاية على طبقة التسوية نفسها.

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

#dusk $DUSK @Dusk
لقد نظرتُ مؤخرًا بعناية إلى الورقة البيضاء الخاصة بـ Dusk، وأجد أن الجزء المثير للاهتمام فيها ليس مجرد "سلسلة بلوكشين خصوصية"، بل إنها تحاول وضع الخصوصية والامتثال والأصول الواقعية على نفس البنية التحتية.
تستخدم Dusk الإثباتات الصفرية لحماية خصوصية المعاملات، وفي الوقت نفسه تلبي متطلبات الجهات التنظيمية من خلال الإفصاح الانتقائي😁. كما تدعم Phoenix وMoonlight المعاملات الخاصة والمعاملات العلنية على التوالي، بينما يتولى Succinct Attestation مسؤولية التسوية النهائية السريعة والحتمية😇. وبالإضافة إلى ذلك، ومع سيناريوهات DuskEVM وRWA، تكون الأهداف واضحة جدًا: تمكين الأصول الخاضعة للتنظيم مثل الأوراق المالية وصناديق الاستثمار من🤔 إصدارها وتداولها وتسويتها فعليًا على السلسلة.
إذا انتقلت مرحلة RWA القادمة من "السرد" إلى "بنية مالية حقيقية"🤑، فإن Dusk يستحق المتابعة المستمرة.

#baby $BABY
فهم إقراض/رهان BABY على أنه “أخذ العائد، والحوكمة مسألة تُترك للصدفة”، قد يكون قد فاتك بند صلاحية واحد: إذا لم تُصوّت، فقد يصوّت المُتحقِّق (المدقق) نيابةً عنك.

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

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

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

في المرة القادمة التي أراجع فيها المقترحات، سأفحص أولًا ثلاثة أوقات: متى ينتهي التصويت، هل كان المُتحقِّق قد صوّت بالفعل، وهل تمّت إضافة تصويتي على السلسلة؛ ثم أتأكد إن كان الاقتراح عاديًا أم عاجلًا. إذا كان في محفظتك رصيد رهني فقط دون تنبيه للحوكمة، فقد يكون “الرهان السلبي” الخاص بـ BABY أيضًا يسلم—بشكل سلبي—سلطة اتخاذ القرار.#baby $BABY @BabylonLabs_io

#baby $BABY
إذا كنت بدأت مؤخرًا بمراجعة محفظتك بسبب نقاشات COLDCARD، فلا تتعجل في مساواة عبارة “المحفظة الباردة” مباشرةً بـ “يمكنها إيداع/تكديس BABY”.
تحديد COLDCARD الرسمي واضح جدًا: هي محفظة أجهزة مخصصة فقط لـ Bitcoin، والجوهر فيها هو التوقيع دون اتصال (offline signing) وحماية مفاتيح Bitcoin الخاصة. أدوات Babylon الرسمية الخاصة بإيداع BABY (BABY Staking Tools) حاليًا لا تُدرج COLDCARD أيضًا ضمن قائمة الدعم؛ وفي نفس الجدول، فإن “عنوان BABY” و“إيداع BABY” لدى Keplr وCosmostation وLeap هي “Coldlar” ثم “عنوان BABY Staking”.
Coldlar وCOLDCARD ليستا المنتج نفسه؛ الاسم قد يشبه بعضهما، لكن الحدود الوظيفية لا يمكن خلطها.
بالنسبة لمستخدمي BABY، فالأمر الحقيقي الذي يجب التأكد منه هو توافق ثلاث طبقات: هل يمكنك إنشاء عنوان Babylon أو الاتصال به، وهل يمكنك بدء تفويض/إيداع BABY، وهل يمكنك ضمن نفس العنوان إكمال الإيداع المشترك BTC-BABY. تكتب صفحة Babylon الرسمية أن استخدام BABY يشمل الإيداع (staking) وBTC-BABY co-staking والحوكمة، لكن هذا لا يعني أن أي محفظة أجهزة Bitcoin يمكنها تحمل هذه العمليات مباشرة.
لذلك فإن الحكم الأكثر أمانًا هو: COLDCARD مناسبة للتخزين دون اتصال والتوقيع لمستخدمي Bitcoin-only؛ أما BABY Staking فيُفضَّل أولًا اختيار الحل المعلَّم عليه ضمن جدول أدوات Babylon الحالي، ثم تأكيد الإصدار والشبكة ومتطلبات العنوان. كما تنبه الوثائق الرسمية بوضوح إلى أن القائمة قد تتغير. وعندما تعود الضجة كنقطة ساخنة مرة أخرى، تحقق أولًا مما إذا كان “عنوان BABY” و“إيداع BABY” أمرين مختلفين ولا تكتفِ بالنظر إلى كون المحفظة تُسمى “محفظة باردة”.@BabylonLabs_io

#baby $BABY
تقوم بإيداع/رهان البيتكوين (BTC) كضمان في بروتوكول إقراض، وأشيع ما يُساء فهمه ليس معدل فائدة القرض نفسه، بل هو: «هل يمكن للسلسلة الأخرى تأكيد حالة هذا الـBTC؟»

توضح الصفحة الرسمية لــ Babylon الآن عملية Trustless Bitcoin Vaults (TBV) بشكل مباشر للغاية: أولاً يتم قفل BTC الأصلي داخل الـVault، ثم تصبح حالة الضمان قابلة للتحقق على Ethereum، وأخيراً يتم الحصول على سيولة العملات المستقرة عبر Aave v4. ويبين هذا التسلسل أن نقطة البيع الجوهرية لـTBV ليست «إضافة مدخل إقراض آخر»، بل محاولة تحويل واقعة رهن BTC إلى حالة يمكن للبروتوكولات الخارجية قراءتها.

وهذا يختلف عن فكرة تغليف BTC كرمز ثم إجراء نقل عبر السلاسل. كما أن توصيف Babylon لعملية staking لبيتكوين يؤكد أنه لا يلزم wrapping أو pegging أو bridging. لكن «الحفاظ على إتاحة/إدارة BTC كضمان مع الحصول على السيولة» و«بإمكان بروتوكول الإقراض قبول هذا الرهن بأمان» هما طرحان مختلفان ولا يمكن خلطهما.

حالياً، ما ينبغي تذكره ليس رقم عائد بعينه، بل حقيقة أن الموقع الرسمي ما زال يوفر مدخل «Launch TBV Testnet». فكون شبكة الاختبار قادرة على تشغيل المسار لا يعني أن الشبكة الرئيسية قد فُتحت بالفعل، ولا يعني أيضاً أن معدل الضمانات، والتصفية (liquidation)، والأوراكل، وشروط الخروج، قد خضعت لاختبار عملي كافٍ على مدى فترة طويلة. وبالأخص، عندما يتم أخذ قرض بالعملات المستقرة، فإن تقلب سعر BTC أو حالات شاذة في حالة العقود أو تعذّر مسار الخروج، كلها قد تحول «الضمان القابل للتحقق» إلى مخاطر فعلية.

الأهم أن نراقب ثلاثة مؤشرات لاحقاً: هل يزال BTC الأصلي موجوداً ضمن ظروف الـVault المتوقعة؟ وهل تظل حالة الضمان المقروءة على جهة Ethereum متسقة باستمرار؟ وهل ظهرت خارج شبكة الاختبار معاملات/معلمات الشبكة الرئيسية علناً مع إفصاحات عن المخاطر؟ إن الفاصل الحقيقي لـTBV ليس ما إذا كان بإمكانك الدخول إلى صفحة الاقتراض، بل ما إذا كانت هذه الطبقات الثلاث من الحالة يمكن التحقق منها بشكل مستقل.#baby $BABY @BabylonLabs_io

#baby $BABY
ما زلت أعمل لساعات إضافية في عطلة نهاية الأسبوع، وعند العودة إلى المنزل اطلب طعامًا جاهزًا، وأكثر شيء يسهل الوقوع في خطأ ليس عدم الحصول على القسيمة، بل أن يتم استخدام قسيمتين من خلال هاتفين مختلفين، وفي النهاية لا تتم إضافتهما إلى نفس الطلب. لدى استثمار Babylon المشترك لـ BTC وBABY مشكلة “المطابقة/التسوية” مماثلة: كون BTC وBABY مقفلين لا يعني بالضرورة أن النظام سيحسبهما معًا.

وفقًا للقواعد الرسمية لدى Babylon، ليس المهم الكلام عن “نفس الشخص”، بل ما إذا كانت عمليتا delegation مرتبطتين بعنوان BABY نفسه. إذا اختلف العنوان، فقد تصبح مكافأة الاستحقاق المشترك مباشرة 0؛ كما لا يكفي أن يبقى BTC وBABY في حالة VERIFIED فقط، بل يجب أن يكون كلاهما في حالة ACTIVE القابلة للاحتساب ضمن النظام.

كما أن لآلية النِّسب أيضًا أثر تقصير: w = min（عدد BABY ÷ 20,000，عدد BTC）。على سبيل المثال، 0.1 BTC مقابل 1,000 BABY تعطي وزنًا مشتركًا فعليًا يعادل 0.05 BTC فقط؛ ولكي تحصل على وزن كامل 0.1 BTC، تحتاج إلى حوالي 2,000 BABY. وضع المزيد في جهة لن يتجاوز حد الجهة الأخرى، أما المبالغ الصغيرة فتُحسب بنسبة لا بشرط تحقيق حدٍّ رقمي محدد.

أعتقد أن ما يستحق أن تركز عليه من أجل الاستمرار في متابعة الاستحقاق المشترك لـ BABY ليس رقم الربح الفردي كما يظهر في الإعلانات، بل ما إذا كانت العناوين والحالات والنِّسب تتطابق معًا. كما ينبغي فهم 2.35% على أنها معلمة تضخم سنوي ضمن “حوض المكافآت المشتركة”، وليست APR ثابتًا للشخص؛ بعد تغيّر أوزان المشاركين وإجمالي الوزن في الشبكة، سيتغير توزيع الفرد. الخطوة التالية الأكثر أهمية هي تسجيل حالة delegation والوزن الفعلي وإجمالي الوزن الكلي في الشبكة؛ وأي تحديث لأحد هذه المعايير قد يجعل تقديرات الربح القديمة غير صالحة.#baby @BabylonLabs_io

#baby $BABY
لقد تقاطع “BABY” وحقّق ربحًا مرة أخرى. بعد ذلك قمتُ بإجراء طلبين معًا: افتحتُ التسوّق مع شخصين لتجميع عروض التقسيم/الخصم حسب الحد الأدنى، واختَرنا السلع والقسائم بشكل صحيح. لكن عند إتمام الدفع اكتشفتُ أن الخصم لم يُفعَّل. والسبب بسيط: يتم الطلب بحساب، بينما يتم استلام القسيمة بحساب آخر، والمنصّة لا تعرف أنهما ينتميان إلى نفس الطلب.
كما أن الرهن المشترك BTC-BABY عالق في هذا التفصيل الصغير. ليست عبارة “تم رهن BTC، وتم رهن BABY” تعني تلقائيًا إضافة مكافأة إضافية؛ يجب أن تكون عناوين BABY المرتبطة بالرصْدين متطابقة تمامًا. إذا كانت العناوين مختلفة، فالإجابة في مستندات الطرف الرسمي واضحة: مكافأة الرهن المشترك = 0.
ولا تكتفِ بالنظر إلى حالة VERIFIED ثم تُغلق الصفحة. يجب أن يستمر تفويض BTC حتى يصل إلى ACTIVE، ويجب أن تكون تفويضات BABY أيضًا في حالة active؛ عندها فقط يقوم النظام بدمج الجانبين في وزن الرهن المشترك. “تم التحقق” يبدو كأنه أمر تم إنجازه، لكنه في الحقيقة ليس هو مرحلة احتساب الوزن بعد.
الصيغة الحقيقية هي: w = min（كمية رهن BABY ÷ 20,000، كمية رهن BTC）。مثال: لو كانت 0.1 BTC تقابل 1,000 BABY، فوزن الرهن المشترك لا يتجاوز 0.05 BTC. ولتعبئة وزن هذه الـ0.1 BTC بالكامل، تحتاج إلى 2,000 BABY. وبالعكس، زيادة BABY لن تجعل الوزن يتجاوز كمية BTC التي تم رهنها بالفعل.
لا توجد عتبة من نوع “لا بد أن يكون هناك 1 BTC أو 20,000 BABY على الأقل”، فحتى المبالغ الصغيرة تُحسب بنسبة. توزيع BABY على عدة مُتحققين أيضًا لا مشكلة فيه، ما دام المصدر من نفس العنوان؛ عندها يقوم النظام بدمج الكميات.
وهناك رقم يُساء فهمه بسهولة: 2.35% ليس معدل APR ثابتًا شخصيًا، بل هو إجمالي حوض مكافآت التضخم السنوي الذي يشارك فيه جميع مُشاركي الرهن المشترك. مقدار ما تحصل عليه أنت يعتمد على نسبة وزنِك من إجمالي أوزان الشبكة. كلما زاد عدد المشاركين، صارت الحصة المخصّصة لنفس الوزن أصغر.
لذلك هذه الآلية ليست “يكفي أن يتم رهن العملتين معًا”، بل يجب أن تتطابق العناوين والحالات ونسب المقابلة في الوقت نفسه. سأركّز على التحقق من أربع نقاط: هل عنوان BABY متطابق؟ هل وصل BTC إلى ACTIVE؟ هل تم كبح الوزن فعليًا بسبب “عنق الزجاجة”؟ وهل يوجد تغيّر واضح في إجمالي وزن الشبكة؟ وقد يتم تحديث المعلمات؛ وقبل أي عملية، ما زال يجب الاعتماد على صفحة الطرف الرسمي كمرجع.
أكثر شيء يُفوَّت في الرهن المشترك غالبًا ليس فعل الرهن نفسه، بل هل قام النظام بضمّ الحسابين إلى نفس العنوان.#baby @BabylonLabs_io

#baby $BABY
ترك منزلي يعجّ بأشياء غير مستخدمة، وفي عطلة نهاية الأسبوع بِعتَ السيارة المستعملة. وفي مكالمة هاتفية قال المشتري جملة واحدة: “أنا أستطيع (سآتي/أستطيع الاستلام)”. هذا لا يعني أن الأموال وصلت فعلاً. بعد التفاوض على السعر وتوقيع العقد، يبقى السؤال: هل ستهبط الصفقة فعلياً على أرض الواقع؟ في النهاية كل شيء يعتمد على ما إذا كان الطرف الآخر يستطيع إخراج النقد فوراً.
وبالمثل، يتم تصفية TBV. عندما يهبط عامل الصحة تحت 1.0، فهذا يعني فقط أن مفتاح/بوابة التصفية قد فُتِح، لا يعني أن BTC تحولت إلى نقد بسلاسة. BTC الأصلية على Bitcoin؛ عملية الاسترداد تمر عبر claim ثم تحدّي ثم payout، وعادةً تحتاج أياماً، ولا يمكن إنجاز خطوة سداد الديون على Ethereum في نفس معاملة واحدة.
الطريقة التي يتبعها Babylon الآن هي وضع طبقة وسيطة من LLP. وبشكل افتراضي، يقوم BTCVaultSwap بتوفير تسوية فورية من احتياطي WBTC في Aave Hub: يسدد المُصفّي أولاً ويستلم WBTC، ثم يتم حجز الـ vault المقتطع في escrow؛ وبعد ذلك يقوم مُتداول التحكيم المسجل بشرائه، وببطء يتم إكمال جانب الاسترداد على Bitcoin. وبكلمة بسيطة: يتم تمويل WBTC مقدّماً أولاً، لكي تُسوى دفاتر Ethereum.
لكن هذا التمويل المقدم ليس حفرة لا قاع لها. تقول الوثائق الرسمية بوضوح: إذا لم تكن سيولة WBTC في Aave Hub أو سماح (allowance) Vault Swap كافية، فإن معاملات التصفية بدون إذن ستفشل (revert). سيظل بإمكان متداولي التحكيم المسجلين استخدام الاسترداد المباشر، لكن عدد الأشخاص القادرين على “الاستيعاب” سيكون أقل بكثير.
وهناك أيضاً “درج” (خطوة) UTXO يسهل تجاهله. لا يمكن لِـ vault أن يتم تصفيته على نصفه فقط؛ فإذا كان لديك vault واحد فقط، فقد يؤدي تجاوز بسيط إلى تفعيل إغلاق كامل للمحفظة، وسيتم إدراج UTXO كاملاً في التصفية. إن قيمة الضمان الزائد لا تُمحى بالكامل؛ بل تُستخدم آليات عادلة لتسوية الديون أو يتم تعويضها بـ WBTC. لذلك توصي بوابة Portal الرسمية افتراضياً بالتقسيم إلى: “تضحية بـ vault + حماية vault”.
المعلمات الحالية والعرض أعلاه مبنيّة على شبكة الاختبار العامة لـ TBV؛ وsignet BTC وmock WBTC والـ stablecoins لا تمتلك قيمة نقدية.
لذلك عندما أنظر الآن إلى TBV، لا أركز فقط على عامل الصحة، بل أيضاً على عمق WBTC داخل Hub، وallowance الخاص بـ Vault Swap، وكم من الوقت يمكن شراء الـ vault الموجود في escrow. خط التصفية مجرد مفتاح: بعد الضغط، هل توجد نقود وهل يوجد مشتري؟ هذا هو ما يحدد ما إذا كان يمكن لهذا النظام أن يصمد في ظروف السوق الضاغطة. #baby @BabylonLabs_io

شاندَي باع بسعر مرتفع، لكن لا نخسر طالما كسب المال $SNDK

#baby $BABY
اليوم قمتُ بتغيير هاتفي، ووجدتُ أن الأمور سيئة للغاية. الأسوأ ليس مجرد تسجيل الدخول من جديد، بل أن تكتشف فجأة: كلمة المرور ما زالت موجودة، ورمز التحقق أيضًا ما زال موجودًا، لكن ملفات النسخ الاحتياطي الحاسمة لا يمكن فتحها. الأشياء ما زالت ملكي، لكن استعادتها تصبح شديدة التعقيد.
لذلك اليوم عندما أتابع TBV، لا يهمني بقدر ما يهمني السؤال التالي: هل يمكن لـ BTC ألا تعبر الجسر؟ بل الأهم هو: عند حدوث مشكلة، هل تكون لدى المستخدم في يده فعلاً “المفتاح الأخير”.
تذكر وثائق Babylon عدة مسارات استرداد عملية جدًا. إذا تعلّق تنشيط البطاقة في منتصف الطريق، ويمكن تجاوز النافذة، فهناك خيار استرداد الأموال. وعند الاسترداد (redeem)، إذا لم يشرع Vault Provider ببدء claim، يمكن للمستخدم استخدام مفاتيح WOTS الخاصة به وملف claimer، وتشغيل الأوامر عبر سطر الأوامر بنفسه لإتمام claim وassert وpayout. وإذا حدث خطأ في claim ولم يقم المتحدّي بمعالجته في الوقت المناسب، يمكن للمستخدم كذلك بدء challenge بنفسه باستخدام ملف BABE الذي تم حفظه.
هذا أهم من جملة واحدة مثل “trustless”. لأن السيناريوهات المزعجة غالبًا ليست أن النظام يعمل بشكل طبيعي، بل أن مزود الخدمة يصبح غير متصل، أو أن الإثبات يتعطل، أو أن النظام يدخل حالة إيقاف (pause). ففكرة TBV هي: قد يتعرض المشغل لمشكلة، لكن لا ينبغي أن يبقى المستخدم لديه طريق واحد فقط ينتظر خدمة العملاء.
بالطبع، الاسترداد الذاتي لا يعني أنه بلا عوائق. يجب نسخ ملفات WOTS وملفات claimer artifacts احتياطيًا بأنفسنا، وتسلسل سطر الأوامر ليس زرًا واحدًا تضغطه فحسب؛ كما أن أموال الشبكة الاختبارية ليست لها قيمة حقيقية. عقود التطبيق، والأوركِل (النبؤات/مزوّد البيانات)، وقواعد التسوية، وmultisig الحوكمة، ما زالت تتطلب تقييمًا منفصلاً.
بعد ذلك سأتتبع ثلاثة تفاصيل: هل ملفات الاسترداد سهلة للحفظ؟ وهل يستطيع المستخدم العادي إعادة إنتاج عملية سطر الأوامر؟ وكم يستغرق الأمر من لحظة بدء claim حتى يتم وصول BTC فعليًا. إذا استطعت TBV أن تسلّم “المفتاح الأخير” إلى يد المستخدم، فلن يكون رقم #baby مجرد قصة عن الاحتفاظ الذاتي. $BABY @BabylonLabs_io