طبقة السجلّ الخاصّة، ما زلت أفكّر في هذه… كنت أرى أصولًا واقعية على السلسلة في كل مكان تقريبًا، وكأنّ التوكنة تُزيل كل الأعمال القانونية الكامنة. لذلك بدأت أبحث فيما الذي يبقى خارج السلسلة فعلًا بعد التوكنة.
ما لفت انتباهي هو تركيز Dusk على العقود الذكية السرّية ومعيار XSC. لذا فالتعمية هنا ليست مجرد إخفاء مبلغ. بل هي بناء الخصوصية داخل البنية التحتية المالية.
دورة حياة توكنة شركات الجهات الصغيرة والمتوسطة (SME) هي ما جعل الأمر أكثر إثارة لاهتمامي. قد لا تزال عملية الهيكلة تتطلب موافقات الشركات. وقد لا تزال عمليات النقل تتطلب صكًّا موثقًا. وقد لا تزال أعمال الخدمة تتضمن أشخاصًا يتخذون قرارات بشأن المعاملة الضريبية. لمجرّد أن شيئًا ما أصبح مُرمّزًا (tokenized) لا يعني أن كل شيء يتحول تلقائيًا.
جعلني NPEX أفهم ذلك بشكل أوضح. فتوكنة أسهم شركة BV الهولندية لا تُقصي ببساطة العملية القانونية القائمة. يبدو أنها تتواجد إلى جانبها.
لعلّ Dusk إذًا ليست طبقة الاستبدال فعلًا. ربما هي أشبه بسجلٍّ سريٍّ مشترك يعمل بالتوازي مع الموثقين والجهات التنظيمية والمشغّلين المسؤولين، لأن هؤلاء الأشخاص وهذه العمليات لن تختفي.
كما أن حقيقة أن Dusk Trade ما يزال على قائمة انتظار جعلتني أفكر في الأمر بشكل مختلف. ربما يتم بناء البنية التحتية المؤسسية قبل وقت طويل من بدء التداول الحقيقي.
ما زلت أحاول أن أفهم شيئًا واحدًا: مع ازدياد تعقيد هذه البنى، كيف تعمل السرّية والإنفاذ القانوني معًا فعليًا؟ @Dusk #dusk $DUSK $TUT $GPS
ضوء القمر ضد العنقاء، ما زلت أفكر في هذه… السؤال الذي بدأني هو: لماذا نجعل كل معاملة عامة أو كل معاملة خاصة، بينما التمويل يحتاج فعلاً إلى الاثنين معًا؟
يستخدم ضوء القمر نموذج حسابات مع أرصدة عامة ونوْنس، بشكلٍ يشبه إلى حد كبير Ethereum. هذا منطقي للأشياء التي تحتاج إلى سجل تدقيق بشكل افتراضي.
أما Phoenix فيستخدم نموذج UTXO مع “notes” بدلًا من الأرصدة، والخصوصية مُدمجة في التصميم. وهو مناسب للتحويلات التي قد يكون فيها كشف المبلغ أو الطرف الآخر هو الخطر الحقيقي.
ما علِق بي حقًا هو أن الوثائق لا تحاول دمج نموذجين معًا. فهما يُحافظان على الفصل بوضوح: نوعان مختلفان للمعاملات يعملان على نفس طبقة DuskDS، بدلًا من نموذج واحد مع إضافة خيار خصوصية في وقت لاحق.
قد تميل التسوية المؤسسية أكثر إلى Moonlight، لأن الامتثال غالبًا ما يحتاج إلى أن تكون المعاملات مرئية وقابلة للتدقيق. من ناحية أخرى، تبدو التحويلات من نظير إلى نظير والمراكز الحساسة أنسب لـ Phoenix.
وصف Dusk كسلسلة خصوصية فقط يبدو وكأنه يفوّت الاختيار التصميمي الأوسع. يبدو أن Dusk تراهن على أن لا الشفافية ولا الخصوصية تكفي وحدها.
والآن فضولي يدفعني لمعرفة أي نموذج سينتهي به الأمر للتعامل مع حجم أكبر من المعاملات الواقعية على المدى الطويل. @Dusk #dusk $DUSK $DOLO $AIO
كنت أعتقد أن رمز الأمان (Security Token) هو في الأساس عقد ERC-20 مع أوراق إضافية مرفقة، نفس منطق التحويل، نفس الوصول المفتوح، فقط مُسمّى بشكل مختلف لأسباب قانونية. كلما بحثت أكثر فيما تتطلبه الأوراق المالية المُنظَّمة فعليًا، كلما بدا أن هذا الافتراض لا معنى له. تحمل الورقة المالية قيودًا لا علاقة لها بالشفرة إطلاقًا وبكل ما يتعلق بمن يُسمح له بحملها. كيف يمكن أن تنتقل الملكية ومن ترافقها الإفصاحات مع ذلك الانتقال. أهلية المستثمر، وحدود الاختصاص القضائي، وظروف التحويل الخاضعة للرقابة ليست ميزات يمكنك إضافتها إلى الرمز لاحقًا، بل هي السلوك الحقيقي للأصل. من هنا يبدو أن منطق مفهوم Dusk لـ XSC، "عقد الأوراق المالية السرّي" (Confidential Security Contract)، يستمد فكرته. بدلًا من التعامل مع الامتثال كقائمة تحقق خارجية تُفرض بواسطة وسطاء، فإنه يجعل الأهلية وقيود التحويل جزءًا من القواعد الداخلية للعقد نفسه، مع الاستمرار في استخدام آليات الخصوصية بحيث لا تكون تفاصيل الملكية مكشوفة بالكامل على السلسلة. يضع Dusk XSC كمعيار للأوراق المالية المُرمّزة التي تتيح الخصوصية. هذا يحوّل المسؤولية بعيدًا عن أمناء الحفظ الذين يتحققون يدويًا من كل صفقة، نحو بنية تحتية تُطبق القاعدة تلقائيًا. المقابل هو أن ترميز التعقيد والدقة القانونية داخل عقد أصعب من ترميز تحويل رصيد بسيط. هل يؤدي أتمتة الامتثال فعليًا إلى تقليل المخاطر أم أنه فقط ينقل مكان حدوث الأخطاء؟
منذ وقت طويل، افترضت أن التوافق مع EVM كان في معظمه مجرد بند تسويقي، أضافته بعض السلاسل لتبدو أكثر ترحيبًا دون أن يغيّر الكثير من التفاصيل الأساسية. لكن كلما تعمّقت في DuskEVM، كلما ضعفت هذه التبريرات.
يتيح DuskEVM للمطوّرين كتابة Solidity واستخدام أدوات الإيثريوم المألوفة، مع توفير بيئة تنفيذ متوافقة مع EVM وتتمتع بتوافق مع OP Stack. وتحت هذه التجربة المطوّرة المألوفة، توفر DuskDS طبقة التسوية الأساسية.
هذا الفرق مهم أكثر مما قد يبدو أولًا. تبدو بيئة التنفيذ مألوفة لمطوّري الإيثريوم، لكن التسوية والنهائية الأساسية ترتبط ببنية Dusk الخاصة، بدلًا من ربطها بالطبقة الأساسية لإيثريوم.
وما يفعله ذلك فعليًا هو خفض تكلفة تجربة شيء جديد. لا يحتاج المطوّر إلى إعادة تعلّم لغة أو إعادة بناء البنية التحتية فقط لاختبار ما إذا كانت ميزات الخصوصية والامتثال في Dusk تناسب حالة الاستخدام الخاصة به. وهذا يغيّر الدافع من «أقنعني بالتبديل» إلى «دعني آتي بما لديّ بالفعل وأرى ما الذي سيتغير من تحته».
أما المقابل فهو أن الألفة قد تُخفي الاختلافات الحقيقية في سلوك التسوية إذا افترض الناس أن التوافق مع EVM يعني أن كل شيء يعمل بالطريقة نفسها.
لذلك السؤال هو: هل يؤدي خفض تكلفة التبديل فعلًا إلى تسريع تبنّي التقنية، أم أنه يؤخر فقط النقطة التي يصبح فيها على المطورين التعامل مع الاختلافات الكامنة من الأسفل؟
يُقال إن الجهات التنظيمية في اليابان تشجّع حدود السحب الخاصة بالعملات المشفّرة للمساعدة في تقليل عمليات الاحتيال والاحتيال المالي. للوهلة الأولى، تبدو الفكرة معقولة. إذا كان بإمكان حماية المستخدمين بشكل أفضل وتقليل عمليات السحب غير المصرح بها، فقد يؤدي ذلك أيضًا إلى زيادة الثقة في استخدام العملات المشفّرة.
ومع ذلك، أعتقد أن كل تنظيم يأتي مع مقايضة. يمكن أن يؤدي المزيد من التحكم إلى تحسين الأمان، لكنه قد يقلّل تدريجيًا من الحرية المالية. بعد كل شيء، تتمثل إحدى المبادئ الأساسية للعملات المشفّرة في منح المستخدمين التحكم بأصولهم الخاصة.
بالنسبة لي، لا يتعلق الأمر فقط بحدود السحب. السؤال الأكبر هو كيفية إيجاد التوازن الصحيح بين الجهات التنظيمية والمستخدمين—توازن يقلّل عمليات الاحتيال والاحتيال المالي دون الإخلال بالقيم التي تجعل العملات المشفّرة مميزة.
تُعتبر كلٌّ من السلامة والأمان والحرية المالية أمرًا مهمًا. التحدي الحقيقي هو إيجاد توازن يحمي المستخدمين مع الحفاظ على المبادئ الأساسية للعملات المشفّرة.
على مرّ السنين، اعتقدت أن أقوى ما يتمتع به البيتكوين هو ببساطة الوجود بهدوء كمخزنٍ للقيمة—آمنٌ تحديدًا لأنه لا يفعل الكثير غير ذلك. كلما تعمّقت في تصميم بابيلون، بدأت هذه الفكرة تشعر بالنقص. يمكن لـ BTC المحفوظ ذاتيًا الآن أن تساهم بشكل مباشر في تأمين شبكات أخرى، دون مغادرة البيتكوين نفسها أبدًا. في حين أن مكافآت التكديس تُعد حافزًا للمشاركين، فإن الهدف الأوسع لبابلون هو استخدام البيتكوين لتوفير أمنٍ اقتصادي للشبكات الخارجية المعتمدة على الإثبات بالمصلحة (Proof-of-Stake). هنا يبدأ مفهوم الأمن بأن يصبح قابلاً لإعادة الاستخدام؛ بدلًا من أن تقوم كل سلسلة جديدة بإعداد مجموعة المدققين الخاصة بها وافتراضات الثقة من الصفر، يمكن لعدة منظومات الاستفادة من نفس أمن البيتكوين المدعوم في الوقت نفسه. ما يجعل هذا يعمل هو أن البيتكوين لا يتحرك أبدًا—لا تغليف، ولا تسليم الحيازة عبر جسر. يتم تصدير الأمان بينما تبقى الأصول في مكانها تمامًا كما كانت دائمًا. ليس لدى بابيلون نية لتغيير ماهية البيتكوين، بل لتوسيع ما يمكن للبيتكوين حمايته. إذا نجحت هذه المنظومة في التوسع واستمر التبنّي، فقد يصبح البيتكوين بنيةً تحتية أساسية تحت العديد من منظومات البلوك تشين بدلًا من البقاء مجرد أصلٍ سلبي يظل وحده. لذا إذا انتهى الأمر بأن يؤمّن البيتكوين عشرات البيئات بهذه الطريقة، فهل يمكن أن يصبح ذلك واحدًا من أكبر استخداماته بعد، أكبر حتى من كونه مخزنًا للقيمة؟
في البداية، افترضت أن الأمان المدعوم بالبيتكوين وحده كافٍ لجذب المطورين إلى نظام بيئي، وأن قوة الأمان كانت هي جوهر العرض. لكن كلما نظرت إلى كيفية نمو الأنظمة البيئية فعليًا، بدا ذلك الافتراض ناقصًا. يختار المطورون بالفعل البنية التحتية الآمنة بدلًا من إعادة بناء الأمان من الصفر، ويُخفِّض بابيلون تلك التكلفة بشكل ملحوظ عبر السماح للسلاسل باستعارة أمن اقتصادي مشترك مدعوم بالبيتكوين بدلًا من التمهيد لمجموعة مُحدِّدين (validator) خاصة بها. لكن الأمان لا يحل سوى نصف المشكلة. إذا كان معظم نشاط التداول ما يزال يحدث على منصات تداول مركزية، فإن النظام البيئي يظل يعتمد بشكل كبير على البنية التحتية خارج أسواقه داخل السلسلة. هذه الفجوة تستحق المراقبة، إذ إن سيطرة حجم التداول في منصات CEX على نشاط DEX تشير إلى شيء غير مريح بشأن مدى واقعية التبني اللامركزي في الوقت الحالي. الأرقام الحالية تجعل هذا التحدي أسهل في الرؤية. وبعبارة أخرى، إذا ظل التداول عبر الجهات المركزية عند المستويات الحالية، فستحتاج أن ينمو نشاط DEX بنحو 7.7× تقريبًا قبل أن يحدث حوالي 30% من إجمالي التداول على السلسلة. وهذا يوضح مدى بدائية السيولة اللامركزية حتى الآن. عندما تعمّق النظر في السيولة داخل السلسلة، فإنها تغيّر الصورة: انزلاق أقل، واكتشاف أفضل للأسعار، وتجربة لا يتعين على المستخدمين مغادرة السلسلة من أجلها. ولا تخدم السيولة المستخدمين فقط، بل تجعل البيئة بأكملها أكثر جاذبية للمطورين أيضًا، لأن التطبيقات تحتاج إلى سيولة موثوقة لتعمل بشكل جيد. ينتهي الأمر بأن يعزز الأمان والسيولة بعضهما بعضًا: تبنّي المطورين يغذي السيولة، والسيولة تجذب المزيد من المطورين. لذلك ربما لا تكون علامة بابيلون الفارقة الحقيقية هي عدد السلاسل أو أرقام الحجم، بل ما إذا كان يمكن للأمان المدعوم بالبيتكوين أن يستمر في النهاية في دعم اقتصاد داخل السلسلة الخاص به. هل يمكن للأمان المدعوم بالبيتكوين في النهاية أن يُنشئ سيولة ذاتية الاستدامة، أم أن الأسواق العميقة ستعتمد دائمًا على الحوافز?
في البداية، اعتقدت أن بيتكوين ديفاي (DeFi) يعني عمليًا التفاف (Wrapping) البيتكوين (BTC) تقريبًا تلقائيًا، وأن ذلك بدا الطريقة الوحيدة لجعله قابلًا للاستخدام في أماكن أخرى. وكلما تعمقت أكثر في نهج بايبيليون (Babylon)، لم يعد هذا الافتراض منطقيًا. الالتفاف يطلب منك الثقة بوصي يحتفظ ببيتكوين حقيقي (BTC) بينما تتداول نسخة مُصنَّعة في مكان آخر؛ وهذا لا يزيل المخاطر بل يعيد توطينها فقط.
تبدأ بايبيليون من سؤال مختلف تمامًا: ماذا لو لم يكن بيتكوين الأصلي مضطرًا أبدًا إلى مغادرته في المقام الأول؟ هذا ما بُنيت عليه فعليًا خزائن بيتكوين بلا ثقة (Trustless Bitcoin Vaults): إبقاء BTC أصليًا مع الاستمرار في كونه ضمانًا (collateral) قابلًا للاستخدام، وذلك عبر التحقق باستخدام سكربتات بيتكوين نفسها بدلًا من عقد جسر. لا وجود لجسر يعني عدم وجود سطح استغلال جالس بين السلاسل (chains)، ولا وجود لرمز مُصنَّع تعتمد قيمته على ملاءة طرفٍ آخر.
وهذا يضع الأساس للتطبيقات المستقبلية المدعومة ببيتكوين مثل الإقراض والاقتراض والمنتجات المالية المُهيكلة (structured financial products)، وكلها مبنية مباشرة فوق الأمان الحقيقي لبيتكوين (BTC) بدلًا من مشتقٍ مُلتف (wrapped derivative). يبدو الأمر كأنه أساس مختلف بوضوح ليتطور منه BTCFi. وإذا ثبتت قابلية هذا النموذج للتوسع، فقد تتطور BTCFi لتدور حول بيتكوين الأصلي نفسه بدل الاعتماد على التمثيلات المُلتفة.
لذا إذا كان بإمكان بيتكوين الأصلي دعم ديفاي دون التفاف على الإطلاق، فهل يزال لـ BTC المُلتف غرض حقيقي، أم أن نهج بايبيليون قد يغيّر ذلك تدريجيًا؟
كنت أعتقد أن تقليل الثقة في عالم العملات المشفّرة يعني فقط إضافة المزيد من القائمين بالتحقق (validators) أو بناء جسرٍ آخر خاضع للتدقيق (audited)، على أساس أن وجود مزيد من العيون تراقب النظام يعني مزيدًا من الأمان. لكن كلما تعمّقتُ في كيفية تعامل Babylon مع هذا الأمر، شعرت أن هذا الإطار يقلب الصورة رأسًا على عقب.
إن إضافة validators أو الجسور لا يُلغي الثقة، بل يوزّعها فحسب على أطراف أكثر قد تفشل أو تتواطأ. تتخذ Babylon مسارًا مختلفًا بدلًا من ذلك. في تصميمها، يبقى BTC في الحيازة الذاتية طوال الوقت. لا يحتاج المستخدمون أبدًا إلى تسليم عملاتهم إلى وسيط احتياطي (custodian) أو إلى عقد جسر يمكن استغلاله.
يبقى Bitcoin الأصلي على سلاسله الخاصة، باستخدام برمجة (scripting) أصلية متوافقة مع Bitcoin، وقيود زمنية (timelocks)، وآليات تشفير تدعم نموذج الأمان الخاص بـ Babylon، بدلًا من الاعتماد على وعد طرف ثالث أو حيازته.
هنا، يقوم الأمان التشفيري بالعمل الفعلي، وليس الثقة في أي مؤسسة أو شخص. يحدث التحقق على السلسلة (on-chain)، وبطريقة قابلة للإثبات (provable)، دون أن يحتاج أي أحد إلى قبول كلام شخصٍ ما كما هو.
في رأيي، هذا ليس مجرد ميزة، بل قرار معماري. عندما تزيل الوسطاء من صميم التصميم، لا يتعلق الأمر فقط بمن يتحمّل المسؤولية، بل يقلّل أيضًا من نقاط الضعف الخفية التي يمكن أن تتراكم فيها المشكلات بهدوء.
وجود عدد أقل من الأطراف التي يجب الوثوق بها يعني وجود أماكن أقل يمكن للنظام أن يتعطل فيها بصمت.
لذلك، إذا كانت تقليل الثقة هو الهدف الحقيقي، ألا يعني ذلك أن البنية/المعمار (architecture) يصبح مهمًا أكثر حتى من سمعة من يدير النظام؟
في البداية، اعتقدت أنه إذا كان البيتكوين يوفر بالفعل الأمن الاقتصادي، فإن إضافة توكن جديد تبدو غير ضرورية تقريبًا، كأن بابل كانت تحل مشكلة لا وجود لها فعلًا. لكن عندما نظرت أعمق إلى ما يفعله توكن BABY فعليًا، تغيّر هذا الاعتقاد.
الحقيقة هي أن $BTC and $BABY لا يقومان بنفس الدور. دور البيتكوين يقتصر على توفير الأمن الاقتصادي. إنه رأس المال الحقيقي الذي يحمي الشبكة، وإذا أراد مهاجم أن يفسد الإجماع، فعليه أن يضع نفس هذا رأس المال على المحك.
$BABY ، من ناحية أخرى، يتحمل مسؤوليات لم تكن البيتكوين مصممة لها من الأساس، خصوصًا الحوكمة. يجب أن تتم ترقيات البروتوكول، وتغييرات مختلف المعلمات، والقرارات المتعلقة بموفري الإنهاء (Finality Providers) بطريقة ما، وهذا يتطلب توكنًا لا يُبنى فقط كضمان، بل كأداة لتنسيق الشبكة واتخاذ القرار.
تسري الحوافز داخل الشبكة عبر #Baby بالطريقة نفسها. فهذا هو التوكن الذي يكافئ الرهان، والمشاركة، وتكاليف التشغيل اليومية لتشغيل هذا النظام عبر سلاسل بلوكشين متعددة. وبالإضافة إلى ذلك، فإنه يُبقي المشاركين المختلفين في النظام البيئي متوافقين من خلال إطار مشترك للحوكمة والحوافز.
لو لم يكن موجودًا، لظل الأمن الاقتصادي القوي للبيتكوين حاضرًا، لكن لن تكون هناك طريقة فعّالة لتنظيمه، واتخاذ القرارات، أو الحفاظ على تنسيق النظام البيئي.
الفرق الحقيقي هو أن البيتكوين توفر القوة والأمن الاقتصادي، بينما يحمل Baby مسؤولية الحوكمة والتنسيق واتخاذ القرار. أدوارهما مختلفة، وفي نموذج بابل، يُكملان بعضهما البعض.
لذا إذا كانت BTC تؤمّن النظام وBABY تحكمه، فمتى حدث خطأ—فأين تقع المسؤولية الفعلية؟
في البداية، اعتقدت أن قصة بابل تبدأ وتنتهي بأمان أصلي من بيتكوين: بدون جسور، بدون أمناء حفظ، وبتحققٍ منغرس مباشرةً في بيتكوين بدلًا من الثقة بأصلٍ مُلتف.
لكن كلما تدقيقت أكثر، شعرت أنها ليست سوى نصف الصورة. تأتي قوة التحقق مقابل تنازل حقيقي: تأخيرات التأكيد التي تُبطئ الأمور، وأمانٌ يُشترى على حساب السرعة وسلاسة تجربة المستخدم. هذا اختيارٌ مقصود وليس خللًا، لكنه يعني أن البروتوكول ما يزال يحتاج إلى شيء لا يمكن للأمان وحده توفيره: اقتصاديات رمزية مستدامة.
نِسَب التخصيص نادرًا ما تحكي القصة كاملة؛ فالأهم هو جدول الاستحقاق (الـvesting)، لأن تخصيصًا صغيرًا يُفكّ ببطء يختلف سلوكه اختلافًا كبيرًا عن تخصيصٍ كبير يُفك بسرعة. تؤثر عمليات الإطلاق المستقبلية في المعروض المتداول وضغوط البيع قبل أن تؤثر القيمة الإجمالية لأي إجمالي إمداد حتى. وبالنهاية، تأتي قيمة الرمز من الطلب الحقيقي: المشاركة في الإتستيكينغ، ونشاط الحوكمة، والاستخدام الفعلي—وليس من الندرة وحدها.
وتُعد أيضًا الحيازات طويلة الأجل مهمة هنا: فالقناعة تقلّل البيع الانعكاسي وتدعم سلوكًا سوقيًا أكثر اتزانًا مع نضوج النظام البيئي.
لذلك، إذا كانت بابل تُحقق وعودها بشأن الأمان الأصلي من بيتكوين، فهل ستصمد اقتصادياتها الرمزية بما يكفي للحفاظ على هذه الرؤية، أم أن ديناميكيات الإمداد المستقبلية ستنتهي لتكون المشكلة الأصعب التي يتعين حلها؟
في البداية، ظننت أن كل بلوكتشين يجب أن يبني أمنيته الخاصة من الصفر. كان ذلك يبدو وكأنه مجرد تكلفة إطلاق شبكة جديدة. لكن كلما تعمقت أكثر في مدى تجزؤ أمن البلوكتشين فعليًا، أصبحت الصورة أكثر تعقيدًا وفوضوية.
مئات السلاسل تبني مجموعات مدققين منفصلة، يتنافس كل منها على رأس مال جديد، ويطلب من المستخدمين الثقة في أنظمة لا تمتلك سجلًا يذكر أو شبه معدوم. عندما رأيت هذا النمط، تساءلت عما إذا كانت كل شبكة جديدة فعلًا تحتاج إلى حل مشكلة الأمان نفسها من تلقاء نفسها.
عند هذه النقطة لفت انتباهي بابيلون. لا تتمحور طريقتها حول طلب أن يصبح البيتكوين شيئًا مختلفًا. بدلًا من التعامل مع البيتكوين كأصلٍ يظل فقط في التخزين البارد، تستكشف بابيلون كيف يمكن للأمان الاقتصادي للبيتكوين أن يساعد في تعزيز عدة سلاسل إثبات حصة (Proof-of-Stake).
يحمي البيتكوين بالفعل واحدة من أكبر الشبكات الاقتصادية في مجال التشفير وأكثرها اختبارًا في ساحات المعارك. وتتمثل فكرة بابيلون في بساطة: بدلًا من ترك هذا الأمان معزولًا، لماذا لا نجعل سلاسل إثبات الحصة الأخرى تستفيد منه؟
تبدو الفكرة جذابة لأنها قد تجعل إطلاق الشبكات الجديدة وتأمينها أكثر كفاءة من حيث رأس المال. وفي الوقت نفسه، يطرح الأمان المشترك أسئلة مهمة. إذا اعتمدت عدة سلاسل على المصدر نفسه للأمان الاقتصادي، فهل يقلل ذلك المخاطر الإجمالية عبر أمان أقوى، أم أنه ببساطة يركز المخاطر في مكان مختلف؟
ما زلت أستكشف الفكرة، لكنها واحدة من أكثر المقاربات إثارة للاهتمام التي صادفتها لإعادة التفكير في أمن البلوكتشين.
كنت أعتقد أن القيمة الإجمالية المقفلة (TVL) كانت في الأساس مجرد مؤشر على مدى أمان الشبكة؛ فكلما كانت القيمة المقفلة أكبر، كان ذلك يعني ثقة أكبر. لكن عندما نظرت عن كثب إلى كيفية تعرض الإجماع للهجوم فعليًا، بدأت تلك العلاقة تبدو غير صحيحة.
تقيس TVL رأس المال الموجود داخل نظام ما، لكنها لا تقول شيئًا عن تكلفة أن يقوم شخص ما بإفساد مُدقِّقي ذلك النظام. هذا هو الفرق بين القيمة المقفلة والأمن الاقتصادي، وهو فرق ذو معنى.
تصبح الشبكة صعبة الهجوم ليس لأنها تحتجز قدرًا كبيرًا من القيمة، بل لأن مهاجمتها تتطلب وضع كمّ هائل من رأس المال على المحك، مع احتمال أن يتم خصم ذلك رأس المال (slashing). وهو رأس مال يفضّل المهاجمون ألا يخسروه. هنا تحديدًا يغيّر استخدام بيتكوين كضمان طريقة الحساب.
تتيح بيبلون (Babylon) للمُدقِّقين أن يدعموا قوة توقيعهم عبر BTC يمكن إثبات إمكانية خصمه عليها في بيتكوين نفسها، مما يربط سوء السلوك برأس مال خارجي حقيقي بدلًا من رموز محلية مُنتفخة. فجأةً، لم يعد إفساد الإجماع أمرًا رخيصًا؛ بل أصبح غير منطقي اقتصاديًا.
لذلك ربما يكون السؤال الأكثر فائدة لأي شبكة تعمل بإثبات الحصة (PoS) ليس مقدار القيمة المقفلة داخلها، بل كم ستكون مكلفة فعليًا مهاجمتها من الخارج.
يَفترض الجميع أن بيتكوين يجب أن تصبح قابلة للبرمجة لتفعل المزيد. كلما تعمّقت في بابل، ازددتُ اقتناعًا بأن هذا الافتراض مُقلوب.
لغة برمجة بيتكوين مقصودة بالحدّية والتقييد. هذا ليس عيبًا بل هو السبب في أن الشبكة ظلت آمنة ويمكن التنبؤ بها على مدار أكثر من عقد. معظم المحاولات لجعل بيتكوين "مفيدة" في أماكن أخرى تنتهي بالاعتماد على الجسور أو الرموز الملتفّة (wrapped)، وقد رأينا ما يكفي من استغلالات الجسور لنفهم أن الكثير من المخاطر الفعلية يتم إدخالها هناك، وليس داخل بيتكوين نفسها.
تسلك بابل طريقًا مختلفًا. بدلًا من مطالبة بيتكوين بتشغيل العقود الذكية، تُمكّن حَمَلة BTC من الرهان (staking) بشكل أصلي، وتمدد الأمان الاقتصادي إلى سلاسل أخرى، عبر الاستفادة من خاصيتيّ الطابع الزمني لإيداع بيتكوين والإجماع الخاص بها، بدلًا من نسخة مُركّبة/مُلتفّة صناعيًا من BTC. لا حُرّاس (custodians) يحتفظون بأموالِك، ولا عقد جسر لتثق به.
ما أجده مُلفتًا هو هذا القدر من التقييد: ليست بابل تحاول تحويل بيتكوين إلى إيثريوم. لكن التحديات حقيقية أيضًا: شروط الإقطِاع (slashing)، وحِيوية المُتحققين (validator liveness)، وتبنّي سلاسل PoS التي تكون مستعدة للاتصال بطبقة الأمان هذه ما زالت قيد الاختبار على نطاق واسع.
إذا كانت بيتكوين قادرة على تأمين سلاسل أخرى دون أن تغيّر نفسها، فلماذا ما زلنا نلاحق فكرة القابلية للبرمجة بدلًا من حماية ما يعمل بالفعل؟
كنت أظن أن إقحام/تأمين البيتكوين (staking) يعني فقط حبس الـBTC في مكان ما وكسب عائد، مثلما يحدث مع أي توكن آخر. وهذا بالضبط ما تقوله أيضًا الحملات التسويقية حول Babylon. لكن عندما غصت فعليًا في طريقة عمله، شعرت أن هذا التصوير غير دقيق.
إليك ما لفت انتباهي: الـBTC الخاص بك لا يتحرك أبدًا. لا توجد تغليفات (wrapping)، ولا جسور (bridging)، ولا نسخة اصطناعية من عملتك تطفو في سلسلة أخرى. بل يبقى محبوسًا عبر سكربت مؤقت/Timelock أصيل للبيتكوين، وأنت تحتفظ به بنفسك طوال الوقت.
ما يفعله Babylon في الحقيقة هو تصدير أمن البيتكوين إلى سلاسل بلوكشين إثبات الحصة (Proof-of-Stake). فهذه السلاسل تستعير الوزن الاقتصادي للـBTC لتأمين نفسها، دون لمس طبقة البيتكوين الأساسية ودون الحاجة إلى توكن جديد.
جزء فك الـstaking أيضًا فاجأني. كنت أتوقع شيئًا أقرب إلى فترات فك الارتباط الطويلة التي تراها في أغلب أنظمة PoS. لكن تصميم Babylon مقصود أن يكون أسرع بكثير، لأنه لا توجد أصول مُغلّفة يتعين فكها.
ما زلت غير متأكد بشأن موضوع الـslashing (الخصم/الغرامات عند سوء السلوك). إذا تَصرّف مُحقق/validator بشكل خاطئ على سلسلة PoS ما، وكان الـBTC الخاص بك يدعمه، فماذا يحدث فعليًا لحصتك؟ تبدو الآليات أكثر تعقيدًا مما يظن الناس، ولم أقتنع بعد تمامًا بأن المخاطر “سلبية” كما يتم تسويقها.
ما زلت أحاول معرفة أين بالضبط يقع المقابل الحقيقي هنا—هل قام أي شخص بالنظر عن كثب إلى شروط slashing..؟؟ #baby @BabylonLabs_io $BABY $BTC @Bitcoin
أتردد. لقد كنت أحتفظ بالبيتكوين عبر محفظة أجهزة منذ فترة، وكل مرة يطلب مني بروتوكول جديد نقل الأموال إلى إعداد احتجاز (custody) غير مألوف...
هذا التردد هو جوهر معضلة الحيازة الذاتية بالكامل. أنت تتحكم بمفاتيحك، صحيح، لكن ما إن تتفاعل مع أي شيء جديد، فأنت تثق بواجهة لم تختبرها من قبل.
لهذا برز لي تكامل Babylon وLedger عندما بحثت فيه. Babylon لا يطلب من أحد تغيير عاداتِه؛ إذا كنت تتعامل مع BTC بجدية، فغالبًا تكون محفظة Ledger بالفعل جزءًا من تجهيزاتك. لقد أُدرج ذلك ببساطة ضمن سير عمل يثق به الناس مسبقًا—بدون هجرة، وبدون محفظة جديدة.
أكثر ما وجدته مفيدًا هو جزء “التوقيع الواضح”. لقد أقلقني التوقيع الأعمى لسنوات بصراحة. الموافقة على معاملة دون معرفة ما الذي توافق عليه بالضبط دائمًا شعرت بأنه فجوة لم يتحدث عنها أحد بما يكفي. مع التوقيع الواضح، سترى تفاصيل المعاملة على الجهاز قبل تأكيد أي شيء. هذا ليس مجرد تحديث تجميلي لواجهة المستخدم—بل هو إصلاح أمني حقيقي.
الآن، عدد موقّعي Ledger الذي يتجاوز 8 ملايين رقم كبير، ويمنح Babylon فرصة جدية للوصول والتوزيع. لكني أذكّر نفسي دائمًا أن الوصول إلى المستخدمين ليس هو نفسه امتلاك ثقتهم. ما سيحدث بعد ذلك يعتمد كثيرًا على ما إذا كان المطورون فعلًا سيبنون أشياء ذات معنى فوق هذه الخزائن البيتكوين دون ثقة (Trustless).
وبصراحة، السؤال الأكبر في رأسي هو مسألة “الحجم/النطاق”. منطق الخزن يبدو نظيفًا في بيئة مُتحكم بها، لكن هل سيصمد عندما تزيد فعليًا أحجام المعاملات؟ هنا إما أن تثبت الأنظمة نفسها، أو أن تنهار بصمت.
هل سيجلب التصميم الأمني أولًا أخيرًا حَمَلة البيتكوين المحافظين إلى الشبكة على السلسلة (on-chain)، أم أن الحوافز ستظل دائمًا تفوق أفضل الأمان...? #baby @BabylonLabs_io $BABY
كنت أقرأ الكثير عن بابل، وسؤال واحد يستمر في شغف ذهني: لماذا يجلس الكثير من البيتكوين هناك دون أن يفعل شيئًا..؟
إما أن يحتفظ الناس ببيتكوينهم ويحصلون على فائدة معدومة منه، أو يقومون بتغليفه ومنح السيطرة لشخص آخر. كلا الخيارين يبدو خاطئًا إذا كنت تهتم حقًا ببقاء البيتكوين لامركزيًا وبدون ثقة.
وهذه هي المشكلة التي يحاول بابل حلها عبر شيء يُسمى صناديق بيتكوين بدون ثقة. استثمرت a16z كريبتو 15 مليون دولار في بابل، واشترت توكنات BABY مباشرة، للمساعدة في بناء هذا النظام. الفكرة بسيطة: تبقى بيتكوينك الفعلية على سلسلة البيتكوين، ولن يتم تغليفها أبدًا، ولن تُرسل إلى أمين حفظ، لكنها مع ذلك يمكن استخدامها كضمان في التمويل اللامركزي DeFi. تتحقق إثباتات تشفيرية خاصة من أن البيتكوين مُقفَل بشكل صحيح، بدلًا من الاعتماد على شركة أو وسيط.
ما يلفت انتباهي هو أن بابل لا تبني مجرد تطبيق آخر. بل تبني الطبقة الأساسية التي يمكن للمشاريع الأخرى استخدامها لاحقًا. إذا نجح هذا فعلًا، سيحصل البيتكوين على حالة استخدام حقيقية جديدة تتجاوز مجرد الاحتفاظ به، وهذا أمر كبير.
بالنسبة لـ BABY، قد يعني ذلك دورًا أكبر عبر كل نشاط الصناديق هذه، إذا بدأ الناس فعلًا في استخدامه.
لكن لنكن واقعيين: هذه التقنية ما زالت جديدة ومعقدة. لا يعني الدعم من أسماء كبيرة تلقائيًا أن الناس سيستخدمونها.
هل تعتقد أن ضمان بيتكوين بدون ثقة سيصبح أكبر حالة استخدام حقيقية للبيتكوين، أم أن هذه الفكرة ما زالت بعيدة عن العمل على نطاق واسع؟ v#baby @BabylonLabs_io $BABY
لقد كنت أفكر في الفرق بين البنية التحتية والشبكة، لأنهما ليست الشيء نفسه.
البنية التحتية تحتاج فقط إلى أن تعمل. الشبكة تحتاج إلى أن تُستخدم.
يمكن أن تمتلك @NewtonProtocol بنية معمارية مثالية وسياسات متينة ومشغّلين أمناء وأمانًا حقيقيًا، ومع ذلك تظل بنية تحتية صِرفة إذا لم يكن هناك من يبني فعاليةً فعليةً فوقها. لم تكن مسألة العمل بشكل صحيح هي الجزء الصعب أبدًا.
تحدث النقلة الحقيقية عندما يبدأ المطورون في الاعتماد عليها يوميًا، عندما تقوم العوامل (الـagents) بالتوجيه عبرها دون تفكير، عندما يتفاعل المستخدمون معها دون أن يعرفوا اسمها.
عندها فقط تصبح البنية التحتية شبكةً بشكلٍ صامت. ليس عبر الإعلانات. بل عبر التكرار الذي لم يعد أحد يهتم بذكره.
لا أعتقد أن سؤال هندسة نيوتن هو السؤال المفتوح هنا. أعتقد أن السؤال المفتوح هو ما إذا كانت هناك بالفعل كمية كافية من النشاط الحقيقي لتظهر وتحوِّل نظامًا مُحكم البناء إلى شيء يعتمد عليه الناس فعليًا. هذا أمر أصعب بكثير من كتابة الكود. @NewtonProtocol #Newt $NEWT
الخطر الأكبر على بروتوكول نيوتن ليس الأمن. بل هو إثبات أنه يمكن أن يصبح ضروريًا...
في كل مرة أقرأ فيها عن بروتوكول بنية تحتية جديد، تكون المسألة الأولى التي يقلق بشأنها الناس هي الأمان. هل يمكن اختراقه. هل يمكن للمشغّلين التواطؤ. هل يمكن أن يتم التحايل على النظام. هذه أسئلة عادلة، ويبدو أن @NewtonProtocol قد جعلتها تتطلب تفكيرًا حقيقيًا عند الإجابة عنها: التحديات الخطِرة/الخطرة، والتحديات على نحو ZK، والمصلحة الاقتصادية المرتبطة بالسلوك الصادق. لكنني لا أعتقد أن الأمن هو في الحقيقة أكبر خطر هنا. هناك الكثير من الأنظمة الآمنة في عالم التشفير لم يكن لها شأنٌ يومًا. لقد عملت تمامًا كما صُمِّمت وانتهى بها الأمر إلى النسيان، لأن العمل بشكل صحيح لم يكن يعني أبدًا أنها كانت مُطلوبة. تُجيب الأجوبة الأمنية عن "هل يمكن الوثوق به." لكنها لا تُجيب عن "هل يحتاجه أي شخص فعلًا كي يعمل."
هناك شيء أستمر في التفكير فيه حول @NewtonProtocol وهو أن الثقة تُختبَر في لحظتين مختلفتين تمامًا.
قبل حدوث أي معاملة، تُبنى الثقة عبر السياسة. يتم التحقق من القواعد، ويتم إنتاج شهادة إثبات (attestation)، ولا يحدث التنفيذ إلا إذا كان كل شيء متطابقًا. هذا الجزء متعمد، ومُهندَس، وربما مملّ نوعًا ما من حيث مدى دقته وتحديده.
لا توجد “محرك سياسات” لسلوك السوق. لا توجد شهادة إثبات تُظهر أن الناس لن يبيعوا. تُظهر عمليات الإطلاق شيئًا مختلفًا، سواء أكان الأشخاص الذين يحملون الرمز يؤمنون فعلًا بما يجري بناؤه، أم كانوا فقط ينتظرون السيولة.
أظن أن هذا هو الاختبار الأكثر صدقًا، على نحوٍ ما.
يمكن لأي شخص بناء نظام يتصرف بشكل جيد عندما لا تكون هناك حوافز لكسرِه. تظهر الإشارة الحقيقية عندما تتوفر سببٌ سهلٌ للانسحاب ولا يحدث ذلك.
بنية نيوتن (Newton) تثبت الأمور قبل تنفيذ المعاملات. هذه هي الثقة التقنية.
عمليات الإطلاق تختبر شيئًا لا يستطيع الكود التحقق منه: هل يثق الأشخاص من حول المشروع فيه بما يكفي للبقاء.
كلاهما مهم. واحدٌ منهما فقط هو الذي يتولى البروتوكول أمره. #Newt $NEWT