Nova_eth_20
422 منشورات
Nova_eth_20
129 تتابع
1.5K+ المتابعون
450 إعجاب
منشورات
الكل
اقتباسات
#baby $BABY @BabylonLabs_io
كنت أقارن المدققين لتفويض "BABY" الخاص بي، وكدت أتجاوز كلمة "الحجز" (jailing) لأنها القالب القياسي لبرنامج Cosmos لكل سلسلة: كتل مفقودة، مهلة مؤقتة، ولا شيء محدد يتعلق بـ Babylon. ثم قرأت ما يوقّعه المدققون فعليًا مرتين، وليس مرة واحدة.
كل مدقق في Genesis لدى Babylon يقوم بوظيفتين منفصلتين. الأولى: توقيع كتل CometBFT العادية، وهو العمل المعتاد الذي يقوم به أي مدقق في Cosmos. والثانية: التصويت باستخدام BLS في نهاية كل حقبة (epoch)، حيث تُجمَّع تواقيع المدققين في نقطة تحقق (checkpoint) تُؤرَّخ مباشرة على Bitcoin. هذا التوقيع الثاني هو السبب الكامل وراء تسمية هذه السلسلة بأنها "مؤمّنة بواسطة Bitcoin".
الحجز بسبب التوقف (downtime jailing) يهتم فقط بالمهمة الأولى، ضمن شروطها الخاصة، وهو تطبيق قياسي للالتزام الحيّ (liveness) ولا يحمل أي شيء درامي. ما لم أستطع تحديده بدقة هو التفاعل الدقيق: هل يؤدي حجز يحدث في منتصف الحقبة إلى استبعاد مساهمة BLS لتلك الحقبة كاملةً بهدوء، أم لا يهم إلا إذا كان المدقق ما يزال نشطًا لحظة إغلاق الحقبة. تؤكد وثائق Babylon أن الوظيفتين منفصلتان. لكنها لا توضح أبدًا حد التوقيت المحدد الذي كنت أبحث عنه.
على أي حال، تشترك الوظيفتان في سجل واحد للوقت/الإتاحة. مدقق محجوز بسبب كتل مفقودة بشكل عادي—وهو نفس القاعدة التي تعمل بها أي سلسلة Cosmos—ليس محميًا من فقدان التوقيع الذي يتم تثبيته فعليًا على Bitcoin في تلك الحقبة، ولسبب لا علاقة له بأمن Bitcoin على الإطلاق.
لا أعتقد أنها عيب تصميم؛ لا توجد طريقة نظيفة لحبس شخص من دور دون الآخر على نفس المفتاح. ما لم أكن قد فصلته في ذهني قبل ذلك هو أن تاريخ التوقف ليس فقط حول المكافآت الفائتة. بل هو مؤشر تقريبي مزعج لمدى حضور المدقق فعليًا للتوقيع الذي يجعل "Bitcoin-secured" حقيقية.
راجعت سجل الحجز للقائمة المختصرة لدي مرة أخرى. كان لدى اسمين إدخال واحد لكل منهما، وكلاهما عمره أكثر من سنة، وكلاهما يتبعه فترات طويلة نظيفة منذ ذلك الحين. ليست علامة تحذير. إنها فقط ليست هي نفس الصفر الذي افترضته بأن نسبة الإتاحة النظيفة كانت تقول لي.
$BLESS
🤔 ما أول شيء تتحقق منه قبل تفويض الـ baby؟
كنت أقارن المدققين لتفويض "BABY" الخاص بي، وكدت أتجاوز كلمة "الحجز" (jailing) لأنها القالب القياسي لبرنامج Cosmos لكل سلسلة: كتل مفقودة، مهلة مؤقتة، ولا شيء محدد يتعلق بـ Babylon. ثم قرأت ما يوقّعه المدققون فعليًا مرتين، وليس مرة واحدة.
كل مدقق في Genesis لدى Babylon يقوم بوظيفتين منفصلتين. الأولى: توقيع كتل CometBFT العادية، وهو العمل المعتاد الذي يقوم به أي مدقق في Cosmos. والثانية: التصويت باستخدام BLS في نهاية كل حقبة (epoch)، حيث تُجمَّع تواقيع المدققين في نقطة تحقق (checkpoint) تُؤرَّخ مباشرة على Bitcoin. هذا التوقيع الثاني هو السبب الكامل وراء تسمية هذه السلسلة بأنها "مؤمّنة بواسطة Bitcoin".
الحجز بسبب التوقف (downtime jailing) يهتم فقط بالمهمة الأولى، ضمن شروطها الخاصة، وهو تطبيق قياسي للالتزام الحيّ (liveness) ولا يحمل أي شيء درامي. ما لم أستطع تحديده بدقة هو التفاعل الدقيق: هل يؤدي حجز يحدث في منتصف الحقبة إلى استبعاد مساهمة BLS لتلك الحقبة كاملةً بهدوء، أم لا يهم إلا إذا كان المدقق ما يزال نشطًا لحظة إغلاق الحقبة. تؤكد وثائق Babylon أن الوظيفتين منفصلتان. لكنها لا توضح أبدًا حد التوقيت المحدد الذي كنت أبحث عنه.
على أي حال، تشترك الوظيفتان في سجل واحد للوقت/الإتاحة. مدقق محجوز بسبب كتل مفقودة بشكل عادي—وهو نفس القاعدة التي تعمل بها أي سلسلة Cosmos—ليس محميًا من فقدان التوقيع الذي يتم تثبيته فعليًا على Bitcoin في تلك الحقبة، ولسبب لا علاقة له بأمن Bitcoin على الإطلاق.
لا أعتقد أنها عيب تصميم؛ لا توجد طريقة نظيفة لحبس شخص من دور دون الآخر على نفس المفتاح. ما لم أكن قد فصلته في ذهني قبل ذلك هو أن تاريخ التوقف ليس فقط حول المكافآت الفائتة. بل هو مؤشر تقريبي مزعج لمدى حضور المدقق فعليًا للتوقيع الذي يجعل "Bitcoin-secured" حقيقية.
راجعت سجل الحجز للقائمة المختصرة لدي مرة أخرى. كان لدى اسمين إدخال واحد لكل منهما، وكلاهما عمره أكثر من سنة، وكلاهما يتبعه فترات طويلة نظيفة منذ ذلك الحين. ليست علامة تحذير. إنها فقط ليست هي نفس الصفر الذي افترضته بأن نسبة الإتاحة النظيفة كانت تقول لي.
$BLESS
🤔 ما أول شيء تتحقق منه قبل تفويض الـ baby؟
Validator uptime 📈
34%
Jailing history 🚨
0%
Commission fees 💰
33%
Reputation & community 🌟
33%
3 الأصوات • تمّ إغلاق التصويت
$CYS
Mù 穆涵
·
--
$BABY #baby @BabylonLabs_io
اخترت مزود نهائية بناءً على حجم تفويضه لـ BTC وسجلّ التوفر، الأرقام التي تعرضها كل لوحة معلومات. لم أقرأ لاحقًا فقط ما الذي يحافظ فعليًا على تشغيل ذلك المزود يومًا بعد يوم، وأنه ليس BTC على الإطلاق.
كل مزود نهائية يحتاج إلى مفتاح تشغيل منفصل ممول بـ BABY، بمبالغ صغيرة، ويُستخدم لدفع رسوم الغاز لالتزام توليد عشوائية جديدة بشكل دوري. تُسترد عمليات إرسال التصويت تلقائيًا، وتؤكد وثائق مشغّل Babylon الخاصة بذلك مباشرة. المعاملات الأخرى على نفس المفتاح، بما في ذلك التزامات العشوائية الدورية، تحتاج إلى غاز لا يعود. تصف الوثائق ذلك تقريبًا على أنه فكرة لاحقة: تمويله بمبلغ حد أدنى، والحفاظ عليه قيد التشغيل مدة طويلة، وجملة واحدة بجانب آليات الأمان التي بحثت عنها فعلًا.
إن فاتك هذا التزويد بالمرة فلن يكون المزود مخترقًا سرًا؛ تفويض BTC لديهم ما زال بحجمه نفسه تمامًا وبنزاهة كما كان بالأمس. لكنهم ببساطة لن يستطيعوا الاستمرار في المشاركة حتى يلاحظ أحد أن المحفظة فارغة وأنه تم تزويدها. يمكن أن يكون المزود مثاليًا في كل مقياس تحققته قبل التفويض، ومع ذلك يختفي إلى الظلام بسبب شيء صغير مثل مفتاح غاز لم يتذكر أحد أن يعيده بالتمويل.
لوحات التفويض تعرض العمولة وحجم التفويض وتاريخ التوفر. لا يعرض أيٌّ منها ما إذا كان مفتاح تشغيل مزود ما ممولًا بشكل مريح أم يعمل على آخر رمق، لأن هذا الرقم لم يُصمَّم أصلًا ليكون عامًا في المقام الأول.
لا أعتقد أن هذا خلل في التصميم؛ فحفظ مفتاح التشغيل بحجمٍ أدنى وبعيدًا عن مقتنيات المزود الفعلية خيار أمني معقول، وليس إهمالًا. وما يعنيه للمفوّضين هو أقل: المزود الذي اخترته لسجله مع BTC هو أيضًا، بهدوء، في مجال تذكّر شراء الغاز.
$HEI
هل تعلم أن مفتاح تشغيل مزود نهائية يمكن أن ينفد حتى بينما يبدو تفويض BTC الخاص به بصحة ممتازة؟
اخترت مزود نهائية بناءً على حجم تفويضه لـ BTC وسجلّ التوفر، الأرقام التي تعرضها كل لوحة معلومات. لم أقرأ لاحقًا فقط ما الذي يحافظ فعليًا على تشغيل ذلك المزود يومًا بعد يوم، وأنه ليس BTC على الإطلاق.
كل مزود نهائية يحتاج إلى مفتاح تشغيل منفصل ممول بـ BABY، بمبالغ صغيرة، ويُستخدم لدفع رسوم الغاز لالتزام توليد عشوائية جديدة بشكل دوري. تُسترد عمليات إرسال التصويت تلقائيًا، وتؤكد وثائق مشغّل Babylon الخاصة بذلك مباشرة. المعاملات الأخرى على نفس المفتاح، بما في ذلك التزامات العشوائية الدورية، تحتاج إلى غاز لا يعود. تصف الوثائق ذلك تقريبًا على أنه فكرة لاحقة: تمويله بمبلغ حد أدنى، والحفاظ عليه قيد التشغيل مدة طويلة، وجملة واحدة بجانب آليات الأمان التي بحثت عنها فعلًا.
إن فاتك هذا التزويد بالمرة فلن يكون المزود مخترقًا سرًا؛ تفويض BTC لديهم ما زال بحجمه نفسه تمامًا وبنزاهة كما كان بالأمس. لكنهم ببساطة لن يستطيعوا الاستمرار في المشاركة حتى يلاحظ أحد أن المحفظة فارغة وأنه تم تزويدها. يمكن أن يكون المزود مثاليًا في كل مقياس تحققته قبل التفويض، ومع ذلك يختفي إلى الظلام بسبب شيء صغير مثل مفتاح غاز لم يتذكر أحد أن يعيده بالتمويل.
لوحات التفويض تعرض العمولة وحجم التفويض وتاريخ التوفر. لا يعرض أيٌّ منها ما إذا كان مفتاح تشغيل مزود ما ممولًا بشكل مريح أم يعمل على آخر رمق، لأن هذا الرقم لم يُصمَّم أصلًا ليكون عامًا في المقام الأول.
لا أعتقد أن هذا خلل في التصميم؛ فحفظ مفتاح التشغيل بحجمٍ أدنى وبعيدًا عن مقتنيات المزود الفعلية خيار أمني معقول، وليس إهمالًا. وما يعنيه للمفوّضين هو أقل: المزود الذي اخترته لسجله مع BTC هو أيضًا، بهدوء، في مجال تذكّر شراء الغاز.
$HEI
هل تعلم أن مفتاح تشغيل مزود نهائية يمكن أن ينفد حتى بينما يبدو تفويض BTC الخاص به بصحة ممتازة؟
#baby @BabylonLabs_io
قرأت تقريرًا تفصيليًا مُركّزًا عن العقوبات أمس أثناء بحثي عن رقم غرامة الـBTC المحدد. وجدته: 0.1% من الـBTC المرهَنة مقابل التوقيع المزدوج. ثم وجدت السطر الذي بجانبه مباشرة والذي لم أكن أبحث عنه: المكافآت التي تم الحصول عليها سابقًا لا يتم استعادتها.
يتم حظر المزوّد بشكل دائم، والسجن إلى الأبد، دون تفويضات بعد الآن، ولا عمولات بعد الآن. لكن أي عمولة كان قد جمعها بالفعل قبل المخالفة تظل ملكه. تسري العقوبة إلى الأمام من لحظة اكتشافه. ولا تسري إلى الوراء عبر المدة التي كان يعمل فيها قبل ذلك.
بالنسبة لمزوّد جديد تمامًا، فإن هذه الفجوة لا تهم تقريبًا؛ لا توجد أي مكافآت متراكمة بعد. أما بالنسبة لمن كان يدير تفويضات منذ عام، ويكسب حصة من العمولة في كل دورة مكافآت طوال الوقت، فستتغير الحسابات. الضربة بنسبة 0.1% تطال الجميع المفوضين له، بشكل نسبي؛ المزوّدون والمفوّضون على حد سواء. لكن الذي لا يُمس هو سجل العمولة، مهما كان مقدار ما كان يحصل عليه ويمشي به.
لا أعرف كم من الأرباح حقق أي مزوّد فرديًا فعلًا خلال مدة عمله—ليس ذلك منشورًا في أي مكان وجدته—لذلك لا أستطيع أن أخبرك ما إذا كانت هذه الفجوة بسيطة أم حقيقية. لكن ما يمكنني قوله إن الرادع صُمم عمدًا ليكون إلى الأمام فقط. استعادة المكافآت التاريخية كانت ستعني إعادة فتح كل دورة مكافآت سابقة، وهذا فوضى خاصة يجب تصميمها حولها.
الحظر إلى الأبد و“الإفلاس” نتيجتان مختلفتان، وتصميم Babylon الخاص بالـslashing يضمن النتيجة الأولى فقط.
$CYS $BABY
قرأت تقريرًا تفصيليًا مُركّزًا عن العقوبات أمس أثناء بحثي عن رقم غرامة الـBTC المحدد. وجدته: 0.1% من الـBTC المرهَنة مقابل التوقيع المزدوج. ثم وجدت السطر الذي بجانبه مباشرة والذي لم أكن أبحث عنه: المكافآت التي تم الحصول عليها سابقًا لا يتم استعادتها.
يتم حظر المزوّد بشكل دائم، والسجن إلى الأبد، دون تفويضات بعد الآن، ولا عمولات بعد الآن. لكن أي عمولة كان قد جمعها بالفعل قبل المخالفة تظل ملكه. تسري العقوبة إلى الأمام من لحظة اكتشافه. ولا تسري إلى الوراء عبر المدة التي كان يعمل فيها قبل ذلك.
بالنسبة لمزوّد جديد تمامًا، فإن هذه الفجوة لا تهم تقريبًا؛ لا توجد أي مكافآت متراكمة بعد. أما بالنسبة لمن كان يدير تفويضات منذ عام، ويكسب حصة من العمولة في كل دورة مكافآت طوال الوقت، فستتغير الحسابات. الضربة بنسبة 0.1% تطال الجميع المفوضين له، بشكل نسبي؛ المزوّدون والمفوّضون على حد سواء. لكن الذي لا يُمس هو سجل العمولة، مهما كان مقدار ما كان يحصل عليه ويمشي به.
لا أعرف كم من الأرباح حقق أي مزوّد فرديًا فعلًا خلال مدة عمله—ليس ذلك منشورًا في أي مكان وجدته—لذلك لا أستطيع أن أخبرك ما إذا كانت هذه الفجوة بسيطة أم حقيقية. لكن ما يمكنني قوله إن الرادع صُمم عمدًا ليكون إلى الأمام فقط. استعادة المكافآت التاريخية كانت ستعني إعادة فتح كل دورة مكافآت سابقة، وهذا فوضى خاصة يجب تصميمها حولها.
الحظر إلى الأبد و“الإفلاس” نتيجتان مختلفتان، وتصميم Babylon الخاص بالـslashing يضمن النتيجة الأولى فقط.
$CYS $BABY
$BICO
Mù 穆涵
·
--
#baby $BABY @BabylonLabs_io
تحققت من عمولة مزوّد خدمة الإنهاء قبل التفويض الليلة الماضية، 5%، بدا معقولًا مقارنةً بالآخرين في القائمة. كدت أفوض اعتمادًا على هذا الرقم وحده. ثم اكتشفت أن أمر التسجيل بابليون يتطلب خلفه.
كل مزوّد خدمة إ نهاء يضع ثلاثة أرقام عند التسجيل، وليس رقمًا واحدًا. معدل العمولة الحالي، ومعدل أقصى يمكنه ألا يتجاوز أبدًا، ومعدل أقصى للتغيير، أي مدى سرعة الارتفاع المسموح له بالاقتراب من ذلك السقف. الـ5% التي كنت أنظر إليها لم تكن الصورة الكاملة؛ كانت مجرد لقطة على قرص، مع توقفه الأعلى الخاص المبني من اليوم الأول.
لا شيء يمنع أي مزوّد من التسجيل عند 5% مع حد أقصى 50%، ثم رفعه بخطوات قانونية صغيرة كل فترة، حتى يحصل المفوضون الذين انضمّوا عند 5% على أرباح تحت رقم مختلف جدًا. لم تُكسر أي قاعدة، ولا يوجد أي فخ، فقط سقف كان واضحًا للعامة طوال الوقت.
بحثت عن المكان الذي يظهر فيه هذا السقف فعلًا للمفوض عندما يقرر من يختار. بحسب ما تمكنت من العثور عليه، تُظهر وثائق الاستيك الخاصة ببابليون وواجهة الـAPI التي تغذي لوحة التحكم في تلك المرحلة حقلًا واحدًا فقط: العمولة؛ كلما كانت أقل كانت المكافآت أعلى، ولا يوجد شيء أكثر تفصيلًا من ذلك. ليس الحد الأقصى للعمولة الموجود في الحقل التالي مباشرةً ضمن بيانات تسجيل المزود.
لا أعتقد أن هذا يجعل الآلية مفترسة. توجد سقف لتغير العمولة موجود تحديدًا حتى لا يمكن أن تقفز بين عشية وضحاها، وهذه الحماية حقيقية. ما ينقص هو الجزء الأصغر: الرقم الذي يحدد فعليًا أرباحك المستقبلية لم يُبنَ للوصول إلى الشاشة التي تتخذ قراراتك منها. لا تقول الوثائق كم عدد المزوّدين النشطين الذين غادروا أصل معدلهم بالفعل، ولا مدى قرب أيٍّ منهم من سقفه الآن، لذلك لا أستطيع أن أخبرك إن كان هذا خطرًا قائمًا أم مجرد افتراض.
الـ5% التي تراها هي صورة ثابتة. كان السقف دائمًا هو الاتفاق الحقيقي.
هل تعلم أن عمولة مزوّد الإنهاء الخاص بك يمكن أن ترتفع لتتجاوز الرقم الذي تراه اليوم؟ 📈
تحققت من عمولة مزوّد خدمة الإنهاء قبل التفويض الليلة الماضية، 5%، بدا معقولًا مقارنةً بالآخرين في القائمة. كدت أفوض اعتمادًا على هذا الرقم وحده. ثم اكتشفت أن أمر التسجيل بابليون يتطلب خلفه.
كل مزوّد خدمة إ نهاء يضع ثلاثة أرقام عند التسجيل، وليس رقمًا واحدًا. معدل العمولة الحالي، ومعدل أقصى يمكنه ألا يتجاوز أبدًا، ومعدل أقصى للتغيير، أي مدى سرعة الارتفاع المسموح له بالاقتراب من ذلك السقف. الـ5% التي كنت أنظر إليها لم تكن الصورة الكاملة؛ كانت مجرد لقطة على قرص، مع توقفه الأعلى الخاص المبني من اليوم الأول.
لا شيء يمنع أي مزوّد من التسجيل عند 5% مع حد أقصى 50%، ثم رفعه بخطوات قانونية صغيرة كل فترة، حتى يحصل المفوضون الذين انضمّوا عند 5% على أرباح تحت رقم مختلف جدًا. لم تُكسر أي قاعدة، ولا يوجد أي فخ، فقط سقف كان واضحًا للعامة طوال الوقت.
بحثت عن المكان الذي يظهر فيه هذا السقف فعلًا للمفوض عندما يقرر من يختار. بحسب ما تمكنت من العثور عليه، تُظهر وثائق الاستيك الخاصة ببابليون وواجهة الـAPI التي تغذي لوحة التحكم في تلك المرحلة حقلًا واحدًا فقط: العمولة؛ كلما كانت أقل كانت المكافآت أعلى، ولا يوجد شيء أكثر تفصيلًا من ذلك. ليس الحد الأقصى للعمولة الموجود في الحقل التالي مباشرةً ضمن بيانات تسجيل المزود.
لا أعتقد أن هذا يجعل الآلية مفترسة. توجد سقف لتغير العمولة موجود تحديدًا حتى لا يمكن أن تقفز بين عشية وضحاها، وهذه الحماية حقيقية. ما ينقص هو الجزء الأصغر: الرقم الذي يحدد فعليًا أرباحك المستقبلية لم يُبنَ للوصول إلى الشاشة التي تتخذ قراراتك منها. لا تقول الوثائق كم عدد المزوّدين النشطين الذين غادروا أصل معدلهم بالفعل، ولا مدى قرب أيٍّ منهم من سقفه الآن، لذلك لا أستطيع أن أخبرك إن كان هذا خطرًا قائمًا أم مجرد افتراض.
الـ5% التي تراها هي صورة ثابتة. كان السقف دائمًا هو الاتفاق الحقيقي.
هل تعلم أن عمولة مزوّد الإنهاء الخاص بك يمكن أن ترتفع لتتجاوز الرقم الذي تراه اليوم؟ 📈
#baby @BabylonLabs_io
لديّ بيتكوين مُعرَّض/مُرهَن (staked) الآن عبر Babylon، لذا عندما وجدت كلمة "overflow" مدفونَة في وثائق Cap-3 القديمة الليلة الماضية، لم أقرأها كأنها تاريخ. قرأتها كأنها سؤال عن وضعي أنا: هل يمكن أن يحدث لي.
خلال المرحلة 1، كانت معاملات الرهان التي تأكدَت بعد أن امتلأ الحدّ (cap) بالفعل تقفل البيتكوين في العقد تمامًا مثل أي شخص آخر. لم يكن لديها فقط أي مكافأة: لا نقاط، ولا تخصيص. كما أن استرجاع العملات لم يكن تلقائيًا أيضًا؛ الوثائق واضحة: رَهانات overflow كان يجب إلغاء ربطها (unbond) وسحبها، مع نفس فترة الانتظار مثل وضع نشط، لرهان دفع صفرًا طوال الوقت الذي ظل فيه مقفلاً.
ما الذي حسم من سيُقبل ومن لا؟ لم يكن وقت الضغط على زر الرهان من أي شخص. بل كان رقم كتلة البيتكوين التي أكدت المعاملة فعليًا عليها؛ وهو رقم لا يتحكم فيه أحد بشكل كامل بمجرد أن يغادر المحفظة. قد يُرسل شخصان المعاملة بفارق دقائق، ثم يَصلان بالترتيب هذا أو ذاك اعتمادًا على الرسوم، أو ازدحام الـ mempool، أو أي مُعدّن عثر أولًا على الكتلة التالية.
انتهت حدود المرحلة 1، لكن الآلية التي أنشأت overflow ليست حصرية لتلك المرحلة. أي جولة مستقبلية بحدود (capped)، أو إعداد انضمام BSN جديد بتخصيص ثابت، أو تكامل بعدد مقاعد محدود، يرث نفس سباق الترتيب لحظة استخدامه لتأكيدات الكتل بدلًا من طابور. لم تتم معالجة أي شيء في هذا العيب التصميمي. لقد تم تجاوزه فقط عندما اختفت الحدود.
لا أعتقد أن التصميم الأصلي كان غير عادل؛ فحدّ صارم يحتاج إلى نقطة قطع، ولا يمكن تزوير تأكيدات الكتل بالطريقة التي يمكن بها تزوير timestamp. ما يظل في ذهني أمر أصغر: بيتكوين الخاص بي وهو مقفل الآن لم يكن محميًا بمهارة أو توقيت جيد. لقد تجاوز/أزاح الخط الذي رسمه المُعدّنون، لا أنا، وعندما يُرسم الخط مرة أخرى، فسيُرسم أيضًا في مواجهتي.
$SKYAI $BICO $BABY
"هل سيمنعك هذا الخطر المرتبط بالـ overflow من المشاركة في رهان (staking) في جولة مستقبلية محدودة؟" 🎯
لديّ بيتكوين مُعرَّض/مُرهَن (staked) الآن عبر Babylon، لذا عندما وجدت كلمة "overflow" مدفونَة في وثائق Cap-3 القديمة الليلة الماضية، لم أقرأها كأنها تاريخ. قرأتها كأنها سؤال عن وضعي أنا: هل يمكن أن يحدث لي.
خلال المرحلة 1، كانت معاملات الرهان التي تأكدَت بعد أن امتلأ الحدّ (cap) بالفعل تقفل البيتكوين في العقد تمامًا مثل أي شخص آخر. لم يكن لديها فقط أي مكافأة: لا نقاط، ولا تخصيص. كما أن استرجاع العملات لم يكن تلقائيًا أيضًا؛ الوثائق واضحة: رَهانات overflow كان يجب إلغاء ربطها (unbond) وسحبها، مع نفس فترة الانتظار مثل وضع نشط، لرهان دفع صفرًا طوال الوقت الذي ظل فيه مقفلاً.
ما الذي حسم من سيُقبل ومن لا؟ لم يكن وقت الضغط على زر الرهان من أي شخص. بل كان رقم كتلة البيتكوين التي أكدت المعاملة فعليًا عليها؛ وهو رقم لا يتحكم فيه أحد بشكل كامل بمجرد أن يغادر المحفظة. قد يُرسل شخصان المعاملة بفارق دقائق، ثم يَصلان بالترتيب هذا أو ذاك اعتمادًا على الرسوم، أو ازدحام الـ mempool، أو أي مُعدّن عثر أولًا على الكتلة التالية.
انتهت حدود المرحلة 1، لكن الآلية التي أنشأت overflow ليست حصرية لتلك المرحلة. أي جولة مستقبلية بحدود (capped)، أو إعداد انضمام BSN جديد بتخصيص ثابت، أو تكامل بعدد مقاعد محدود، يرث نفس سباق الترتيب لحظة استخدامه لتأكيدات الكتل بدلًا من طابور. لم تتم معالجة أي شيء في هذا العيب التصميمي. لقد تم تجاوزه فقط عندما اختفت الحدود.
لا أعتقد أن التصميم الأصلي كان غير عادل؛ فحدّ صارم يحتاج إلى نقطة قطع، ولا يمكن تزوير تأكيدات الكتل بالطريقة التي يمكن بها تزوير timestamp. ما يظل في ذهني أمر أصغر: بيتكوين الخاص بي وهو مقفل الآن لم يكن محميًا بمهارة أو توقيت جيد. لقد تجاوز/أزاح الخط الذي رسمه المُعدّنون، لا أنا، وعندما يُرسم الخط مرة أخرى، فسيُرسم أيضًا في مواجهتي.
$SKYAI $BICO $BABY
"هل سيمنعك هذا الخطر المرتبط بالـ overflow من المشاركة في رهان (staking) في جولة مستقبلية محدودة؟" 🎯
😰 Yeah, dealbreaker
34%
😌 Nah, worth the risk
33%
🤔 Depends on the cap size
33%
🙈 Didn't know this existed
0%
3 الأصوات • تمّ إغلاق التصويت
$BLESS
Mù 穆涵
·
--
$BABY $BLESS #baby
قمتُ بتثبيت نسبة المشاركة (co-staking) قبل ثلاثة أسابيع — 20,000 BABY لكل BTC، وهي النسبة الموصى بها من بابيلون نفسها. في الليلة الماضية تحققت من مكافآتي. كانت أقل من العدد الذي حسبته في اليوم الذي قمتُ فيه بالتعـاكُس (staked).
لم تتحرك موقعي شيئًا على الإطلاق. لكن هناك شيئًا آخر تحرك.
تعزيز المشاركة بنسبة 2.35% ليس “معدلًا”. إنه عبارة عن وعاء/حوض بحجم ثابت، يُقسَّم تناسبيًا عبر كل محفظة تشارك في المشاركة (co-staking) في ذلك الوقت. تقول بابيلون هذا بوضوح في وثائقها: كلما زاد عدد المشاركين، صغرت المكافآت الفردية. إذا أصبت النسبة تمامًا، فإن حصتك الفعلية ما تزال تعتمد على عدد المحافظ الأخرى التي أصابت النسبة أيضًا—وهو رقم يتغير دون أن تلمس موقعك.
لا توجد لوحة تحكم تتابع هذا الرقم في الوقت الفعلي. يمكنك رؤية وزنك أنت. لا يمكنك رؤية الوزن الإجمالي للوعاء وهو يتغير تحتك.
بعكس مخاطر بابيلون الأخرى التي قد تختبئ داخل نقص البنية التحتية أو تركّز المشغّلين، فإن هذه المخاطرة تختبئ في وضح النهار — فالصيغة منشورة بالكامل. الشيء الوحيد المفقود هو: من غيرك يستخدمها.
هناك نقطة واحدة تستحق المراقبة: أن 2.35% ليست “مرساة/قاعدة”، بل هي رقم حَوْكمي (governance). لا توجد إلا لأن اقتراحًا في سبتمبر الماضي قسم تضخم بابيلون إلى شرائح ثابتة: 1% لمستثمري BTC، 2% لمستثمري BABY، 2.35% لمشاركي co-stakers، والباقي يُقسَّم في أماكن أخرى. يمكن للتصويت المستقبلي أن يعيد تحجيم تلك الشريحة بالطريقة نفسها التي أنشأ بها هذا الاقتراح تلك الشريحة. لم يُقترح حتى الآن تقليصها، لذلك يبقى هذا “مقعدًا” تراقبه، لا “طاولة” مضمون أنك ستظل جالسًا عليها.
هناك حافة ثانية مدمجة في الصيغة. تُقَيَّد الأوزان المؤهلة عند الأصغر بين: BABY الخاص بك مقسومًا على 20,000، أو BTC الخاص بك. إذا تجاوزت النسبة، فإن الـBABY الإضافية لا تكسب إلا معدل التستكين العادي. وإذا كنت أقل منها، فلا يُعزَّز سوى جزء من BTC الخاص بك.
تم تصميم اقتران BTC وBABY لتعزيز هذا الارتباط، ويعدّ توفير وعاء مشترك طريقة معقولة لتمويله. التصميم ليس المشكلة. عدم القدرة على رؤية أن حصتك ستتحول قبل حدوث ذلك هو المشكلة.
إذا كنتَ قد أصبت النسبة تمامًا مثلما فعلت أنا، فأنت لا تكسب 2.35% ثابتة. أنت تستأجر مقعدًا في طاولة تزدحم أكثر وفقًا لجدولها الخاص، من أشخاص لن ترى أبدًا وصولهم.
قمتُ بتثبيت نسبة المشاركة (co-staking) قبل ثلاثة أسابيع — 20,000 BABY لكل BTC، وهي النسبة الموصى بها من بابيلون نفسها. في الليلة الماضية تحققت من مكافآتي. كانت أقل من العدد الذي حسبته في اليوم الذي قمتُ فيه بالتعـاكُس (staked).
لم تتحرك موقعي شيئًا على الإطلاق. لكن هناك شيئًا آخر تحرك.
تعزيز المشاركة بنسبة 2.35% ليس “معدلًا”. إنه عبارة عن وعاء/حوض بحجم ثابت، يُقسَّم تناسبيًا عبر كل محفظة تشارك في المشاركة (co-staking) في ذلك الوقت. تقول بابيلون هذا بوضوح في وثائقها: كلما زاد عدد المشاركين، صغرت المكافآت الفردية. إذا أصبت النسبة تمامًا، فإن حصتك الفعلية ما تزال تعتمد على عدد المحافظ الأخرى التي أصابت النسبة أيضًا—وهو رقم يتغير دون أن تلمس موقعك.
لا توجد لوحة تحكم تتابع هذا الرقم في الوقت الفعلي. يمكنك رؤية وزنك أنت. لا يمكنك رؤية الوزن الإجمالي للوعاء وهو يتغير تحتك.
بعكس مخاطر بابيلون الأخرى التي قد تختبئ داخل نقص البنية التحتية أو تركّز المشغّلين، فإن هذه المخاطرة تختبئ في وضح النهار — فالصيغة منشورة بالكامل. الشيء الوحيد المفقود هو: من غيرك يستخدمها.
هناك نقطة واحدة تستحق المراقبة: أن 2.35% ليست “مرساة/قاعدة”، بل هي رقم حَوْكمي (governance). لا توجد إلا لأن اقتراحًا في سبتمبر الماضي قسم تضخم بابيلون إلى شرائح ثابتة: 1% لمستثمري BTC، 2% لمستثمري BABY، 2.35% لمشاركي co-stakers، والباقي يُقسَّم في أماكن أخرى. يمكن للتصويت المستقبلي أن يعيد تحجيم تلك الشريحة بالطريقة نفسها التي أنشأ بها هذا الاقتراح تلك الشريحة. لم يُقترح حتى الآن تقليصها، لذلك يبقى هذا “مقعدًا” تراقبه، لا “طاولة” مضمون أنك ستظل جالسًا عليها.
هناك حافة ثانية مدمجة في الصيغة. تُقَيَّد الأوزان المؤهلة عند الأصغر بين: BABY الخاص بك مقسومًا على 20,000، أو BTC الخاص بك. إذا تجاوزت النسبة، فإن الـBABY الإضافية لا تكسب إلا معدل التستكين العادي. وإذا كنت أقل منها، فلا يُعزَّز سوى جزء من BTC الخاص بك.
تم تصميم اقتران BTC وBABY لتعزيز هذا الارتباط، ويعدّ توفير وعاء مشترك طريقة معقولة لتمويله. التصميم ليس المشكلة. عدم القدرة على رؤية أن حصتك ستتحول قبل حدوث ذلك هو المشكلة.
إذا كنتَ قد أصبت النسبة تمامًا مثلما فعلت أنا، فأنت لا تكسب 2.35% ثابتة. أنت تستأجر مقعدًا في طاولة تزدحم أكثر وفقًا لجدولها الخاص، من أشخاص لن ترى أبدًا وصولهم.
#baby $BABY @BabylonLabs_io
يستقر نصف عملاتي البيتكوين الخاصة بي الآن على شكل رهانات عبر Babylon. لم أسأل قط ماذا يحدث لها إذا تعطل نصف مجموعة المدققين في الوقت نفسه — حتى الليلة الماضية، عندما قرأت الجزء الذي كنت قد تجاهله من الورقة التأسيسية لـ Babylon.
التدقيق بنقاط تفتيش على بيتكوين يعالج السلامة. يكفي أن يرسل مدققٌ واحدٌ صادقٌ إثباتًا إلى البيتكوين ليتمكن من معاقبة الكاذبين والحسم في أي تاريخ هو الصحيح. أما قابلية الاستمرار (liveness) فهي سؤالٌ منفصل: هل تستمر السلسلة في إنتاج الكتل على الإطلاق.
وهذا الجزء الذي لا تستطيع بيتكوين لمسه. لا تضمن أي بروتوكولات إثبات حصة (PoS) قابلية الاستمرار بمجرد أن يتجاوز المدققون الخصومون نصف المجموعة الفعّالة. لا إذا كانت بيتكوين في الخلفية، ولا مع أي خدمة تضمينٍ زمني — إلا إذا تم نشر بيانات كل مدقق على السلسلة بشكلٍ on-chain، ولم تكن قدرة بيتكوين مُصممة أصلًا لتحمل ذلك.
لا يتهاوى هذا الاستدلال أمام الخبث. هو لا يقول شيئًا عن مدققين يكتفون ببساطة بالتوقف عن الظهور. تتعطل السلسلة بالطريقة نفسها في كلتا الحالتين، وبيتكوين لا يمكنها أن تخبرك أيهما حدث.
"مؤمّنة بواسطة بيتكوين" تبدو كأنها ضمان واحد. إنها ضمانان. تشتري بيتكوين اليقين بشأن أي تاريخ هو الصحيح. لكنها لا تشتري وعدًا بأن السلسلة ستستمر في الحركة إذا اختفى نصف المدققين في وقتٍ واحد — تعطل، أو خروج، أو هجوم لم يُلتقط في الوقت المناسب.
لجان تحتاج إلى مُوقّعٍ صادقٍ واحد، ومرحل (relayer) يحتاج إلى واحد كي يبقى على الإنترنت — تُحل هذه الأمور بزيادة عدد المشغلين المتواجدين. هذا الحدّ مثبتٌ رياضياتيًا، وليس مشكلة توظيف. مراقبةٌ أكبر لا تغيّر شيئًا.
عمليّة بيتكوين الخاصة بي مُقيدة على أي حال. ستمنحني بيتكوين إيصالًا في اللحظة الدقيقة التي توقفت فيها السلسلة. لم تكن العودة إلى التنفس جزءًا من البرهان.
$BLESS $HOME
إذا تعطل نصف مدققي Babylon الليلة، فماذا سيحدث لبيتكوين الخاصة بك؟
يستقر نصف عملاتي البيتكوين الخاصة بي الآن على شكل رهانات عبر Babylon. لم أسأل قط ماذا يحدث لها إذا تعطل نصف مجموعة المدققين في الوقت نفسه — حتى الليلة الماضية، عندما قرأت الجزء الذي كنت قد تجاهله من الورقة التأسيسية لـ Babylon.
التدقيق بنقاط تفتيش على بيتكوين يعالج السلامة. يكفي أن يرسل مدققٌ واحدٌ صادقٌ إثباتًا إلى البيتكوين ليتمكن من معاقبة الكاذبين والحسم في أي تاريخ هو الصحيح. أما قابلية الاستمرار (liveness) فهي سؤالٌ منفصل: هل تستمر السلسلة في إنتاج الكتل على الإطلاق.
وهذا الجزء الذي لا تستطيع بيتكوين لمسه. لا تضمن أي بروتوكولات إثبات حصة (PoS) قابلية الاستمرار بمجرد أن يتجاوز المدققون الخصومون نصف المجموعة الفعّالة. لا إذا كانت بيتكوين في الخلفية، ولا مع أي خدمة تضمينٍ زمني — إلا إذا تم نشر بيانات كل مدقق على السلسلة بشكلٍ on-chain، ولم تكن قدرة بيتكوين مُصممة أصلًا لتحمل ذلك.
لا يتهاوى هذا الاستدلال أمام الخبث. هو لا يقول شيئًا عن مدققين يكتفون ببساطة بالتوقف عن الظهور. تتعطل السلسلة بالطريقة نفسها في كلتا الحالتين، وبيتكوين لا يمكنها أن تخبرك أيهما حدث.
"مؤمّنة بواسطة بيتكوين" تبدو كأنها ضمان واحد. إنها ضمانان. تشتري بيتكوين اليقين بشأن أي تاريخ هو الصحيح. لكنها لا تشتري وعدًا بأن السلسلة ستستمر في الحركة إذا اختفى نصف المدققين في وقتٍ واحد — تعطل، أو خروج، أو هجوم لم يُلتقط في الوقت المناسب.
لجان تحتاج إلى مُوقّعٍ صادقٍ واحد، ومرحل (relayer) يحتاج إلى واحد كي يبقى على الإنترنت — تُحل هذه الأمور بزيادة عدد المشغلين المتواجدين. هذا الحدّ مثبتٌ رياضياتيًا، وليس مشكلة توظيف. مراقبةٌ أكبر لا تغيّر شيئًا.
عمليّة بيتكوين الخاصة بي مُقيدة على أي حال. ستمنحني بيتكوين إيصالًا في اللحظة الدقيقة التي توقفت فيها السلسلة. لم تكن العودة إلى التنفس جزءًا من البرهان.
$BLESS $HOME
إذا تعطل نصف مدققي Babylon الليلة، فماذا سيحدث لبيتكوين الخاصة بك؟
🔐 Safety's covered, I'm fine
33%
🛑 Liveness could still stall
0%
🧊 Frozen either way
0%
⚡ Didn't know
67%
3 الأصوات • تمّ إغلاق التصويت
تمّ التحقق
@BabylonLabs_io $BABY #baby
في كل مرة تفك ربط BTC من بابل، توجد تسع مفاتيح بين بيتكوينك ومحفظتك. يجب أن يوافق ستة منها قبل أن تستعيد أموالك.
واحد من تلك التسعة ينتمي إلى Babylon Labs.
العرض هو «ثقة بلا وسطاء»: لا وصيّ ولا شركة تحتفظ بـ BTC الخاصة بك، فقط Bitcoin Script يفرض القواعد. والأمر حقيقي — لا يمكن لمفتاح واحد فقط أن يلمس أموالك بمفرده. لكن فكّ الربط هو الباب الوحيد للعودة إلى عملاتك قبل انتهاء مهلة 15 شهرًا، والفريق الذي بنى هذا الباب يمتلك أيضًا أحد المفاتيح لفتحه.
هذا ليس فضيحة. تمتلك المفاتيح الثمانية الأخرى جهاتٌ موثوقة ومُسماة، ولا يمكن للّجنة سوى الموافقة أو الرفض على المعاملات القياسية — لم يُبنَ النظام ليتمكن من الاستيلاء على BTC لأي شخص. ومع ذلك، إذا قرأت وثائق بابل الخاصة بدقة كافية، فستجد أن المُنشئ مذكور كمُوقِّع على النظام الذي بنته جهة بابل، دون الحاجة إلى مُوقّعين.
اسأل أحد مَسْتَك بابل لماذا نقلوا BTC إلى البروتوكول، وغالبًا ما تكون «ثقة بلا وسطاء» أول كلمة تخرج من فمه. اسألهم من الذي يمسك بالمفتاح رقم واحد، وغالبًا لن يعرفوا أن الإجابة هي Babylon Labs.
$IDOL
هل يؤثر كون المُنشئ يمتلك أحد مفاتيح فكّ الربط على نظرتك إلى «الثقة بلا وسطاء»؟
في كل مرة تفك ربط BTC من بابل، توجد تسع مفاتيح بين بيتكوينك ومحفظتك. يجب أن يوافق ستة منها قبل أن تستعيد أموالك.
واحد من تلك التسعة ينتمي إلى Babylon Labs.
العرض هو «ثقة بلا وسطاء»: لا وصيّ ولا شركة تحتفظ بـ BTC الخاصة بك، فقط Bitcoin Script يفرض القواعد. والأمر حقيقي — لا يمكن لمفتاح واحد فقط أن يلمس أموالك بمفرده. لكن فكّ الربط هو الباب الوحيد للعودة إلى عملاتك قبل انتهاء مهلة 15 شهرًا، والفريق الذي بنى هذا الباب يمتلك أيضًا أحد المفاتيح لفتحه.
هذا ليس فضيحة. تمتلك المفاتيح الثمانية الأخرى جهاتٌ موثوقة ومُسماة، ولا يمكن للّجنة سوى الموافقة أو الرفض على المعاملات القياسية — لم يُبنَ النظام ليتمكن من الاستيلاء على BTC لأي شخص. ومع ذلك، إذا قرأت وثائق بابل الخاصة بدقة كافية، فستجد أن المُنشئ مذكور كمُوقِّع على النظام الذي بنته جهة بابل، دون الحاجة إلى مُوقّعين.
اسأل أحد مَسْتَك بابل لماذا نقلوا BTC إلى البروتوكول، وغالبًا ما تكون «ثقة بلا وسطاء» أول كلمة تخرج من فمه. اسألهم من الذي يمسك بالمفتاح رقم واحد، وغالبًا لن يعرفوا أن الإجابة هي Babylon Labs.
$IDOL
هل يؤثر كون المُنشئ يمتلك أحد مفاتيح فكّ الربط على نظرتك إلى «الثقة بلا وسطاء»؟
🔑 No, still trustless
100%
🔒 Slightly concerning
0%
🚨 Yes, big issue
0%
❓ Didn't know this
0%
1 الأصوات • تمّ إغلاق التصويت
٢ صباحًا، ما زلت مستيقظًا، أقرأ وثائق التحقق/التسجيل بنقطة التفتيش (checkpointing) الخاصة بـ Babylon دون سبب سوى أنني لم أستطع النوم. سطر واحد أوقف تمريري: وجود مراقب/ناشط يقظ واحد وصادق وقائم على الواقع عبر الشبكة يكفي لضمان تحقق نقاط تفتيش ناجحة وآمنة إلى بيتكوين.
اقرأ بسرعة، يبدو كأن اللامركزية تؤدي عملها. عشرات المشغّلين المستقلين، واحد فقط يحتاج إلى أن يتصرف بشكل صحيح.
عدت إلى الورقة البحثية الأكاديمية لعام 2022 الخاصة بـ Babylon، وهي التي شارك في تأليفها مؤسسوها، تلك التي تثبت هذا الادعاء كـ نظرية رسمية بدلًا من كونها عبارة تسويقية. الإثبات يعتمد على شرط واحد: يوجد مُتحقق (validator) صادق واحد يعمل بنشاط طوال الوقت. الورقة تقول ذلك بصراحة.
إليك ما لا تفصح عنه. "واحد كافٍ رياضيًا" و"واحد متصل حاليًا" ضمانان مختلفان. الأول فقط يأتي معه إثبات مُرفق.
ثم ظهرت الجملة نفسها مرة أخرى، هذه المرة بجوار مُحاكي العهد (covenant emulator) وموصل/مرحل IBC (IBC relayer)، مُسماة كبرامج منفصلة خاصة بها: يتطلب التشغيل الآمن وجود على الأقل مشغّل صادق واحد لكل برنامج من البرامج المذكورة، وإلا يرفع النظام إنذارًا. لست متأكدًا إن كان ذلك يغطي الثلاثة بالتساوي، أو إن كانت مكتوبة مع حزمة المراقبة/اليقظة (vigilante suite) وحدها في الاعتبار. على أي حال، عدد الأشخاص يبقى غير منشور.
تسمي Babylon هذا طوعيًا، يمكن لأي شخص تشغيله. صحيح، ومع ذلك لا تقول كم عدد الأشخاص الذين يقومون بذلك حاليًا، ولا ما إذا كان هذا العدد سيظل ثابتًا أثناء قفزة رسوم بيتكوين التي لا أحد يريد دفعها.
هناك سبب لعدم نشر أحد لهذا العدد. كشف مدى رقة الفاصل/الهوامش يساعد المُهاجم أكثر مما يساعدك.
إذا كنت تراهن/تُسند (stake) من خلال Babylon الآن، فهذه هي الافتراضات الكامنة تحت الـ BTC لديك والتي لا تُظهرها لوحة التحكم: ليس ما إذا كانت الرياضيات تعمل، بل ما إذا كان هناك شخص مستيقظ فعلًا ليشغّلها الليلة، ولكل ليلة بعدها.
@BabylonLabs_io $BABY #baby
$1000RATS $KOMA
هل ستراهن/تُسند إذا كان عدد "مشغّل واحد صادق" غير معروف؟ 👀
اقرأ بسرعة، يبدو كأن اللامركزية تؤدي عملها. عشرات المشغّلين المستقلين، واحد فقط يحتاج إلى أن يتصرف بشكل صحيح.
عدت إلى الورقة البحثية الأكاديمية لعام 2022 الخاصة بـ Babylon، وهي التي شارك في تأليفها مؤسسوها، تلك التي تثبت هذا الادعاء كـ نظرية رسمية بدلًا من كونها عبارة تسويقية. الإثبات يعتمد على شرط واحد: يوجد مُتحقق (validator) صادق واحد يعمل بنشاط طوال الوقت. الورقة تقول ذلك بصراحة.
إليك ما لا تفصح عنه. "واحد كافٍ رياضيًا" و"واحد متصل حاليًا" ضمانان مختلفان. الأول فقط يأتي معه إثبات مُرفق.
ثم ظهرت الجملة نفسها مرة أخرى، هذه المرة بجوار مُحاكي العهد (covenant emulator) وموصل/مرحل IBC (IBC relayer)، مُسماة كبرامج منفصلة خاصة بها: يتطلب التشغيل الآمن وجود على الأقل مشغّل صادق واحد لكل برنامج من البرامج المذكورة، وإلا يرفع النظام إنذارًا. لست متأكدًا إن كان ذلك يغطي الثلاثة بالتساوي، أو إن كانت مكتوبة مع حزمة المراقبة/اليقظة (vigilante suite) وحدها في الاعتبار. على أي حال، عدد الأشخاص يبقى غير منشور.
تسمي Babylon هذا طوعيًا، يمكن لأي شخص تشغيله. صحيح، ومع ذلك لا تقول كم عدد الأشخاص الذين يقومون بذلك حاليًا، ولا ما إذا كان هذا العدد سيظل ثابتًا أثناء قفزة رسوم بيتكوين التي لا أحد يريد دفعها.
هناك سبب لعدم نشر أحد لهذا العدد. كشف مدى رقة الفاصل/الهوامش يساعد المُهاجم أكثر مما يساعدك.
إذا كنت تراهن/تُسند (stake) من خلال Babylon الآن، فهذه هي الافتراضات الكامنة تحت الـ BTC لديك والتي لا تُظهرها لوحة التحكم: ليس ما إذا كانت الرياضيات تعمل، بل ما إذا كان هناك شخص مستيقظ فعلًا ليشغّلها الليلة، ولكل ليلة بعدها.
@BabylonLabs_io $BABY #baby
$1000RATS $KOMA
هل ستراهن/تُسند إذا كان عدد "مشغّل واحد صادق" غير معروف؟ 👀
✨ Yes, the math is enough
100%
🤌🏻I'd wnt live operator data
0%
⚠️ That’s a real concern
0%
❓ Didn’t know this
0%
1 الأصوات • تمّ إغلاق التصويت
تمّ التحقق
#baby $BABY @BabylonLabs_io
كنت أعتقد أن التقطيع كان طريقة بابل لمعاقبة عدم الأمانة. تغيّر ذلك عند الساعة 2 صباحًا أثناء تصفّحي تدقيقًا أمنيًا مستقلًا لتنفيذ EOTS، نوع المستند الذي لا يفتحه أحد دون سبب.
الآلية بحد ذاتها أنيقة من حيث مبدأ عملها. يلتزم مُقدّم الحتمية بقطعة من العشوائية قبل توقيع أي بلوك عند مستوى معيّن. إذا تم توقيعها مرة واحدة، فلا يحدث شيء. إذا تم توقيعها مرتين، برسالتين مختلفتين، فإن الرياضيات الكامنة وراء توقيعات شنور تحول نفس العشوائية إلى مفتاحه الخاص المكشوف. يصبح التوقيع المزدوج المتعمد معاقِبًا ذاتيًا بطبيعة التصميم، وهناك سبب لذلك: يمكن للبروتوكول قراءة التوقيعات، لا النوايا، لذا فإن قاعدة صارمة بما يكفي لالتقاط مهاجم لا يمكنها التمييز بين مهاجم وحادثة.
هذا هو التبادل الذي أشارت إليه عملية التدقيق. هجومٌ متعمّد، وبدء تحويل فشل node احتياطي أمين عند نفس الارتفاع، ينتجان نمط التوقيع نفسه تمامًا. كلاهما يبدو مطابقًا تمامًا لـ EOTS. وكلاهما يُقصّ بنفس الطريقة، ويُوضع في سجل tombstoned، دون إمكانية إعادة التفعيل.
هذا ليس مجرد افتراض. تقوم شركة Hex Trust، وهي أمين مؤسسي يشغّل بنية تحتية لمقدمي الحتمية على بابل، بإدراج ضمانات محددة ضد هذا بعينه: عدم إعادة استخدام المفتاح الخاص عبر الأجهزة، وتحويل فشل يدوي بدلًا من التلقائي، لأن التحويل التلقائي هو بالضبط ما يمكنه أن ينتج مُوقّعين مباشرين اثنين لمفتاح واحد في الوقت نفسه.
وهنا الجزء الذي لا توجد له إجابة نظيفة. لا يوجد معيار إفصاح عام حول إعداد التحويل الذي يشغّله مقدم الخدمة. يمكنك التحقق من العمولة، ووقت التوفر، وعدد المفوضين. ليس هذا، ليس قبل أن يكون BTC الخاص بك قد تم قفله بالفعل.
لم يكن التفويض أبدًا مجرد رهان بأن المشغّل لن يهاجمك. إنه أيضًا رهان بأن بنيته التحتية لن تمرّ بيوم سيّئ طالما أن BTC الخاص بك مقفل، على تفصيل يجعل البروتوكول من المستحيل معرفته مسبقًا.
$KOMA
كنت أعتقد أن التقطيع كان طريقة بابل لمعاقبة عدم الأمانة. تغيّر ذلك عند الساعة 2 صباحًا أثناء تصفّحي تدقيقًا أمنيًا مستقلًا لتنفيذ EOTS، نوع المستند الذي لا يفتحه أحد دون سبب.
الآلية بحد ذاتها أنيقة من حيث مبدأ عملها. يلتزم مُقدّم الحتمية بقطعة من العشوائية قبل توقيع أي بلوك عند مستوى معيّن. إذا تم توقيعها مرة واحدة، فلا يحدث شيء. إذا تم توقيعها مرتين، برسالتين مختلفتين، فإن الرياضيات الكامنة وراء توقيعات شنور تحول نفس العشوائية إلى مفتاحه الخاص المكشوف. يصبح التوقيع المزدوج المتعمد معاقِبًا ذاتيًا بطبيعة التصميم، وهناك سبب لذلك: يمكن للبروتوكول قراءة التوقيعات، لا النوايا، لذا فإن قاعدة صارمة بما يكفي لالتقاط مهاجم لا يمكنها التمييز بين مهاجم وحادثة.
هذا هو التبادل الذي أشارت إليه عملية التدقيق. هجومٌ متعمّد، وبدء تحويل فشل node احتياطي أمين عند نفس الارتفاع، ينتجان نمط التوقيع نفسه تمامًا. كلاهما يبدو مطابقًا تمامًا لـ EOTS. وكلاهما يُقصّ بنفس الطريقة، ويُوضع في سجل tombstoned، دون إمكانية إعادة التفعيل.
هذا ليس مجرد افتراض. تقوم شركة Hex Trust، وهي أمين مؤسسي يشغّل بنية تحتية لمقدمي الحتمية على بابل، بإدراج ضمانات محددة ضد هذا بعينه: عدم إعادة استخدام المفتاح الخاص عبر الأجهزة، وتحويل فشل يدوي بدلًا من التلقائي، لأن التحويل التلقائي هو بالضبط ما يمكنه أن ينتج مُوقّعين مباشرين اثنين لمفتاح واحد في الوقت نفسه.
وهنا الجزء الذي لا توجد له إجابة نظيفة. لا يوجد معيار إفصاح عام حول إعداد التحويل الذي يشغّله مقدم الخدمة. يمكنك التحقق من العمولة، ووقت التوفر، وعدد المفوضين. ليس هذا، ليس قبل أن يكون BTC الخاص بك قد تم قفله بالفعل.
لم يكن التفويض أبدًا مجرد رهان بأن المشغّل لن يهاجمك. إنه أيضًا رهان بأن بنيته التحتية لن تمرّ بيوم سيّئ طالما أن BTC الخاص بك مقفل، على تفصيل يجعل البروتوكول من المستحيل معرفته مسبقًا.
$KOMA
تمّ التحقق
$BABY $UAI $COTI #baby @BabylonLabs_io
في البداية افترضت أن لجنة العهود خطوة تمهيدية (bootstrap)، شيء ستتقاعده بابل بمجرد أن ينضج مخططها الخاص، بالطريقة التي تعد بها معظم البروتوكولات الفتية باللامركزية ضمن جدولها الزمني. تقول الوثائق شيئًا أكثر هدوءًا وغرابة من ذلك.
توجد اللجنة لأن بيتكوين نفسها لا تملك طريقة أصلية لفرض العهود، ولا توجد أية تعليمة (opcode) يمكنها إجبار UTXO على الإنفاق فقط وفق قواعد تم الاتفاق عليها مسبقًا. لذلك بنت بابل multisig من 6-of-9 لمحاكاة هذه الوظيفة المفقودة: تراقب طلبات التسييل/الاستيكينغ، وتقوم بالتوقيع المشترك لإلغاء الربط (unbonding) والخصم (slashing)، وتقوم مقام القدرة التي لا يملكها Bitcoin Script ببساطة بعد. هذه الجزء هندسة صادقة حول فجوة حقيقية، وافتراض الثقة هنا أخف حقًا من multisig تقليدي قائم على الحضانة؛ صدق وجودي بدلًا من صدق الأغلبية، فموقّع واحد صادق يكفي لإيقاف السرقة.
ما أوقفني كان شرط الخروج. لا تقول وثائق بابل إن اللجنة تتقاعد بمجرد أن تنضج الحوكمة، أو بمجرد بلوغ حدّ معين من TVL، أو بمجرد وصول بعض المعالم الداخلية للشحن. تقول إن اللجنة تبقى حتى تصبح وظيفة العهود متاحة أصليًا على بيتكوين، عبر تعليمات مثل OP-CAT أو OP-CTV التي لم يتبنّها Bitcoin Core ولا توجد لديه أي خطة زمنية ملتزمة لتبنيها. تاريخ التقاعد ليس موجودًا في خارطة بابل. إنه موجود ضمن عملية حوكمة لبروتوكول آخر؛ بابل لا تملك فيه أي تصويت ولا قدرة على تسريع الأمور.
لذلك لم تختفِ الثقة عندما وصفت بابل هذا كنظام مؤمّن عبر بيتكوين. لقد انتقلت طبقة إلى أبعد—بعيدًا عن multisig ذو عضوية محددة—وعلى شوكة برمجية (soft fork) لبيتكوين قد يتم إطلاقها هذا العقد أو قد لا يتم. ستة من تسعة موقّعين معروفين هي على الأقل افتراض ثقة يمكنك تسميته. ترقية opcode معلّقة دون موعد نهائي هي افتراض ثقة لا يمكنك سوى الانتظار عليه.
تبقى لجنة العهود حتى تضيف بيتكوين تعليمات العهود. لا تتحكم فيها أي خطة زمنية من بابل.
ما رأيك؟ 👀
في البداية افترضت أن لجنة العهود خطوة تمهيدية (bootstrap)، شيء ستتقاعده بابل بمجرد أن ينضج مخططها الخاص، بالطريقة التي تعد بها معظم البروتوكولات الفتية باللامركزية ضمن جدولها الزمني. تقول الوثائق شيئًا أكثر هدوءًا وغرابة من ذلك.
توجد اللجنة لأن بيتكوين نفسها لا تملك طريقة أصلية لفرض العهود، ولا توجد أية تعليمة (opcode) يمكنها إجبار UTXO على الإنفاق فقط وفق قواعد تم الاتفاق عليها مسبقًا. لذلك بنت بابل multisig من 6-of-9 لمحاكاة هذه الوظيفة المفقودة: تراقب طلبات التسييل/الاستيكينغ، وتقوم بالتوقيع المشترك لإلغاء الربط (unbonding) والخصم (slashing)، وتقوم مقام القدرة التي لا يملكها Bitcoin Script ببساطة بعد. هذه الجزء هندسة صادقة حول فجوة حقيقية، وافتراض الثقة هنا أخف حقًا من multisig تقليدي قائم على الحضانة؛ صدق وجودي بدلًا من صدق الأغلبية، فموقّع واحد صادق يكفي لإيقاف السرقة.
ما أوقفني كان شرط الخروج. لا تقول وثائق بابل إن اللجنة تتقاعد بمجرد أن تنضج الحوكمة، أو بمجرد بلوغ حدّ معين من TVL، أو بمجرد وصول بعض المعالم الداخلية للشحن. تقول إن اللجنة تبقى حتى تصبح وظيفة العهود متاحة أصليًا على بيتكوين، عبر تعليمات مثل OP-CAT أو OP-CTV التي لم يتبنّها Bitcoin Core ولا توجد لديه أي خطة زمنية ملتزمة لتبنيها. تاريخ التقاعد ليس موجودًا في خارطة بابل. إنه موجود ضمن عملية حوكمة لبروتوكول آخر؛ بابل لا تملك فيه أي تصويت ولا قدرة على تسريع الأمور.
لذلك لم تختفِ الثقة عندما وصفت بابل هذا كنظام مؤمّن عبر بيتكوين. لقد انتقلت طبقة إلى أبعد—بعيدًا عن multisig ذو عضوية محددة—وعلى شوكة برمجية (soft fork) لبيتكوين قد يتم إطلاقها هذا العقد أو قد لا يتم. ستة من تسعة موقّعين معروفين هي على الأقل افتراض ثقة يمكنك تسميته. ترقية opcode معلّقة دون موعد نهائي هي افتراض ثقة لا يمكنك سوى الانتظار عليه.
تبقى لجنة العهود حتى تضيف بيتكوين تعليمات العهود. لا تتحكم فيها أي خطة زمنية من بابل.
ما رأيك؟ 👀
Safest for now ✅
25%
Uncomfortable, but fair 😕
0%
🚩 Real red flag
75%
Didn’t know this🥱
0%
4 الأصوات • تمّ إغلاق التصويت
كنت أختار مزوِّد “النهائية” الأسبوع الماضي، أنظر إلى قائمة تضم قرابة 30 اسمًا مُتحققًا، وفاجأني نفسي على وشك النقر على الذي لديه بالفعل أكبر عدد من المفوضين. نفس الغريزة التي حوّلت جزءًا كبيرًا من استيكينغ إيثريوم إلى قصة ليدو.
ثم قرأت دليل استيكينغ بابل الخاص فعلًا.
إنه يذكر المخاطر بشكل مباشر: إن التفويض إلى أكثر المزوِّدين شهرة يزيد من مخاطر مركزية النظام. ليست ملاحظة من ناقد؛ توثيقهم هم أنفسهم يقول ذلك.
➡ قرابة 30 مزوِّدًا يحمل علامة تحقق مُعتمدة في التطبيق.
➡ لا شيء في تلك القائمة يضع حدًا لكم يمكن لأي مزوِّد فردي استيعابه من التفويض.
أُعطي بابل حقّه على قول ذلك بصوت عالٍ؛ معظم منتجات الاستيك لا تحذّر المستخدم النهائي قبل أن ينقر.
إليك ما بقي عالقًا في ذهني: علامة التحقق موجودة لبناء الثقة. لكن إذا افترض معظم الميسّرين (الستيكرز) تلقائيًا اسمًا مُتحققًا سبق أن حظي بأكبر عدد من المفوضين—وهو النمط الذي عاشته إيثريوم بالفعل—فالأداة التي كان يُفترض أن تبني الثقة تصبح هي الآلية التي تُركّز الخطر نفسه الذي تحذّر منه.
بحثت عن أرقام فعلية لنصيب التفويض: كم يتحكم المزوِّدون الخمسة أو العشرة الأوائل مجتمعةً. لم أجد شيئًا منشورًا علنًا. وصفٌ خاص ببورصة كريبتو واحدة عن البروتوكول قال إن ذلك “ما زال يتطلب مناقشة إضافية”، وهي مشكلة مفتوحة أشار إليها مصدر خارجي وليست شيئًا عالجته بابل نفسها بشكل موثق.
لذلك قسمت التفويضي بين ثلاثة مزوِّدين أصغر بدلًا من واحد كبير. وعلى هذا النطاق، فمن المحتمل أن يكون الأمر أقرب إلى إشارة رمزية أكثر منه إصلاحًا فعليًا، وأنا أعلم ذلك.
@BabylonLabs_io $BABY #baby $ON
“هل ستفوض عمدًا إلى مزوِّد نهائية أصغر؟”
ثم قرأت دليل استيكينغ بابل الخاص فعلًا.
إنه يذكر المخاطر بشكل مباشر: إن التفويض إلى أكثر المزوِّدين شهرة يزيد من مخاطر مركزية النظام. ليست ملاحظة من ناقد؛ توثيقهم هم أنفسهم يقول ذلك.
➡ قرابة 30 مزوِّدًا يحمل علامة تحقق مُعتمدة في التطبيق.
➡ لا شيء في تلك القائمة يضع حدًا لكم يمكن لأي مزوِّد فردي استيعابه من التفويض.
أُعطي بابل حقّه على قول ذلك بصوت عالٍ؛ معظم منتجات الاستيك لا تحذّر المستخدم النهائي قبل أن ينقر.
إليك ما بقي عالقًا في ذهني: علامة التحقق موجودة لبناء الثقة. لكن إذا افترض معظم الميسّرين (الستيكرز) تلقائيًا اسمًا مُتحققًا سبق أن حظي بأكبر عدد من المفوضين—وهو النمط الذي عاشته إيثريوم بالفعل—فالأداة التي كان يُفترض أن تبني الثقة تصبح هي الآلية التي تُركّز الخطر نفسه الذي تحذّر منه.
بحثت عن أرقام فعلية لنصيب التفويض: كم يتحكم المزوِّدون الخمسة أو العشرة الأوائل مجتمعةً. لم أجد شيئًا منشورًا علنًا. وصفٌ خاص ببورصة كريبتو واحدة عن البروتوكول قال إن ذلك “ما زال يتطلب مناقشة إضافية”، وهي مشكلة مفتوحة أشار إليها مصدر خارجي وليست شيئًا عالجته بابل نفسها بشكل موثق.
لذلك قسمت التفويضي بين ثلاثة مزوِّدين أصغر بدلًا من واحد كبير. وعلى هذا النطاق، فمن المحتمل أن يكون الأمر أقرب إلى إشارة رمزية أكثر منه إصلاحًا فعليًا، وأنا أعلم ذلك.
@BabylonLabs_io $BABY #baby $ON
“هل ستفوض عمدًا إلى مزوِّد نهائية أصغر؟”
🔀 Yes, spread it out
0%
🛡️ No, biggest is safest
0%
💰 Depends on commission
0%
🤷 Never thought about it
100%
1 الأصوات • تمّ إغلاق التصويت
#baby @BabylonLabs_io
كدت قبل أسبوع أن أضع مبلغًا صغيرًا من البيتكوين في مركز إقراض مدعومًا بإيداعات/خزانة (vault). قبل أن أفعل ذلك، أردت أن أعرف شيئًا واحدًا: إذا تحرك السوق بسرعة ضدي، فما الذي يحدد فعليًا متى سيتم تصفيتي (liquidated)؟ هذا السؤال هو ما دفعني للبحث بعيدًا عن التسويق وإلى موقع Babylon نفسه — حيث يتوقف تطبيق كلمة "trustless" حرفيًا. لم تكن مخفية. بل إنها ببساطة لا تصمد أمام الترجمة إلى كل عنوان يُبنى حول تلك الكلمة الواحدة. ➡ صفحة Learn الخاصة بـ Babylon تقولها بوضوح: الخطر الحقيقي يقع في جانب الـ DeFi، وليس داخل الخزانة نفسها، وتستخدم التصفيات في الإقراض كمثال. ➡ الورقة البيضاء تؤكد ذلك: التصفيـة تحتاج إلى توقيع من مزوّد بيانات أسعار (price oracle)، ويُعامل هذا كمكوّن/اعتماد منفصل عن التصميم الأساسي للخزانة. امنح Babylon حقها — فقد كتبت هذا بنفسها. لم يكن على أحد أن يحفر عنها داخلها. الجزء الذي علِق في ذهني، والجزء الذي غيّر فعليًا مقدار ما كنت على وشك إيداعه، كان كالتالي: "مزود بيانات الأسعار" يبدو مفهومًا تجريديًا، حتى إن تقريرًا واحدًا عن هذا النظام تحديدًا ذكر أي الشبكات فعلاً تحمل هذه العلاقة مع Babylon: Band Protocol و Pyth، وهي نفس الشبكات العامة الغرض التي تسعّر عشرات سلاسل أخرى في الوقت نفسه. مواد Babylon الخاصة لا تسميها بشكل مباشر، لذا اعتبر هذا الاقتران المحدد مُبلّغًا عنه، وليس مؤكدًا من Babylon نفسها. إذا تأخر أحد هذه التدفقات أو كان خاطئًا أثناء حركة سريعة، فإن تصفيتي ستظل تحدث تمامًا كما هو مُبرمج. التصرف اعتمادًا على معلومات سيئة — بشكل صحيح من ناحية التنفيذ. طبقة البيتكوين الأساسية لا تُصوّت على نتيجة كهذه. الخزانة تفعل بالضبط ما وعدت به. الجهة المزوِّدة بالأسعار فقط تسلّمها شيئًا غير صحيح. هذا ليس فشلًا من الخزانة. هذا هو خطر الـ DeFi، يرتدي بطاقة/وسم "trustless"، ويستعير أي تاريخ تعطل تحمله بالفعل تغذية السعر الخاصة به من سلاسل أخرى أنا لا أستخدمها حتى. لقد أجريت الإيداع في النهاية. لكن أصغر مما كنت سأفعله قبل ساعة. تعني كلمة trustless ما الذي يحدث لبيتكوينك. لم تكن أبدًا وعدًا حول ما الذي سيحدث لأموالك بمجرد خروجها من الخزانة.
$BROCCOLIF3B $ON $BABY
كدت قبل أسبوع أن أضع مبلغًا صغيرًا من البيتكوين في مركز إقراض مدعومًا بإيداعات/خزانة (vault). قبل أن أفعل ذلك، أردت أن أعرف شيئًا واحدًا: إذا تحرك السوق بسرعة ضدي، فما الذي يحدد فعليًا متى سيتم تصفيتي (liquidated)؟ هذا السؤال هو ما دفعني للبحث بعيدًا عن التسويق وإلى موقع Babylon نفسه — حيث يتوقف تطبيق كلمة "trustless" حرفيًا. لم تكن مخفية. بل إنها ببساطة لا تصمد أمام الترجمة إلى كل عنوان يُبنى حول تلك الكلمة الواحدة. ➡ صفحة Learn الخاصة بـ Babylon تقولها بوضوح: الخطر الحقيقي يقع في جانب الـ DeFi، وليس داخل الخزانة نفسها، وتستخدم التصفيات في الإقراض كمثال. ➡ الورقة البيضاء تؤكد ذلك: التصفيـة تحتاج إلى توقيع من مزوّد بيانات أسعار (price oracle)، ويُعامل هذا كمكوّن/اعتماد منفصل عن التصميم الأساسي للخزانة. امنح Babylon حقها — فقد كتبت هذا بنفسها. لم يكن على أحد أن يحفر عنها داخلها. الجزء الذي علِق في ذهني، والجزء الذي غيّر فعليًا مقدار ما كنت على وشك إيداعه، كان كالتالي: "مزود بيانات الأسعار" يبدو مفهومًا تجريديًا، حتى إن تقريرًا واحدًا عن هذا النظام تحديدًا ذكر أي الشبكات فعلاً تحمل هذه العلاقة مع Babylon: Band Protocol و Pyth، وهي نفس الشبكات العامة الغرض التي تسعّر عشرات سلاسل أخرى في الوقت نفسه. مواد Babylon الخاصة لا تسميها بشكل مباشر، لذا اعتبر هذا الاقتران المحدد مُبلّغًا عنه، وليس مؤكدًا من Babylon نفسها. إذا تأخر أحد هذه التدفقات أو كان خاطئًا أثناء حركة سريعة، فإن تصفيتي ستظل تحدث تمامًا كما هو مُبرمج. التصرف اعتمادًا على معلومات سيئة — بشكل صحيح من ناحية التنفيذ. طبقة البيتكوين الأساسية لا تُصوّت على نتيجة كهذه. الخزانة تفعل بالضبط ما وعدت به. الجهة المزوِّدة بالأسعار فقط تسلّمها شيئًا غير صحيح. هذا ليس فشلًا من الخزانة. هذا هو خطر الـ DeFi، يرتدي بطاقة/وسم "trustless"، ويستعير أي تاريخ تعطل تحمله بالفعل تغذية السعر الخاصة به من سلاسل أخرى أنا لا أستخدمها حتى. لقد أجريت الإيداع في النهاية. لكن أصغر مما كنت سأفعله قبل ساعة. تعني كلمة trustless ما الذي يحدث لبيتكوينك. لم تكن أبدًا وعدًا حول ما الذي سيحدث لأموالك بمجرد خروجها من الخزانة.
$BROCCOLIF3B $ON $BABY
✅ Bitcoin security
0%
📈 Oracle accuracy
0%
⚖️ Both equally
0%
❓Depends on the protocol
0%
0 الأصوات • تمّ إغلاق التصويت
صحيح جزئيًا
#baby $BABY @BabylonLabs_io
كاد أن أضع كمية صغيرة من عملة البيتكوين (BTC) في مركز إقراض مدعومًا بخزنة (vault-backed) الأسبوع الماضي. قبل أن أفعل ذلك، أردت معرفة شيء واحد: إذا تحرك السوق بسرعة ضدي، فما الذي يحدد فعليًا متى يتم تصفيتي (liquidation)؟
هذا السؤال هو ما دفعني للبحث بعيدًا عن المواد التسويقية وإلى موقع بابيلون (Babylon) نفسه، بحثًا عن المكان الذي تتوقف فيه كلمة "trustless" عن العمل.
لم تكن مدفونـة. لكنها ببساطة لا تصمد أمام الترجمة إلى كل عنوان مبني على تلك الكلمة وحدها.
➡ صفحة التعلم الخاصة ببابلون تقول بوضوح إن الخطر الحقيقي يقع على جانب الـ DeFi، وليس داخل الخزنة نفسها، وتضرب مثالًا للتصفية في الإقراض.
➡ الورقة البيضاء تؤكد ذلك: تتطلب عملية التصفية توقيعًا من مزود بيانات أسعار (price oracle)، مع اعتبارها تبعية منفصلة عن التصميم الأساسي للخزنة.
دعونا نُنصف بابلون — لقد كتبوا ذلك بأنفسهم. لم يكن هناك ما يستدعي البحث عنها في مكان آخر.
هذه هي الفقرة التي علقت في ذهني، والتي تغيّرت بسببها كمية الإيداع التي كنت على وشك القيام بها. "مزوّد بيانات الأسعار" تبدو فكرة مجردة، حتى جاء تقرير واحد عن هذا النظام بالذات ذكر الشبكات التي تربطها بعلاقة مع بابلون: Band Protocol و Pyth، وهما نفس الشبكتين متعددتي الاستخدامات اللتين تُسعِّران عشرات سلاسل الكتل الأخرى في الوقت نفسه. لا تذكر المواد الخاصة ببابلون هاتين الشبكتين مباشرةً، لذا اعتبر هذا الاقتران المحدد كما ورد في التقرير، وليس تأكيدًا من بابلون نفسها.
إذا تأخرت إحدى هذه التغذيات أو كانت خاطئة أثناء حركة سريعة، فإن التصفية لدي ستعمل تمامًا كما هي مُبرمجة. بشكل صحيح، التعامل مع معلومات سيئة. الطبقة الأساسية للبيتكوين لا تحصل على تصويت في هذه النتيجة. الخزنة تفعل بالضبط ما وعدت به. الـ oracle فقط يقدم لها شيئًا غير صحيح.
هذا ليس فشلًا من الخزنة. هذا هو خطر الـ DeFi، وهو يرتدي تسمية trustless، وينقل معه أي سجل تعطل/انقطاع (outage history) تحمله تغذية سعره الفعلية القادمة من سلاسل أخرى حتى إنني لا أستخدمها.
لقد قمت بالإيداع في النهاية. لكن أقل مما كنت سأفعله قبل ساعة.
تشير كلمة trustless إلى ما يحدث لـ BTC الخاص بك. لم تكن أبدًا وعدًا بما يحدث لفلوسك بمجرد خروجها من الخزنة.
$EUL
هل يمكن لخزنة trustless أن تعتمد على oracles (مزوّدي بيانات)؟
كاد أن أضع كمية صغيرة من عملة البيتكوين (BTC) في مركز إقراض مدعومًا بخزنة (vault-backed) الأسبوع الماضي. قبل أن أفعل ذلك، أردت معرفة شيء واحد: إذا تحرك السوق بسرعة ضدي، فما الذي يحدد فعليًا متى يتم تصفيتي (liquidation)؟
هذا السؤال هو ما دفعني للبحث بعيدًا عن المواد التسويقية وإلى موقع بابيلون (Babylon) نفسه، بحثًا عن المكان الذي تتوقف فيه كلمة "trustless" عن العمل.
لم تكن مدفونـة. لكنها ببساطة لا تصمد أمام الترجمة إلى كل عنوان مبني على تلك الكلمة وحدها.
➡ صفحة التعلم الخاصة ببابلون تقول بوضوح إن الخطر الحقيقي يقع على جانب الـ DeFi، وليس داخل الخزنة نفسها، وتضرب مثالًا للتصفية في الإقراض.
➡ الورقة البيضاء تؤكد ذلك: تتطلب عملية التصفية توقيعًا من مزود بيانات أسعار (price oracle)، مع اعتبارها تبعية منفصلة عن التصميم الأساسي للخزنة.
دعونا نُنصف بابلون — لقد كتبوا ذلك بأنفسهم. لم يكن هناك ما يستدعي البحث عنها في مكان آخر.
هذه هي الفقرة التي علقت في ذهني، والتي تغيّرت بسببها كمية الإيداع التي كنت على وشك القيام بها. "مزوّد بيانات الأسعار" تبدو فكرة مجردة، حتى جاء تقرير واحد عن هذا النظام بالذات ذكر الشبكات التي تربطها بعلاقة مع بابلون: Band Protocol و Pyth، وهما نفس الشبكتين متعددتي الاستخدامات اللتين تُسعِّران عشرات سلاسل الكتل الأخرى في الوقت نفسه. لا تذكر المواد الخاصة ببابلون هاتين الشبكتين مباشرةً، لذا اعتبر هذا الاقتران المحدد كما ورد في التقرير، وليس تأكيدًا من بابلون نفسها.
إذا تأخرت إحدى هذه التغذيات أو كانت خاطئة أثناء حركة سريعة، فإن التصفية لدي ستعمل تمامًا كما هي مُبرمجة. بشكل صحيح، التعامل مع معلومات سيئة. الطبقة الأساسية للبيتكوين لا تحصل على تصويت في هذه النتيجة. الخزنة تفعل بالضبط ما وعدت به. الـ oracle فقط يقدم لها شيئًا غير صحيح.
هذا ليس فشلًا من الخزنة. هذا هو خطر الـ DeFi، وهو يرتدي تسمية trustless، وينقل معه أي سجل تعطل/انقطاع (outage history) تحمله تغذية سعره الفعلية القادمة من سلاسل أخرى حتى إنني لا أستخدمها.
لقد قمت بالإيداع في النهاية. لكن أقل مما كنت سأفعله قبل ساعة.
تشير كلمة trustless إلى ما يحدث لـ BTC الخاص بك. لم تكن أبدًا وعدًا بما يحدث لفلوسك بمجرد خروجها من الخزنة.
$EUL
هل يمكن لخزنة trustless أن تعتمد على oracles (مزوّدي بيانات)؟
✅ Yes, already knew
0%
🤯 No,I asumed it covered both
0%
0 الأصوات • تمّ إغلاق التصويت
⚡✨
Nova_eth_20
·
--
#baby $BABY @BabylonLabs_io
لم أستطع النوم الليلة الماضية، ففتحت ثلاثة ملخصات منفصلة عن جانب Aave Temp Check في Babylon جنبًا إلى جنب، أكثر بدافع العادة من أي شيء آخر.
كانت هناك كلمة واحدة لا تتوقف عن مضايقتي.
تصف Bitcoin.com وCointribune وLiveBitcoinNews جميع تدفق تصفية TBV بالطريقة نفسها تمامًا. يقوم مُصَفٍّ بدون إذن (permissionless liquidator) بتبادل القبو المُصادَر مقابل WBTC فورًا، مع علاوة صغيرة. ثم يقوم بعد ذلك فريق منفصل من "التحكّميين" (permissioned arbitrageurs) بشراء هذا المركز واسترداد البيتكوين الحقيقي لاحقًا، وفقًا لجدول Bitcoin الخاص به.
منحُ Babylon الفضل للنصف الأول: فحوصات التصفية غير المقيدة (permissionless liquidation) جاءت مطابقة تمامًا لما هو مُعلن.
أما النصف الثاني، فكان ما جعلني أبحث أعمق من اقتراح Aave. لا تذكر ورقة Babylon البيضاء الخاصة بشهر أغسطس عن Trustless Bitcoin Vaults كلمة "permissioned" إطلاقًا. بل تقول إن عمليات التصفية تمر عبر "مُصَفِّين مُدرجين في القائمة المسموح بها" (whitelisted liquidators) يراقبون السعر وحالة القبو. كلمة مختلفة، لكن نفس الشكل. طرح محلل مستقل، تبادل الرسائل مع فريق Babylon على X، نفس النقطة مباشرة معهم: مقدار كافٍ من هذه الأطراف المسموح لها بالتصرف بشكل صحيح هو افتراض ثقة لا تذكره الدعاية.
لذا، اتضح أن الكلمة كانت دقيقة. السؤال الحقيقي هو لماذا يجب أن يُقيَّد هذا الدور على الإطلاق، بينما لا يُقيَّد جانب تبادل WBTC. لغة برمجة Bitcoin لا تستطيع تقييم حالة تعاقدية خارج السلسلة (off-chain) بشكل تعسفي. يعمل BitVM3 حول ذلك عبر تغليف مُتحقق من إثبات معرفة صفر (zero-knowledge proof verifier) داخل دائرة مُشفّرة (garbled circuit)، لكن على أي حال يجب على شخص ما إنشاء ذلك الإثبات وإرساله لتفعيل الاسترداد. جانب تبادل WBTC سهل تركه بدون إذن: أي متصفي (liquidator) لديه رأس مال يمكنه تنفيذ الصفقة. إرسال الإثبات هو المشكلة الأصعب التي لم يحلها BitVM3 بعد.
هذا لا يتعلق بما إذا كان القبو غير قائم على الثقة. لم تُخفِ Babylon عملية إدراج القوائم في ورقتها البيضاء الخاصة بها. لا تختفي اللامركزية/عدم الحاجة للثقة (Trustlessness) هنا. هي فقط تنتهي قبل خطوة واحدة مما تشير إليه معظم التغطية.
$EUL
ما الذي يحدد قبو BTC يكون قائمًا فعلًا على عدم الثقة (trustless)؟
لم أستطع النوم الليلة الماضية، ففتحت ثلاثة ملخصات منفصلة عن جانب Aave Temp Check في Babylon جنبًا إلى جنب، أكثر بدافع العادة من أي شيء آخر.
كانت هناك كلمة واحدة لا تتوقف عن مضايقتي.
تصف Bitcoin.com وCointribune وLiveBitcoinNews جميع تدفق تصفية TBV بالطريقة نفسها تمامًا. يقوم مُصَفٍّ بدون إذن (permissionless liquidator) بتبادل القبو المُصادَر مقابل WBTC فورًا، مع علاوة صغيرة. ثم يقوم بعد ذلك فريق منفصل من "التحكّميين" (permissioned arbitrageurs) بشراء هذا المركز واسترداد البيتكوين الحقيقي لاحقًا، وفقًا لجدول Bitcoin الخاص به.
منحُ Babylon الفضل للنصف الأول: فحوصات التصفية غير المقيدة (permissionless liquidation) جاءت مطابقة تمامًا لما هو مُعلن.
أما النصف الثاني، فكان ما جعلني أبحث أعمق من اقتراح Aave. لا تذكر ورقة Babylon البيضاء الخاصة بشهر أغسطس عن Trustless Bitcoin Vaults كلمة "permissioned" إطلاقًا. بل تقول إن عمليات التصفية تمر عبر "مُصَفِّين مُدرجين في القائمة المسموح بها" (whitelisted liquidators) يراقبون السعر وحالة القبو. كلمة مختلفة، لكن نفس الشكل. طرح محلل مستقل، تبادل الرسائل مع فريق Babylon على X، نفس النقطة مباشرة معهم: مقدار كافٍ من هذه الأطراف المسموح لها بالتصرف بشكل صحيح هو افتراض ثقة لا تذكره الدعاية.
لذا، اتضح أن الكلمة كانت دقيقة. السؤال الحقيقي هو لماذا يجب أن يُقيَّد هذا الدور على الإطلاق، بينما لا يُقيَّد جانب تبادل WBTC. لغة برمجة Bitcoin لا تستطيع تقييم حالة تعاقدية خارج السلسلة (off-chain) بشكل تعسفي. يعمل BitVM3 حول ذلك عبر تغليف مُتحقق من إثبات معرفة صفر (zero-knowledge proof verifier) داخل دائرة مُشفّرة (garbled circuit)، لكن على أي حال يجب على شخص ما إنشاء ذلك الإثبات وإرساله لتفعيل الاسترداد. جانب تبادل WBTC سهل تركه بدون إذن: أي متصفي (liquidator) لديه رأس مال يمكنه تنفيذ الصفقة. إرسال الإثبات هو المشكلة الأصعب التي لم يحلها BitVM3 بعد.
هذا لا يتعلق بما إذا كان القبو غير قائم على الثقة. لم تُخفِ Babylon عملية إدراج القوائم في ورقتها البيضاء الخاصة بها. لا تختفي اللامركزية/عدم الحاجة للثقة (Trustlessness) هنا. هي فقط تنتهي قبل خطوة واحدة مما تشير إليه معظم التغطية.
$EUL
ما الذي يحدد قبو BTC يكون قائمًا فعلًا على عدم الثقة (trustless)؟
$EUL $CHILLGUY Goooo
واعطني ملاحظات
واعطني ملاحظات
Nova_eth_20
·
--
#baby $BABY @BabylonLabs_io
لم أستطع النوم الليلة الماضية، ففتحت ثلاثة ملخصات منفصلة عن جانب Aave Temp Check في Babylon جنبًا إلى جنب، أكثر بدافع العادة من أي شيء آخر.
كانت هناك كلمة واحدة لا تتوقف عن مضايقتي.
تصف Bitcoin.com وCointribune وLiveBitcoinNews جميع تدفق تصفية TBV بالطريقة نفسها تمامًا. يقوم مُصَفٍّ بدون إذن (permissionless liquidator) بتبادل القبو المُصادَر مقابل WBTC فورًا، مع علاوة صغيرة. ثم يقوم بعد ذلك فريق منفصل من "التحكّميين" (permissioned arbitrageurs) بشراء هذا المركز واسترداد البيتكوين الحقيقي لاحقًا، وفقًا لجدول Bitcoin الخاص به.
منحُ Babylon الفضل للنصف الأول: فحوصات التصفية غير المقيدة (permissionless liquidation) جاءت مطابقة تمامًا لما هو مُعلن.
أما النصف الثاني، فكان ما جعلني أبحث أعمق من اقتراح Aave. لا تذكر ورقة Babylon البيضاء الخاصة بشهر أغسطس عن Trustless Bitcoin Vaults كلمة "permissioned" إطلاقًا. بل تقول إن عمليات التصفية تمر عبر "مُصَفِّين مُدرجين في القائمة المسموح بها" (whitelisted liquidators) يراقبون السعر وحالة القبو. كلمة مختلفة، لكن نفس الشكل. طرح محلل مستقل، تبادل الرسائل مع فريق Babylon على X، نفس النقطة مباشرة معهم: مقدار كافٍ من هذه الأطراف المسموح لها بالتصرف بشكل صحيح هو افتراض ثقة لا تذكره الدعاية.
لذا، اتضح أن الكلمة كانت دقيقة. السؤال الحقيقي هو لماذا يجب أن يُقيَّد هذا الدور على الإطلاق، بينما لا يُقيَّد جانب تبادل WBTC. لغة برمجة Bitcoin لا تستطيع تقييم حالة تعاقدية خارج السلسلة (off-chain) بشكل تعسفي. يعمل BitVM3 حول ذلك عبر تغليف مُتحقق من إثبات معرفة صفر (zero-knowledge proof verifier) داخل دائرة مُشفّرة (garbled circuit)، لكن على أي حال يجب على شخص ما إنشاء ذلك الإثبات وإرساله لتفعيل الاسترداد. جانب تبادل WBTC سهل تركه بدون إذن: أي متصفي (liquidator) لديه رأس مال يمكنه تنفيذ الصفقة. إرسال الإثبات هو المشكلة الأصعب التي لم يحلها BitVM3 بعد.
هذا لا يتعلق بما إذا كان القبو غير قائم على الثقة. لم تُخفِ Babylon عملية إدراج القوائم في ورقتها البيضاء الخاصة بها. لا تختفي اللامركزية/عدم الحاجة للثقة (Trustlessness) هنا. هي فقط تنتهي قبل خطوة واحدة مما تشير إليه معظم التغطية.
$EUL
ما الذي يحدد قبو BTC يكون قائمًا فعلًا على عدم الثقة (trustless)؟
لم أستطع النوم الليلة الماضية، ففتحت ثلاثة ملخصات منفصلة عن جانب Aave Temp Check في Babylon جنبًا إلى جنب، أكثر بدافع العادة من أي شيء آخر.
كانت هناك كلمة واحدة لا تتوقف عن مضايقتي.
تصف Bitcoin.com وCointribune وLiveBitcoinNews جميع تدفق تصفية TBV بالطريقة نفسها تمامًا. يقوم مُصَفٍّ بدون إذن (permissionless liquidator) بتبادل القبو المُصادَر مقابل WBTC فورًا، مع علاوة صغيرة. ثم يقوم بعد ذلك فريق منفصل من "التحكّميين" (permissioned arbitrageurs) بشراء هذا المركز واسترداد البيتكوين الحقيقي لاحقًا، وفقًا لجدول Bitcoin الخاص به.
منحُ Babylon الفضل للنصف الأول: فحوصات التصفية غير المقيدة (permissionless liquidation) جاءت مطابقة تمامًا لما هو مُعلن.
أما النصف الثاني، فكان ما جعلني أبحث أعمق من اقتراح Aave. لا تذكر ورقة Babylon البيضاء الخاصة بشهر أغسطس عن Trustless Bitcoin Vaults كلمة "permissioned" إطلاقًا. بل تقول إن عمليات التصفية تمر عبر "مُصَفِّين مُدرجين في القائمة المسموح بها" (whitelisted liquidators) يراقبون السعر وحالة القبو. كلمة مختلفة، لكن نفس الشكل. طرح محلل مستقل، تبادل الرسائل مع فريق Babylon على X، نفس النقطة مباشرة معهم: مقدار كافٍ من هذه الأطراف المسموح لها بالتصرف بشكل صحيح هو افتراض ثقة لا تذكره الدعاية.
لذا، اتضح أن الكلمة كانت دقيقة. السؤال الحقيقي هو لماذا يجب أن يُقيَّد هذا الدور على الإطلاق، بينما لا يُقيَّد جانب تبادل WBTC. لغة برمجة Bitcoin لا تستطيع تقييم حالة تعاقدية خارج السلسلة (off-chain) بشكل تعسفي. يعمل BitVM3 حول ذلك عبر تغليف مُتحقق من إثبات معرفة صفر (zero-knowledge proof verifier) داخل دائرة مُشفّرة (garbled circuit)، لكن على أي حال يجب على شخص ما إنشاء ذلك الإثبات وإرساله لتفعيل الاسترداد. جانب تبادل WBTC سهل تركه بدون إذن: أي متصفي (liquidator) لديه رأس مال يمكنه تنفيذ الصفقة. إرسال الإثبات هو المشكلة الأصعب التي لم يحلها BitVM3 بعد.
هذا لا يتعلق بما إذا كان القبو غير قائم على الثقة. لم تُخفِ Babylon عملية إدراج القوائم في ورقتها البيضاء الخاصة بها. لا تختفي اللامركزية/عدم الحاجة للثقة (Trustlessness) هنا. هي فقط تنتهي قبل خطوة واحدة مما تشير إليه معظم التغطية.
$EUL
ما الذي يحدد قبو BTC يكون قائمًا فعلًا على عدم الثقة (trustless)؟
#baby $BABY @BabylonLabs_io
لم أستطع النوم الليلة الماضية، ففتحت ثلاثة ملخصات منفصلة عن جانب Aave Temp Check في Babylon جنبًا إلى جنب، أكثر بدافع العادة من أي شيء آخر.
كانت هناك كلمة واحدة لا تتوقف عن مضايقتي.
تصف Bitcoin.com وCointribune وLiveBitcoinNews جميع تدفق تصفية TBV بالطريقة نفسها تمامًا. يقوم مُصَفٍّ بدون إذن (permissionless liquidator) بتبادل القبو المُصادَر مقابل WBTC فورًا، مع علاوة صغيرة. ثم يقوم بعد ذلك فريق منفصل من "التحكّميين" (permissioned arbitrageurs) بشراء هذا المركز واسترداد البيتكوين الحقيقي لاحقًا، وفقًا لجدول Bitcoin الخاص به.
منحُ Babylon الفضل للنصف الأول: فحوصات التصفية غير المقيدة (permissionless liquidation) جاءت مطابقة تمامًا لما هو مُعلن.
أما النصف الثاني، فكان ما جعلني أبحث أعمق من اقتراح Aave. لا تذكر ورقة Babylon البيضاء الخاصة بشهر أغسطس عن Trustless Bitcoin Vaults كلمة "permissioned" إطلاقًا. بل تقول إن عمليات التصفية تمر عبر "مُصَفِّين مُدرجين في القائمة المسموح بها" (whitelisted liquidators) يراقبون السعر وحالة القبو. كلمة مختلفة، لكن نفس الشكل. طرح محلل مستقل، تبادل الرسائل مع فريق Babylon على X، نفس النقطة مباشرة معهم: مقدار كافٍ من هذه الأطراف المسموح لها بالتصرف بشكل صحيح هو افتراض ثقة لا تذكره الدعاية.
لذا، اتضح أن الكلمة كانت دقيقة. السؤال الحقيقي هو لماذا يجب أن يُقيَّد هذا الدور على الإطلاق، بينما لا يُقيَّد جانب تبادل WBTC. لغة برمجة Bitcoin لا تستطيع تقييم حالة تعاقدية خارج السلسلة (off-chain) بشكل تعسفي. يعمل BitVM3 حول ذلك عبر تغليف مُتحقق من إثبات معرفة صفر (zero-knowledge proof verifier) داخل دائرة مُشفّرة (garbled circuit)، لكن على أي حال يجب على شخص ما إنشاء ذلك الإثبات وإرساله لتفعيل الاسترداد. جانب تبادل WBTC سهل تركه بدون إذن: أي متصفي (liquidator) لديه رأس مال يمكنه تنفيذ الصفقة. إرسال الإثبات هو المشكلة الأصعب التي لم يحلها BitVM3 بعد.
هذا لا يتعلق بما إذا كان القبو غير قائم على الثقة. لم تُخفِ Babylon عملية إدراج القوائم في ورقتها البيضاء الخاصة بها. لا تختفي اللامركزية/عدم الحاجة للثقة (Trustlessness) هنا. هي فقط تنتهي قبل خطوة واحدة مما تشير إليه معظم التغطية.
$EUL
ما الذي يحدد قبو BTC يكون قائمًا فعلًا على عدم الثقة (trustless)؟
لم أستطع النوم الليلة الماضية، ففتحت ثلاثة ملخصات منفصلة عن جانب Aave Temp Check في Babylon جنبًا إلى جنب، أكثر بدافع العادة من أي شيء آخر.
كانت هناك كلمة واحدة لا تتوقف عن مضايقتي.
تصف Bitcoin.com وCointribune وLiveBitcoinNews جميع تدفق تصفية TBV بالطريقة نفسها تمامًا. يقوم مُصَفٍّ بدون إذن (permissionless liquidator) بتبادل القبو المُصادَر مقابل WBTC فورًا، مع علاوة صغيرة. ثم يقوم بعد ذلك فريق منفصل من "التحكّميين" (permissioned arbitrageurs) بشراء هذا المركز واسترداد البيتكوين الحقيقي لاحقًا، وفقًا لجدول Bitcoin الخاص به.
منحُ Babylon الفضل للنصف الأول: فحوصات التصفية غير المقيدة (permissionless liquidation) جاءت مطابقة تمامًا لما هو مُعلن.
أما النصف الثاني، فكان ما جعلني أبحث أعمق من اقتراح Aave. لا تذكر ورقة Babylon البيضاء الخاصة بشهر أغسطس عن Trustless Bitcoin Vaults كلمة "permissioned" إطلاقًا. بل تقول إن عمليات التصفية تمر عبر "مُصَفِّين مُدرجين في القائمة المسموح بها" (whitelisted liquidators) يراقبون السعر وحالة القبو. كلمة مختلفة، لكن نفس الشكل. طرح محلل مستقل، تبادل الرسائل مع فريق Babylon على X، نفس النقطة مباشرة معهم: مقدار كافٍ من هذه الأطراف المسموح لها بالتصرف بشكل صحيح هو افتراض ثقة لا تذكره الدعاية.
لذا، اتضح أن الكلمة كانت دقيقة. السؤال الحقيقي هو لماذا يجب أن يُقيَّد هذا الدور على الإطلاق، بينما لا يُقيَّد جانب تبادل WBTC. لغة برمجة Bitcoin لا تستطيع تقييم حالة تعاقدية خارج السلسلة (off-chain) بشكل تعسفي. يعمل BitVM3 حول ذلك عبر تغليف مُتحقق من إثبات معرفة صفر (zero-knowledge proof verifier) داخل دائرة مُشفّرة (garbled circuit)، لكن على أي حال يجب على شخص ما إنشاء ذلك الإثبات وإرساله لتفعيل الاسترداد. جانب تبادل WBTC سهل تركه بدون إذن: أي متصفي (liquidator) لديه رأس مال يمكنه تنفيذ الصفقة. إرسال الإثبات هو المشكلة الأصعب التي لم يحلها BitVM3 بعد.
هذا لا يتعلق بما إذا كان القبو غير قائم على الثقة. لم تُخفِ Babylon عملية إدراج القوائم في ورقتها البيضاء الخاصة بها. لا تختفي اللامركزية/عدم الحاجة للثقة (Trustlessness) هنا. هي فقط تنتهي قبل خطوة واحدة مما تشير إليه معظم التغطية.
$EUL
ما الذي يحدد قبو BTC يكون قائمًا فعلًا على عدم الثقة (trustless)؟
⚡ Permissionless liquidation
100%
🔓 Permissionless redemption
0%
🤔 Not sure yet
0%
⚖️ Both are equally important
0%
1 الأصوات • تمّ إغلاق التصويت
انضم
英鸿³³₇
·
--
[إعادة تشغيل] 🎙️ تحدث عن المحبة والكراهية في السوق الأولية، والاستثمار الدوري في السوق الثانوية لـbnb
02 ساعة 17 دقيقة 48 ثانية · 12.8k يستمعون
$DEXE Goooooo 👉🏻
Mù 穆涵
·
--
#baby $BABY @BabylonLabs_io
tجمعان من نفس الأصل، يفصل بينهما بضعة “نقرات” على الخريطة، دون أي اتصال بينهما حتى الآن. لدى Aave تقريبًا 5 مليارات دولار من WBTC لا يتحرك كثيرًا في جانب الاقتراض. وتحتفظ Babylon بما يزيد عن 4 مليارات دولار في BTC مُرهَن، ولا تحقق شيئًا يتجاوز عوائد الرهن.
هذه هي في الواقع “العرض” المطمور داخل اختبار Temp Check الخاص بـ Babylon — وليس “بيتكوين بلا ثقة”، بل مطابقة المعروض الخامل على منصة واحدة مع الضمان الخامل على منصة أخرى.
تصميم Aave بنمط Hub-and-Spoke في V4 هو ما يجعل ذلك ممكنًا دون أن تلمس Babylon الإطلاقًا النواة الأساسية لإقراض Aave. يتم نشر Spokeَين جديدين كوحدات معزولة — تمتلك Babylon منطق ضمان BTC، بينما يبقى Hub الرئيسي لدى Aave دون تغيير من أي مخاطر قد يَستتبعها ذلك.
تجدر الإشارة: هذه ليست مقترحًا مجتمعيًا يطفو في الخلفية دون أن يلاحظه أحد. فقد دعمها مؤسس Aave بنفسه علنًا، مشيرًا تحديدًا إلى تنفيذ الـ Spoke باعتباره نمطًا جديدًا لـ V4 — وليس مجرد إضافة أصل آخر.
لا يزال الأمر في مرحلة Temp Check. يجب أن يتم كل من ARFC والتصويت على السلسلة قبل أن تتحرك أي BTC فعلًا عبر ذلك.
إذا كانت كلتا المجموعتين ما زالتا جالستين بخمول بعد بضعة أشهر من اجتياز هذه الخطوة عبر الحوكمة، فالمشكلة لم تكن في “السباكة”. بل كانت في الشهية.
$DEXE
ما الأهم إذا تم تفعيل ذلك فعلاً؟
tجمعان من نفس الأصل، يفصل بينهما بضعة “نقرات” على الخريطة، دون أي اتصال بينهما حتى الآن. لدى Aave تقريبًا 5 مليارات دولار من WBTC لا يتحرك كثيرًا في جانب الاقتراض. وتحتفظ Babylon بما يزيد عن 4 مليارات دولار في BTC مُرهَن، ولا تحقق شيئًا يتجاوز عوائد الرهن.
هذه هي في الواقع “العرض” المطمور داخل اختبار Temp Check الخاص بـ Babylon — وليس “بيتكوين بلا ثقة”، بل مطابقة المعروض الخامل على منصة واحدة مع الضمان الخامل على منصة أخرى.
تصميم Aave بنمط Hub-and-Spoke في V4 هو ما يجعل ذلك ممكنًا دون أن تلمس Babylon الإطلاقًا النواة الأساسية لإقراض Aave. يتم نشر Spokeَين جديدين كوحدات معزولة — تمتلك Babylon منطق ضمان BTC، بينما يبقى Hub الرئيسي لدى Aave دون تغيير من أي مخاطر قد يَستتبعها ذلك.
تجدر الإشارة: هذه ليست مقترحًا مجتمعيًا يطفو في الخلفية دون أن يلاحظه أحد. فقد دعمها مؤسس Aave بنفسه علنًا، مشيرًا تحديدًا إلى تنفيذ الـ Spoke باعتباره نمطًا جديدًا لـ V4 — وليس مجرد إضافة أصل آخر.
لا يزال الأمر في مرحلة Temp Check. يجب أن يتم كل من ARFC والتصويت على السلسلة قبل أن تتحرك أي BTC فعلًا عبر ذلك.
إذا كانت كلتا المجموعتين ما زالتا جالستين بخمول بعد بضعة أشهر من اجتياز هذه الخطوة عبر الحوكمة، فالمشكلة لم تكن في “السباكة”. بل كانت في الشهية.
$DEXE
ما الأهم إذا تم تفعيل ذلك فعلاً؟
صحيح جزئيًا
#baby $BABY @BabylonLabs_io
كنتُ أقرأ ملاحظات ترحيل Aave من v3 إلى v4 الليلة الماضية، غالبًا من باب الملل، وجملة واحدة من ورقة “vault” الخاصة بـ Babylon عالقة بذهني بعد أن أغلقت التبويب: شروط إنفاق صندوق الـ TBV، بما في ذلك عقد الوجهة، ثابتة لحظة إنشائه؛ وهذا هو حرفيًا ما يجعله عديم الثقة (trustless). لا يمكن لأي أحد إعادة توجيه الـ BTC لاحقًا دون ذلك المسار المتفق عليه مسبقًا. ما يعنيه ذلك بهدوء هو أنه إذا قام Aave مرة أخرى بترحيل العقود بالطريقة نفسها التي حدثت من v3 إلى v4، فإن الـ vault الموجود لا يمكنه المضي قدمًا؛ بل يجب أن يفكّ (unwind) على الجدول الزمني الخاص بـ Bitcoin وأن يُعاد إنشاؤه مُوجَّهًا إلى الوجهة الجديدة، في كل مرة تقوم فيها بروتوكول الوجهة بترقية. إن “عديم الثقة” هنا ليس مجانيًا؛ بل يُشترى مقابل الصرامة (rigidity)، ولا أحد يبدو أنه يُسعّر ذلك. لم أجد أي تفاصيل عامة حول ما إذا كان لدى Babylon أو Aave أدوات مخططة لجعل هذا الانتقال أكثر سلاسة. هذه ليست مسألة تتعلق بمدى أمان الـ vault الذي يبدو عليه يوم تنشئه، بل بما يحدث في اليوم الذي يجب فيه تغيير الجهة الأخرى منه.
$DEXE
ما المقايضة الأكبر هنا؟
كنتُ أقرأ ملاحظات ترحيل Aave من v3 إلى v4 الليلة الماضية، غالبًا من باب الملل، وجملة واحدة من ورقة “vault” الخاصة بـ Babylon عالقة بذهني بعد أن أغلقت التبويب: شروط إنفاق صندوق الـ TBV، بما في ذلك عقد الوجهة، ثابتة لحظة إنشائه؛ وهذا هو حرفيًا ما يجعله عديم الثقة (trustless). لا يمكن لأي أحد إعادة توجيه الـ BTC لاحقًا دون ذلك المسار المتفق عليه مسبقًا. ما يعنيه ذلك بهدوء هو أنه إذا قام Aave مرة أخرى بترحيل العقود بالطريقة نفسها التي حدثت من v3 إلى v4، فإن الـ vault الموجود لا يمكنه المضي قدمًا؛ بل يجب أن يفكّ (unwind) على الجدول الزمني الخاص بـ Bitcoin وأن يُعاد إنشاؤه مُوجَّهًا إلى الوجهة الجديدة، في كل مرة تقوم فيها بروتوكول الوجهة بترقية. إن “عديم الثقة” هنا ليس مجانيًا؛ بل يُشترى مقابل الصرامة (rigidity)، ولا أحد يبدو أنه يُسعّر ذلك. لم أجد أي تفاصيل عامة حول ما إذا كان لدى Babylon أو Aave أدوات مخططة لجعل هذا الانتقال أكثر سلاسة. هذه ليست مسألة تتعلق بمدى أمان الـ vault الذي يبدو عليه يوم تنشئه، بل بما يحدث في اليوم الذي يجب فيه تغيير الجهة الأخرى منه.
$DEXE
ما المقايضة الأكبر هنا؟
🔒 Stronger security
33%
🔄 Easier upgrades
0%
⚖️ Need both
0%
🤔 Still researching
67%
6 الأصوات • تمّ إغلاق التصويت
سجّل الدخول لاستكشاف المزيد من المُحتوى