(المصدر: قيمة سوق الشركات)
تم إنشاء بيتكوين في عام 2008 من قبل مطور مجهول، وقد نما ليصبح أصولًا ضخمة، حيث احتل المركز السابع من حيث رأس المال السوقي بين جميع فئات الأصول. وأصبح الآن معترفًا به ليس فقط من قبل المؤسسات المالية ولكن حتى من قبل الرئيس الأمريكي. حاليًا، يتمتع بيتكوين برأس المال السوقي المماثل لفضة. نظرًا لأن اعتماد بيتكوين لا يزال منخفضًا نسبيًا وأن رأس المال السوقي له لا يزال يمثل عُشرًا واحدًا فقط من ذهب، فإن الإمكانات المستقبلية لنموه تظل واعدة للغاية.
على الرغم من النمو الهائل لبيتكوين كأصل، إلا أن هناك نقصا كبيرا ما زال قائما، وهو مستوى استخدامه. يمكن استخدام الأصول التقليدية مثل الأسهم والسندات في مجموعة واسعة من المنتجات المالية، لكن تطبيقات بيتكوين المالية لا تزال محدودة للغاية، سواء من الناحية التقنية أو العملية. على غرار أيام الحدود في الغرب الأمريكي، يمثل بيتكوين أرضًا غير مستغلة من الفرص.
نظرًا لحجم رأس المال السوقي الهائل الذي يتمتع به، سعت العديد من الشركات والبروتوكولات إلى استغلال بيتكوين لإنشاء ائتمان إضافي. وتشمل المحاولات الرئيسية لاستخدام بيتكوين حتى الآن:
فحص هذه المحاولات لاستخدام BTC يكشف عن تحدي مشترك - فمن الصعب استخدام بيتكوين بطريقة أصلية. إحدى أكبر نقاط قوة بيتكوين هي أمانها، ولكن إذا ضعفت افتراضات الثقة الإضافية هذا الأمان، فإنه يخلق عائقاً كبيراً لحاملي BTC. هذا هو السبب الرئيسي الذي يجعل مستوى استخدام بيتكوين يبقى منخفضاً نسبياً.
هذا هو المكان@babylonlabs_ioيأتي إلى التركيز. يتيح بابلون لحاملي BTC الرهان على بتكوين بشكل أصلي على شبكة بتكوين والمشاركة في التحقق من البروتوكولات الأخرى للنسبة المئوية للحصة، مكتسبين مكافآت إضافية.
بفضل استخدام BTC دون افتراضات الثقة الإضافية، تمكنت Babylon بسرعة من تحقيق أكثر من 5 مليارات دولار أمريكي في قيمة القرض بالتثبيت. كان بإمكان قيمة القرض بالتثبيت أن تكون أعلى لو لم تكن هناك حدود تثبيت على BTC.
ولكن انتظر، لغة سكريبت بيتكوين غير كاملة تورينغ، مما يعني أنها لا يمكن أن تدعم بسهولة العقود الذكية المعقدة. إذا، كيف تدير بابل لتحقيق هذه الوظيفة؟ في هذه المقالة، سنكتشف الآليات الدقيقة وراء عمل بابل.
هل يمكننا أن نصل أي وقت مضى إلى استخدام بي تي سي الأصلي الحقيقي مثل بناء برج بابل؟
مهمة بابل هي توسيع بتكوين لتأمين العالم اللامركزي. على الرغم من أنه من المعروف على نطاق واسع بأنه بروتوكول لحيازة بتكوين، إلا أن بابل تقدم أيضًا خدمات تسجيل الزمن لبتكوين، مكونة مجموعة من بروتوكولات مشاركة الأمان لبتكوين.
بابل مكون من بروتوكولين رئيسيين:
(المصدر: بابلون)
تُوضَّح الهندسة المعمارية الأساسية لبابل في الرسم البياني أعلاه، مع سلسلة بابل، التي تم بناؤها على Cosmos SDK، في صميمها. بالإضافة إلى سلسلة بابل، تُيَسِّر البرامج الطرفية العديدة الرهان على BTC والتواصل مع بتكوين ومناطق المستهلك الأخرى. تشير مناطق المستهلك إلى سلاسل PoS التي تسجل نقاط تفتيش على شبكة بتكوين من خلال بابل.
يتكون سلسلة بابل من وحدات مختلفة تؤدي وظائف أساسية داخل النظام البيئي، بما في ذلك إدارة مجموعة المحققين، وتتبع رؤوس كتل Bitcoin، وتقديم نقاط التحقق إلى شبكة Bitcoin، وإدارة مجموعة مزودي الثبات النشطة المتعلقة بالمراهنة على BTC. للإشارة، مزود الثبات مشابه لمشغل AVS في EigenLayer، مما يعني أنه يشارك في التحقق من بروتوكولات PoS أخرى.
بالإضافة إلى ذلك، نفذت بابل برامج داعمة عدة لتيسير التواصل السلس بين شبكة بيتكوين وسلسلة بابلون:
من خلال هذا النظام البيئي، يمكن لبابلون تمكين صناعة العملات المشفرة من الاستفادة من أمان بيتكوين القوي والسيولة العميقة. الآن، دعونا نستكشف ميزتي بابلون الأساسيتين بمزيد من التفصيل: تسجيل الوقت لبيتكوين والرهان على بيتكوين.
أي شخص قد حصل على رهن الرموز من قبل سيعرف أن إلغاء الرهن يتطلب عادة فترة انتظار تتراوح بين 1 إلى 2 أسبوع. خلال هذه الفترة، لا يمكن استخدام الرموز أو كسب الفائدة، مما يسبب عدم الكفاءة. ولكن لماذا يتطلب إلغاء الرهن فترة انتظار؟ لماذا لا تسمح بالسحب الفوري؟
أبسط سبب هو أمان الشبكة. إذا كان إلغاء الرهن فوريًا، يمكن إلغاء كميات كبيرة من الرموز ردًا على تقلبات السوق، مما يضعف بشكل كبير أمان الشبكة. ومع ذلك، بخلاف الأمان، هناك سبب آخر أساسي: منع الهجمات على المدى الطويل.
(المصدر: AP)
هجوم على مسافات طويلة يشير إلى هجوم يقوم فيه المحققون الخبيثون بإنشاء فork جديد يبدأ من الكتل السابقة، في محاولة لاستبدال السلسلة الكنسية الحالية. إذا أصبحت السلسلة الفرعية الخبيثة بنفس طول أو أطول من السلسلة الكنسية، فقد تصبح العقد الجديدة المنضمة إلى الشبكة مرتبكة بشأن أي سلسلة هي الشرعية، مما يؤدي إلى قضايا محتملة. ولكن انتظر - هل هذا ممكن حتى؟
في شبكة PoW، يكاد يكون من المستحيل تنفيذ هجوم عن بعد بعيد. للحاق بسلسلة الكتل القانونية الحالية، سيحتاج المهاجمون إلى إعادة إنشاء كتل جديدة من الماضي متجاوزين قوة الحوسبة للشبكة القائمة، وهو أمر غير قابل للتنفيذ عملياً.
بالمثل، في شبكة PoS تعمل بشكل صحيح، هذا الهجوم أيضًا مستحيل. إن إنشاء فورك جديد سيتطلب من المحققين الخبيثين توقيع كتل متضاربة متعددة، وهو ما يعتبر التوقيع المزدوج—انتهاك للبروتوكول يؤدي إلى تقطيع العقوبات.
وماذا لو سمح التحصيل فورا؟
على عكس شبكات PoW، لا تتطلب شبكات PoS قوة حسابية ضخمة لتوليد الكتل. وهذا يعني أنه إذا قام المحققون الخبيثون بإلغاء رهن أصولهم من السلسلة الحالية ثم إنشاء سلسلة مشعبة جديدة من كتلة سابقة حيث كانت مفاتيح المحقق الخاصة بهم صالحة ما زالوا، فإنهم قد يمكنهم بشكل محتمل اللحاق بالسلسلة الكنونية الحالية. في هذ scenar، قد تصارع العقد الجديدة التي تنضم إلى الشبكة لتحديد أي سلسلة هي الشرعية، مما قد يؤدي إلى الارتباك ومخاطر الأمان المحتملة.
(مصدر: بابل)
إذا نجح الهجوم عن بُعد، يمكن للمحققين الخبيثين استغلال آليات الجسر لسرقة الأموال. على سبيل المثال، لنفترض أن مهاجمًا خبيثًا يُدعى جون ينقل 1 مليون رمز RUG من سلسلة RugPull إلى Osmosis ويبادلها برموز OSMO. يحدث هذا التحويل من خلال IBC، الذي يعمل عن طريق قفل الرموز الأصلية RUG على سلسلة RugPull أثناء ضخ ما يعادله من رموز RUG على سلسلة Osmosis.
(المصدر: بابل)
إذا افترضنا أن جون نفذ بنجاح هجومًا عن بُعد على سلسلة RugPull، فيمكنه حذف الصفقة بشكل خبيث التي قفلت رموز RUG لإرسالها إلى سلسلة Osmosis في السلسلة المشعبة الجديدة. ونتيجة لذلك، سيحصل جون بشكل فعال على رموز OSMO مجانًا.
لمنع الهجمات عن بعد الطويلة، من الضروري وجود فترة فك الرهن لفترة معينة. لا يمكن للمهاجمين الخبيثين تنفيذ هجوم عن بعد طويل الأجل خلال فترة فك الرهن (إذا حاولوا ذلك، سيواجهون عقوبات القطع). بالإضافة إلى ذلك، خلال هذه الفترة، يمكن للمشاركين في الشبكة التوصل إلى اتفاق اجتماعي بشأن أي سلسلة هي السلسلة الكنونية. نتيجة لذلك، حتى إذا حدث هجوم عن بعد طويل الأجل في وقت لاحق، من غير المرجح أن تتم قبول السلسلة الخبيثة المشعبة من قبل الشبكة.
فترة فك الرهن هي طريقة فعالة لمنع الهجمات على مدى بعيد، ولكنها تأتي مع بعض العيوب.
القضية الأولى هي أنها تعتمد على التوافق الاجتماعي للتصدي للهجمات. بينما يمكن أن تلعب التواصل خارج السلسلة بين المشاركين دورًا حاسمًا على مدى فترة كافية، إلا أنها ليست حلاً مضموناً بنسبة 100٪.
المشكلة الثانية هي أنه، كما ذُكر سابقاً، يؤثر فترة إلغاء العقد الطويلة سلباً على تجربة المستخدم والسيولة.
بابل يقدم حلا يسمى التسمية الزمنية لبيتكوين، مما يتيح لسلاسل PoS تقليل فترات عدم الاستقرار بشكل كبير إلى ساعات قليلة فقط. يتيح هذا لسلاسل PoS تسجيل بيانات كتل سلسلة الكانونية على شبكة البيتكوين.
مع الطابع الزمني، حتى لو حاول المحققون الخبيثون هجومًا على مدى بعيد وادعوا أن سلسلتهم المنقسمة هي السلسلة القانونية، فإن هجومهم لن ينجح - لأن بيانات السلسلة القانونية الأصلية مسجلة بالفعل بشكل آمن على شبكة بيتكوين. طالما بقيت أمانة بيتكوين سليمة، فإن الهجوم مضمون للفشل. نظرًا لأن هذا النهج يقضي على الحاجة إلى التوافق الاجتماعي، فإنه يسمح بتقليل كبير في فترة الفك.
(مصدر: بابل)
هنا، يتم تسجيل البيتكوين بتأريخ باستخدام عملية OP_RETURN في شبكة البيتكوين. OP_RETURN هي تعليمة تسمح بتخزين ما يصل إلى 80 بايتًا من البيانات التعسفية على شبكة البيتكوين. على عكس المعاملات العادية في البيتكوين، لا يمكن استخدام OP_RETURN لنقل الأموال ولا يولد UTXOs.
إحدى النقاط الرئيسية المهمة هي ما إذا كان بإمكان جميع سلاسل PoS إنشاء نقاط تفتيش مباشرة على شبكة بيتكوين. حيث تكون كتل بيتكوين صغيرة الحجم، وتمتلك وقت كتلة يبلغ 10 دقائق، ويمكن لـ OP_RETURN تخزين حد أقصى يبلغ 80 بايتًا من البيانات. إذا قامت سلاسل PoS العديدة بإرسال معاملات فحص متكررة، فإن شبكة بيتكوين لن تكون قادرة على تحمل العبء.
لحل هذه المشكلة، تُقدم بابليون سلسلة بابليون، التي تجمع نقاط التفتيش من عدة سلاسل PoS عبر IBC ثم تقدم نقطة تفتيش مجمعة واحدة إلى شبكة بيتكوين.
جزء أساسي من هذه العملية هو Vigilante Relayer، كيان مسؤول عن قراءة نقاط التفتيش من عقدة Babylon، وتغليفها في معاملات OP_RETURN، ثم تقديمها إلى شبكة Bitcoin. يتطلب النظام وجود مرسل Vigilante صادق وحي للعمل بشكل صحيح على الأقل.
(المصدر: بابلون)
يحدث تحديد الوقت BTC على النحو التالي: تقوم سلاسل PoS بتقديم نقاط تفتيش تحتوي على معلومات الكتل إلى سلسلة بابلون. تقوم سلسلة بابلون بتقديم نقطة فحص لكتل بابلون إلى شبكة بيتكوين عند الكتلة النهائية لكل حقبة.
(المصدر: بابل)
حتى لو حدث هجوم عن بعد طويل المدى، سيكون لدى نقطة التفتيش في السلسلة المشعولة الخبيثة دائمًا الطابع الزمني لاحق من نقطة التفتيش في السلسلة القانونية. وهذا يعني أن المشاركين في الشبكة يمكنهم ببساطة التحقق من نقطة التفتيش في شبكة البيتكوين لتحديد الشواخص الخبيثة بسهولة. نظرًا لأن هذا النهج يقضي على الحاجة إلى التوافق الاجتماعي، يمكن تقليل فترة فك الرهن من عدة أسابيع إلى بضع ساعات فقط.
يقوم توقيت بيتكوين في بابل بالمزيد من تحسين تجربة المستخدم وكفاءة السيولة من خلال تقليل فترات سحب PoS—كما أنه يوفر أيضًا فوائد إضافية متنوعة.
من خلال اعتماد الانتهاء البطيء من خلال بابل، يمكن لسلاسل PoS تحقيق مستوى أمان يمكن مقارنته ببيتكوين. عندما يتم تسجيل كتلة PoS تحتوي على معاملة معينة على شبكة بيتكوين زمنيًا وتأكيدها من خلال ست كتل بيتكوين، تصبح المعاملة لا يمكن عكسها - طالما بقي أمان بيتكوين سليمًا.
هذا الآليّة مفيدة لمعالجة المعاملات ذات القيمة العالية، مثل عمليات شراء العقارات، حيث تكون الأمانة المطلقة ضرورية. بالإضافة إلى ذلك، بالنسبة لمناطق Cosmos الجديدة التي قد تكون أمانها أضعف، يمكن أن يوفر تنفيذ النهاية البطيء طبقة إضافية من الحماية لمعالجة المعاملات بشكل آمن.
يمكن أيضًا أن يساعد تسجيل الوقت في بيتكوين على استعادة الحيوية في حالة هجوم الرقابة على سلسلة PoS. لمعالجة هذا، تقدم بابلون مفهومًا خاصًا يُسمى وضع اللف.
في سلسلة PoS التقليدية، يجب أن تكون ما لا يقل عن ثلثي (2/3) المحققين شرفاء للحفاظ على مقاومة الرقابة. ومع ذلك، مع وضع rollup في بابلون، يكفي أن يكون نصف (1/2) المحققين شرفاء لتحقيق مقاومة الرقابة، مما يحسن بشكل كبير من مرونة السلسلة ضد الهجمات.
(المصدر: بابليون)
إذا كان مستخدم سلسلة PoS يعتقد أنه يتم رقابة معينة على معاملة معينة، فيمكنه تقديم شكوى بشأن الرقابة (الجزء الأحمر في الرسم البياني) إلى سلسلة Babylon، مما يبدأ عملية الدخول في وضع التجميع. تحتوي الشكوى بشأن الرقابة على تجزئة المعاملة المراقبة.
إذا، بعد ست تأكيدات لكتل Bitcoin، لم تتم تضمين الصفقة المحجوبة المشتبه بها في سلسلة PoS، سيقوم المحققون الصادقون بتقديم آرائهم حول سلسلة PoS إلى Babylon. إذا، بعد ست تأكيدات إضافية لكتل Bitcoin، لم يتم اكتشاف نقطة فحص متعلقة بالصفقة المحجوبة في أي كتلة Bitcoin، سيدخل المحققون والمستخدمون الصادقون في وضع التجميع النهائي.
في وضع اللف، يمكن لأي محقق اقتراح حزمة من معاملات PoS، وإذا وقع المحققون الذين يمتلكون ما لا يقل عن نصف (1/2) من الرهان الإجمالي على الحزمة، سيتم تثبيت المعاملة على شبكة البيتكوين، وبالتالي منع الرقابة بشكل فعال.
يُسمح لتسجيل الوقت في بيتكوين لسلاسل PoS باستغلال أمان بيتكوين لتقليل فترات فك تثبيت الرهن وتعزيز مقاومة الرقابة، ولكن هذا يستغل الأمان المتاح في بيتكوين جزئيًا فقط.
بعد البتكوين تمبرستامبينغ، تقدم بابلون بيتكوين ستاكينغ، الذي ينفذ بشكل أصلي ستاكينغ بيتكوين باستخدام لغة سكريبت البيتكوين. يتيح هذا لبروتوكولات أخرى للمنافع من أمان بيتكوين الاقتصادي التشفيري. تم تصميم بروتوكول الستاكينغ على أنه إضافة قابلة للتعديل، مما يجعله سهل التكيف مع بروتوكولات موافقة PoS مختلفة.
بالنسبة لمالكي BTC، فإن الرهان على بيتكوين في بابلون يُعتبر فرصة استثمارية جذابة حيث يمكنهم رهن BTC على مستوى أمان بيتكوين دون الاعتماد على كيانات خارجية، مع كسب مكافآت من البروتوكولات الخارجية أيضًا.
دعونا نحدد بعض المصطلحات الرئيسية:
لكن انتظر - على عكس إثريوم، شبكة بيتكوين ليست كاملة التورينغ، مما يجعل من الصعب تنفيذ عقود الرهان المعقدة. فكيف يتحقق بابلون من ذلك؟
لنستكشف التفاصيل من خلال مثال من مدونة بابلون.
// العقد V0: إضافة شرط قفل إلى إشارة البيانات غير المصروفة لأليس
الشرط-1 (القفل): time_lock = 1000 & alice_public_key
لنفترض أن آليس تراهن على بتكوين وتعمل أيضًا كمزود نهائي. لتنفيذ تراهن البتكوين، يُطلب توفير آلية لقفل البتكوين. يتم تحقيق ذلك عن طريق تعيين أحد شروط إنفاق UTXO بحيث يمكن لآليس (مالك البتكوين) سحب الأموال بعد فترة زمنية معينة (time_lock = 1000) باستخدام مفتاحها العام (alice_public_key).
// العقد V1: إضافة تقطيع سذاجة
الشرط 1 (القفل): time_lock = 1000 & alice_public_key؛ أو
الحالة-2 (التقطيع): alice_eots_public_key
أحد العناصر الأساسية التي يجب تنفيذها في الحصة هو الحذف. إذا حدث إجراء خبيث، يمكن تنفيذ آلية حوافز من خلال حرق BTC المراهنة. لتحقيق ذلك، يتم تعيين شرط إنفاق UTXO الثاني بحيث يمكن حدوث الحذف إذا كان شخص ما يمتلك مفتاح EOTS الخاص بـ Alice.
هنا، EOTS (Extractable One-Time Signature) هو توقيع تم تنفيذه باستخدام تواقيع Schnorr، التي تم تقديمها بعد ترقية Bitcoin's Taproot. ببساطة، هو خوارزمية تضمن أنه إذا قام ممثل شرير بتوقيع مزدوج على كتلتين مختلفتين في نفس الارتفاع باستخدام نفس المفتاح، يتم الكشف عن مفتاحهم السري علنًا.
عند النظر في هذا بمزيد من التفصيل، تتكون توقيع Schnorr من مفتاح خاص x، ومفتاح عام P=xG، وترمز عشوائية k. عملية التوقيع كما يلي: يتم إنشاء ترمز عشوائي k، ويتم حساب القيمة العامة R=kG من الترمز. ثم، يتم حساب قيمة التجزئة e من الرسالة M و R، وتتم حساب قيمة التوقيع s بناءً على الترمز و e، حيث s = k + ex. تتكون توقيع Schnorr النهائي من (s، R).
الفكرة الأساسية لـ EOTS هي أنه إذا تم استخدام نفس المفتاح مرتين للتوقيع، فإن المفتاح الخاص يتعرض. إذا قامت أليس بتوقيع رسالتين مختلفتين باستخدام نفس القيمة العشوائية k، فإن التوقيع الأول هو s1= k + e_1x والتوقيع الثاني هو s2= k + e_2x. نظرًا لأن s1، s2، e1، e2 معروفة علنًا، يمكن لأي شخص حل للحصول على المفتاح الخاص لأليس x باستخدام المعادلة x=(s1 - s2)/(e1 - e2).
باستخدام هذئ الآلية، إذا قامت أليس بتوقيع رسالتين مختلفتين بشكل خبيث باستخدام نفس مفتاح EOTS أثناء عملية التحقق من BSN، يمكن لأي شخص يكتشف ذلك استخراج مفتاح أليس السري EOTS. بمجرد كشف مفتاح EOTS السري، يمكن للمهاجم إما سرقة BTC المرهونة لدى أليس أو حرق BTC المرهونة لدى أليس كعقوبة.
// عقد V2
الشرط-1 (القفل): time_lock = 1000 & alice_public_key؛ OR
الشرط-2 (القطع): مفتاح الجمهور الخاص بـ Alice_eots ونصاب اللجنة العهد
// عملية تقليح V0
المدخلات:
النواتج:
0000...0000
// الموافقة المسبقة V0: فرض الحرق
// لجنة العهد توقع مسبقًا على عملية تقليص الرسوم أعلاه كموافقة مسبقة
نظرًا لأننا ناقشنا سابقًا الشروط التي يحدث فيها التقليص، دعونا الآن نفحص كيف يتم فعليًا تنفيذ التقليص. تنفيذ التقليص أمر حاسم لأنه، إذا قامت أليس بسلوك خبيث، فقد تحاول سحب BTC الخاص بها قبل أن يكتشف أحدهم السلوك غير القانوني، ويستخرج مفتاح EOTS السري الخاص بها، ويحرق BTC الخاص بها.
لمنع هذا، يجب تنفيذ القطع في طريقة تقوم بنقل BTC بقوة إلى عنوان حرق محدد مسبقًا (0000…0000). ولتحقيق ذلك، تتضمن شرط الإنفاق الثاني UTXO لجنة العهد. تتولى لجنة العهد مسؤولية التحقق مما إذا كان القطع مشروعًا. من خلال دمج نظام التوقيع المتعدد (M-of-N)، يضمن النظام أن لا يمكن لأليس سحب BTC بها بمفردها إلى محفظتها الخاصة قبل تنفيذ القطع.
ميزة هذا النهج هي أنه طالما تتصرف أليس بصدق، فإن توقيع EOTS الخاص بها لا يتعرض أبدًا، مما يعني أن لجنة العهد لا يمكنها الاستيلاء على أموالها. لذلك، لا يحتاج أليس إلى الثقة في لجنة العهد، حيث لا يمكن لهم القيام بأي إجراء ضدها ما لم تنخرط في سلوك خبيث.
// العقد V3: تمكين التفويض الآمن
condition-1 (القفل): time_lock = 1000 & alice_public_key; OR
الشرط-2 (التخفيض): مفتاح_عليس_العام ومفتاح_بوابة_المحفظة_العام ونصاب_لجنة_العهد
// عملية تقليص V0
المدخلات:
النواتج:
0000...0000
// الموافقة المسبقة V1
// يقوم أليس بتوقيع معاملة القطع كموافقة مسبقة.
// لجنة العهد توقع مسبقًا على تقليص عملية التحويل كموافقة مسبقة لها.
يمكن لأليس أن ترهن BTC مباشرة والمشاركة في التحقق من البروتوكولات الأخرى لنظام النفاذ كمزود نهائي. ومع ذلك، سيختار معظم المستخدمين تفويض ترهين BTC الخاص بهم.
لتنفيذ هذا، إضافة مفتاح EOTS للمحقق إلى الشرط الثاني يضمن أنه إذا تورط المحقق في سلوك خبيث، يمكن حرق بيتكوين أليس. ومع ذلك، المشكلة هنا هي أنه إذا تواطأ المحقق مع لجنة العهد، يمكنهم سرقة بيتكوين أليس، مما يجبر أليس على الثقة بالمحقق.
الحل البسيط لهذه المشكلة هو أيضًا تضمين مفتاح Alice العام في الشرط الثاني. بهذه الطريقة، سيتطلب حرق BTC توقيع Alice أيضًا، مما يمنع سرقة BTC غير المصرح بها.
لتحقيق ذلك، توقعت أليس مسبقًا عملية تحويل تنص على أنه "إذا حدث تقليص، يجب إرسال BTC إلى عنوان الحرق." في هذه الحالة، إذا تصرف المحقق بشكل خبيث وتمت كشف مفتاح EOTS الخاص به، وإذا قامت اللجنة العهدية بتنفيذ توقيع متعدد، سيتم إرسال BTC إلى عنوان الحرق، مما يفرض عملية التقليص.
/ عقد V3
الشرط-1 (القفل): time_lock = 1000 & مفتاح عليس العام؛ OR
الشرط-2 (الحذف): مفتاح عليس العام ومفتاح بوابة المطابقة ونصاب اللجنة التأسيسية
// عملية تخفيض العملات V0
المدخلات:
النواتج:
0000...0000
// الموافقة المسبقة V2: فرض تخفيض ذري عند التفويض
تصريح Alice's المسبق هو توقيع محول لصفقة القطع
// تم إنشاؤه باستخدام مفتاح EOTS العام للمحقق.
وقعت لجنة العهد مسبقا على قطع tx كموافقة مسبقة عليها.
ماذا لو استهدف محقق البيانات الخبيث مراهنين محددين فقط للتقليص؟ لمنع هذا، تقدم Babylon توقيعات المحول.
عاليس تقوم بتشفير توقيعها باستخدام مفتاح EOTS العام للمحقق كتوقيع محول. إذا حاول المحقق خفض عقوبة على عاليس فقط، يجب عليه استخدام مفتاحه الخاص EOTS. نتيجة لطبيعة توقيعات المحول، سيؤدي هذا إلى كشف مفتاح المحقق الخاص EOTS، مما يزيل أي دافع للمحققين للانخراط في سلوك خبيث.
// عقد V3
condition-1 (القفل): time_lock = 1000 & alice_public_key; أو
الحالة 2 (القطع): alice_public_key و validator_eots_public_key و covenant_committee_quorum
// عملية الحذف V1: تمكين الحذف الجزئي
الإدخالات:
النواتج:
الناتج-1: القيمة = 0.09 بيتكوين، المالك = 0000...0000
الناتج-2: القيمة = 0.9 بيتكوين،
الشروط:
// الموافقة المسبقة V2
تصريح مسبق من Alice هو توقيع محول لصفقة القطع
// تم إنشاؤها باستخدام مفتاح EOTS العام للمحقق.
// لجنة العهد توقع مسبقًا على عملية تقليص التكلفة كجزء من الموافقة المسبقة.
ولكن هل لا تعتقد أن حرق كل البيتكوين في حالة التقليص هو أمر مبالغ فيه؟ لمعالجة هذا، يمكن حرق جزء فقط من البيتكوين (على سبيل المثال، حرق 10٪ فقط بينما يتم إعادة الـ 90٪ المتبقية بعد فترة معينة). يمكن تنفيذ ذلك عن طريق تقسيم مخرجات عملية التقليص إلى قسمين، كما هو موضح أعلاه.
العقد V4: تمكين إعادة التخزين
الشرط-1 (القفل): time_lock = 1000 & alice_public_key؛ OR
الشرط-2 (التقطيع): مفتاح عام لليس & أي توقيع من القائمة [مفتاح عام للمحقق] & نصاب لجنة العهد
يمكن لـ BTC المُفوّض لـ Alice المشاركة في التحقق من صحة عدة بروتوكولات PoS، وليس فقط واحدة. إذا شارك محقق في التحقق من صحة بروتوكولات PoS مختلفة باستخدام نفس مفتاح EOTS، فإن أي تسرب في مكان واحد قد يؤثر على الأنظمة الأخرى. لذلك، يجب على موفّرو Babylon النهائيين استخدام مفاتيح EOTS مختلفة لأنظمة PoS مختلفة، ويتم تقديم قائمة بمفاتيح EOTS في الشرط الثاني.
على عكس شبكات PoS مثل Ethereum أو Solana ، تعمل شبكة Bitcoin على PoW ، لذا فإن مفهوم التخزين غير موجود بطبيعته. ومع ذلك ، فقد نفذت Babylon ميزات قفل BTC وقطعها وتفويضها اللازمة للتكديس من خلال خصائص UTXOs ولغة البرمجة النصية الخاصة ب Bitcoin وخوارزميات التوقيع المختلفة. يتيح ذلك لحاملي BTC كسب أرباح إضافية أصلا من خلال استخدام BTC ، دون الحاجة إلى الجسور أو خدمات الوصاية.
بصرف النظر عن شبكة Lightning ، لا يوجد بروتوكول آخر يرث أمان شبكة Bitcoin بالكامل. ومع ذلك ، تماما مثل شبكة Bitcoin ، فإن وظائف شبكة Lightning Network محدودة للغاية ، ومن الثمين جدا التخلي عن أمان Bitcoin القوي والسيولة الهائلة.
قام بابليون بتمكين استخدام أمان بيتكوين بطريقتين مختلفتين من خلال تسجيل الوقت في بيتكوين والرهان على بيتكوين. يستخدم الأول بيتكوين كخادم للطابع الزمني لمنع عكس الصفقة أو الشوكات الخبيثة، في حين يستغل الثاني سيولة بيتكوين القوية كأمان اقتصادي للربح الإضافي، مما يسمح لحاملي بيتكوين بكسب أرباح إضافية بطريقة طبيعية.
حاليًا، يتم إيداع ما يقرب من 55،000 BTC في بابل، وهو ما يتساوى مع الحد الأقصى للإيداع المحدد من قبل بابل. حوالي 3.9% من إجمالي إمدادات ETH يتم إعادة رهنها على EigenLayer. باعتبار ذلك، على الرغم من أن حاملي BTC قد يكونون محافظين في استخدام BTC، فإن الإمكانات النمو لبابل، مع نسبة تقريبية تبلغ حاليًا 0.2% فقط من إجمالي إمدادات BTC المرهونة، تستحق النظر.
(المصدر: قيمة سوق الشركات)
تم إنشاء بيتكوين في عام 2008 من قبل مطور مجهول، وقد نما ليصبح أصولًا ضخمة، حيث احتل المركز السابع من حيث رأس المال السوقي بين جميع فئات الأصول. وأصبح الآن معترفًا به ليس فقط من قبل المؤسسات المالية ولكن حتى من قبل الرئيس الأمريكي. حاليًا، يتمتع بيتكوين برأس المال السوقي المماثل لفضة. نظرًا لأن اعتماد بيتكوين لا يزال منخفضًا نسبيًا وأن رأس المال السوقي له لا يزال يمثل عُشرًا واحدًا فقط من ذهب، فإن الإمكانات المستقبلية لنموه تظل واعدة للغاية.
على الرغم من النمو الهائل لبيتكوين كأصل، إلا أن هناك نقصا كبيرا ما زال قائما، وهو مستوى استخدامه. يمكن استخدام الأصول التقليدية مثل الأسهم والسندات في مجموعة واسعة من المنتجات المالية، لكن تطبيقات بيتكوين المالية لا تزال محدودة للغاية، سواء من الناحية التقنية أو العملية. على غرار أيام الحدود في الغرب الأمريكي، يمثل بيتكوين أرضًا غير مستغلة من الفرص.
نظرًا لحجم رأس المال السوقي الهائل الذي يتمتع به، سعت العديد من الشركات والبروتوكولات إلى استغلال بيتكوين لإنشاء ائتمان إضافي. وتشمل المحاولات الرئيسية لاستخدام بيتكوين حتى الآن:
فحص هذه المحاولات لاستخدام BTC يكشف عن تحدي مشترك - فمن الصعب استخدام بيتكوين بطريقة أصلية. إحدى أكبر نقاط قوة بيتكوين هي أمانها، ولكن إذا ضعفت افتراضات الثقة الإضافية هذا الأمان، فإنه يخلق عائقاً كبيراً لحاملي BTC. هذا هو السبب الرئيسي الذي يجعل مستوى استخدام بيتكوين يبقى منخفضاً نسبياً.
هذا هو المكان@babylonlabs_ioيأتي إلى التركيز. يتيح بابلون لحاملي BTC الرهان على بتكوين بشكل أصلي على شبكة بتكوين والمشاركة في التحقق من البروتوكولات الأخرى للنسبة المئوية للحصة، مكتسبين مكافآت إضافية.
بفضل استخدام BTC دون افتراضات الثقة الإضافية، تمكنت Babylon بسرعة من تحقيق أكثر من 5 مليارات دولار أمريكي في قيمة القرض بالتثبيت. كان بإمكان قيمة القرض بالتثبيت أن تكون أعلى لو لم تكن هناك حدود تثبيت على BTC.
ولكن انتظر، لغة سكريبت بيتكوين غير كاملة تورينغ، مما يعني أنها لا يمكن أن تدعم بسهولة العقود الذكية المعقدة. إذا، كيف تدير بابل لتحقيق هذه الوظيفة؟ في هذه المقالة، سنكتشف الآليات الدقيقة وراء عمل بابل.
هل يمكننا أن نصل أي وقت مضى إلى استخدام بي تي سي الأصلي الحقيقي مثل بناء برج بابل؟
مهمة بابل هي توسيع بتكوين لتأمين العالم اللامركزي. على الرغم من أنه من المعروف على نطاق واسع بأنه بروتوكول لحيازة بتكوين، إلا أن بابل تقدم أيضًا خدمات تسجيل الزمن لبتكوين، مكونة مجموعة من بروتوكولات مشاركة الأمان لبتكوين.
بابل مكون من بروتوكولين رئيسيين:
(المصدر: بابلون)
تُوضَّح الهندسة المعمارية الأساسية لبابل في الرسم البياني أعلاه، مع سلسلة بابل، التي تم بناؤها على Cosmos SDK، في صميمها. بالإضافة إلى سلسلة بابل، تُيَسِّر البرامج الطرفية العديدة الرهان على BTC والتواصل مع بتكوين ومناطق المستهلك الأخرى. تشير مناطق المستهلك إلى سلاسل PoS التي تسجل نقاط تفتيش على شبكة بتكوين من خلال بابل.
يتكون سلسلة بابل من وحدات مختلفة تؤدي وظائف أساسية داخل النظام البيئي، بما في ذلك إدارة مجموعة المحققين، وتتبع رؤوس كتل Bitcoin، وتقديم نقاط التحقق إلى شبكة Bitcoin، وإدارة مجموعة مزودي الثبات النشطة المتعلقة بالمراهنة على BTC. للإشارة، مزود الثبات مشابه لمشغل AVS في EigenLayer، مما يعني أنه يشارك في التحقق من بروتوكولات PoS أخرى.
بالإضافة إلى ذلك، نفذت بابل برامج داعمة عدة لتيسير التواصل السلس بين شبكة بيتكوين وسلسلة بابلون:
من خلال هذا النظام البيئي، يمكن لبابلون تمكين صناعة العملات المشفرة من الاستفادة من أمان بيتكوين القوي والسيولة العميقة. الآن، دعونا نستكشف ميزتي بابلون الأساسيتين بمزيد من التفصيل: تسجيل الوقت لبيتكوين والرهان على بيتكوين.
أي شخص قد حصل على رهن الرموز من قبل سيعرف أن إلغاء الرهن يتطلب عادة فترة انتظار تتراوح بين 1 إلى 2 أسبوع. خلال هذه الفترة، لا يمكن استخدام الرموز أو كسب الفائدة، مما يسبب عدم الكفاءة. ولكن لماذا يتطلب إلغاء الرهن فترة انتظار؟ لماذا لا تسمح بالسحب الفوري؟
أبسط سبب هو أمان الشبكة. إذا كان إلغاء الرهن فوريًا، يمكن إلغاء كميات كبيرة من الرموز ردًا على تقلبات السوق، مما يضعف بشكل كبير أمان الشبكة. ومع ذلك، بخلاف الأمان، هناك سبب آخر أساسي: منع الهجمات على المدى الطويل.
(المصدر: AP)
هجوم على مسافات طويلة يشير إلى هجوم يقوم فيه المحققون الخبيثون بإنشاء فork جديد يبدأ من الكتل السابقة، في محاولة لاستبدال السلسلة الكنسية الحالية. إذا أصبحت السلسلة الفرعية الخبيثة بنفس طول أو أطول من السلسلة الكنسية، فقد تصبح العقد الجديدة المنضمة إلى الشبكة مرتبكة بشأن أي سلسلة هي الشرعية، مما يؤدي إلى قضايا محتملة. ولكن انتظر - هل هذا ممكن حتى؟
في شبكة PoW، يكاد يكون من المستحيل تنفيذ هجوم عن بعد بعيد. للحاق بسلسلة الكتل القانونية الحالية، سيحتاج المهاجمون إلى إعادة إنشاء كتل جديدة من الماضي متجاوزين قوة الحوسبة للشبكة القائمة، وهو أمر غير قابل للتنفيذ عملياً.
بالمثل، في شبكة PoS تعمل بشكل صحيح، هذا الهجوم أيضًا مستحيل. إن إنشاء فورك جديد سيتطلب من المحققين الخبيثين توقيع كتل متضاربة متعددة، وهو ما يعتبر التوقيع المزدوج—انتهاك للبروتوكول يؤدي إلى تقطيع العقوبات.
وماذا لو سمح التحصيل فورا؟
على عكس شبكات PoW، لا تتطلب شبكات PoS قوة حسابية ضخمة لتوليد الكتل. وهذا يعني أنه إذا قام المحققون الخبيثون بإلغاء رهن أصولهم من السلسلة الحالية ثم إنشاء سلسلة مشعبة جديدة من كتلة سابقة حيث كانت مفاتيح المحقق الخاصة بهم صالحة ما زالوا، فإنهم قد يمكنهم بشكل محتمل اللحاق بالسلسلة الكنونية الحالية. في هذ scenar، قد تصارع العقد الجديدة التي تنضم إلى الشبكة لتحديد أي سلسلة هي الشرعية، مما قد يؤدي إلى الارتباك ومخاطر الأمان المحتملة.
(مصدر: بابل)
إذا نجح الهجوم عن بُعد، يمكن للمحققين الخبيثين استغلال آليات الجسر لسرقة الأموال. على سبيل المثال، لنفترض أن مهاجمًا خبيثًا يُدعى جون ينقل 1 مليون رمز RUG من سلسلة RugPull إلى Osmosis ويبادلها برموز OSMO. يحدث هذا التحويل من خلال IBC، الذي يعمل عن طريق قفل الرموز الأصلية RUG على سلسلة RugPull أثناء ضخ ما يعادله من رموز RUG على سلسلة Osmosis.
(المصدر: بابل)
إذا افترضنا أن جون نفذ بنجاح هجومًا عن بُعد على سلسلة RugPull، فيمكنه حذف الصفقة بشكل خبيث التي قفلت رموز RUG لإرسالها إلى سلسلة Osmosis في السلسلة المشعبة الجديدة. ونتيجة لذلك، سيحصل جون بشكل فعال على رموز OSMO مجانًا.
لمنع الهجمات عن بعد الطويلة، من الضروري وجود فترة فك الرهن لفترة معينة. لا يمكن للمهاجمين الخبيثين تنفيذ هجوم عن بعد طويل الأجل خلال فترة فك الرهن (إذا حاولوا ذلك، سيواجهون عقوبات القطع). بالإضافة إلى ذلك، خلال هذه الفترة، يمكن للمشاركين في الشبكة التوصل إلى اتفاق اجتماعي بشأن أي سلسلة هي السلسلة الكنونية. نتيجة لذلك، حتى إذا حدث هجوم عن بعد طويل الأجل في وقت لاحق، من غير المرجح أن تتم قبول السلسلة الخبيثة المشعبة من قبل الشبكة.
فترة فك الرهن هي طريقة فعالة لمنع الهجمات على مدى بعيد، ولكنها تأتي مع بعض العيوب.
القضية الأولى هي أنها تعتمد على التوافق الاجتماعي للتصدي للهجمات. بينما يمكن أن تلعب التواصل خارج السلسلة بين المشاركين دورًا حاسمًا على مدى فترة كافية، إلا أنها ليست حلاً مضموناً بنسبة 100٪.
المشكلة الثانية هي أنه، كما ذُكر سابقاً، يؤثر فترة إلغاء العقد الطويلة سلباً على تجربة المستخدم والسيولة.
بابل يقدم حلا يسمى التسمية الزمنية لبيتكوين، مما يتيح لسلاسل PoS تقليل فترات عدم الاستقرار بشكل كبير إلى ساعات قليلة فقط. يتيح هذا لسلاسل PoS تسجيل بيانات كتل سلسلة الكانونية على شبكة البيتكوين.
مع الطابع الزمني، حتى لو حاول المحققون الخبيثون هجومًا على مدى بعيد وادعوا أن سلسلتهم المنقسمة هي السلسلة القانونية، فإن هجومهم لن ينجح - لأن بيانات السلسلة القانونية الأصلية مسجلة بالفعل بشكل آمن على شبكة بيتكوين. طالما بقيت أمانة بيتكوين سليمة، فإن الهجوم مضمون للفشل. نظرًا لأن هذا النهج يقضي على الحاجة إلى التوافق الاجتماعي، فإنه يسمح بتقليل كبير في فترة الفك.
(مصدر: بابل)
هنا، يتم تسجيل البيتكوين بتأريخ باستخدام عملية OP_RETURN في شبكة البيتكوين. OP_RETURN هي تعليمة تسمح بتخزين ما يصل إلى 80 بايتًا من البيانات التعسفية على شبكة البيتكوين. على عكس المعاملات العادية في البيتكوين، لا يمكن استخدام OP_RETURN لنقل الأموال ولا يولد UTXOs.
إحدى النقاط الرئيسية المهمة هي ما إذا كان بإمكان جميع سلاسل PoS إنشاء نقاط تفتيش مباشرة على شبكة بيتكوين. حيث تكون كتل بيتكوين صغيرة الحجم، وتمتلك وقت كتلة يبلغ 10 دقائق، ويمكن لـ OP_RETURN تخزين حد أقصى يبلغ 80 بايتًا من البيانات. إذا قامت سلاسل PoS العديدة بإرسال معاملات فحص متكررة، فإن شبكة بيتكوين لن تكون قادرة على تحمل العبء.
لحل هذه المشكلة، تُقدم بابليون سلسلة بابليون، التي تجمع نقاط التفتيش من عدة سلاسل PoS عبر IBC ثم تقدم نقطة تفتيش مجمعة واحدة إلى شبكة بيتكوين.
جزء أساسي من هذه العملية هو Vigilante Relayer، كيان مسؤول عن قراءة نقاط التفتيش من عقدة Babylon، وتغليفها في معاملات OP_RETURN، ثم تقديمها إلى شبكة Bitcoin. يتطلب النظام وجود مرسل Vigilante صادق وحي للعمل بشكل صحيح على الأقل.
(المصدر: بابلون)
يحدث تحديد الوقت BTC على النحو التالي: تقوم سلاسل PoS بتقديم نقاط تفتيش تحتوي على معلومات الكتل إلى سلسلة بابلون. تقوم سلسلة بابلون بتقديم نقطة فحص لكتل بابلون إلى شبكة بيتكوين عند الكتلة النهائية لكل حقبة.
(المصدر: بابل)
حتى لو حدث هجوم عن بعد طويل المدى، سيكون لدى نقطة التفتيش في السلسلة المشعولة الخبيثة دائمًا الطابع الزمني لاحق من نقطة التفتيش في السلسلة القانونية. وهذا يعني أن المشاركين في الشبكة يمكنهم ببساطة التحقق من نقطة التفتيش في شبكة البيتكوين لتحديد الشواخص الخبيثة بسهولة. نظرًا لأن هذا النهج يقضي على الحاجة إلى التوافق الاجتماعي، يمكن تقليل فترة فك الرهن من عدة أسابيع إلى بضع ساعات فقط.
يقوم توقيت بيتكوين في بابل بالمزيد من تحسين تجربة المستخدم وكفاءة السيولة من خلال تقليل فترات سحب PoS—كما أنه يوفر أيضًا فوائد إضافية متنوعة.
من خلال اعتماد الانتهاء البطيء من خلال بابل، يمكن لسلاسل PoS تحقيق مستوى أمان يمكن مقارنته ببيتكوين. عندما يتم تسجيل كتلة PoS تحتوي على معاملة معينة على شبكة بيتكوين زمنيًا وتأكيدها من خلال ست كتل بيتكوين، تصبح المعاملة لا يمكن عكسها - طالما بقي أمان بيتكوين سليمًا.
هذا الآليّة مفيدة لمعالجة المعاملات ذات القيمة العالية، مثل عمليات شراء العقارات، حيث تكون الأمانة المطلقة ضرورية. بالإضافة إلى ذلك، بالنسبة لمناطق Cosmos الجديدة التي قد تكون أمانها أضعف، يمكن أن يوفر تنفيذ النهاية البطيء طبقة إضافية من الحماية لمعالجة المعاملات بشكل آمن.
يمكن أيضًا أن يساعد تسجيل الوقت في بيتكوين على استعادة الحيوية في حالة هجوم الرقابة على سلسلة PoS. لمعالجة هذا، تقدم بابلون مفهومًا خاصًا يُسمى وضع اللف.
في سلسلة PoS التقليدية، يجب أن تكون ما لا يقل عن ثلثي (2/3) المحققين شرفاء للحفاظ على مقاومة الرقابة. ومع ذلك، مع وضع rollup في بابلون، يكفي أن يكون نصف (1/2) المحققين شرفاء لتحقيق مقاومة الرقابة، مما يحسن بشكل كبير من مرونة السلسلة ضد الهجمات.
(المصدر: بابليون)
إذا كان مستخدم سلسلة PoS يعتقد أنه يتم رقابة معينة على معاملة معينة، فيمكنه تقديم شكوى بشأن الرقابة (الجزء الأحمر في الرسم البياني) إلى سلسلة Babylon، مما يبدأ عملية الدخول في وضع التجميع. تحتوي الشكوى بشأن الرقابة على تجزئة المعاملة المراقبة.
إذا، بعد ست تأكيدات لكتل Bitcoin، لم تتم تضمين الصفقة المحجوبة المشتبه بها في سلسلة PoS، سيقوم المحققون الصادقون بتقديم آرائهم حول سلسلة PoS إلى Babylon. إذا، بعد ست تأكيدات إضافية لكتل Bitcoin، لم يتم اكتشاف نقطة فحص متعلقة بالصفقة المحجوبة في أي كتلة Bitcoin، سيدخل المحققون والمستخدمون الصادقون في وضع التجميع النهائي.
في وضع اللف، يمكن لأي محقق اقتراح حزمة من معاملات PoS، وإذا وقع المحققون الذين يمتلكون ما لا يقل عن نصف (1/2) من الرهان الإجمالي على الحزمة، سيتم تثبيت المعاملة على شبكة البيتكوين، وبالتالي منع الرقابة بشكل فعال.
يُسمح لتسجيل الوقت في بيتكوين لسلاسل PoS باستغلال أمان بيتكوين لتقليل فترات فك تثبيت الرهن وتعزيز مقاومة الرقابة، ولكن هذا يستغل الأمان المتاح في بيتكوين جزئيًا فقط.
بعد البتكوين تمبرستامبينغ، تقدم بابلون بيتكوين ستاكينغ، الذي ينفذ بشكل أصلي ستاكينغ بيتكوين باستخدام لغة سكريبت البيتكوين. يتيح هذا لبروتوكولات أخرى للمنافع من أمان بيتكوين الاقتصادي التشفيري. تم تصميم بروتوكول الستاكينغ على أنه إضافة قابلة للتعديل، مما يجعله سهل التكيف مع بروتوكولات موافقة PoS مختلفة.
بالنسبة لمالكي BTC، فإن الرهان على بيتكوين في بابلون يُعتبر فرصة استثمارية جذابة حيث يمكنهم رهن BTC على مستوى أمان بيتكوين دون الاعتماد على كيانات خارجية، مع كسب مكافآت من البروتوكولات الخارجية أيضًا.
دعونا نحدد بعض المصطلحات الرئيسية:
لكن انتظر - على عكس إثريوم، شبكة بيتكوين ليست كاملة التورينغ، مما يجعل من الصعب تنفيذ عقود الرهان المعقدة. فكيف يتحقق بابلون من ذلك؟
لنستكشف التفاصيل من خلال مثال من مدونة بابلون.
// العقد V0: إضافة شرط قفل إلى إشارة البيانات غير المصروفة لأليس
الشرط-1 (القفل): time_lock = 1000 & alice_public_key
لنفترض أن آليس تراهن على بتكوين وتعمل أيضًا كمزود نهائي. لتنفيذ تراهن البتكوين، يُطلب توفير آلية لقفل البتكوين. يتم تحقيق ذلك عن طريق تعيين أحد شروط إنفاق UTXO بحيث يمكن لآليس (مالك البتكوين) سحب الأموال بعد فترة زمنية معينة (time_lock = 1000) باستخدام مفتاحها العام (alice_public_key).
// العقد V1: إضافة تقطيع سذاجة
الشرط 1 (القفل): time_lock = 1000 & alice_public_key؛ أو
الحالة-2 (التقطيع): alice_eots_public_key
أحد العناصر الأساسية التي يجب تنفيذها في الحصة هو الحذف. إذا حدث إجراء خبيث، يمكن تنفيذ آلية حوافز من خلال حرق BTC المراهنة. لتحقيق ذلك، يتم تعيين شرط إنفاق UTXO الثاني بحيث يمكن حدوث الحذف إذا كان شخص ما يمتلك مفتاح EOTS الخاص بـ Alice.
هنا، EOTS (Extractable One-Time Signature) هو توقيع تم تنفيذه باستخدام تواقيع Schnorr، التي تم تقديمها بعد ترقية Bitcoin's Taproot. ببساطة، هو خوارزمية تضمن أنه إذا قام ممثل شرير بتوقيع مزدوج على كتلتين مختلفتين في نفس الارتفاع باستخدام نفس المفتاح، يتم الكشف عن مفتاحهم السري علنًا.
عند النظر في هذا بمزيد من التفصيل، تتكون توقيع Schnorr من مفتاح خاص x، ومفتاح عام P=xG، وترمز عشوائية k. عملية التوقيع كما يلي: يتم إنشاء ترمز عشوائي k، ويتم حساب القيمة العامة R=kG من الترمز. ثم، يتم حساب قيمة التجزئة e من الرسالة M و R، وتتم حساب قيمة التوقيع s بناءً على الترمز و e، حيث s = k + ex. تتكون توقيع Schnorr النهائي من (s، R).
الفكرة الأساسية لـ EOTS هي أنه إذا تم استخدام نفس المفتاح مرتين للتوقيع، فإن المفتاح الخاص يتعرض. إذا قامت أليس بتوقيع رسالتين مختلفتين باستخدام نفس القيمة العشوائية k، فإن التوقيع الأول هو s1= k + e_1x والتوقيع الثاني هو s2= k + e_2x. نظرًا لأن s1، s2، e1، e2 معروفة علنًا، يمكن لأي شخص حل للحصول على المفتاح الخاص لأليس x باستخدام المعادلة x=(s1 - s2)/(e1 - e2).
باستخدام هذئ الآلية، إذا قامت أليس بتوقيع رسالتين مختلفتين بشكل خبيث باستخدام نفس مفتاح EOTS أثناء عملية التحقق من BSN، يمكن لأي شخص يكتشف ذلك استخراج مفتاح أليس السري EOTS. بمجرد كشف مفتاح EOTS السري، يمكن للمهاجم إما سرقة BTC المرهونة لدى أليس أو حرق BTC المرهونة لدى أليس كعقوبة.
// عقد V2
الشرط-1 (القفل): time_lock = 1000 & alice_public_key؛ OR
الشرط-2 (القطع): مفتاح الجمهور الخاص بـ Alice_eots ونصاب اللجنة العهد
// عملية تقليح V0
المدخلات:
النواتج:
0000...0000
// الموافقة المسبقة V0: فرض الحرق
// لجنة العهد توقع مسبقًا على عملية تقليص الرسوم أعلاه كموافقة مسبقة
نظرًا لأننا ناقشنا سابقًا الشروط التي يحدث فيها التقليص، دعونا الآن نفحص كيف يتم فعليًا تنفيذ التقليص. تنفيذ التقليص أمر حاسم لأنه، إذا قامت أليس بسلوك خبيث، فقد تحاول سحب BTC الخاص بها قبل أن يكتشف أحدهم السلوك غير القانوني، ويستخرج مفتاح EOTS السري الخاص بها، ويحرق BTC الخاص بها.
لمنع هذا، يجب تنفيذ القطع في طريقة تقوم بنقل BTC بقوة إلى عنوان حرق محدد مسبقًا (0000…0000). ولتحقيق ذلك، تتضمن شرط الإنفاق الثاني UTXO لجنة العهد. تتولى لجنة العهد مسؤولية التحقق مما إذا كان القطع مشروعًا. من خلال دمج نظام التوقيع المتعدد (M-of-N)، يضمن النظام أن لا يمكن لأليس سحب BTC بها بمفردها إلى محفظتها الخاصة قبل تنفيذ القطع.
ميزة هذا النهج هي أنه طالما تتصرف أليس بصدق، فإن توقيع EOTS الخاص بها لا يتعرض أبدًا، مما يعني أن لجنة العهد لا يمكنها الاستيلاء على أموالها. لذلك، لا يحتاج أليس إلى الثقة في لجنة العهد، حيث لا يمكن لهم القيام بأي إجراء ضدها ما لم تنخرط في سلوك خبيث.
// العقد V3: تمكين التفويض الآمن
condition-1 (القفل): time_lock = 1000 & alice_public_key; OR
الشرط-2 (التخفيض): مفتاح_عليس_العام ومفتاح_بوابة_المحفظة_العام ونصاب_لجنة_العهد
// عملية تقليص V0
المدخلات:
النواتج:
0000...0000
// الموافقة المسبقة V1
// يقوم أليس بتوقيع معاملة القطع كموافقة مسبقة.
// لجنة العهد توقع مسبقًا على تقليص عملية التحويل كموافقة مسبقة لها.
يمكن لأليس أن ترهن BTC مباشرة والمشاركة في التحقق من البروتوكولات الأخرى لنظام النفاذ كمزود نهائي. ومع ذلك، سيختار معظم المستخدمين تفويض ترهين BTC الخاص بهم.
لتنفيذ هذا، إضافة مفتاح EOTS للمحقق إلى الشرط الثاني يضمن أنه إذا تورط المحقق في سلوك خبيث، يمكن حرق بيتكوين أليس. ومع ذلك، المشكلة هنا هي أنه إذا تواطأ المحقق مع لجنة العهد، يمكنهم سرقة بيتكوين أليس، مما يجبر أليس على الثقة بالمحقق.
الحل البسيط لهذه المشكلة هو أيضًا تضمين مفتاح Alice العام في الشرط الثاني. بهذه الطريقة، سيتطلب حرق BTC توقيع Alice أيضًا، مما يمنع سرقة BTC غير المصرح بها.
لتحقيق ذلك، توقعت أليس مسبقًا عملية تحويل تنص على أنه "إذا حدث تقليص، يجب إرسال BTC إلى عنوان الحرق." في هذه الحالة، إذا تصرف المحقق بشكل خبيث وتمت كشف مفتاح EOTS الخاص به، وإذا قامت اللجنة العهدية بتنفيذ توقيع متعدد، سيتم إرسال BTC إلى عنوان الحرق، مما يفرض عملية التقليص.
/ عقد V3
الشرط-1 (القفل): time_lock = 1000 & مفتاح عليس العام؛ OR
الشرط-2 (الحذف): مفتاح عليس العام ومفتاح بوابة المطابقة ونصاب اللجنة التأسيسية
// عملية تخفيض العملات V0
المدخلات:
النواتج:
0000...0000
// الموافقة المسبقة V2: فرض تخفيض ذري عند التفويض
تصريح Alice's المسبق هو توقيع محول لصفقة القطع
// تم إنشاؤه باستخدام مفتاح EOTS العام للمحقق.
وقعت لجنة العهد مسبقا على قطع tx كموافقة مسبقة عليها.
ماذا لو استهدف محقق البيانات الخبيث مراهنين محددين فقط للتقليص؟ لمنع هذا، تقدم Babylon توقيعات المحول.
عاليس تقوم بتشفير توقيعها باستخدام مفتاح EOTS العام للمحقق كتوقيع محول. إذا حاول المحقق خفض عقوبة على عاليس فقط، يجب عليه استخدام مفتاحه الخاص EOTS. نتيجة لطبيعة توقيعات المحول، سيؤدي هذا إلى كشف مفتاح المحقق الخاص EOTS، مما يزيل أي دافع للمحققين للانخراط في سلوك خبيث.
// عقد V3
condition-1 (القفل): time_lock = 1000 & alice_public_key; أو
الحالة 2 (القطع): alice_public_key و validator_eots_public_key و covenant_committee_quorum
// عملية الحذف V1: تمكين الحذف الجزئي
الإدخالات:
النواتج:
الناتج-1: القيمة = 0.09 بيتكوين، المالك = 0000...0000
الناتج-2: القيمة = 0.9 بيتكوين،
الشروط:
// الموافقة المسبقة V2
تصريح مسبق من Alice هو توقيع محول لصفقة القطع
// تم إنشاؤها باستخدام مفتاح EOTS العام للمحقق.
// لجنة العهد توقع مسبقًا على عملية تقليص التكلفة كجزء من الموافقة المسبقة.
ولكن هل لا تعتقد أن حرق كل البيتكوين في حالة التقليص هو أمر مبالغ فيه؟ لمعالجة هذا، يمكن حرق جزء فقط من البيتكوين (على سبيل المثال، حرق 10٪ فقط بينما يتم إعادة الـ 90٪ المتبقية بعد فترة معينة). يمكن تنفيذ ذلك عن طريق تقسيم مخرجات عملية التقليص إلى قسمين، كما هو موضح أعلاه.
العقد V4: تمكين إعادة التخزين
الشرط-1 (القفل): time_lock = 1000 & alice_public_key؛ OR
الشرط-2 (التقطيع): مفتاح عام لليس & أي توقيع من القائمة [مفتاح عام للمحقق] & نصاب لجنة العهد
يمكن لـ BTC المُفوّض لـ Alice المشاركة في التحقق من صحة عدة بروتوكولات PoS، وليس فقط واحدة. إذا شارك محقق في التحقق من صحة بروتوكولات PoS مختلفة باستخدام نفس مفتاح EOTS، فإن أي تسرب في مكان واحد قد يؤثر على الأنظمة الأخرى. لذلك، يجب على موفّرو Babylon النهائيين استخدام مفاتيح EOTS مختلفة لأنظمة PoS مختلفة، ويتم تقديم قائمة بمفاتيح EOTS في الشرط الثاني.
على عكس شبكات PoS مثل Ethereum أو Solana ، تعمل شبكة Bitcoin على PoW ، لذا فإن مفهوم التخزين غير موجود بطبيعته. ومع ذلك ، فقد نفذت Babylon ميزات قفل BTC وقطعها وتفويضها اللازمة للتكديس من خلال خصائص UTXOs ولغة البرمجة النصية الخاصة ب Bitcoin وخوارزميات التوقيع المختلفة. يتيح ذلك لحاملي BTC كسب أرباح إضافية أصلا من خلال استخدام BTC ، دون الحاجة إلى الجسور أو خدمات الوصاية.
بصرف النظر عن شبكة Lightning ، لا يوجد بروتوكول آخر يرث أمان شبكة Bitcoin بالكامل. ومع ذلك ، تماما مثل شبكة Bitcoin ، فإن وظائف شبكة Lightning Network محدودة للغاية ، ومن الثمين جدا التخلي عن أمان Bitcoin القوي والسيولة الهائلة.
قام بابليون بتمكين استخدام أمان بيتكوين بطريقتين مختلفتين من خلال تسجيل الوقت في بيتكوين والرهان على بيتكوين. يستخدم الأول بيتكوين كخادم للطابع الزمني لمنع عكس الصفقة أو الشوكات الخبيثة، في حين يستغل الثاني سيولة بيتكوين القوية كأمان اقتصادي للربح الإضافي، مما يسمح لحاملي بيتكوين بكسب أرباح إضافية بطريقة طبيعية.
حاليًا، يتم إيداع ما يقرب من 55،000 BTC في بابل، وهو ما يتساوى مع الحد الأقصى للإيداع المحدد من قبل بابل. حوالي 3.9% من إجمالي إمدادات ETH يتم إعادة رهنها على EigenLayer. باعتبار ذلك، على الرغم من أن حاملي BTC قد يكونون محافظين في استخدام BTC، فإن الإمكانات النمو لبابل، مع نسبة تقريبية تبلغ حاليًا 0.2% فقط من إجمالي إمدادات BTC المرهونة، تستحق النظر.