Sattar Chaqer

السوق يتسلى اليوم

$CLO
$1000RATS
$ACE

ثلاثة أسماء ظهرت فجأة على راداري.

أقسم أن العملات المشفرة لديها موهبة تجعلك تكتشف الحركة بعد أن تكون بدأت بالفعل.

الآن أنا أراقب عن كثب.

ألاحظ باستمرار مشكلة واحدة في التمويل اللامركزي (DeFi) يتم تجاهلها: يمكن أن تتغير الفائدة التي تقترض بها بينما لا تزال استراتيجيتك قيد التنفيذ.

معدلات الاقتراض والإقراض المتغيرة تتحرك مع ظروف السوق. هذا يخلق حالة من عدم اليقين. قد يواجه المقترض تكاليف سداد أعلى بينما يمكن أن تتغير العوائد المتوقعة للمقرض مع تحرك الفائدة.

@TermMax يتعامل مع هذا بشكل مختلف.

نموذجه يستخدم معدلات اقتراض وإقراض ثابتة لآجال محددة. وبعبارات بسيطة يمكنك معرفة الفائدة ومعرفة متى تنتهي الصفقة.

هذا يغير معادلة التخطيط.

بالنسبة للمقترضين، تجعل الفائدة الثابتة تكلفة السداد أكثر قابلية للتنبؤ خلال الفترة المتفق عليها.

بالنسبة للمقرضين، يمكن للهيكل الثابت أن يجعل العوائد أسهل للفهم والتخطيط حولها.

وأعتقد أن تاريخ الاستحقاق هو الجزء الذي يقلل الناس من تقدير أهميته.

معرفة الفائدة وحدها تخبرك بكم.

معرفة الفائدة بالإضافة إلى الاستحقاق تخبرك بكم ولمدة كم.

هذا الفرق يهم عند بناء استراتيجية.

TermMax ليس مجرد تغيير لطريقة عمل الإقراض في DeFi. بل هو يعالج حالة عدم اليقين الناتجة عن تحرك الفوائد باستمرار ويمنح الطرفين شروطًا أوضح من البداية.

لهذا السبب فإن DeFi بسعر ثابت يستحق المتابعة.

#TermMax

ما الذي يهم أكثر في الإقراض؟

يومٌ آخر، زوجٌ آخر يجعل المخطط يبدو مثيرًا للاهتمام.

$EDEN +27.59%
$ACE +27.08%

كلاهما يقوم بخطوة هادئة وثابتة اليوم. وفي الوقت نفسه، أنا فقط أراقب وأتساءل أيّهما كان يجب أن أنتبه له في وقتٍ أبكر.

كنت أظن أن اختيار لجنة Dusk كان مجرد: كلما زادت الحصة زادت الفرص.

لكن الأمر أكثر تعقيدًا من ذلك.

تستخدم Dusk الاستخراج الحتمي لاختيار مقدّمي الخدمة بحيث تكون تكرارية الاختيار متناسبةً مع الحصة.

يتلقى كل مقدّم خدمة مؤهل رصيدًا بناءً على درجة شبه عشوائية، وتحدد هذه الأرصدة من سيتم اختياره لأدوار الإجماع.

والجزء المثير للاهتمام؟

العملية حتمية، لكن الاختيارات المستقبلية يصعب التنبؤ بها.

تستخدم Dusk SHA3 مع مدخلات تشمل بذرة الكتلة السابقة، والجولة والخطوة الحاليّتان، والرصيد الممنوح.

ثم تتغير البذرة مع كل كتلة.

وهناك أيضًا آلية موازنة وجدتها ممتعة.

بعد أن يحصل مقدّم الخدمة على رصيد، يتم تقليل وزنه بمقدار 1 DUSK للاختيار التالي.

لذلك فالنظام ليس ببساطة:

أكبر حصة → تأثير دائم.

بدلًا من ذلك، فهو يجمع بين وزن الحصة وعشوائية حتمية وأوزان اختيار تتغير.

النتيجة هي عملية اختيار لجنة تُعتبر فيها الحصة مهمة، لكن معرفة من سيتم اختياره في المرة التالية ليست أمرًا مباشرًا.

وبالنسبة لشبكة صُممت حول بنية مالية تحتية، فإن هذا القدر من عدم اليقين مهم.

@Dusk $DUSK #dusk

ما الذي يشكّل اختيار Dusk أكثر؟

قائمة الرابحين أصبحت مثيرة للاهتمام مرة أخرى.

$GPS +57.86%
$ACE +39.51%

كلاهما يمر بيوم جيد جدًا بينما أنا هنا أتساءل لماذا ألاحظ دائمًا هذه التحركات بعد حدوثها.

غالبًا ما توصف معاملة البلوك تشين بأنها إما مؤكدة أو غير مؤكدة. يجعل نموذج الإجماع لدى Dusk هذا الجواب أكثر دقة.

يمكن أن ينتقل البلوك عبر أربع حالات: accepted attested confirmed و final. تمثل كل مرحلة مستوى مختلفًا من الثقة بشأن ما إذا كان يمكن استبدال هذا البلوك لاحقًا.

البلوك accepted لديه attestation بالنجاح لكن ما زال يمكن استبداله ببلوك من iteration أدنى مع attestation بالنجاح أيضًا. أما البلوك attested فيمتلك attestation بالنجاح وقد فشلت جميع التكرارات السابقة، لذا لا يمكن استبداله ببلوك من iteration أدنى.

ثم يأتي confirmed. في هذه المرحلة يكون من غير المحتمل استبدال البلوك، على الرغم من أن أحد أجداده قد لا يزال قابلًا للاستبدال. وهذا يجعل confirmed مختلفًا عن final.

البلوك final يتقدم خطوة إضافية: فهو مؤكد، ووالده (parent) هو أيضًا final. وفقًا للوثائق، لا يمكن استبدال البلوك final تحت أي ظرف.

هذا التمييز سهل التغاضي عنه لأن confirmed و final غالبًا ما يُعاملان كشيء واحد. يوضح Dusk هذا التسلسل بشكل صريح.

بالنسبة للتطبيقات المالية، فإن معرفة اللحظة بالضبط التي يصبح فيها البلوك غير قابل للعكس ليست تفصيلًا صغيرًا. فقد يؤثر ذلك على توقيت اعتبار التسوية منتهية حقًا.

@Dusk $DUSK #dusk

متى يصبح البلوك نهائيًا بشكل حقيقي؟

سوق اليوم يبعث إشارات متضاربة.

$HEMI +27.74%
$CYS -52.75%

واحد يندفع للأعلى بينما الآخر يُسحق تمامًا. يمكن للـ”كريبتو“ أن يغيّر المزاج في ثوانٍ.

الهوية على سلسلة الكتل لا تعني دائمًا عرض كل التفاصيل الخاصة بالمستخدم للعلن.

ولهذا لفتت “Citadel” انتباهي عندما كنت أراجع توثيق “Dusk”. يصف “Glossary” “Citadel” بأنها طبقة هوية وإتاحة لدى “Dusk” مبنية حول الإفصاح الانتقائي.

الفكرة بسيطة، لكن الفرق مهم: إثبات من هو الشخص أو ما إذا كان لديه إمكانية وصول لا يعني تلقائيًا جعل كل جزء من معلومات الهوية مرئيًا للجميع.

في التطبيقات المالية قد يصبح ذلك مهمًا. قد تحتاج الشبكة إلى ضوابط هوية وإتاحة مع الحفاظ أيضًا على سرية المعلومات الحساسة. بدلًا من اعتبار الشفافية خيارًا “كلّه أو لا شيء”، يشير الإفصاح الانتقائي إلى نموذج رؤية أكثر تحكمًا.

ما أراه مثيرًا للاهتمام هو أن “Citadel” تجاور بنية الخصوصية الأوسع لدى “Dusk” بدلًا من استبدالها. كما يعرّف “Dusk” معيار “Confidential Security Contract Standard” كإطار يمكنه التكيّف مع متطلبات الأعمال مثل قيود الخصوصية وقواعد الامتثال.

هذا يجعل الهوية تبدو أقل كأنها صندوق KYC منفصل وأكثر كجزء من البنية التحتية.

السؤال الحقيقي بالنسبة لي هو: إلى أي مدى يمكن أن يصل الإفصاح الانتقائي مع الحفاظ على التطبيقات المالية خاصة وقابلة للاستخدام.

@Dusk $DUSK #dusk

لا يعني الخصوصيّة على سلسلة الكتل بالضرورة أن كل معاملة تصبح غير مرئية للجميع، وأن هذا التمييز مهم للتطبيقات الماليّة.

تتناول Dusk الخصوصيّة عبر مستويات مختلفة من إمكانيّة الظهور. توفّر Moonlight تدفقات حسابات عامة شفّافة، بينما تدعم Phoenix عمليات تحويل مُشفّاة باستخدام إثباتات المعرفة الصفريّة. ومع Phoenix يمكن التحقّق من صحّة المعاملة دون الكشف علنًا عن المبلغ المحوَّل أو المُرسِل أو الملاحظات (الـnotes) المحدّدة المتعلّقة بها.

الجزء المثير للاهتمام هو ما يحدث عندما يحتاج شخص ما فعلًا إلى دليل. يصف توثيق Dusk الإفصاح الانتقائي كوسيلة للأطراف المصرّح لها مثل المُصدِرين أو الجهات/المنصّات أو المدقّقين أو المشرفين للوصول إلى المعلومات المطلوبة دون جعل بيانات غير ضروريّة متاحة للعامة. يمكن استخدام مفاتيح العرض (Viewing keys) عندما تتطلّب القواعد أو عمليات التدقيق إظهارًا مُتحكمًا.

وهذا يخلق فكرة مختلفة عن الشفافية. بدلًا من افتراض أن كل شيء يجب أن يكون عامًا كي تبقى سلسلة الكتل قابلة للتدقيق، تفصل Dusk بين الظهور العام والإفصاح المُتحكم به.

بالنسبة للأسواق المُنظَّمة، قد يهمّ هذا التمييز. قد لا يرغب المستثمر في أن تُعرَض كل الأرصدة أو التحويلات على كامل الشبكة، بينما قد لا يزال المدقق بحاجة إلى أدلة محدّدة للتحقق من معاملة أو عملية مالية.

لذلك فإن الهدف ليس فقط المعاملات الخاصّة. بل هو أكثر دقّة: الحفاظ على سرّية المعلومات الحساسة مع الإبقاء على مسار للتحقق المُصرّح به عندما يكون ذلك مطلوبًا فعلًا.

@Dusk $DUSK #dusk

غالبًا ما تتطلب المعاملات العامة والخاصة نظمًا مختلفة، لكن الغسق يضع النموذجين في نفس الشبكة.

القمر هو نموذج المعاملات العامة للحساب الخاص بالغسق. تحدد المعاملة المُرسِل والمُستقبِل عبر مفاتيحهما العامة، بينما تساعد حقول مثل المبلغ nonce وحدّ الغاز وسعر الغاز والتوقيع الشبكة على التحقق منها ومعالجتها. كما يوفر هذا النموذج حماية مثل عدم القابلية للتزييف ومنع الإنفاق المزدوج وعدم القابلية للتلاعب ومنع هجمات إعادة التشغيل.

تتبع فونيكس نهجًا مختلفًا. فهو مبني على بنية UTXO المشابهة لبيتكوين، لكنه يضيف آليات الخصوصية. بدلًا من كشف أي ملاحظة (note) بعينها تم إنفاقها، تقوم الشبكة بتتبع nullifiers لمنع الإنفاق المزدوج دون تحديد علني للملاحظة الدقيقة داخل شجرة Merkle.

يوجد أيضًا اختلاف مهم في التحقق. تتضمن معاملات فونيكس برهانًا ذا معرفة معدومة (zero knowledge proof) يتيح للشبكة التحقق من أن المعاملة تتبع القواعد دون الاعتماد على نوع الفحوصات المباشرة نفسها المستخدمة بواسطة القمر.

لذا فالقمر وفونيكس ليسا نسختين متنافستين من الغسق. بل يقدمان نموذجين مختلفين للمعاملات وفقًا لمتطلبات الرؤية المختلفة.

@Dusk $DUSK #dusk

غالبًا ما تبدو سلاسل الكتل العامة العامة والتمويل الخاضع للتنظيم وكأنهما تطلبان أشياء متعاكسة. فواحدة تُفضّل الشفافية المفتوحة بينما تحتاج الأخرى إلى قابلية التدقيق للسرية والامتثال.

تم تصميم Dusk لسد هذه الفجوة.

تصف الورقة البيضاء لـ Dusk بلوك تشين جاهزًا للامتثال ومركّزًا على الخصوصية، ومُصممًا لربط المنصات اللامركزية بالأسواق المالية التقليدية. بدلًا من التعامل مع الخصوصية والتنظيم كطبقات منفصلة، تُضمّن Dusk قابلية التدقيق للمعاملات السرّية والامتثال ضمن البنية الأساسية الخاصة بها.

يُعد نموذج المعاملات جزءًا مهمًا من هذا التصميم. تدعم Dusk Moonlight، وهو نموذجها العام المعتمد على الحسابات، إلى جانب Phoenix، وهو نموذجها المعتمد على UTXO المُشفّر. وهذا يمنح الشبكة طرقًا مختلفة للتعامل مع ظهور المعاملات وفقًا لحالة الاستخدام.

يهم ذلك للتطبيقات المالية لأن الخصوصية لا تعني بالضرورة اختفاء المعلومات. نهج Dusk أقرب إلى التحكم بما هو ظاهر ولمن هو ظاهر، مع الحفاظ على القدرة على تلبية متطلبات الأسواق الخاضعة للتنظيم.

بالنسبة لي، يجعل ذلك طرح Dusk أكثر إثارة للاهتمام من مجرد تسميته بلوك تشين للخصوصية. فهو يحاول أن يجعل الخصوصية والامتثال والبنية التحتية المالية تعمل معًا على مستوى البروتوكول.

@Dusk $DUSK #dusk

كان سوق اليوم مليئًا بالمفاجآت.

$CYS +95.27%
$UAI -33.33%

هناك رمز يطير بينما آخر يتعرض لضربة كبيرة. هكذا هي العملات المشفرة. كنت أراقب الرسوم البيانية اليوم.

غالبًا ما يظن الناس أن سلسلتي بلوكشين تحتاجان إلى فهم بعضهما قبل أن تتمكنا من العمل معًا. كلما درستُ بنية Babylon أكثر، كلما أصبحت هذه الفرضية أقل إقناعًا.

لم يكن بيتكوين مُصممًا أصلًا لتفسير تنفيذ الإيثيريوم أو الاحتفاظ بنسخة من حالته. إن محاولة جعله يفعل ذلك ستغيّر المبادئ نفسها التي تجعل بيتكوين قابلًا للتنبؤ. بدلًا من ذلك، تتعامل Babylon مع المشكلة من اتجاه مختلف. فهي لا “تعلم” بيتكوين أن يفهم بلوكشين آخر، بل تمنح بيتكوين شيئًا يعرف بالفعل كيفية تقييمه: البرهان التشفيري. الهدف ليس فهمًا مشتركًا. بل تحقق مستقل.

غيّر هذا الفرق طريقتي في التفكير بشأن قابلية التشغيل البيني. لا يتعين على نظامين بالضرورة أن يتكلّما اللغة نفسها للوصول إلى النتيجة نفسها. كل ما يحتاجانه هو أدلة يمكن التحقق منها وفقًا لقواعد كلٍ منهما. وبهذا المعنى تصبح البراهين أقل شبهاً بالرسائل وأكثر شبهاً بشهود رياضيين لا يحتاج أي طرف إلى تفسيرها على أساس الثقة.

كلما انعكست على هذا التصميم، كلما ازددت قناعة بأن بنية تحتية للتشغيل البيني عبر السلاسل قد تكون كانت تطرح السؤال الخطأ. بدلًا من التساؤل عن كيفية فهم البلوكشين لبعضها، ربما ينبغي أن نسأل كيف يمكنها التحقق من الواقع نفسه مع البقاء مستقلّة تمامًا.

ربما لا ينتمي مستقبل قابلية التشغيل البيني إلى الشبكات التي تتواصل أكثر. قد ينتمي إلى الشبكات التي تحتاج إلى الثقة في التواصل بأقل قدر ممكن.

@BabylonLabs_io $BABY #baby

منذ يومين في المرور، لا أحصل على نقاط التداول 2026/07/31 و2026/08/01، وهذه لقطات الشاشة

غالبًا ما يَفترض الناس أنه إذا كان البيتكوين سَيشارك في مكانٍ آخر، فيجب أن يتحرك البيتكوين نفسه أولًا. وقد شكّل هذا الافتراض تصميمات السلاسل المتقاطعة لسنوات. بدأت أعتقد أن الحركة نفسها ليست الجزء المهم.

ما لفت انتباهي أثناء قراءة وثائق Babylon هو أن المعمارية تفصل بين الملكية والمشاركة الاقتصادية. يبقى BTC الأصلي مُقفلًا على شبكة البيتكوين تحت افتراضات الأمان الأصلية، بينما يمكن لقيمته الاقتصادية دعم الإقراض بالعملات المستقرة والعقود الدائمة والتطبيقات المالية الأخرى عبر Trustless Bitcoin Vaults. الهدف ليس نقل البيتكوين. الهدف هو توسيع ما يمكن للبيتكوين تقديمه دون تغيير ما هو عليه البيتكوين.

غيّر هذا التمييز طريقة تفكيري بشأن قابلية التشغيل البيني. ربما قضينا وقتًا طويلًا في تصميم طرق أفضل لنقل الأصول بين النُظم البيئية، ولم نقضِ وقتًا كافيًا في تصميم أنظمة يمكنها العمل مع الأصول حيثما كانت موجودة بالفعل.

إذا استمرت هذه الفكرة في النضوج، فقد لا يعتمد دور البيتكوين في التمويل اللامركزي بعد الآن على عدد السلاسل التي يمكنه الوصول إليها. قد يعتمد الأمر على مقدار النشاط الاقتصادي الذي يمكن أن يتطور بينما يبقى البيتكوين في مكانه دون مغادرة البيت.

ربما لا يتعلق مستقبل BTCFi بنقل البيتكوين. ربما يتعلق الأمر بتحريك كل شيء باستثناء البيتكوين.

@BabylonLabs_io $BABY #baby

غالبًا ما يفترض الناس أنه بمجرد دخول البيتكوين إلى التمويل اللامركزي (DeFi) يجب أن يتوقف عن كونه بيتكوينًا. لقد جعلت الرموز المُغلّفة والأصول الاصطناعية والوسطاء/الحُفّاظ (custodians) هذا الافتراض يبدو وكأنه أمر لا مفر منه تقريبًا. بدأت أفكر أن الافتراض نفسه يحتاج إلى تدقيق أكبر.

ما لفت انتباهي في بنية بابيلون (Babylon) هو أنها تتعامل مع المشكلة من الاتجاه المعاكس. بدلًا من إنشاء تمثيلٍ آخر للـBTC، فإنها تتساءل عمّا إذا كان يمكن للبيتكوين الأصلية أن تبقى على شبكتها الخاصة بينما تدعم في الوقت نفسه الإقراض، والـstablecoins، والعقود الدائمة (perpetuals)، وغيرها من التطبيقات المالية عبر «خزائن بيتكوين بدون ثقة» (Trustless Bitcoin Vaults). التحدي ليس منح البيتكوين هوية جديدة. بل إثبات أن هويته الحالية تكفي.

غيّر هذا التمييز طريقتي في التفكير بشأن الضمانات (collateral). ربما لا تتمثل الابتكار الحقيقي في ابتكار نسخة أفضل من البيتكوين. ربما يتمثل في تصميم بنية تحتية تتكيّف مع البيتكوين بدلًا من مطالبة البيتكوين بأن يتكيّف أولًا.

إذا نجح هذا النهج فقد يتغير تمامًا مسار الحديث حول BTCFi. لن يصبح السؤال بعد ذلك هو كيفية إعادة خلق البيتكوين في مكان آخر. بل سيكون: إلى أي مدى يمكن للبيتكوين الأصلية أن تشارك دون أن تصبح أصلًا مختلفًا.

ربما لا يُحدد مستقبل البيتكوين في التمويل اللامركزي (DeFi) بالتمثيل (representation). ربما يُحدد بالاحتفاظ بالأصالة مع توسيع المنفعة.

@BabylonLabs_io $BABY #baby

غالبًا ما يصف الناس Babylon Genesis باعتبارها مجرد بلوك تشين آخر. بعد قراءة الوثائق، لا أعتقد أن هذا هو الطريقة الأكثر إثارة للاهتمام للنظر إليها.

تركّز معظم سلاسل الكتل أساسًا على إنتاج بلوكاتها الخاصة. يقوم Babylon Genesis بذلك بالتأكيد، لكن الوثائق تصف مرارًا شيئًا أوسع. فهو يعمل كطبقة تنسيق للتأمين على الـBitcoin (staking) وتحديد الوقت (timestamping) والأمان وتوزيع المكافآت. وبدلًا من منافسة الـBitcoin، فإنه ينظم كيفية تطبيق أمن الـBitcoin عبر أنظمة أخرى.

غيّر هذا التمييز طريقة تفكيري بشأن الشبكة. قد لا تأتي قيمة Babylon Genesis من كونها وجهة أخرى للأصول. بل تأتي من مساعدتها للمشاركين المستقلين على الوصول إلى الرؤية نفسها للأمان والحالة، مع تثبيت الأحداث المهمة في دفتر الأستاذ الخاص بـBitcoin عبر تحديد الوقت وعمل نقاط التفتيش (checkpointing).

كلما تأملت تصميمها، قلّ إحساسي أنها تشبه طبقة أولى Layer 1 تقليدية. بدت أكثر كأنها بنية تحتية تُنسّق الثقة بدلًا من منافستها. إنتاج البلوك هو مجرد مسؤولية واحدة. الدور الأكبر هو جعل مكافآت الأمان وتنسيق ما يدعمه Bitcoin عملا كنظام واحد.

ربما لا يتم تعريف Babylon Genesis من خلال البلوكات التي تنتجها. ربما يتم تعريفها من خلال كل ما تنسقه بهدوء فيما بينها.

@BabylonLabs_io $BABY #baby

غالبًا ما يظن الناس أنه إذا كان لدى البروتوكول مُشغِّل، فهذا يعني أن المُشغِّل نفسه يجب أن يكون الطرف الذي تثق به لأصولك. كلما درستُ تصميم خزنة Babylon أكثر، أدركت أن هاتين المسؤوليتين قد تم فصلُهما عمدًا.

يؤدي مزوّد الخزنة مهمة مهمة. فهو يُنسّق العمل خارج السلسلة المطلوب لإنشاء الخزنة لاحقًا واستردادها، بما في ذلك توليد الإثباتات والتعامل مع معاملات مُوقَّعة مسبقًا والتنسيق مع مُحافظي الخزنة الخاصة بالتطبيق. لكن وفقًا للوثائق، فإنه لا يحتفظ ببيتكوين المُودِع ولا يتحكم فيه. تُحدَّد شروط الإنفاق عند إنشاء الخزنة، ما يجعل دور المزوّد دورًا تشغيليًا لا دور حفظٍ للأموال.

غيّر هذا التمييز طريقة تفكيري بشأن البنية التحتية. التنسيق ضروري لأن الأنظمة المعقّدة تحتاج إلى مشاركين كي تبقى العمليات في حركة. الثقة شيء مختلف. فالثقة تحدد من يملك في النهاية القدرة على تقرير مصير أصولك.

يبدو أن معمارية Babylon ترسم حدًا واضحًا عمدًا بين هاتين الفكرتين. يساعد مزوّد الخزنة البروتوكول على العمل، لكنه لا يكتسب سلطة على البيتكوين نفسه. وحتى إذا أصبح المزوّد غير متاح لاحقًا، تصف الوثائق مسار مطالبة ذاتية للمُودِع مصممًا لتمكين المستخدمين من استرداد بيتكوينهم بشكل مستقل.

ربما تكون إحدى علامات تصميم البروتوكول الناضج ليست إزالة الأدوار التشغيلية تمامًا، بل التأكد من أن هذه الأدوار لا تتحول أبدًا إلى مناصب حفظ.

@BabylonLabs_io $BABY #baby

غالبًا ما يفترض الناس أنه إذا كان لديك بيتكوين يعمل كضمان وتبقيه كله في مكان واحد، فهذا هو الخيار الأبسط. كلما أمعنت النظر في تصميم خزائن بابل، كلما أصبحت أقل اقتناعًا.

توصي الوثائق بتقسيم البيتكوين إلى خزينتين بدلًا من الاعتماد على خزينه واحدة. في البداية بدا الأمر وكأنه تعقيد إضافي. ثم أدركت أن التصميم ليس بهدف إنشاء المزيد من الخزائن. بل هو بهدف توفير مزيد من التحكم. يمكن ترتيب الخزائن ضمن مركز الاقتراض بحيث يصل التصفية إلى واحدة قبل الأخرى، ما يسمح لخزينةٍ تضحيةٍ محددة بامتصاص الخسائر بينما تبقى الخزينة المحمية دون مساس إذا تحسنت الظروف قبل الحاجة إلى تصفية إضافية.

هذا يغيّر طريقة تفكيري حول الضمان. بدلًا من التعامل مع كل ساتوشي على أنه مكشوف بشكلٍ متساوٍ، تُدخل بابل حدودًا داخل المركز نفسه. إن الهدف ليس مجرد النجاة من التصفية. بل هو تجنب تحويل كل انتكاسة في السوق إلى حدثٍ من نوع “كل شيء أو لا شيء”.

ربما لا يُقاس تصميم الضمان الجيد بمقدار البيتكوين الذي تقفله. ربما يُقاس بمدى تعمّدك في تحديد أي بيتكوين يجب أن يتحمل طبقة المخاطر الأولى.

@BabylonLabs_io $BABY #baby

يعتقد معظم الناس أن تجميع الأصول معًا يجعل النظام أكثر كفاءة. يبدو ذلك معقولًا حتى تبدأ في التفكير في ما يحدث عندما تسوء الأمور.

تتبع خزائن بيبيليـون للبيتكوين غير القابلة للثقة مسارًا مختلفًا بشكل ملحوظ. بدلًا من وضع العديد من مستخدمي البيتكوين في مجمع مشترك، ترتبط كل خزانة بـ UTXO خاص بها. في البداية قد يبدو ذلك مجرد تفصيل تنفيذي. لكن كلما دققت أكثر، شعرت أنه نهج مقصود لإدارة المخاطر وليس مجرد تخزين للبيتكوين.

عندما يتم تجميع الضمان، قد تتحول مشكلة أحد المشاركين تدريجيًا إلى شأن يقلقه الجميع. تغيّر الخزائن المعزولة هذه العلاقة. تتبع كل خزانة دورة حياتها الخاصة، وعملية تحققها الخاصة، ومسار استردادها الخاص. تبقى المخاطر مرتبطة بالبيتكوين المحدد المستخدم بدلًا من أن تمتد عبر إيداعات غير ذات صلة.

أثار ذلك تساؤلي حول ما إذا كان العزل يتعلق فعلًا بالحيازة على الإطلاق. ربما يتعلق الأمر بالحفاظ على حدود واضحة. لا يصبح البروتوكول أكثر مرونة لمجرد أنه يجمع كل شيء معًا. أحيانًا تأتي المرونة من ضمان بقاء المراكز المستقلة مستقلة حتى عندما تشارك في النظام نفسه.

ربما تكون أهم نقطة في تصميم خزائن بيبيليـون ليست أن البيتكوين يبقى على البيتكوين. بل أن كل خزانة تحمل مسؤوليتها وحدها فقط.

@BabylonLabs_io $BABY #baby

غالبًا ما يصف الناس أنظمة السلاسل المتقاطعة وكأن أصعب جزء فيها هو إرسال المعلومات من شبكة إلى أخرى. لست مقتنعًا بأن هذه هي المشكلة الحقيقية.

لا تمتلك بيتكوين بطبيعتها طريقة لفهم ما يحدث على الإيثيريوم. لم تُبنَ لتُفسّر السجل التاريخي لسلسلة بلوك تشين أخرى، وطلب ذلك منها سيثير تغيير الافتراضات ذاتها التي تجعلها موثوقة.

ما شدّ انتباهي في بنية بابيلون هو أنها لا تحاول تعليم بيتكوين لغة جديدة. بدلًا من ذلك، تتعامل مع البراهين التشفيرية بوصفها الشيء الوحيد الذي يستحق تقديمه. ليست الغاية رسائل أفضل بين السلاسل. بل هي تزويد بيتكوين بأدلة يمكنها التحقق منها دون الاعتماد على تفسير طرف آخر.

جعلتني هذه النظرة أعيد التفكير في قابلية التشغيل البيني. ربما لا تحتاج الشبكات المستقلة إلى فهم بعضها بعضًا على الإطلاق. كل ما تحتاجه هو طريقة موثوقة للتحقق من الواقع نفسه عبر برهان تشفيري.

إذا كان ذلك صحيحًا، فإن التحقق من البراهين ليس مجرد عنصر تقني مخفي تحت السطح. بل يصبح، بصمت، الأساس الذي يسمح للأنظمة المنفصلة بالتنسيق مع الحفاظ على نماذج أمنها الخاصة.

ربما لا يُحدَّد مستقبل البنية التحتية للسلاسل المتقاطعة بمدى جودة تواصل سلاسل البلوك تشين مع بعضها، بل بمدى ضآلة الثقة التي يتعين عليها منح الاتصال نفسه.

@BabylonLabs_io $BABY #baby

أحد الأشياء التي تبرز بوضوح أثناء دراسة بيبليون هو أن قيود بيتكوين قد تكون في الواقع واحدة من أعظم نقاط قوتها. لم يتم تصميم Bitcoin Script ليكون منصة عامة لعقود ذكية. وغالبًا ما كان بساطتها يُنظر إليها على أنها قيد، لكن معمارية بابل تشير إلى منظور آخر؛ بدلًا من مطالبة بيتكوين بأن تصبح شيئًا ليست عليه، تم بناء نظام يحترم تلك الحدود.

لفتتني فلسفة التصميم هذه. بدلًا من توسيع بيتكوين بأكواد جديدة أو الاعتماد على الأصول المُغلَّفة (wrapped assets)، تستخدم Trustless Bitcoin Vaults قدرات البرمجة الموجودة في بيتكوين جنبًا إلى جنب مع تحقق تشفيري على مستوى البروتوكول لتنسيق التفاعلات مع التطبيقات الخارجية. يؤكد التوثيق أن عمليات الاسترداد والتحولات بين حالات السلاسل يتم التحقق منها باستخدام بدهيات سكربت بيتكوين الموجودة بدلًا من اشتراط إجراء تفرّع (fork) لبيتكوين.

كلما فكرت في الأمر أكثر، ازداد اقتناعي بأن القيود غالبًا ما تنتج هندسة أفضل. عندما لا يمكن للبروتوكول الاعتماد على برمجية غير محدودة، يتعين عليه حل المشكلات عبر تنسيق دقيق بدلًا من إضافة تعقيد إلى الطبقة الأساسية. ويبدو هذا النهج مختلفًا عن محاولة جعل كل سلسلة بلوكشين تعمل بالطريقة نفسها.

ربما ليست “الابتكار الحقيقي” هو جعل بيتكوين يتصرف مثل منصة عقود ذكية. ربما هو تصميم أنظمة تفهم بيتكوين جيدًا بما يكفي للعمل ضمن قواعدها بدلًا من إعادة كتابتها.

هل تؤدي القيود التقنية القوية في النهاية إلى تصميم بروتوكول أكثر مرونة، أم أنها تُبطئ الابتكار على المدى الطويل؟

@BabylonLabs_io $BABY #baby