币圈貂蝉

كنت أراقب الوثائق المرتبطة بـ @OpenGradient لمدة تقارب الأسبوعين، وفي عدة مرات اعتقدت أنني فهمت، ثم أكتشف أنني لم أفهم شيئًا.

في البداية، كان المفهوم الذي أوقفني هو الخلط بين مفهومين. OpenGradient Chat يبدو كمنتج محادثة AI مستقل، وقد اعتقدت في مرحلة ما أنه هو كل المشروع. حتى عدت لفرز السلسلة وأدركت أن Chat هو مدخل الاستدلال من جانب المستخدم، بينما OpenGradient هو طبقة البروتوكول الموثوق خلفه، والاثنان هما الواجهة الأمامية والخلفية لنفس النظام، ورؤية كل منهما بمفرده غير مكتملة. #opg

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

أكثر التفاصيل التي تم التقليل من شأنها هي طيف التحقق: فئة LLM تستخدم أجهزة TEE لتغليف الإثبات، وفئة إدارة المخاطر DeFi تستخدم zkML لتوليد إثباتات SNARK، والطريقتان يمكن استخدامهما معًا في نفس المعاملة. ليس تنازلاً، بل هو التعرف على أن متطلبات الثقة في السيناريوهات المختلفة مختلفة بطبيعتها. الشبكة قامت بتشغيل 2000000 مرة من الاستدلال القابل للتحقق، وأكثر من 500000 إثبات تشفير على السلسلة، ودمج DeepProve زاد سرعة إثبات zkML بمقدار 158 مرة.

بعد فهم هذه الأمور، يمكنني التعامل مع $OPG بسهولة: بروتوكول x402 يدمجه في كل سلسلة دفع للاستراد، وتردد الاستهلاك مرتبط مباشرة بالقدرة على المعالجة، وغير مرتبط بدورة السرد. #OPG

السؤال الوحيد الذي يدور في ذهني هو: هل سيكون المطورون مستعدين للمشاركة؟ الاستدلال الموثوق لا يتطلب طرق مختصرة، يجب بناء كل تطبيق على حدة. ولكن بمجرد الانتهاء، فإن OpenGradient و OpenGradient Chat سيكونان أساس الثقة في عصر AI.

OpenGradient هو جوهر مرتبط ارتباطًا وثيقًا، ليس قدرة النموذج، ولكن OpenGradient Chat كطبقة مدخلات تحمل الشكل الأولي للمعلومات، وكيفية إعادة بناء Protocol للحالة قبل حدوث الحساب بناءً على ذلك، مع الاستمرار في ضبط توزيع مسار الحساب باستخدام $OPG . #opg

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

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

Protocol هنا ليست معالجة مسبقة بالمعنى التقليدي، بل هي إعادة كتابة المدخلات إلى كائن حالة موحد قبل دخول Chat إلى الحساب، مما يجعل النموذج يواجه ليس نصًا، بل شكل حساب منظم.

بينما يؤثر $OPG في عملية تنفيذها على توزيع أوزان مسارات الحساب المختلفة، مما يسمح للنظام بجدولة الموارد ديناميكيًا بين حسابات متعددة.

عندما عدت لترتيب سجلات هذه التجارب، أدركت أن الاختلاف الحقيقي لا يكمن في "تحسن الردود"، بل في أن المدخلات قد أعيد تعريفها كشكل آخر من الوجود. #OPG @OpenGradient

أول ما بدأت أتواصل مع @OpenGradient و OpenGradient Chat، ما كان عندي فكرة معقدة، كنت أعتبره كبيئة تجريبية أقدر أجرب فيها نماذج مختلفة، عشان أشوف مين يجاوب بشكل أفضل. في الجولات الأولى كان في اختلاف، لكن مو بشكل كبير، ما وصل لمرحلة تخليني أتحمس كثير. الشيء اللي خلى بالي يتوقف شوية هو ظاهرة غريبة: بعض مسارات الاستدلال اللي انتهت، ترجع تظهر مرة ثانية، لكن مو بنفس الشكل، كأن النظام يعيد صياغتها ويعيد إدخالها في استدلال جديد، في البداية حتى شكيت إذا كنت أذكر غلط. #opg

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

بعد فترة، بدأت أفهم OpenGradient Chat كحالة متغيرة مستمرة، مو كالسياق التقليدي اللي يعتمد على سؤال وجواب. مخرجات النماذج المتعددة هنا مو مجرد تكدس، بل دائمًا تتفكك، يعاد تشكيلها، وتوزع. بعض المسارات ما راح تختفي تمامًا، لكن مو ثابتة، بل في حالة "أحيانًا يمكن استدعائها، وأحيانًا لا"، وهذا الشيء يعتبر غير بديهي. #OPG

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

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

بالأمس في الليل، عندما كنت أستخدم OpenGradient Chat برقم @OpenGradient ، لم يكن لدي هدف واضح، كنت فقط أتعامل مع بعض الأمور العشوائية. المدخلات لم تكن مرتبة عمدًا، كثيرًا ما كنت أكتب ما يخطر على بالي، وفي بعض الأحيان كنت أرسل أفكاري قبل أن أكون قد فكرت فيها بالكامل، ولم أشعر حينها أن هناك مشكلة في ذلك. #opg

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

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

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

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

عند النظر إلى OpenGradient من منظور أعمق، فإن قيمته ليست في تحسين جودة الإجابات الفردية، بل في السماح لمهمة ما بالتدفق بين نماذج متعددة دون أن تتعطل بسبب تغييرات في أسلوب المدخلات. #OPG

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

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

في الأيام القليلة الماضية، كنت أركز كل طاقتي على تفكيك تصميم بروتوكول @OpenGradient ، واختبرت OpenGradient Chat عدة مرات. في البداية، كنت أعتقد أن أبرز ميزاته هي حماية الخصوصية، لكن بعد أن قمت بتغيير نفس الـ Prompt خمس مرات، وفي المرة الثالثة عمدت إلى تقسيم جملة كاملة إلى عدة أجزاء، وأضفت في المنتصف جملتين غير ذي صلة تمامًا. بعد انتهاء الاختبارات، توقفت لأعيد قراءة وثائق البروتوكول، لأنني اكتشفت أن ما يستحق البحث فيه ليس الخصوصية. #opg

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

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

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

عند دراسة الأمر حتى النهاية، قللت من رؤيتي لـ @OpenGradient كمنتج دردشة ذكاء اصطناعي. ما جعلني أبحث فيه مرارًا وتكرارًا هو محاولته تحديد مدخلات حساب الذكاء الاصطناعي أولاً، ثم تحديد كيفية تعاون الذكاء الاصطناعي في الحساب. إذا استطاع هذا البروتوكول أن ينضج بشكل مستمر، فإن OpenGradient Chat يشبه المدخل الأول الذي يتم تنفيذه في الشبكة البروتوكولية بأكملها، وليس نقطة النهاية. #OPG $OPG

عند دراسة @OpenGradient ، في البداية كنت أفكر في الاتجاه الخاطئ. #OPG

في البداية، كنت مهتمًا بـ OpenGradient Chat، واعتقدت أنه مجرد منتج AI يربط بين نماذج متعددة. ولكن بعد أن قمت بالتعمق في الوثائق، بدأت أطرح سؤالًا متكررًا: إذا كانت نتائج AI لا يمكن إثبات مصدرها، فهل لا تزال قادرة على الدخول في نظام القيمة على السلسلة؟

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

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

تتولى OpenGradient Chat في الواقع دور مدخل الطلب. بدون استدعاء مستمر، لا يمكن أن تنتج طبقة التحقق قيمة؛ وبدون طبقة تحقق، ستتحول منتجات الدردشة إلى أدوات AI عادية. إنها ليست طبقات علوية وسفلية، بل هي هيكل مرتبط ببعضه البعض.

لاحظت أيضًا في الدراسة فرقًا رئيسيًا: التحقق من النموذج وتحقيق الاستدلال ليسا نفس الشيء. الأول يمكنه فقط إثبات موضوع الاستدعاء، بينما الثاني يجب أن يثبت أن عملية الحساب قد حدثت بالفعل. من الناحية النظرية، zkML أكثر شمولًا، لكن تكلفته مرتفعة جدًا، لذلك تعتمد OpenGradient في الوقت الحالي بشكل أساسي على TEE لإكمال تحقق الاستدلال، وهذا يبدو كمسار عملي ضمن قيود الهندسة.

عند كتابة هذا، أشعر بأنني أكثر تأكيدًا على نقطة واحدة: ما تؤكده OpenGradient حول AI القابلة للتحقق، في جوهرها ليس تحسين جودة الإجابات، بل تحويل "قدرة الحوسبة القابلة للتصديق" إلى أصول يمكن التحقق منها وتحديد سعرها.

#opg $OPG

قبل يومين في منتصف الليل، كنت أعدّل على رسم بياني بشكل متكرر، وكنت متعباً قليلاً من تغيير الـ prompt، تعبيرات الشخصيات والأجواء في الصورة لم تتطابق أبداً، وبعد عدة جولات من التوليد، كنت أتنقل بين "الفشل" و"التسوية"، وكنت على وشك إيقاف العمل مباشرة.

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

وهذا كان النقطة الرئيسية التي أعادت لي فهم ورشة عمل OpenGradient Chat الخاصة بـ @OpenGradient . أدوات التوليد التقليدية، في جوهرها، تعطي نتيجة مرة واحدة: إدخال → إخراج، والعملية مضغوطة. لكن في بيئة النماذج المتعددة المتوازية (مثل Gemini، ByteDance، xAI، وغيرها)، سيتم تقسيم نفس الإدخال إلى مسارات توليد متعددة، وهذه المسارات ليست للاختيار من "الحل الأمثل"، بل لتوسيع "مساحة الاستكشاف". #opg

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

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

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

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

بعد ما فتحت مسار معالجة بيانات @OpenGradient و OpenGradient Chat، صار عندي سؤال ظل في ملاحظاتي لفترة طويلة: لما AI يصير أذكى في فهم تعبيرات البشر، كم يحتاج يعرف عن "هالشخص" نفسه.

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

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

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

ما أدري إذا هالفكرة راح تصير اتجاه مهم في أنظمة AI المستقبلية، لكن على الأقل خلال دراسة $OPG و #OPG ، صرت أكثر اهتمامًا بسؤال: AI الممتاز في المستقبل، مو بس راح يكون أذكى في فهمنا، لكنه لازم يعرف أي أجزاء ما تحتاج يعرفها.

#opg $OPG

عندما كنت أبحث في Bedrock 2.0، كنت أشعر دائمًا أن الهيكل الناضج لـ BTCFi، النقطة التي تستحق المراقبة ليست في عدد الشبكات الموثوقة التي تتصل بها، ولكن في كيفية تحديد التعقيدات التي يجب أن تُعرض على المستخدمين، وأي منها يجب أن تُخفى داخل النظام. #bedrock

يتحدث الكثير من الناس عن توسيع أمان BTC، ويركزون على مقدار مصادر الدخل الجديدة، ولكن من منظور الهيكل، فإن الأهم هو "أين يجب أن تبقى التغييرات". يمكن أن تستمر Babylon و Kernel وغيرها من الشبكات الموثوقة المستقبلية في تعديل آليات الأمان ونماذج العائدات وحتى قواعد الخروج، وإذا تم نقل هذه التغييرات مباشرة إلى مستوى DeFi الأعلى، فإن الاقتراض، التداول، وغيرها من السيناريوهات المالية ستضطر إلى التكيف مع تغييرات القواعد الأساسية.

عندما وصلت إلى هذه النقطة في دراستي، أدركت أن تصميم uniBTC في Bedrock 2.0 ليس مجرد إصدار موحد لشهادة BTC. بل هو أشبه بواجهة نظام: الشبكة الموثوقة الأساسية مسؤولة عن تطور العلاقات الأمنية، والتطبيقات العليا مسؤولة عن الابتكار المالي، و uniBTC مسؤولة عن الحفاظ على طريقة تفاعل مستقرة نسبيًا بين الاثنين.

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

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

إذا دخلت BTCFi في مراحل أكثر تعقيدًا في المستقبل، فقد يأتي القيمة التي تحملها $BR على المدى الطويل من هذه القدرة الأساسية على إدارة تعقيد النظام، وارتباط تطور الأمان والابتكار المالي. #Bedrock @Bedrock

قبل فترة، كنت أبحث في بعض مشاريع BTCFi وسجلت سؤالًا: ليش كلهم يستخدموا نفس BTC للدخول لعالم البلوكتشين، لكن في النهاية طلعوا بأعداد متزايدة من نسخ أصول BTC المختلفة؟ بعض البروتوكولات تركز على كفاءة العوائد، وبعضها يهتم بتغطية البيئة، لكن المستخدمين مضطرين يتنقلوا بين منصات مختلفة ويفهموا القواعد من جديد. بصراحة، شفت نقاشات كثيرة، ولاحظت أن اهتمام الكثير من الناس كان محصورًا في مدى ارتفاع الـAPR، وهذا للأسف يجعلني أشعر أنه فيه ضياع، لأن السيولة تتقطع أكثر فأكثر، وهذا ممكن يكون هو المشكلة الأكبر في هذا المجال بالمستقبل.

بالعودة إلى @Bedrock وBedrock 2.0، أشوف أن اليونيBTC فعليًا مميز لأنه مو بس أداة ربح بسيطة، بل يحاول يجمع السيولة المتناثرة في بيئات مختلفة ليدعم الأصول بقدرة تجميع أقوى. بصراحة، إذا كل بيئة صار عندها نسختها من BTC، المستخدمين كل يوم ينقلوا بين بروتوكولات مختلفة، الرسوم، تكاليف التعلم، وتعقيد الإدارة في النهاية راح تصبح عقبة حقيقية. #bedrock

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

أما بالنسبة لـ $BR ، ما راح أستعجل في متابعة الأسعار القصيرة أو حرارة السوق. اللي يهمني هو، مع توسع @Bedrock ، هل القدرة على الحكم، تصميم الحوافز، ومنطق القيمة راح يشتغل بشكل فعلي. بعد كل شيء، المشاريع التحتية تخاف مو من النمو البطيء، بل من عدم قدرة الآلية الأساسية على مواكبة الحجم المتزايد.

على الأقل الآن، ما راح أقول أن Bedrock 2.0 راح تكون طبقة أساسية مهمة في BTCFi. لكن السؤال اللي طرحته لا يزال يستحق المتابعة: هل السيولة في BTC راح تتناثر على مداخل متعددة، أو راح تتجمع تدريجيًا في بنية تحتية ناضجة ومستقرة، هذه المنافسة يمكن تكون بس بدأت.

في الفترة الأخيرة، كنت أ整理 سجلاتي المتفرقة عن BTCFi، ووجدت ورقة قديمة كتبت عليها بعض الأشياء، وفي الزاوية كانت هناك ثلاث كلمات: الأمان، السيولة، والعائد. في ذلك الوقت، لم أفكر كثيرًا، بل كانت فكرة عابرة سجلتها. لكن بعد أن قمت بتفكيك بعض بروتوكولات BTCFi المختلفة، أدركت أن الأمور خلف هذه الكلمات أكثر تعقيدًا مما كنت أتصور. زيادة العائد قليلاً قد تعني زيادة مخاطر استراتيجيات جديدة أو مخاطر العقود الذكية؛ لكن إذا كان الهدف هو الأمان فقط، فإن BTC قد تبقى في المحفظة، مما يعني فقدان الفرصة للمشاركة في الأنشطة المالية على السلسلة. #Bedrock

بعد ذلك، عندما نظرت مجددًا في @Bedrock عن تصميم Bedrock 2.0، أدركت أنني كنت مهتمًا جدًا بارتفاع APR في السابق. ما يستحق الوقت للتحليل هو في الواقع كيف تمر BTC الخاصة بالمستخدم عبر مسارات مختلفة إلى استراتيجيات متعددة، وأين تتراكم المخاطر، وما إذا كان هناك وسيلة لتقليل هذه التعقيدات. #bedrock

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

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

بصراحة، بعد كل هذا البحث، لم أعد سهل الانجذاب نحو ارتفاع APR كما كنت في السابق. مقارنة بالأرقام القصيرة الأجل، أريد أن أرى @Bedrock إذا كان يمكن أن تدير التوازن بين الأمان، السيولة، والعائد على المدى الطويل. إذا شكلت uniBTC طلبًا مستقرًا على السلسلة في المستقبل، أعتقد أن $BR التطورات التالية ستكون على الأقل تستحق أن أتابعها.

هل نهاية BTCFi هي عوائد أعلى؟ هذا السؤال رأيته في العديد من المناقشات، لكن إجابتي تتجه أكثر نحو لا.

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

وهذا هو السبب الذي يجعلني أتابع @Bedrock 2.0. في فهمي، الشيء المثير للاهتمام هو أنه لا يقتصر على إرسال BTC إلى المزيد من مشاهد العائد، بل يحاول إعادة تصميم طريقة مشاركة BTC في العوائد على السلسلة. الفرص المختلفة على السلسلة لها دورات مخاطرة ومتطلبات سيولة مختلفة، وإذا كان على المستخدمين البحث عن مدخلات جديدة، ونقل الأصول، وضبط الاستراتيجيات في كل مرة يظهر فيها مشهد جديد، فهذا في الواقع يستهلك الكثير من الطاقة. #bedrock

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

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

لذا، الآن أنظر إلى @Bedrock ، ما أركز عليه لم يعد أداء العائد في مرحلة معينة. ما يهمني أكثر هو، هل يمكن أن يدفع BTCFi من مقارنة أرقام العائد، تدريجياً إلى مقارنة كفاءة تنظيم الأصول، وقدرة إدارة المخاطر، ونضج هيكل العائد.

أما بالنسبة لل$BR ، ما هي القيمة التي ستحتملها في النهاية، أعتقد أن الإجابة لا تزال مخبأة في عمق الاستخدام الحقيقي في المستقبل، وليس في ذروة أي شعور سوقي.

#Bedrock
$BR

أثناء بحثي مؤخرًا في قطاع التمويل القائم على البيتكوين (BTCFi)، لاحظتُ فجأةً مشكلةً نادرة النقاش: الجميع يبحث عن كيفية زيادة عوائد البيتكوين، لكن قليلين هم من يُفكرون بجدية في كيفية نقل البيتكوين على البلوكشين بأمان وكفاءة عند تغير ظروف السوق.

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

بالنظر إلى Bedrock 2.0 (@Bedrock ) من هذا المنظور، أعتقد أن قيمته الحقيقية لا تكمن في نموذج عائد قصير الأجل مُحدد، بل في محاولته بناء إطار عمل أكثر مرونة لسيولة البيتكوين حول uniBTC. ببساطة، يتغير الطلب على البيتكوين في سيناريوهات التمويل اللامركزي المختلفة باستمرار. إذا اقتصر استخدام الأصول على غرض واحد، فإن كفاءتها ستتراجع تدريجيًا مع تقلبات السوق. #bedrock

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

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

بخصوص $BR ، ليس لدي حاليًا رؤية واضحة، سواء كانت إيجابية أو سلبية. ما يقلقني أكثر هو كيف سيتحقق @Bedrock لاحقًا من هذا التصميم، وما إذا كان بإمكانه إثبات أن BTCFi لديه مسار تطوير آخر أكثر استدامة إلى جانب السعي وراء العوائد.

#Bedrock $BR

أخيرًا جاء كأس العالم 2026 بين أمريكا وكندا والمكسيك! بصراحة، عندما رأيت جدول المباريات، شعرت أن الـDNA عندي تحرك. هذه المرة تم توسيع البطولة إلى 48 فريقًا، وأتمنى أن نرى بعض الفرق الصغيرة المجهولة تظهر كالحصان الأسود وتفجر مفاجآت ضد الفرق الكبيرة! قبل قليل كنت أعمل على مهمة التوقعات، وكنت فعلاً أشعر بالتوتر، كل مباراة كنت أعتقد أنها 50-50. خصوصًا في المباريات التي يلعب فيها فريق قوي ضد فريق ضعيف، إذا قرر الفريق الضعيف الدفاع بشكل مكثف، فعلاً يمكن أن يتسبب في إرهاق الفريق القوي. الآن، أنا متشوق لبدء البطولة، الجعة والروبيان جاهزين، فقط في انتظار صفارة البداية. أمل أن تكون فعالية بينانس قوية، لكي أستطيع استرجاع بعض النقود لشراء قمصان الفرق! لننفذ الصفقة وننتهي من الأمر! #BinancePickAndWin

عندما كنت أبحث في Bedrock 2.0، كان فهمي الأولي بديهيًا: ربط Babylon وKernel وشبكات التحقق الموسعة، أليس هذا مجرد زيادة مستمرة في مصادر العائد؟ لكن هذا التفسير سرعان ما فقد جدواه، لأنه لا يفسر مسألة أعمق، لماذا يجب معالجة العوائد الأمنية لبيتكوين من شبكات التحقق المختلفة ضمن نفس الهيكل. #bedrock @Bedrock

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

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

لذا، فإن المفتاح ليس في "هل هناك خيارات أخرى"، بل في "أي هيكل يمكنه التوسع دون أن ينهار ذاتيًا".

كتبت لاحقًا في ملاحظاتي حكمًا أكثر تطرفًا: طالما أن معايير العائد غير موحدة، فلن يمكن توحيد الطبقة الأصلية.

في ظل هذا القيد، لم يعد uniBTC خيار تصميم، بل كان نتيجة حتمية للهيكل نفسه. إنه ليس طبقة تسوية، ولا طبقة قواعد، بل هو المدخل الوحيد الذي تم "ضغطه" بواسطة النظام تحت شروط شبكة تحقق متعددة + معايير متعددة غير مستدامة.

بعبارة أكثر دقة، uniBTC ليس مكونًا، بل هو بديهي هيكلي: نظام عائد بيتكوين متعدد المعايير، أثناء عملية التوسع، يجب أن يتقارب حتمًا إلى مدخل واحد للتعبير الموحد.

بمجرد قبول هذا الافتراض، يصبح هيكل Bedrock 2.0 واضحًا تمامًا: إنه لا يوسع شبكة العائد، بل يبني مسار نظام غير قابل للتفرع، إدخال متطلبات الأمان → uniBTC تقارب موحد → مخرجات أصول موحدة. #Bedrock

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

لذا، لم يعد النمو توسعًا متعدد المسارات، بل يتم امتصاص جميع المسارات بشكل موحد قبل دخول النظام.

إذا كان هذا الهيكل قائمًا، فإن $BR لا تتعلق بنمو بروتوكول معين، بل هي نتيجة مستمرة لتضخيم "البديهي الهيكلي".

عندما درست @GeniusOfficial ، في البداية كان عندي شوية صعوبة في فهم التركيز، ما كانش مشروع سهل التصنيف، MPC، تجميع المسارات، أوامر الشبح لو اتفرجت عليهم كل واحد لوحده، مش معقدين، لكن لما يتجمعوا مع بعض، كنت دايمًا حاسس إن في شيء ناقص. #genius

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

يعني، المستخدمين في الحقيقة كانوا زي طبقة تنسيق مؤقتة، بيجمعوا الشظايا المتفرقة من بروتوكولات مختلفة علشان يكملوا الصفقة. لكن الدور ده مش مصمم، بل هو ناتج عن هيكل السلسلة، لأن السيولة، المسارات والتنفيذ كلها متقطعة، وفي نفس الوقت المعلومات متاحة للجميع.

لذا كل صفقة لازم يكون فيه حد يعمل "تكملة"، والدور الافتراضي هو المستخدم.

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

الثلاثة مع بعض، في الحقيقة تشير لنفس النتيجة: المستخدمين بيتم إبعادهم تدريجيًا عن سلسلة التنفيذ.

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

لذا في النهاية، Genius بتشير لتغيير في نمط التنفيذ، وهو ما يسمى بطبقة النوايا. في الهيكل ده، المستخدم بس محتاج يعبر عن النتيجة، وباقي المسارات، تطابق السيولة وعملية التنفيذ كلها بتنتهي بواسطة النظام.

$GENIUS معناها لو ثبت، مش في الوظيفة نفسها، لكن في هل بتدفع المعاملات على السلسلة من "مشاركة المستخدم في التنفيذ" إلى "تنفيذ النظام للنوايا".

دراسة @Bedrock في هذه الفترة، كان لدي سؤال عالق في ملاحظاتي: إذا بدأ المزيد من BTC بالمشاركة في العوائد على السلسلة، كيف يجب تحديد أسعار هذه العوائد؟

في البداية، اعتقدت أن الإجابة ليست معقدة، العوائد تتبع الأصول فقط. لكن بعد تفكيك هيكل منتجات Bedrock 2.0، أدركت أنني كنت أرى الأمور بشكل مبسط. #bedrock

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

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

أما Bedrock و Bedrock 2.0، فالنقطة الأكثر جوهرية هي محاولة فصل قدرة العوائد المرفقة بالأصل، وتحويلها عبر منطق موحد إلى أصول عوائد معيارية. الهدف من ذلك ليس زيادة شكل جديد من الأصول، بل السماح لحقوق العوائد بالتسعير بشكل مستقل، والتجميع، والتداول.

بعد ذلك، بدأت أدرك ببطء أن هذا يختلف عن منتجات العوائد العادية.

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

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

إذا تمكنت هذه المسار من العمل، فإن @Bedrock لن تربط فقط نوعًا معينًا من مشاهد عوائد BTC، بل نظامًا يمكن توسيعه باستمرار من أصول العوائد.

#Bedrock $BR

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

أنا شخصيًا لا أعتقد أن الوضع كذلك.

خلال دراسة @GeniusOfficial ، صرت أكثر تركيزًا على شيء تم تجاهله: توفر السيولة. #genius

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

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

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

وبسبب هالشي، تركيزي على $GENIUS ما كان على ميزة معينة. مقارنةً بالابتكارات الوظيفية، أنا أكثر اهتمامًا إذا كان يحل مشكلة تشتت السيولة المتزايد هذه. إذا استمر نمو الأصول على السلسلة، وزادت سيناريوهات التداول، فكيف نربط هالموارد الموزعة بشكل فعال، ممكن يكون مفتاح المنافسة في البنية التحتية، وهذا هو السبب اللي يخلي Genius تظل تحت مراقبتي.

في اليومين الماضيين، عندما كنت أبحث مجددًا عن آلية S1 لـ @GeniusOfficial ، خصصت وقتًا لمراجعة قواعد الاستلام المبكر والإتلاف عدة مرات. في البداية، كنت أركز على ما إذا كان بإمكان المستخدمين الحصول على الرموز بشكل أسرع، لكنني اكتشفت أنني كنت أركز على الاتجاه الخاطئ. #genius

ما يستحق البحث فيه حقًا هو لماذا يربط Genius بين الإفراج المبكر ونسبة الإتلاف العالية بشكل قوي.

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

لكن فكرة Genius مختلفة بوضوح.

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

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

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

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

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

عندي سؤال قعدت أتحير فيه شوية.

إذا بس نبغى نعمل عوائد على BTC، ليش @Bedrock قاعد يسوي uniBTC و brBTC في Bedrock 2.0؟ أول مرة شفت فيها مخطط الهيكل، حسيت إنه شوي معقد، وكنت أفكر هل يعقدوا الأمور البسيطة.

بعدها قمت أعدت قراءة المعلومات الرسمية ومسار المنتج. كل ما شفت أكثر، كل ما اكتشفت إن Bedrock 2.0 مو هدفه العائد، بل توسيع قدرات البروتوكول المستقبلية. #bedrock

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

لكن Bedrock 2.0 مميز لأنه فصل بين الشيئين.

uniBTC هي المدخل للأصول المعيارية، وتركز على السيولة والتوافق؛ بينما brBTC مسؤول عن العوائد وقدرات الأمان. قبل يومين كنت أتابع مخطط الهيكل لفترة طويلة، وفجأة فهمت إنه هذا التصميم فعليا يترك مساحة للمستقبل. بعدين، سواء كانت مصادر عوائد جديدة أو شبكات تعاون جديدة، ما يحتاج نعدل طبقة الأصول نفسها.

هذا التفصيل أعتقد كثير من الناس ما انتبهوا له.

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

بصراحة، في البداية كان فهمي لهذا التحديث سطحي. لكن لما فرزت الوظائف اللي تحملها uniBTC و brBTC، أدركت إنه هذه ممكن تكون التغيرات الجوهرية في Bedrock 2.0. التحديث مو مجرد تحسين رقم معين، بل هو قدرة البروتوكول على استيعاب كم أصول، وكم مصدر عوائد في المستقبل.

الكثير من التحديثات تخلي البيانات شكلها حلو، وبعض التحديثات تعيد بناء الأساس. على الأقل من وجهة نظري، Bedrock 2.0 يشبه للثاني.

@Bedrock $BR #Bedrock