الآن أرى Babylon، وأبسط عبارة قد تُساء فُهمها هي: «BTC ما زال موجودًا دائمًا في محفظتك». العبارة صحيحة، لكن غير مكتملة. لأن حق التحكم في الأصول لا يتوقف فقط على وجود المفتاح الخاص، بل أيضًا على ما إذا كان بإمكان هذا الـ BTC في المستقبل أن يُنفق بالطريقة التي تريدها. @BabylonLabs_io
ستكنج Bitcoin في Babylon ليس نقلًا عبر السلاسل (cross-chain) ولا تسليمه إلى طرف وسيط للتخزين (托管)؛ وهذه نقطة أكثر وضوحًا في حدود الأمان مقارنةً بـ wrapped BTC. لكن بمجرد دخول الـ BTC في معاملة staking، يتم كتابته في مسار مُعدّ مسبقًا ضمن سكربت Taproot: خروج عند الاستحقاق بشكل طبيعي، أو unbonding، أو slashing—وفي كل مسار شروطه الخاصة. أنت ما زلت تملك المفتاح الخاص، لكن الأصول لم تعد في حالة «يمكن تحويلها وقتما تريد». #baby
وهذا مهم جدًا. فالخروج العادي يتطلب انتظار فترة قفل زمني والالتزام بإجراءات البروتوكول؛ أما unbonding فليس مجرد تحويل عادي، بل تبديل حالة مُقيّدًا بواسطة السكربت. وبالنسبة لمسار slashing الأكثر تطرفًا، فسيشمل أيضًا سلوك Finality Provider والأدلة الخاصة بـ EOTS وشروط مرتبطة بـ Covenant Committee. بمعنى آخر، Babylon يحافظ على صفة عدم الحِيازة/الوكالة (non-custodial)، لكنه يقيّد القدرة على الإنفاق بحرية. $BTC
أعتقد أن هذا ليس أمرًا سيئًا؛ بل هو شرط يتيح للـ BTC توفير الأمان الاقتصادي لشبكات PoS خارجية. بدون هذه القيود على السكربت، فإن ما يُسمى staking سيكون مجرد وعد شفهي، ولن تستطيع السلسلة الخارجية أن تجعل الـ BTC ميزانية أمان يمكن معاقبتها.
لكن على المستخدم أن يفهم: وجود المفتاح الخاص لا يعني أن نموذج التحكم لم يتغير. ما يعيد Babylon فعلاً تشكيله هو «قواعد كيفية إنفاق BTC». ومن الأشياء التي تهمني لاحقًا أكثر: هل يفهم المستخدم العادي قيود unbonding وslashing، وهل ستصبح حدود صلاحيات Covenant Committee أكثر صلابة مع توسع الحجم. $ETH
اللامركزية/عدم الحِيازة هي نقطة البداية، وليست كل شيء. $BABY كي يبقى الأمر ثابتًا على المدى الطويل، يجب أن تجعل المستخدمين يفهمون بوضوح: الـ BTC الذي أقفلُوه في النظام، ما القواعد التي تُقيّده تحديدًا؟
ستكنج Bitcoin في Babylon ليس نقلًا عبر السلاسل (cross-chain) ولا تسليمه إلى طرف وسيط للتخزين (托管)؛ وهذه نقطة أكثر وضوحًا في حدود الأمان مقارنةً بـ wrapped BTC. لكن بمجرد دخول الـ BTC في معاملة staking، يتم كتابته في مسار مُعدّ مسبقًا ضمن سكربت Taproot: خروج عند الاستحقاق بشكل طبيعي، أو unbonding، أو slashing—وفي كل مسار شروطه الخاصة. أنت ما زلت تملك المفتاح الخاص، لكن الأصول لم تعد في حالة «يمكن تحويلها وقتما تريد». #baby
وهذا مهم جدًا. فالخروج العادي يتطلب انتظار فترة قفل زمني والالتزام بإجراءات البروتوكول؛ أما unbonding فليس مجرد تحويل عادي، بل تبديل حالة مُقيّدًا بواسطة السكربت. وبالنسبة لمسار slashing الأكثر تطرفًا، فسيشمل أيضًا سلوك Finality Provider والأدلة الخاصة بـ EOTS وشروط مرتبطة بـ Covenant Committee. بمعنى آخر، Babylon يحافظ على صفة عدم الحِيازة/الوكالة (non-custodial)، لكنه يقيّد القدرة على الإنفاق بحرية. $BTC
أعتقد أن هذا ليس أمرًا سيئًا؛ بل هو شرط يتيح للـ BTC توفير الأمان الاقتصادي لشبكات PoS خارجية. بدون هذه القيود على السكربت، فإن ما يُسمى staking سيكون مجرد وعد شفهي، ولن تستطيع السلسلة الخارجية أن تجعل الـ BTC ميزانية أمان يمكن معاقبتها.
لكن على المستخدم أن يفهم: وجود المفتاح الخاص لا يعني أن نموذج التحكم لم يتغير. ما يعيد Babylon فعلاً تشكيله هو «قواعد كيفية إنفاق BTC». ومن الأشياء التي تهمني لاحقًا أكثر: هل يفهم المستخدم العادي قيود unbonding وslashing، وهل ستصبح حدود صلاحيات Covenant Committee أكثر صلابة مع توسع الحجم. $ETH
اللامركزية/عدم الحِيازة هي نقطة البداية، وليست كل شيء. $BABY كي يبقى الأمر ثابتًا على المدى الطويل، يجب أن تجعل المستخدمين يفهمون بوضوح: الـ BTC الذي أقفلُوه في النظام، ما القواعد التي تُقيّده تحديدًا؟