أريد اليوم أن أتحدث عن رقم محدد جدًا: الحجم البرمجي لسكربت الـ vault في Babylon.
حدّ weight للكتلة في بيتكوين هو 4 ملايين وحدة، والمعاملة القياسية عادةً ما تشغل حوالي 200-300 وحدة. لكن معاملة إنشاء vault الخاصة بـ TBV أكبر بكثير من المعاملات العادية، لأنها تتضمن سكربت covenant معقدًا، وإثباتات لمسار Merkle، ومنطق التوقيع المتعدد.
قمت بحساب تقريبي: معاملة إنشاء TBV vault قياسية يكون weightها تقريبًا بين 1500-2500 وحدة. وهذا يعني أنه يمكن للكتلة الواحدة في بيتكوين أن تستوعب بحد أقصى حوالي 1600-2600 معاملة إنشاء vault. إذا ارتفع عدد مستخدمي Babylon، فقد يؤدي مجرد إنشاء الـ vault إلى استهلاك جزء كبير من مساحة الكتل.
وهذا يطرح مشكلتين.
الأولى هي مشكلة المنافسة. عندما تتنافس معاملة إنشاء الـ vault مع معاملات بيتكوين العادية الأخرى على مساحة الكتلة، من يدفع أكثر يُدرَّج أولاً. يمكن للأحجام الكبيرة تعيين رسوم الغاز (Gas) مرتفعة للدخول في المقدمة؛ أما صغار المستخدمين فيبقون ينتظرون ببطء أو يدفعون رسومًا أعلى. وهذا يشبه تمامًا حرب الـ Gas على الإيثيريوم من حيث الجوهر، فقط أن ساحة المعركة انتقلت من EVM إلى الشبكة الرئيسية لبيتكوين.
الثانية هي مشكلة الاستدامة طويلة المدى. إذا حقق Babylon بالفعل مستوى مستخدمين بالملايين، فستتدفق يوميًا آلاف من معاملات إنشاء الـ vault واستردادها إلى شبكة بيتكوين. فهل ستكون مساحة الكتل كافية؟ نفس المشكلة التي واجهتها Lightning Network سابقًا، سيُحتّم أن يواجهها Babylon عاجلاً أم آجلاً.
أرى أن لدى Babylon حلين للتعامل مع ذلك. الأول هو تجميع الاسترداد: دمج عدة طلبات استرداد في معاملة واحدة للمعالجة، وتقليل الأثر على السلسلة. والثاني هو تشجيع الاحتفاظ طويل الأمد: كلما طال قفل الأموال، انخفضت التكلفة المضمّنة لإنشاء الـ vault.
لكن هذه كلها مجرد تخفيفات وليست علاجًا جذريًا. طالما أن الطبقة الأساسية ما زالت هي الشبكة الرئيسية لبيتكوين، فإن سقف الإنتاجية موجود هناك.
@BabylonLabs_io $BABY #baby
حدّ weight للكتلة في بيتكوين هو 4 ملايين وحدة، والمعاملة القياسية عادةً ما تشغل حوالي 200-300 وحدة. لكن معاملة إنشاء vault الخاصة بـ TBV أكبر بكثير من المعاملات العادية، لأنها تتضمن سكربت covenant معقدًا، وإثباتات لمسار Merkle، ومنطق التوقيع المتعدد.
قمت بحساب تقريبي: معاملة إنشاء TBV vault قياسية يكون weightها تقريبًا بين 1500-2500 وحدة. وهذا يعني أنه يمكن للكتلة الواحدة في بيتكوين أن تستوعب بحد أقصى حوالي 1600-2600 معاملة إنشاء vault. إذا ارتفع عدد مستخدمي Babylon، فقد يؤدي مجرد إنشاء الـ vault إلى استهلاك جزء كبير من مساحة الكتل.
وهذا يطرح مشكلتين.
الأولى هي مشكلة المنافسة. عندما تتنافس معاملة إنشاء الـ vault مع معاملات بيتكوين العادية الأخرى على مساحة الكتلة، من يدفع أكثر يُدرَّج أولاً. يمكن للأحجام الكبيرة تعيين رسوم الغاز (Gas) مرتفعة للدخول في المقدمة؛ أما صغار المستخدمين فيبقون ينتظرون ببطء أو يدفعون رسومًا أعلى. وهذا يشبه تمامًا حرب الـ Gas على الإيثيريوم من حيث الجوهر، فقط أن ساحة المعركة انتقلت من EVM إلى الشبكة الرئيسية لبيتكوين.
الثانية هي مشكلة الاستدامة طويلة المدى. إذا حقق Babylon بالفعل مستوى مستخدمين بالملايين، فستتدفق يوميًا آلاف من معاملات إنشاء الـ vault واستردادها إلى شبكة بيتكوين. فهل ستكون مساحة الكتل كافية؟ نفس المشكلة التي واجهتها Lightning Network سابقًا، سيُحتّم أن يواجهها Babylon عاجلاً أم آجلاً.
أرى أن لدى Babylon حلين للتعامل مع ذلك. الأول هو تجميع الاسترداد: دمج عدة طلبات استرداد في معاملة واحدة للمعالجة، وتقليل الأثر على السلسلة. والثاني هو تشجيع الاحتفاظ طويل الأمد: كلما طال قفل الأموال، انخفضت التكلفة المضمّنة لإنشاء الـ vault.
لكن هذه كلها مجرد تخفيفات وليست علاجًا جذريًا. طالما أن الطبقة الأساسية ما زالت هي الشبكة الرئيسية لبيتكوين، فإن سقف الإنتاجية موجود هناك.
@BabylonLabs_io $BABY #baby