لا يعني الخصوصيّة على سلسلة الكتل بالضرورة أن كل معاملة تصبح غير مرئية للجميع، وأن هذا التمييز مهم للتطبيقات الماليّة.
تتناول Dusk الخصوصيّة عبر مستويات مختلفة من إمكانيّة الظهور. توفّر Moonlight تدفقات حسابات عامة شفّافة، بينما تدعم Phoenix عمليات تحويل مُشفّاة باستخدام إثباتات المعرفة الصفريّة. ومع Phoenix يمكن التحقّق من صحّة المعاملة دون الكشف علنًا عن المبلغ المحوَّل أو المُرسِل أو الملاحظات (الـnotes) المحدّدة المتعلّقة بها.
الجزء المثير للاهتمام هو ما يحدث عندما يحتاج شخص ما فعلًا إلى دليل. يصف توثيق Dusk الإفصاح الانتقائي كوسيلة للأطراف المصرّح لها مثل المُصدِرين أو الجهات/المنصّات أو المدقّقين أو المشرفين للوصول إلى المعلومات المطلوبة دون جعل بيانات غير ضروريّة متاحة للعامة. يمكن استخدام مفاتيح العرض (Viewing keys) عندما تتطلّب القواعد أو عمليات التدقيق إظهارًا مُتحكمًا.
وهذا يخلق فكرة مختلفة عن الشفافية. بدلًا من افتراض أن كل شيء يجب أن يكون عامًا كي تبقى سلسلة الكتل قابلة للتدقيق، تفصل Dusk بين الظهور العام والإفصاح المُتحكم به.
بالنسبة للأسواق المُنظَّمة، قد يهمّ هذا التمييز. قد لا يرغب المستثمر في أن تُعرَض كل الأرصدة أو التحويلات على كامل الشبكة، بينما قد لا يزال المدقق بحاجة إلى أدلة محدّدة للتحقق من معاملة أو عملية مالية.
لذلك فإن الهدف ليس فقط المعاملات الخاصّة. بل هو أكثر دقّة: الحفاظ على سرّية المعلومات الحساسة مع الإبقاء على مسار للتحقق المُصرّح به عندما يكون ذلك مطلوبًا فعلًا.
غالبًا ما تتطلب المعاملات العامة والخاصة نظمًا مختلفة، لكن الغسق يضع النموذجين في نفس الشبكة.
القمر هو نموذج المعاملات العامة للحساب الخاص بالغسق. تحدد المعاملة المُرسِل والمُستقبِل عبر مفاتيحهما العامة، بينما تساعد حقول مثل المبلغ nonce وحدّ الغاز وسعر الغاز والتوقيع الشبكة على التحقق منها ومعالجتها. كما يوفر هذا النموذج حماية مثل عدم القابلية للتزييف ومنع الإنفاق المزدوج وعدم القابلية للتلاعب ومنع هجمات إعادة التشغيل.
تتبع فونيكس نهجًا مختلفًا. فهو مبني على بنية UTXO المشابهة لبيتكوين، لكنه يضيف آليات الخصوصية. بدلًا من كشف أي ملاحظة (note) بعينها تم إنفاقها، تقوم الشبكة بتتبع nullifiers لمنع الإنفاق المزدوج دون تحديد علني للملاحظة الدقيقة داخل شجرة Merkle.
يوجد أيضًا اختلاف مهم في التحقق. تتضمن معاملات فونيكس برهانًا ذا معرفة معدومة (zero knowledge proof) يتيح للشبكة التحقق من أن المعاملة تتبع القواعد دون الاعتماد على نوع الفحوصات المباشرة نفسها المستخدمة بواسطة القمر.
لذا فالقمر وفونيكس ليسا نسختين متنافستين من الغسق. بل يقدمان نموذجين مختلفين للمعاملات وفقًا لمتطلبات الرؤية المختلفة.
غالبًا ما تبدو سلاسل الكتل العامة العامة والتمويل الخاضع للتنظيم وكأنهما تطلبان أشياء متعاكسة. فواحدة تُفضّل الشفافية المفتوحة بينما تحتاج الأخرى إلى قابلية التدقيق للسرية والامتثال.
تم تصميم Dusk لسد هذه الفجوة.
تصف الورقة البيضاء لـ Dusk بلوك تشين جاهزًا للامتثال ومركّزًا على الخصوصية، ومُصممًا لربط المنصات اللامركزية بالأسواق المالية التقليدية. بدلًا من التعامل مع الخصوصية والتنظيم كطبقات منفصلة، تُضمّن Dusk قابلية التدقيق للمعاملات السرّية والامتثال ضمن البنية الأساسية الخاصة بها.
يُعد نموذج المعاملات جزءًا مهمًا من هذا التصميم. تدعم Dusk Moonlight، وهو نموذجها العام المعتمد على الحسابات، إلى جانب Phoenix، وهو نموذجها المعتمد على UTXO المُشفّر. وهذا يمنح الشبكة طرقًا مختلفة للتعامل مع ظهور المعاملات وفقًا لحالة الاستخدام.
يهم ذلك للتطبيقات المالية لأن الخصوصية لا تعني بالضرورة اختفاء المعلومات. نهج Dusk أقرب إلى التحكم بما هو ظاهر ولمن هو ظاهر، مع الحفاظ على القدرة على تلبية متطلبات الأسواق الخاضعة للتنظيم.
بالنسبة لي، يجعل ذلك طرح Dusk أكثر إثارة للاهتمام من مجرد تسميته بلوك تشين للخصوصية. فهو يحاول أن يجعل الخصوصية والامتثال والبنية التحتية المالية تعمل معًا على مستوى البروتوكول.
هناك رمز يطير بينما آخر يتعرض لضربة كبيرة. هكذا هي العملات المشفرة. كنت أراقب الرسوم البيانية اليوم.
غالبًا ما يظن الناس أن سلسلتي بلوكشين تحتاجان إلى فهم بعضهما قبل أن تتمكنا من العمل معًا. كلما درستُ بنية Babylon أكثر، كلما أصبحت هذه الفرضية أقل إقناعًا.
لم يكن بيتكوين مُصممًا أصلًا لتفسير تنفيذ الإيثيريوم أو الاحتفاظ بنسخة من حالته. إن محاولة جعله يفعل ذلك ستغيّر المبادئ نفسها التي تجعل بيتكوين قابلًا للتنبؤ. بدلًا من ذلك، تتعامل Babylon مع المشكلة من اتجاه مختلف. فهي لا “تعلم” بيتكوين أن يفهم بلوكشين آخر، بل تمنح بيتكوين شيئًا يعرف بالفعل كيفية تقييمه: البرهان التشفيري. الهدف ليس فهمًا مشتركًا. بل تحقق مستقل.
غيّر هذا الفرق طريقتي في التفكير بشأن قابلية التشغيل البيني. لا يتعين على نظامين بالضرورة أن يتكلّما اللغة نفسها للوصول إلى النتيجة نفسها. كل ما يحتاجانه هو أدلة يمكن التحقق منها وفقًا لقواعد كلٍ منهما. وبهذا المعنى تصبح البراهين أقل شبهاً بالرسائل وأكثر شبهاً بشهود رياضيين لا يحتاج أي طرف إلى تفسيرها على أساس الثقة.
كلما انعكست على هذا التصميم، كلما ازددت قناعة بأن بنية تحتية للتشغيل البيني عبر السلاسل قد تكون كانت تطرح السؤال الخطأ. بدلًا من التساؤل عن كيفية فهم البلوكشين لبعضها، ربما ينبغي أن نسأل كيف يمكنها التحقق من الواقع نفسه مع البقاء مستقلّة تمامًا.
ربما لا ينتمي مستقبل قابلية التشغيل البيني إلى الشبكات التي تتواصل أكثر. قد ينتمي إلى الشبكات التي تحتاج إلى الثقة في التواصل بأقل قدر ممكن.
منذ يومين في المرور، لا أحصل على نقاط التداول 2026/07/31 و2026/08/01، وهذه لقطات الشاشة
غالبًا ما يَفترض الناس أنه إذا كان البيتكوين سَيشارك في مكانٍ آخر، فيجب أن يتحرك البيتكوين نفسه أولًا. وقد شكّل هذا الافتراض تصميمات السلاسل المتقاطعة لسنوات. بدأت أعتقد أن الحركة نفسها ليست الجزء المهم.
ما لفت انتباهي أثناء قراءة وثائق Babylon هو أن المعمارية تفصل بين الملكية والمشاركة الاقتصادية. يبقى BTC الأصلي مُقفلًا على شبكة البيتكوين تحت افتراضات الأمان الأصلية، بينما يمكن لقيمته الاقتصادية دعم الإقراض بالعملات المستقرة والعقود الدائمة والتطبيقات المالية الأخرى عبر Trustless Bitcoin Vaults. الهدف ليس نقل البيتكوين. الهدف هو توسيع ما يمكن للبيتكوين تقديمه دون تغيير ما هو عليه البيتكوين.
غيّر هذا التمييز طريقة تفكيري بشأن قابلية التشغيل البيني. ربما قضينا وقتًا طويلًا في تصميم طرق أفضل لنقل الأصول بين النُظم البيئية، ولم نقضِ وقتًا كافيًا في تصميم أنظمة يمكنها العمل مع الأصول حيثما كانت موجودة بالفعل.
إذا استمرت هذه الفكرة في النضوج، فقد لا يعتمد دور البيتكوين في التمويل اللامركزي بعد الآن على عدد السلاسل التي يمكنه الوصول إليها. قد يعتمد الأمر على مقدار النشاط الاقتصادي الذي يمكن أن يتطور بينما يبقى البيتكوين في مكانه دون مغادرة البيت.
ربما لا يتعلق مستقبل BTCFi بنقل البيتكوين. ربما يتعلق الأمر بتحريك كل شيء باستثناء البيتكوين.
غالبًا ما يفترض الناس أنه بمجرد دخول البيتكوين إلى التمويل اللامركزي (DeFi) يجب أن يتوقف عن كونه بيتكوينًا. لقد جعلت الرموز المُغلّفة والأصول الاصطناعية والوسطاء/الحُفّاظ (custodians) هذا الافتراض يبدو وكأنه أمر لا مفر منه تقريبًا. بدأت أفكر أن الافتراض نفسه يحتاج إلى تدقيق أكبر.
ما لفت انتباهي في بنية بابيلون (Babylon) هو أنها تتعامل مع المشكلة من الاتجاه المعاكس. بدلًا من إنشاء تمثيلٍ آخر للـBTC، فإنها تتساءل عمّا إذا كان يمكن للبيتكوين الأصلية أن تبقى على شبكتها الخاصة بينما تدعم في الوقت نفسه الإقراض، والـstablecoins، والعقود الدائمة (perpetuals)، وغيرها من التطبيقات المالية عبر «خزائن بيتكوين بدون ثقة» (Trustless Bitcoin Vaults). التحدي ليس منح البيتكوين هوية جديدة. بل إثبات أن هويته الحالية تكفي.
غيّر هذا التمييز طريقتي في التفكير بشأن الضمانات (collateral). ربما لا تتمثل الابتكار الحقيقي في ابتكار نسخة أفضل من البيتكوين. ربما يتمثل في تصميم بنية تحتية تتكيّف مع البيتكوين بدلًا من مطالبة البيتكوين بأن يتكيّف أولًا.
إذا نجح هذا النهج فقد يتغير تمامًا مسار الحديث حول BTCFi. لن يصبح السؤال بعد ذلك هو كيفية إعادة خلق البيتكوين في مكان آخر. بل سيكون: إلى أي مدى يمكن للبيتكوين الأصلية أن تشارك دون أن تصبح أصلًا مختلفًا.
ربما لا يُحدد مستقبل البيتكوين في التمويل اللامركزي (DeFi) بالتمثيل (representation). ربما يُحدد بالاحتفاظ بالأصالة مع توسيع المنفعة.
غالبًا ما يصف الناس Babylon Genesis باعتبارها مجرد بلوك تشين آخر. بعد قراءة الوثائق، لا أعتقد أن هذا هو الطريقة الأكثر إثارة للاهتمام للنظر إليها.
تركّز معظم سلاسل الكتل أساسًا على إنتاج بلوكاتها الخاصة. يقوم Babylon Genesis بذلك بالتأكيد، لكن الوثائق تصف مرارًا شيئًا أوسع. فهو يعمل كطبقة تنسيق للتأمين على الـBitcoin (staking) وتحديد الوقت (timestamping) والأمان وتوزيع المكافآت. وبدلًا من منافسة الـBitcoin، فإنه ينظم كيفية تطبيق أمن الـBitcoin عبر أنظمة أخرى.
غيّر هذا التمييز طريقة تفكيري بشأن الشبكة. قد لا تأتي قيمة Babylon Genesis من كونها وجهة أخرى للأصول. بل تأتي من مساعدتها للمشاركين المستقلين على الوصول إلى الرؤية نفسها للأمان والحالة، مع تثبيت الأحداث المهمة في دفتر الأستاذ الخاص بـBitcoin عبر تحديد الوقت وعمل نقاط التفتيش (checkpointing).
كلما تأملت تصميمها، قلّ إحساسي أنها تشبه طبقة أولى Layer 1 تقليدية. بدت أكثر كأنها بنية تحتية تُنسّق الثقة بدلًا من منافستها. إنتاج البلوك هو مجرد مسؤولية واحدة. الدور الأكبر هو جعل مكافآت الأمان وتنسيق ما يدعمه Bitcoin عملا كنظام واحد.
ربما لا يتم تعريف Babylon Genesis من خلال البلوكات التي تنتجها. ربما يتم تعريفها من خلال كل ما تنسقه بهدوء فيما بينها.
غالبًا ما يظن الناس أنه إذا كان لدى البروتوكول مُشغِّل، فهذا يعني أن المُشغِّل نفسه يجب أن يكون الطرف الذي تثق به لأصولك. كلما درستُ تصميم خزنة Babylon أكثر، أدركت أن هاتين المسؤوليتين قد تم فصلُهما عمدًا.
يؤدي مزوّد الخزنة مهمة مهمة. فهو يُنسّق العمل خارج السلسلة المطلوب لإنشاء الخزنة لاحقًا واستردادها، بما في ذلك توليد الإثباتات والتعامل مع معاملات مُوقَّعة مسبقًا والتنسيق مع مُحافظي الخزنة الخاصة بالتطبيق. لكن وفقًا للوثائق، فإنه لا يحتفظ ببيتكوين المُودِع ولا يتحكم فيه. تُحدَّد شروط الإنفاق عند إنشاء الخزنة، ما يجعل دور المزوّد دورًا تشغيليًا لا دور حفظٍ للأموال.
غيّر هذا التمييز طريقة تفكيري بشأن البنية التحتية. التنسيق ضروري لأن الأنظمة المعقّدة تحتاج إلى مشاركين كي تبقى العمليات في حركة. الثقة شيء مختلف. فالثقة تحدد من يملك في النهاية القدرة على تقرير مصير أصولك.
يبدو أن معمارية Babylon ترسم حدًا واضحًا عمدًا بين هاتين الفكرتين. يساعد مزوّد الخزنة البروتوكول على العمل، لكنه لا يكتسب سلطة على البيتكوين نفسه. وحتى إذا أصبح المزوّد غير متاح لاحقًا، تصف الوثائق مسار مطالبة ذاتية للمُودِع مصممًا لتمكين المستخدمين من استرداد بيتكوينهم بشكل مستقل.
ربما تكون إحدى علامات تصميم البروتوكول الناضج ليست إزالة الأدوار التشغيلية تمامًا، بل التأكد من أن هذه الأدوار لا تتحول أبدًا إلى مناصب حفظ.
غالبًا ما يفترض الناس أنه إذا كان لديك بيتكوين يعمل كضمان وتبقيه كله في مكان واحد، فهذا هو الخيار الأبسط. كلما أمعنت النظر في تصميم خزائن بابل، كلما أصبحت أقل اقتناعًا.
توصي الوثائق بتقسيم البيتكوين إلى خزينتين بدلًا من الاعتماد على خزينه واحدة. في البداية بدا الأمر وكأنه تعقيد إضافي. ثم أدركت أن التصميم ليس بهدف إنشاء المزيد من الخزائن. بل هو بهدف توفير مزيد من التحكم. يمكن ترتيب الخزائن ضمن مركز الاقتراض بحيث يصل التصفية إلى واحدة قبل الأخرى، ما يسمح لخزينةٍ تضحيةٍ محددة بامتصاص الخسائر بينما تبقى الخزينة المحمية دون مساس إذا تحسنت الظروف قبل الحاجة إلى تصفية إضافية.
هذا يغيّر طريقة تفكيري حول الضمان. بدلًا من التعامل مع كل ساتوشي على أنه مكشوف بشكلٍ متساوٍ، تُدخل بابل حدودًا داخل المركز نفسه. إن الهدف ليس مجرد النجاة من التصفية. بل هو تجنب تحويل كل انتكاسة في السوق إلى حدثٍ من نوع “كل شيء أو لا شيء”.
ربما لا يُقاس تصميم الضمان الجيد بمقدار البيتكوين الذي تقفله. ربما يُقاس بمدى تعمّدك في تحديد أي بيتكوين يجب أن يتحمل طبقة المخاطر الأولى.
يعتقد معظم الناس أن تجميع الأصول معًا يجعل النظام أكثر كفاءة. يبدو ذلك معقولًا حتى تبدأ في التفكير في ما يحدث عندما تسوء الأمور.
تتبع خزائن بيبيليـون للبيتكوين غير القابلة للثقة مسارًا مختلفًا بشكل ملحوظ. بدلًا من وضع العديد من مستخدمي البيتكوين في مجمع مشترك، ترتبط كل خزانة بـ UTXO خاص بها. في البداية قد يبدو ذلك مجرد تفصيل تنفيذي. لكن كلما دققت أكثر، شعرت أنه نهج مقصود لإدارة المخاطر وليس مجرد تخزين للبيتكوين.
عندما يتم تجميع الضمان، قد تتحول مشكلة أحد المشاركين تدريجيًا إلى شأن يقلقه الجميع. تغيّر الخزائن المعزولة هذه العلاقة. تتبع كل خزانة دورة حياتها الخاصة، وعملية تحققها الخاصة، ومسار استردادها الخاص. تبقى المخاطر مرتبطة بالبيتكوين المحدد المستخدم بدلًا من أن تمتد عبر إيداعات غير ذات صلة.
أثار ذلك تساؤلي حول ما إذا كان العزل يتعلق فعلًا بالحيازة على الإطلاق. ربما يتعلق الأمر بالحفاظ على حدود واضحة. لا يصبح البروتوكول أكثر مرونة لمجرد أنه يجمع كل شيء معًا. أحيانًا تأتي المرونة من ضمان بقاء المراكز المستقلة مستقلة حتى عندما تشارك في النظام نفسه.
ربما تكون أهم نقطة في تصميم خزائن بيبيليـون ليست أن البيتكوين يبقى على البيتكوين. بل أن كل خزانة تحمل مسؤوليتها وحدها فقط.
خطوة مورغان ستانلي الأخيرة في عالم الكريبتو تقول الكثير عن السوق أكثر من مجرد شركة واحدة
لفترة طويلة، كان بيتكوين هو العملة الرقمية الوحيدة التي بدا أن معظم المؤسسات المالية التقليدية مرتاحة للحديث عنها. إذا كانت هناك مؤسسة مصرفية ترغب في التعرض للأصول الرقمية، فعادةً ما كانت بيتكوين هي الخيار الأول والوحيد. لكن هذا التصور بدأ يتغير. توسّع مورغان ستانلي الأخير في منتجات الاستثمار المرتبطة بالإيثيريوم وسولانا يبدو خطوة أخرى في هذا الاتجاه. بدلًا من حصر تركيزها على بيتكوين، تمنح الشركة المستثمرين إمكانية الوصول إلى شبكتين بلوك تشين بنتا منظومتين مختلفتين جدًا على مرّ السنوات. كما تتضمن المنتجات الإتاحة/الاستيكينغ، ما يعني أن المستثمرين قد يستفيدون من مكافآت الشبكة دون التعامل مع المُصدِّقين أو المحافظ أو الجانب التقني من عالم الكريبتو.
غالبًا ما يصف الناس أنظمة السلاسل المتقاطعة وكأن أصعب جزء فيها هو إرسال المعلومات من شبكة إلى أخرى. لست مقتنعًا بأن هذه هي المشكلة الحقيقية.
لا تمتلك بيتكوين بطبيعتها طريقة لفهم ما يحدث على الإيثيريوم. لم تُبنَ لتُفسّر السجل التاريخي لسلسلة بلوك تشين أخرى، وطلب ذلك منها سيثير تغيير الافتراضات ذاتها التي تجعلها موثوقة.
ما شدّ انتباهي في بنية بابيلون هو أنها لا تحاول تعليم بيتكوين لغة جديدة. بدلًا من ذلك، تتعامل مع البراهين التشفيرية بوصفها الشيء الوحيد الذي يستحق تقديمه. ليست الغاية رسائل أفضل بين السلاسل. بل هي تزويد بيتكوين بأدلة يمكنها التحقق منها دون الاعتماد على تفسير طرف آخر.
جعلتني هذه النظرة أعيد التفكير في قابلية التشغيل البيني. ربما لا تحتاج الشبكات المستقلة إلى فهم بعضها بعضًا على الإطلاق. كل ما تحتاجه هو طريقة موثوقة للتحقق من الواقع نفسه عبر برهان تشفيري.
إذا كان ذلك صحيحًا، فإن التحقق من البراهين ليس مجرد عنصر تقني مخفي تحت السطح. بل يصبح، بصمت، الأساس الذي يسمح للأنظمة المنفصلة بالتنسيق مع الحفاظ على نماذج أمنها الخاصة.
ربما لا يُحدَّد مستقبل البنية التحتية للسلاسل المتقاطعة بمدى جودة تواصل سلاسل البلوك تشين مع بعضها، بل بمدى ضآلة الثقة التي يتعين عليها منح الاتصال نفسه.
أحد الأشياء التي تبرز بوضوح أثناء دراسة بيبليون هو أن قيود بيتكوين قد تكون في الواقع واحدة من أعظم نقاط قوتها. لم يتم تصميم Bitcoin Script ليكون منصة عامة لعقود ذكية. وغالبًا ما كان بساطتها يُنظر إليها على أنها قيد، لكن معمارية بابل تشير إلى منظور آخر؛ بدلًا من مطالبة بيتكوين بأن تصبح شيئًا ليست عليه، تم بناء نظام يحترم تلك الحدود.
لفتتني فلسفة التصميم هذه. بدلًا من توسيع بيتكوين بأكواد جديدة أو الاعتماد على الأصول المُغلَّفة (wrapped assets)، تستخدم Trustless Bitcoin Vaults قدرات البرمجة الموجودة في بيتكوين جنبًا إلى جنب مع تحقق تشفيري على مستوى البروتوكول لتنسيق التفاعلات مع التطبيقات الخارجية. يؤكد التوثيق أن عمليات الاسترداد والتحولات بين حالات السلاسل يتم التحقق منها باستخدام بدهيات سكربت بيتكوين الموجودة بدلًا من اشتراط إجراء تفرّع (fork) لبيتكوين.
كلما فكرت في الأمر أكثر، ازداد اقتناعي بأن القيود غالبًا ما تنتج هندسة أفضل. عندما لا يمكن للبروتوكول الاعتماد على برمجية غير محدودة، يتعين عليه حل المشكلات عبر تنسيق دقيق بدلًا من إضافة تعقيد إلى الطبقة الأساسية. ويبدو هذا النهج مختلفًا عن محاولة جعل كل سلسلة بلوكشين تعمل بالطريقة نفسها.
ربما ليست “الابتكار الحقيقي” هو جعل بيتكوين يتصرف مثل منصة عقود ذكية. ربما هو تصميم أنظمة تفهم بيتكوين جيدًا بما يكفي للعمل ضمن قواعدها بدلًا من إعادة كتابتها.
هل تؤدي القيود التقنية القوية في النهاية إلى تصميم بروتوكول أكثر مرونة، أم أنها تُبطئ الابتكار على المدى الطويل؟
وجدت نفسي أفكر في بابل بعد أن أدركت أن قفل البيتكوين ربما يكون أسهل جزء في العملية. يبدأ تحدي الهندسة الحقيقي بمجرد تأمين BTC بالفعل. عندها يتعين على البروتوكول تنسيق الأحداث عبر أنظمة مختلفة دون أن يطلب من البيتكوين التخلي عن نموذج الأمان الذي جعله ذا قيمة من الأساس.
ما لفت انتباهي أثناء قراءة التوثيق هو أن خزائن بيتكوين بلا ثقة لا تقتصر على إنشاء خزنة فحسب. بل إنها تحدد أيضًا كيفية تنسيق الاسترداد. يبقى BTC مقفلاً في سكربت Taproot مُوقَّع بشكل مشترك، بينما يستخدم البروتوكول تحققًا تشفيرياً موثقًا وآلية استرداد قائمة على التحدّي بحيث يمكن للبيتكوين أن يستجيب للأحداث المُتحقَّق منها دون الاعتماد على وصيّ يقرر ما الذي سيحدث بعد ذلك.
هذا جعلني أنظر إلى قابلية التشغيل البيني بشكل مختلف. إن نقل الأصول بين النظم البيئية يمثل مشكلة واحدة، لكن إثبات أن كل انتقال في الحالة حدث بشكل صحيح هو مشكلة تنسيق أشد تعقيدًا. يمكن لبروتوكول أن يعد بالحيازة الذاتية، ومع ذلك لا يزال يتعين عليه الإجابة عن سؤال أكبر: كيف تتفق الشبكات المستقلة على ما حدث دون إدخال وسيطٍ موثوق؟
كلما درست بابل أكثر، ازددت قناعة بأن مساهمتها الأكبر ربما ليست قفل البيتكوين. قد تكون الجهد المبذول لتنسيق ما يحدث بعد القفل بطريقة تظل وفيةً لافتراضات الأمان الأصلية للبيتكوين.
هل قفل البيتكوين هو الجزء الأصعب حقًا، أم أن إثبات ما يحدث بعد ذلك هو التحدي الحقيقي؟
شيء واحد يلفت الانتباه عند دراسة بابل هو أن نقل البيتكوين هو في الواقع الجزء الأسهل. أما الإبقاء بالبيتكوين تمامًا في مكانه مع السماح لقيمته بالمشاركة في مكان آخر، فيبدو كأنه تحدٍ هندسي أصعب بكثير. لسنوات طويلة، قامت معظم حلول التوافقية بحل المشكلة عبر مطالبة المستخدمين بنقل أصولهم أولاً ثم قبول افتراضات ثقة جديدة لاحقًا.
ما يجعلني أفكر في بابل هو أنها تنطلق من الاتجاه المعاكس. بدلًا من اعتبار الحفظ شيئًا يمكن تفويضه، تسأل إن كان يمكن إعادة تصميم التنسيق نفسه. لا تكون خزائن البيتكوين بدون ثقة مثيرة للاهتمام لأنها تنقل البيتكوين بشكل أسرع؛ بل لأنها تسمح بأن يظل البيتكوين مقفلًا داخل شبكة البيتكوين، بينما تنسّق عملية التحقق التشفيري المُدار بالبروتوكول كيفية استخدام تلك البيتكوين في مكان آخر دون الاعتماد على الأصول المُغلّفة أو الأمناء.
عند النظر إلى بابل اليوم، من السهل التركيز على مقاييس الرموز. حوالي 4.02 مليار $BABY تُتداول حاليًا من إجمالي إمداد قدره 10.89 مليار، لكن هذه الأرقام تصف الشبكة في هذه اللحظة فقط. ما يبدو أكثر أهمية بالنسبة لي هو ما إذا كان يمكن للمعمارية الكامنة وراء البروتوكول أن تثبت متانتها مع مرور الوقت. يخبرنا المعروض من الرموز بمكان يقف فيه النظام البيئي اليوم، بينما قد يحدد تصميم البروتوكول إلى أين يمكن أن يصل غدًا.
ربما الخطوة التالية للبيتكوين ليست إيجاد مزيد من الطرق لنقله عبر الأنظمة البيئية. ربما تتمثل في بناء أنظمة متقدمة بما يكفي لتسمح للبيتكوين بالبقاء بالضبط في المكان الذي ينتمي إليه.
كلما تعمقت أكثر في بابل، أدركت أكثر أن حاملي البيتكوين غالبًا ما قُدّم لهم خيارٌ زائف: إما ترك BTC كما هو لضمان أقصى قدر من الأمان، أو نقله إلى مكان آخر لفتح المزيد من الاستخدامات. وقد شكّل ذلك المفاضلةُ الطريقةَ التي يفكر بها كثيرون في دور البيتكوين في التمويل اللامركزي.
ما لفت انتباهي في خزائن البيتكوين غير القابلة للثقة (TBV) هو أنها تتعامل مع المشكلة من اتجاه مختلف. بدلًا من تغليف البيتكوين أو وضعه تحت وصاية جهةٍ وسيطة، تتيح TBV لـ BTC أن يبقى متقفلًا على شبكة البيتكوين عبر سكربت Taproot مُوقّع بشكل مشترك (co-signed)، بينما يتولى بروتوكول جانبي على شبكة Ethereum متابعة الخزنة لاستخدام الضمانات. يعتمد التصميم على التحقق التشفيري المُوجَّه بالبروتوكول بدلًا من نقل الثقة إلى وسيط.
أعتقد أن الجزء المثير للاهتمام ليس فقط أن البيتكوين يمكنه المشاركة في التمويل اللامركزي. بل هو تغيير طريقة التنسيق. بدلًا من مطالبة المستخدمين باستبدال نموذج ثقة البيتكوين بنموذج آخر، تستكشف بابل كيف يمكن الحفاظ على افتراضات الأمان الحالية للبيتكوين دون المساس بها، مع دعم تطبيقات مالية أوسع. هذا يبدو أقل كونه «تمديدًا للبيتكوين عبر التمثيل» وأكثر كونه «تمديدًا له عبر البنية».
بالنسبة لي، يثير هذا سؤالًا أوسع حول قابلية التشغيل البيني. ربما لا تتمثل المصلحة المستقبلية في نقل البيتكوين بين النُظم البيئية، بل في تصميم أنظمة يمكنها العمل مع البيتكوين دون أن نطلب منه مغادرة مكانه.
ألاحظ باستمرار أن كلمة واحدة يمكن أن تحمل معانٍ مختلفة تمامًا حسب المكان الذي تواجهها فيه. عندما سمعتُ كلمة "vault" لأول مرة، تخيلتُ نموذج DeFi المألوف حيث يودع العديد من المستخدمين الأصول في حوض مشترك. بعد قراءة وثائق Babylon أدركت أن Trustless Bitcoin Vaults (TBV) تتبع فلسفة مختلفة جدًا.
إن TBV ليست عقد استثمار مجمعًا. كل محفظة تمثل Bitcoin UTXO منفصلًا مملوكًا للمودع، مع بقاء BTC مقفلاً على شبكة Bitcoin داخل برنامج Taproot مُوقّع بشكل مشترك. بدلاً من تغليف Bitcoin أو نقله إلى أمين، يستخدم البروتوكول تحققًا تشفيريًا بحيث يمكن للأصل أن يعمل كضمان مع بقائه أصلاً داخل شبكة Bitcoin.
يبدو أن هذا التمييز أكثر أهمية مما يبدو للوهلة الأولى. تم تصميم البنية المعمارية للحفاظ على افتراضات الأمان الأصلية الخاصة بـ Bitcoin بدلًا من استبدالها بمتطلبات ثقة جديدة. كل محفظة معزولة وليست ممزوجة بأموال مستخدمين آخرين، وهذا يغيّر طريقة تفكيري حول كلمة vault في التمويل اللامركزي.
أدى فهم TBV إلى إدراكي أن Babylon لا تقوم فحسب بإدخال منتج DeFi آخر. بل إنها تعيد التفكير في كيفية مشاركة Bitcoin في التمويل اللامركزي مع البقاء وفية لأسسها الذاتية غير القائمة على الحراسة.