Binance Square
2026Rabbit
148 منشورات

2026Rabbit

Newbie tryin’ earn some from the market 👀
10 تتابع
41 المتابعون
59 إعجاب
منشورات
·
--
#baby $BABY @babylonlabs_io نشر أحد الأشخاص في خيط الـtestnet بصيغة “كأوسمة” تجزئة معاملته، ثم اعترف في نفس الوقت بأنه لم يقم أبدًا بملء نموذج الملاحظات. هذه هي المفارقة التي تستحق أن تُسمّى مع مرحلة الـtestnet هذه. الـpublic testnet لا يقيس حقًا ما إذا كان بإمكان الناس الاقتراض مقابل الـBTC الأصلية؛ فهذه العملية بحد ذاتها بسيطة بما يكفي لتعمل بنجاح من المحاولة الأولى لمعظم المستخدمين. ما تم تصميمه فعليًا لقياسه هو أين يحدث العطل: تقديرات الغاز الخاطئة، عتبات التصفية غير الواضحة، وصنبور (faucet) يجف في اللحظة غير المناسبة. لا يظهر هذا المؤشر إلا إذا أبلغ الناس عنه. معظم أنشطة الـtestnet تُحسّن لمؤشر خاطئ. عدد المعاملات يبدو جيدًا على لوحة التحكم، لكنه لا يخبر بابلِون إلا القليل جدًا حول ما إذا كانت منطق الضمانات لدى TBV يصمد تحت الاستخدام المربك أو الهجومي. نموذج الملاحظات هو المنتج الحقيقي، بينما مسار الاقتراض مجرد طُعم لجعل الناس يختبرونه بجدية كافية لوجود شيء يمكن الإبلاغ عنه. مراجعة ذاتية: أفهم لماذا يتخطى معظم المختبرين ذلك؛ فملء نموذج يتطلب جهدًا أكثر من النقر عبر واجهة، ولا توجد مكافأة مرتبطة بكتابة تقرير جيد عن خلل مقارنة بتقرير كسول. هذا التفاوت هو على الأرجح أكبر خطر يهدد جودة الـtestnet هنا، وليس التقنية نفسها.
#baby $BABY @BabylonLabs_io

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

هذه هي المفارقة التي تستحق أن تُسمّى مع مرحلة الـtestnet هذه. الـpublic testnet لا يقيس حقًا ما إذا كان بإمكان الناس الاقتراض مقابل الـBTC الأصلية؛ فهذه العملية بحد ذاتها بسيطة بما يكفي لتعمل بنجاح من المحاولة الأولى لمعظم المستخدمين. ما تم تصميمه فعليًا لقياسه هو أين يحدث العطل: تقديرات الغاز الخاطئة، عتبات التصفية غير الواضحة، وصنبور (faucet) يجف في اللحظة غير المناسبة. لا يظهر هذا المؤشر إلا إذا أبلغ الناس عنه.

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

مراجعة ذاتية: أفهم لماذا يتخطى معظم المختبرين ذلك؛ فملء نموذج يتطلب جهدًا أكثر من النقر عبر واجهة، ولا توجد مكافأة مرتبطة بكتابة تقرير جيد عن خلل مقارنة بتقرير كسول. هذا التفاوت هو على الأرجح أكبر خطر يهدد جودة الـtestnet هنا، وليس التقنية نفسها.
#baby $BABY @babylonlabs_io طرحت سؤال في اختبار شبكة Discord ولم يجب عليه أحد بشكل واضح: إذا كان البيتكوين الأصلي لا يغادر أبدًا سيطرة المستخدم، فماذا يتم تصفيته فعليًا عندما يصبح القرض تحت الماء. هذا هو الجزء من "Trustless Bitcoin Vaults" الذي يستحق التوقف معه لفترة أطول من مجرد سطر التسويق. ويبدو أن الحفظ الذاتي والثقة-المعدومة يمثلان مكسبًا صافياً: مفاتيحك، بيتكوينك، دون جسر، دون توكن مغلف. لكن الإقراض مقابل ضمانات لا يعمل إلا إذا كان بإمكان المُقرِض مصادرة تلك الضمانات عند التعثر. في مكان ما داخل النظام، يجب أن يكون هناك شخص أو شيء ما يملك مطالبةً قابلةً للتنفيذ على البيتكوين التي يحتفظ بها المُقترِض تقنيًا. وهذه ليست تفصيلة تصميم صغيرة؛ بل هي الآلية الكاملة التي يعيش عليها منتج الاقتراض أو يموت بها. إجابة Babylon على ما يبدو مدمجة في منطق خزائن TBV نفسها وليست لدى جهة حاضنة (custodian)، وهي الابتكار الحقيقي هنا وليس مجرد غياب التغليف. إزالة الجسور هي العنوان السهل. جعل التصفية قابلة للإنفاذ دون حيازة (custody) هو مشكلة الهندسة الصعبة الكامنة. مراجعة ذاتية: لا أملك رؤية حول مدى متانة تلك الآلية تحت ضغط حقيقي في السوق؛ فظروف testnet نادرًا ما تعيد إنتاج هبوطًا سريعًا للبيتكوين. وهذا بالضبط سبب وجود testnet، وبالضبط الجزء الذي كنت أرغب في إثباته قبل أن أسمي ذلك "ثقة-معدومة" عمليًا، وليس فقط من خلال التصميم.
#baby $BABY @BabylonLabs_io

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

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

إجابة Babylon على ما يبدو مدمجة في منطق خزائن TBV نفسها وليست لدى جهة حاضنة (custodian)، وهي الابتكار الحقيقي هنا وليس مجرد غياب التغليف. إزالة الجسور هي العنوان السهل. جعل التصفية قابلة للإنفاذ دون حيازة (custody) هو مشكلة الهندسة الصعبة الكامنة.

مراجعة ذاتية: لا أملك رؤية حول مدى متانة تلك الآلية تحت ضغط حقيقي في السوق؛ فظروف testnet نادرًا ما تعيد إنتاج هبوطًا سريعًا للبيتكوين. وهذا بالضبط سبب وجود testnet، وبالضبط الجزء الذي كنت أرغب في إثباته قبل أن أسمي ذلك "ثقة-معدومة" عمليًا، وليس فقط من خلال التصميم.
#baby $BABY @babylonlabs_io قال مطور أتابعه بوضوح: “أي سلسلة، أي تطبيق” هو مجرد شعار حتى يُطرح في مكان محدد. وتستحق هذه الفجوة نظرةً عبر Trustless Bitcoin Vaults. يُقدَّم الأمر باعتباره شاملاً: بيتكوين الأصلية كضمان عبر أي سلسلة وأي تطبيق، إقراض، عملات مستقرة، بطاقات ائتمان، مشتقات، تأمين. لكن ما هو “حيّ” فعليًا الآن هو حالة استخدام واحدة، وسلسلة واحدة، وتطبيق واحد: الاقتراض المضمون ببيتكوين الأصلية عبر Aave v4 على شبكة اختبار Ethereum. وكل ما عدا ذلك ما زال مجرد خريطة طريق بالكلام. لا أظن أن هذا تسويقٌ غير صادق، لكنه يثير سؤالًا حقيقيًا. البنية التحتية التي تدّعي الشمولية يجب أن تثبت نفسها في مكان ما أولًا، واختيار ذلك المكان يقول الكثير عن الأولويات. فإيثيريوم وAave هما أعمق بركة سيولة متاحة؛ وأأمن مكان لاختبار ما إذا كان ضمان BTC الأصلي يتصرف فعليًا بالطريقة التي يعد بها التصميم قبل أن يغامر أي أحد بمنتجات بطاقات ائتمان أو تأمين مبنية عليه. مراجعة ذاتية: قد يكون من السهل اعتبار هذا نطاقًا ضيقًا والمضي قدمًا، لكن البدء بنطاق ضيق هو غالبًا الطريقة التي تكسب بها البنية التحتية الحق في التوسع. تتمثل المشكلة في التعامل مع نجاح شبكة الاختبار في تكامل واحد على أنه دليل على أن الادعاء الأوسع يعمل بالفعل. لذلك الشيء الذي أتابعه هو التكامل الثاني، لا الأول؛ لأن هذا هو ما يختبر حقًا ما إذا كانت TBV تُعمِّم بالفعل.
#baby $BABY @BabylonLabs_io

قال مطور أتابعه بوضوح: “أي سلسلة، أي تطبيق” هو مجرد شعار حتى يُطرح في مكان محدد.

وتستحق هذه الفجوة نظرةً عبر Trustless Bitcoin Vaults. يُقدَّم الأمر باعتباره شاملاً: بيتكوين الأصلية كضمان عبر أي سلسلة وأي تطبيق، إقراض، عملات مستقرة، بطاقات ائتمان، مشتقات، تأمين. لكن ما هو “حيّ” فعليًا الآن هو حالة استخدام واحدة، وسلسلة واحدة، وتطبيق واحد: الاقتراض المضمون ببيتكوين الأصلية عبر Aave v4 على شبكة اختبار Ethereum. وكل ما عدا ذلك ما زال مجرد خريطة طريق بالكلام.

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

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

لذلك الشيء الذي أتابعه هو التكامل الثاني، لا الأول؛ لأن هذا هو ما يختبر حقًا ما إذا كانت TBV تُعمِّم بالفعل.
#baby $BABY @babylonlabs_io سأل شخص ما في دردشة متعلقة بـ DeFi لماذا لم تقم بابيلون ببساطة بإطلاق الاقتراض بعملة BTC الأصلية داخل تطبيقها أولًا. وجاء الرد بسرعة: لأنه لن يستخدمه أحد. هذه هي القصة الأكثر هدوءًا وراء صناديق بيتكوين الموثوقة بلا ثقة. جزء “بلا ثقة” حقيقي: ضمانات BTC أصلية، دون لفّ، ودون جسر يحتجز الأصل. لكن أول تكامل ليس واجهة جديدة يبنيها بابيلون. بل هو Aave v4، وهو اسم يعرفه المقترضون بالفعل ويثقون به، مع مليارات الدولارات في الإيداعات. هناك قدر صغير من المفارقة يستحق التوقف عنده. بروتوكول صُمم لإزالة الثقة من طبقة الضمانات لا يزال يحتاج إلى علامة تجارية موثوقة كي ينقله إلى المستخدمين. TBV يحل مشكلة الحفظ على مستوى البنية التحتية، ومع ذلك ما زال التبنّي يسير عبر الاختصارات السمعة نفسها التي يستخدمها الناس في كل مكان آخر داخل DeFi: اختر المنصة التي تعرفها. مراجعة ذاتية: ليس هذا ضعفًا، بل ربما هو المسار الواقعي الوحيد. طلب من المستخدمين أن يثقوا بآلية صندوق غير مثبت وبِتطبيق غير مألوف في الوقت نفسه سيقتل التبنّي قبل أن تُختبر التقنية. إن توجيه ضمانات بلا ثقة عبر واجهة أمامية موثوقة هو كيف تنتشر البنية التحتية فعلًا—بهدوء، تحت شيء مألوف. ما أراقبه الآن هو ما إذا كان هذا النمط سيستمر عندما يتوسع TBV خارج Aave، أم إذا كان كل تكامل جديد يحتاج إلى مصداقية مقترَضة خاصة به.
#baby $BABY @BabylonLabs_io

سأل شخص ما في دردشة متعلقة بـ DeFi لماذا لم تقم بابيلون ببساطة بإطلاق الاقتراض بعملة BTC الأصلية داخل تطبيقها أولًا. وجاء الرد بسرعة: لأنه لن يستخدمه أحد.

هذه هي القصة الأكثر هدوءًا وراء صناديق بيتكوين الموثوقة بلا ثقة. جزء “بلا ثقة” حقيقي: ضمانات BTC أصلية، دون لفّ، ودون جسر يحتجز الأصل. لكن أول تكامل ليس واجهة جديدة يبنيها بابيلون. بل هو Aave v4، وهو اسم يعرفه المقترضون بالفعل ويثقون به، مع مليارات الدولارات في الإيداعات.

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

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

ما أراقبه الآن هو ما إذا كان هذا النمط سيستمر عندما يتوسع TBV خارج Aave، أم إذا كان كل تكامل جديد يحتاج إلى مصداقية مقترَضة خاصة به.
#baby $BABY أرسل لي صديق لقطة شاشة هذا الأسبوع من شبكة TBV الاختبارية، بفخر لأنه كان قد اقترض USDC بالفعل مقابل BTC الخاص به. سألته أي مسار ضمانات استخدمه. قال إنه أي مسار تقترحه التطبيق افتراضيًا، كما يحدث دائمًا. تأتي الإجابة على سؤال الضمانات في صلب ما يجعل Trustless Bitcoin Vaults مثيرًا للاهتمام وفي الوقت نفسه هشًّا. يتيح TBV قروضًا مدعومة بالبيتكوين الأصلي على Aave v4 دون لفّ أو جسر أو تسليم الحيازة لأي طرف. لا توجد BTC اصطناعية، ولا عقد جسر يحتجز الأصل الحقيقي رهينة. تقنيًا، تم إخراج الثقة من طبقة الضمانات. لكن الثقة لا تختفي؛ بل تنتقل. إذا أزلت الحاجة إلى الثقة في الجسر، فسيظل المستخدمون بحاجة إلى الثقة في شيء ما، غالبًا الواجهة التي توجههم، والمعلمات الافتراضية، ومسار أقل مقاومة. لم يختر صديقي البيتكوين الأصلي لأنه فهم معمارية “trustless”. بل اختاره لأن التطبيق جعله خيارًا سهل الضغط. مراجعة ذاتية هنا: هذا ليس عيبًا حقيقيًا في TBV. نجاح منتج الاقتراض لأنه بسيط أمر طبيعي بل ومطلوب. السؤال الحقيقي هو ما إذا كان إزالة الثقة بالوسطاء على مستوى البروتوكول يغيّر سلوك المستخدمين فعلًا، أم أن الناس فقط ينقلون ثقتهم إلى أعلى باتجاه من يصمم تدفق العملية. أتساءل إن كان @babylonlabs_io قد نظر في مقدار نشاط الشبكة الاختبارية الذي يعكس فهمًا حقيقيًا لـ TBV مقابل مجرد الراحة التي يوفرها المسار الافتراضي.
#baby $BABY

أرسل لي صديق لقطة شاشة هذا الأسبوع من شبكة TBV الاختبارية، بفخر لأنه كان قد اقترض USDC بالفعل مقابل BTC الخاص به. سألته أي مسار ضمانات استخدمه. قال إنه أي مسار تقترحه التطبيق افتراضيًا، كما يحدث دائمًا.

تأتي الإجابة على سؤال الضمانات في صلب ما يجعل Trustless Bitcoin Vaults مثيرًا للاهتمام وفي الوقت نفسه هشًّا. يتيح TBV قروضًا مدعومة بالبيتكوين الأصلي على Aave v4 دون لفّ أو جسر أو تسليم الحيازة لأي طرف. لا توجد BTC اصطناعية، ولا عقد جسر يحتجز الأصل الحقيقي رهينة. تقنيًا، تم إخراج الثقة من طبقة الضمانات.

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

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

أتساءل إن كان @BabylonLabs_io قد نظر في مقدار نشاط الشبكة الاختبارية الذي يعكس فهمًا حقيقيًا لـ TBV مقابل مجرد الراحة التي يوفرها المسار الافتراضي.
#grvt @grvt_io كنت أُحدّث خط @GRVT_io الزمني أكثر من المعتاد في الآونة الأخيرة. $GRVT هناك نوع معيّن من التوتر يتصاعد قبل حدث توليد الرموز (TGE). ليس حماسًا تمامًا، بل أشبه بمشاهدة كشف بطيء كنتَ جزءًا من بنائه. لقد أكدت GRVT فعالية توليد الرموز لها في 21 يوليو، كما نمت حصة تخصيص الإنزال الجوي للمجتمع إلى 28% من إجمالي المعروض الثابت البالغ 1 مليار، مقارنةً بالخطط السابقة. هذا ليس تعديلًا بسيطًا؛ بل يدلّ على أن الفريق يميل أكثر إلى مكافأة الاستخدام الفعلي بدل تقليص الحصة مع نمو الطلب. ما يلفت انتباهي ليس الرقم فقط، بل التسلسل. فتح التسجيل للإنزال الجوي في 10 يوليو ويستمر حتى 27 يوليو، مع وجود خطة مضاعف اختيارية لأي شخص يرغب في تأجيل توزيعه للحصول على حصة أكبر لاحقًا. هذه ليست طريقة تصميم من نوع "ادّعِ ثم صفّر"؛ إنها تطلب من المجتمع أن يقرر مدى صبره الذي يريد التحلي به. ستبدأ التداولات في البداية في السوق الفورية الخاصة بـ GRVT، بينما يعمل الفريق بشكل واضح على إدراجات في بورصات مركزية أكبر بعد ذلك. لذلك الأمر ليس لحظة واحدة، بل سلسلة تتكشف على مدار أسابيع. أنا لا أتعامل مع أي شيء من هذا كإشارة للتنبؤ بالسعر. ما أراقبه هو ما إذا كان هيكل الإنزال الجوي يكافئ فعلًا المتداولين الذين بنوا حجم التداول هنا، أم أنه يكافئ فقط أولئك الذين يظهرون في النهاية. إذا كنتَ تقوم بالزراعة خلال الموسم الثاني، هل أنتَ بصدد الاشتراك في خطة المضاعف أم أخذ حصتك عند TGE؟
#grvt @grvt_io

كنت أُحدّث خط @GRVT_io الزمني أكثر من المعتاد في الآونة الأخيرة. $GRVT
هناك نوع معيّن من التوتر يتصاعد قبل حدث توليد الرموز (TGE). ليس حماسًا تمامًا، بل أشبه بمشاهدة كشف بطيء كنتَ جزءًا من بنائه. لقد أكدت GRVT فعالية توليد الرموز لها في 21 يوليو، كما نمت حصة تخصيص الإنزال الجوي للمجتمع إلى 28% من إجمالي المعروض الثابت البالغ 1 مليار، مقارنةً بالخطط السابقة. هذا ليس تعديلًا بسيطًا؛ بل يدلّ على أن الفريق يميل أكثر إلى مكافأة الاستخدام الفعلي بدل تقليص الحصة مع نمو الطلب.
ما يلفت انتباهي ليس الرقم فقط، بل التسلسل. فتح التسجيل للإنزال الجوي في 10 يوليو ويستمر حتى 27 يوليو، مع وجود خطة مضاعف اختيارية لأي شخص يرغب في تأجيل توزيعه للحصول على حصة أكبر لاحقًا. هذه ليست طريقة تصميم من نوع "ادّعِ ثم صفّر"؛ إنها تطلب من المجتمع أن يقرر مدى صبره الذي يريد التحلي به.
ستبدأ التداولات في البداية في السوق الفورية الخاصة بـ GRVT، بينما يعمل الفريق بشكل واضح على إدراجات في بورصات مركزية أكبر بعد ذلك. لذلك الأمر ليس لحظة واحدة، بل سلسلة تتكشف على مدار أسابيع.
أنا لا أتعامل مع أي شيء من هذا كإشارة للتنبؤ بالسعر. ما أراقبه هو ما إذا كان هيكل الإنزال الجوي يكافئ فعلًا المتداولين الذين بنوا حجم التداول هنا، أم أنه يكافئ فقط أولئك الذين يظهرون في النهاية.
إذا كنتَ تقوم بالزراعة خلال الموسم الثاني، هل أنتَ بصدد الاشتراك في خطة المضاعف أم أخذ حصتك عند TGE؟
#BinanceTurns9 Binance يبلغ من العمر 9 سنوات - Do bạn kiến tạo، تهانينا بمناسبة عيد ميلادك
#BinanceTurns9 Binance يبلغ من العمر 9 سنوات - Do bạn kiến tạo، تهانينا بمناسبة عيد ميلادك
#grvt @grvt_io أحتفظ بقائمة ذهنية بعنوان: "أشياء لا ينبغي أن يكون كلاهما صحيحًا في الوقت نفسه" في عالم العملات المشفّرة. رقم واحد: الخصوصية والشفافية. الجميع يفترض أنك مضطر للاختيار. ثم نظرت عن كثب إلى GRVT. إليك الإعداد. GRVT هي بورصة هجين — ليست CEX بالكامل، وليست DEX بالكامل. تتم مطابقة الأوامر خارج السلسلة، على بنية تحتية سريعة مصممة لسرعة بمستوى المؤسسات. لكن التسوية؟ تلك تتم على السلسلة، كما يُفترض. قسّم المهمة إلى جزأين. دَع كل نصف يقوم بما يجيد فعله. الجزء الموجود خارج السلسلة يعني عدم وجود نوافذ مزعجة لواجهة المحفظة لكل نقرة، لا قلق بشأن رسوم الغاز، وزمن استجابة مُقاس بالملي ثانية بدلًا من أزمنة البلوك. أما الجزء على السلسلة فيعني أن أموالك لا تكون محتجزة فعلًا لدى GRVT. الحيازة الذاتية، طوال الطريق. تأتي ميزة الخصوصية من تقنيات المعرفة الصفرية، التي تعمل على ZKsync كـ validium. بيانات التداول — حجم مركزك، وهامشك، وسعر التصفية — لا تُعرض على سجلّ عام ليقوم كل بوت بنسفها. بدلًا من ذلك، تقوم GRVT بتوليد إثباتات تشفيرية وتقوم فقط بتثبيت تلك الإثباتات على Ethereum. يمكن التحقق منها، دون أن تكون كتابًا مفتوحًا. هذا هو الرهان الحقيقي هنا: هل يمكن لبورصة أن تكون سريعة وخصوصية في الوقت نفسه، وأن تثبت أنها ليست تكذب عليك؟ لدى GRVT عقود دائمة تعمل بالفعل، مع توسيع الخيارات والسبوت، كما كانت تطارد تراخيص تنظيمية في أكثر من منطقة — وهو شيء تتجنبه معظم منصات "مركزية بشكل مزعوم" بصمت. أنا ما زلت أقرأ التفاصيل بنفسي. إذا كانت مناظرة CEX مقابل DEX قد أزعجتك يومًا، فإن grvt.io يستحق عشر دقائق من وقتك.
#grvt @grvt_io

أحتفظ بقائمة ذهنية بعنوان: "أشياء لا ينبغي أن يكون كلاهما صحيحًا في الوقت نفسه" في عالم العملات المشفّرة. رقم واحد: الخصوصية والشفافية. الجميع يفترض أنك مضطر للاختيار.
ثم نظرت عن كثب إلى GRVT.
إليك الإعداد. GRVT هي بورصة هجين — ليست CEX بالكامل، وليست DEX بالكامل. تتم مطابقة الأوامر خارج السلسلة، على بنية تحتية سريعة مصممة لسرعة بمستوى المؤسسات. لكن التسوية؟ تلك تتم على السلسلة، كما يُفترض.
قسّم المهمة إلى جزأين. دَع كل نصف يقوم بما يجيد فعله.
الجزء الموجود خارج السلسلة يعني عدم وجود نوافذ مزعجة لواجهة المحفظة لكل نقرة، لا قلق بشأن رسوم الغاز، وزمن استجابة مُقاس بالملي ثانية بدلًا من أزمنة البلوك. أما الجزء على السلسلة فيعني أن أموالك لا تكون محتجزة فعلًا لدى GRVT. الحيازة الذاتية، طوال الطريق.
تأتي ميزة الخصوصية من تقنيات المعرفة الصفرية، التي تعمل على ZKsync كـ validium. بيانات التداول — حجم مركزك، وهامشك، وسعر التصفية — لا تُعرض على سجلّ عام ليقوم كل بوت بنسفها. بدلًا من ذلك، تقوم GRVT بتوليد إثباتات تشفيرية وتقوم فقط بتثبيت تلك الإثباتات على Ethereum. يمكن التحقق منها، دون أن تكون كتابًا مفتوحًا.
هذا هو الرهان الحقيقي هنا: هل يمكن لبورصة أن تكون سريعة وخصوصية في الوقت نفسه، وأن تثبت أنها ليست تكذب عليك؟
لدى GRVT عقود دائمة تعمل بالفعل، مع توسيع الخيارات والسبوت، كما كانت تطارد تراخيص تنظيمية في أكثر من منطقة — وهو شيء تتجنبه معظم منصات "مركزية بشكل مزعوم" بصمت.
أنا ما زلت أقرأ التفاصيل بنفسي. إذا كانت مناظرة CEX مقابل DEX قد أزعجتك يومًا، فإن grvt.io يستحق عشر دقائق من وقتك.
#grvt @grvt_io كنت أعود إلى @GRVT_io مجددًا، هذه المرة أحاول رؤية الصورة كاملة بدل التركيز على ميزة واحدة في كل مرة. #grvt معظم المنصات تجبرك على اختيار هويتك مبكرًا. إما أن تكون مستخدمًا لـ CEX تتداول بسرعة وتثق بأن شخصًا آخر سيتولى المفاتيح، أو مستخدمًا لـ DEX تحتفظ بمفاتيحك بنفسك وتقبل بعض الاحتكاك كتكلفة مقابل تلك الحرية. GRVT لا يطلب منك حقًا أن تختار مسارًا، بل ببساطة يزيل الانقسام في الطريق. في العمق، تتطابق الأوامر خارج السلسلة (off-chain) ليظل التنفيذ سريعًا، بينما تُجرى التسوية على السلسلة (on-chain) بحيث لا تخرج أموالك فعليًا من سيطرتك. وهذا وحده سيكون مثيرًا للاهتمام. لكن ثم توجد طبقة الخصوصية التي تعمل عبر بنية Validium الخاصة بـ zkSync، فتُبقي بيانات التداول خارج نطاق العرض العام، مع الاستمرار في إثبات أن كل شيء صحيح على Ethereum. السرعة والوصاية والخصوصية عادةً تتعارض فيما بينها كأن ثلاثة أشخاص يحاولون توجيه سيارة واحدة في الوقت نفسه. هنا يبدو أنهم اتفقوا على اتجاه. ما يزيد الصورة وضوحًا هو أن GRVT ألغت اشتراط KYC الإلزامي، بحيث يمكنك بدء التداول بمجرد بريد إلكتروني مع الحفاظ على الحيازة الذاتية الكاملة للأصول. هذه تركيبة غريبة على الورق: وصول بلا إذن بجانب بنية تحتية بمستوى مؤسسي. وخريطة الطريق لم تعد تقتصر على العقود الآجلة (perps) فقط، بل تتجه نحو الأصول الواقعية (RWAs) وإدارة ثروات أوسع، مع اعتبار هذا النموذج الهجين أساسًا وليس مجرد خدعة لمرة واحدة. ما زلت غير متأكدًا إن كان هذا سيصبح القالب الافتراضي للمنصات أو مجرد مساحة متخصصة نُفِّذت بشكل ممتاز. أي جزء يبدو لك أكثر دوامًا: طبقة الخصوصية أم سهولة الوصول بدون KYC؟
#grvt @grvt_io

كنت أعود إلى @GRVT_io مجددًا، هذه المرة أحاول رؤية الصورة كاملة بدل التركيز على ميزة واحدة في كل مرة. #grvt
معظم المنصات تجبرك على اختيار هويتك مبكرًا. إما أن تكون مستخدمًا لـ CEX تتداول بسرعة وتثق بأن شخصًا آخر سيتولى المفاتيح، أو مستخدمًا لـ DEX تحتفظ بمفاتيحك بنفسك وتقبل بعض الاحتكاك كتكلفة مقابل تلك الحرية. GRVT لا يطلب منك حقًا أن تختار مسارًا، بل ببساطة يزيل الانقسام في الطريق.
في العمق، تتطابق الأوامر خارج السلسلة (off-chain) ليظل التنفيذ سريعًا، بينما تُجرى التسوية على السلسلة (on-chain) بحيث لا تخرج أموالك فعليًا من سيطرتك. وهذا وحده سيكون مثيرًا للاهتمام. لكن ثم توجد طبقة الخصوصية التي تعمل عبر بنية Validium الخاصة بـ zkSync، فتُبقي بيانات التداول خارج نطاق العرض العام، مع الاستمرار في إثبات أن كل شيء صحيح على Ethereum. السرعة والوصاية والخصوصية عادةً تتعارض فيما بينها كأن ثلاثة أشخاص يحاولون توجيه سيارة واحدة في الوقت نفسه. هنا يبدو أنهم اتفقوا على اتجاه.
ما يزيد الصورة وضوحًا هو أن GRVT ألغت اشتراط KYC الإلزامي، بحيث يمكنك بدء التداول بمجرد بريد إلكتروني مع الحفاظ على الحيازة الذاتية الكاملة للأصول. هذه تركيبة غريبة على الورق: وصول بلا إذن بجانب بنية تحتية بمستوى مؤسسي. وخريطة الطريق لم تعد تقتصر على العقود الآجلة (perps) فقط، بل تتجه نحو الأصول الواقعية (RWAs) وإدارة ثروات أوسع، مع اعتبار هذا النموذج الهجين أساسًا وليس مجرد خدعة لمرة واحدة.
ما زلت غير متأكدًا إن كان هذا سيصبح القالب الافتراضي للمنصات أو مجرد مساحة متخصصة نُفِّذت بشكل ممتاز. أي جزء يبدو لك أكثر دوامًا: طبقة الخصوصية أم سهولة الوصول بدون KYC؟
#grvt @grvt_io قضيت بعض الوقت هذا الأسبوع أفكر في @GRVT_io من زاوية مختلفة. #grvt $GRVT يتحدث الجميع عن اللامركزية وكأن الشفافية هدية تلقائية. رؤية كاملة، كل أمر، كل مركز، كل شيء موجود ليشاهده أي شخص. لكن إذا كنت قد لعبت البوكر وبطاقاتك مكشوفة، فستعرف لماذا لا تكون هذه الميزة دائمًا في صالحك. وهذا هو الإشكال الذي يبدو أن GRVT يحلّه بهدوء. إن معظم التداولات على السلسلة تكشف بالضبط ما يفعله المتداول في الوقت الفعلي، وهذا يبدو عادلاً إلى أن تدرك أنها تتيح أيضاً المضاربة الأمامية (front-running) وتسمح للاعبين الأكبر بقراءة استراتيجيتك قبل أن تنتهي من تنفيذها. تصبح تدفقات الأوامر إشارة عامة، والإشارات العامة تُستغل. تتمثل إجابة GRVT في إبقاء دفتر الأوامر خارج السلسلة للمطابقة، حتى لا يراقب أحد ورقتك أثناء اللعب، بينما لا تزال التسوية تتم على السلسلة عبر إعداد Validium من zkSync. يتم إثبات الصفقة وتأكيدها على Ethereum، لكن التفاصيل التي من شأنها عادةً أن تكشف نيتك تبقى خاصة. إنها نوع غريب من الخصوصية، مضمونة تشفيريًا وليست مجرد وعود من شركة. المفاجئ أكثر أن الأمر لم يعد متعلقاً بالبيربس (perps) فقط. تتجه البنية التحتية نحو إدارة ثروات أوسع نطاقاً، بحيث تُعامل الحضانة والخصوصية كأساسٍ لا كميزة إضافية مُلصقة فوق تطبيق تداول. ما زلت أتساءل: هل الخصوصية في التداول هي في الواقع آلية عدالة، وليست مجرد حل بديل؟ إذا كانت الأسواق يفترض أن تكافئ المعلومات والتوقيت، فهل يجب حقاً أن تكون يد الجميع ظاهرة قبل أن ينتهي الشوط؟
#grvt @grvt_io

قضيت بعض الوقت هذا الأسبوع أفكر في @GRVT_io من زاوية مختلفة. #grvt $GRVT
يتحدث الجميع عن اللامركزية وكأن الشفافية هدية تلقائية. رؤية كاملة، كل أمر، كل مركز، كل شيء موجود ليشاهده أي شخص. لكن إذا كنت قد لعبت البوكر وبطاقاتك مكشوفة، فستعرف لماذا لا تكون هذه الميزة دائمًا في صالحك.
وهذا هو الإشكال الذي يبدو أن GRVT يحلّه بهدوء. إن معظم التداولات على السلسلة تكشف بالضبط ما يفعله المتداول في الوقت الفعلي، وهذا يبدو عادلاً إلى أن تدرك أنها تتيح أيضاً المضاربة الأمامية (front-running) وتسمح للاعبين الأكبر بقراءة استراتيجيتك قبل أن تنتهي من تنفيذها. تصبح تدفقات الأوامر إشارة عامة، والإشارات العامة تُستغل.
تتمثل إجابة GRVT في إبقاء دفتر الأوامر خارج السلسلة للمطابقة، حتى لا يراقب أحد ورقتك أثناء اللعب، بينما لا تزال التسوية تتم على السلسلة عبر إعداد Validium من zkSync. يتم إثبات الصفقة وتأكيدها على Ethereum، لكن التفاصيل التي من شأنها عادةً أن تكشف نيتك تبقى خاصة. إنها نوع غريب من الخصوصية، مضمونة تشفيريًا وليست مجرد وعود من شركة.
المفاجئ أكثر أن الأمر لم يعد متعلقاً بالبيربس (perps) فقط. تتجه البنية التحتية نحو إدارة ثروات أوسع نطاقاً، بحيث تُعامل الحضانة والخصوصية كأساسٍ لا كميزة إضافية مُلصقة فوق تطبيق تداول.
ما زلت أتساءل: هل الخصوصية في التداول هي في الواقع آلية عدالة، وليست مجرد حل بديل؟ إذا كانت الأسواق يفترض أن تكافئ المعلومات والتوقيت، فهل يجب حقاً أن تكون يد الجميع ظاهرة قبل أن ينتهي الشوط؟
#grvt كنت أتعمّق مؤخرًا في @grvt_io lately، وهو نوع المشروع الذي يجعلك تعيد التفكير في معنى كلمة "التبادل" نفسها. #grvt كنت أتعامل مع هذا كاختيار ثنائي: إما أن تثق في بورصة مركزية بأموالك وتحصل على السرعة، أو تذهب بالكامل على السلسلة (on-chain) وتقبل تنفيذًا أبطأ مقابل ضمان الحيازة. لم يكن كلاهما ممكنًا. بُني GRVT على فكرة أن هذا التنازل لم يكن ضروريًا أصلًا، بل كان مجرد أمر غير محسوم. الإعداد سهل وصفه لكنه صعب تنفيذه. تُطابق الأوامر خارج السلسلة (off-chain)، لذلك تبدو عملية التداول سريعة، أقرب لما تتوقعه من منصة مركزية. أمّا التسوية فتتم على السلسلة (on-chain)، لذلك تبقى أموالك تحت سيطرتك أنت طوال الوقت. ليس الأمر "اختر جانبًا" بقدر ما هو "لماذا كنا مضطرين أصلًا إلى ذلك؟". ما يجعل ذلك ممكنًا وليس مجرد عرض جميل هو طبقة ZK الكامنة تحت السطح. يعمل GRVT على بنية Validium مرتبطة بـ zkSync، وهذا يعني أن بيانات التداول يمكن أن تظل خاصة خارج السلسلة مع بقاء إمكانية إثباتها وتسويتها على Ethereum. هذه هي الجزء الذي كان يبدو لي متناقضًا. الخصوصية وقابلية التحقق لا يُفترض أن تجتمعا، إلى أن تنظر إلى كيفية فصل الـ Validiums بين توفر البيانات وصحة البرهان. يذكرني بمشاهدة نظامين منفصلين لم يُصمّما أصلًا ليتحاورا، ثم يبدأان فجأة بالتعاون. أسواق العقود الدائمة (Perp)، تسعير الأصول الحقيقية (RWA)، الخيارات—كلها تعمل على نفس المسار (rail). لا زلت أعمل على فهم مدى ثبات نماذج الهامش والمخاطر لديهم تحت حجم تداول واقعي. إذا كنت قد استخدمت بورصة هجينة من قبل، هل غيّر نموذج الحيازة بالفعل طريقة تداولك، أم أنه غيّر فقط شعورك تجاه ذلك؟
#grvt

كنت أتعمّق مؤخرًا في @grvt_io lately، وهو نوع المشروع الذي يجعلك تعيد التفكير في معنى كلمة "التبادل" نفسها. #grvt
كنت أتعامل مع هذا كاختيار ثنائي: إما أن تثق في بورصة مركزية بأموالك وتحصل على السرعة، أو تذهب بالكامل على السلسلة (on-chain) وتقبل تنفيذًا أبطأ مقابل ضمان الحيازة. لم يكن كلاهما ممكنًا. بُني GRVT على فكرة أن هذا التنازل لم يكن ضروريًا أصلًا، بل كان مجرد أمر غير محسوم.
الإعداد سهل وصفه لكنه صعب تنفيذه. تُطابق الأوامر خارج السلسلة (off-chain)، لذلك تبدو عملية التداول سريعة، أقرب لما تتوقعه من منصة مركزية. أمّا التسوية فتتم على السلسلة (on-chain)، لذلك تبقى أموالك تحت سيطرتك أنت طوال الوقت. ليس الأمر "اختر جانبًا" بقدر ما هو "لماذا كنا مضطرين أصلًا إلى ذلك؟".
ما يجعل ذلك ممكنًا وليس مجرد عرض جميل هو طبقة ZK الكامنة تحت السطح. يعمل GRVT على بنية Validium مرتبطة بـ zkSync، وهذا يعني أن بيانات التداول يمكن أن تظل خاصة خارج السلسلة مع بقاء إمكانية إثباتها وتسويتها على Ethereum. هذه هي الجزء الذي كان يبدو لي متناقضًا. الخصوصية وقابلية التحقق لا يُفترض أن تجتمعا، إلى أن تنظر إلى كيفية فصل الـ Validiums بين توفر البيانات وصحة البرهان.
يذكرني بمشاهدة نظامين منفصلين لم يُصمّما أصلًا ليتحاورا، ثم يبدأان فجأة بالتعاون. أسواق العقود الدائمة (Perp)، تسعير الأصول الحقيقية (RWA)، الخيارات—كلها تعمل على نفس المسار (rail).
لا زلت أعمل على فهم مدى ثبات نماذج الهامش والمخاطر لديهم تحت حجم تداول واقعي. إذا كنت قد استخدمت بورصة هجينة من قبل، هل غيّر نموذج الحيازة بالفعل طريقة تداولك، أم أنه غيّر فقط شعورك تجاه ذلك؟
#opg $OPG @OpenGradient زاوية المطور: لأول مرة يمكن لعلم/معرفة الذكاء الاصطناعي أن تصبح بنية تحتية أنا أنشأت مشاريع جانبية كثيرة، وأحد المشاكل التي أواجهها كثيرًا هو عدم وجود طريقة جيدة لدمج ذكاء اصطناعي مخصّص بشكل شخصي دون استضافة النموذج بنفسي أو استخدام واجهة برمجة تطبيقات لشركة كبيرة بشروط قد تتغير في أي وقت. والذي لم أتوقعه هو أن Twin.fun على @OpenGradient حلّت هذه المشكلة بطريقة مختلفة تمامًا. يمكن للمطور أن يدمج تغذية الأسعار (price feed) الخاصة بـ twin key، ويتحقق من ملكية المفتاح (verify key ownership)، ويبني تطبيقًا فوق البنية التحتية لـ Twin.fun دون الحاجة إلى إذن من OpenGradient. إذا أردت إنشاء أداة تداول تقتصر على من يمتلك مفتاح (key) محلل معيّن، يمكنني القيام بذلك. وإذا أردت إنشاء لوحة تحكم (dashboard) لا تفتح إلا لمن يمتلك مفتاح باحث معيّن، يمكنني فعل ذلك. منطق التحكم في الوصول موجود في العقد الذكي (smart contract)، وهو مفتوح (open)، ولا يستطيع أي شخص سحبه/إلغاؤه. opengradient هذا يختلف تمامًا عن طريقة تشغيل المنصات المعتادة. عادةً تبني على منصة، وعندما يغيّرون API أو الشروط، يموت منتجك. مع Twin.fun، ما تبنيه فوقه هو عقد ذكي على البلوك تشين، ولا يمكن تعديل هذا المنطق من جانب واحد. $OPG يتم تسوية كل معاملة على هذه البنية التحتية. لا توجد شركة في الوسط يمكنها أن تقرر إيقافها. هذه هي المرة الأولى التي يمكن فيها أن تتحول أصول المعرفة الخاصة بالذكاء الاصطناعي إلى بدائية (primitive) لكي يبني عليها المطورون، بدلًا من كونها مجرد منتج يستهلكه المستخدمون النهائيون. إذا كنت مطورًا، فماذا ستبني على بنية ملكية مفاتيح Twin.fun؟
#opg $OPG @OpenGradient

زاوية المطور: لأول مرة يمكن لعلم/معرفة الذكاء الاصطناعي أن تصبح بنية تحتية
أنا أنشأت مشاريع جانبية كثيرة، وأحد المشاكل التي أواجهها كثيرًا هو عدم وجود طريقة جيدة لدمج ذكاء اصطناعي مخصّص بشكل شخصي دون استضافة النموذج بنفسي أو استخدام واجهة برمجة تطبيقات لشركة كبيرة بشروط قد تتغير في أي وقت.
والذي لم أتوقعه هو أن Twin.fun على @OpenGradient حلّت هذه المشكلة بطريقة مختلفة تمامًا.
يمكن للمطور أن يدمج تغذية الأسعار (price feed) الخاصة بـ twin key، ويتحقق من ملكية المفتاح (verify key ownership)، ويبني تطبيقًا فوق البنية التحتية لـ Twin.fun دون الحاجة إلى إذن من OpenGradient. إذا أردت إنشاء أداة تداول تقتصر على من يمتلك مفتاح (key) محلل معيّن، يمكنني القيام بذلك. وإذا أردت إنشاء لوحة تحكم (dashboard) لا تفتح إلا لمن يمتلك مفتاح باحث معيّن، يمكنني فعل ذلك. منطق التحكم في الوصول موجود في العقد الذكي (smart contract)، وهو مفتوح (open)، ولا يستطيع أي شخص سحبه/إلغاؤه. opengradient
هذا يختلف تمامًا عن طريقة تشغيل المنصات المعتادة. عادةً تبني على منصة، وعندما يغيّرون API أو الشروط، يموت منتجك. مع Twin.fun، ما تبنيه فوقه هو عقد ذكي على البلوك تشين، ولا يمكن تعديل هذا المنطق من جانب واحد.
$OPG يتم تسوية كل معاملة على هذه البنية التحتية. لا توجد شركة في الوسط يمكنها أن تقرر إيقافها.
هذه هي المرة الأولى التي يمكن فيها أن تتحول أصول المعرفة الخاصة بالذكاء الاصطناعي إلى بدائية (primitive) لكي يبني عليها المطورون، بدلًا من كونها مجرد منتج يستهلكه المستخدمون النهائيون.
إذا كنت مطورًا، فماذا ستبني على بنية ملكية مفاتيح Twin.fun؟
#opg $OPG @OpenGradient العنوان: التطبيق الذي استخدمته لأشهر كان يعمل سراً على بلوكتشين آخر استخدمت BitQuant لأسابيع قبل أن أفهم ما الذي كانت في الحقيقة تفعله عندما كانت تجيبني عن أسئلتي. كنت أكتب مثلاً: ما هو خطر التصفية الخاص بهذا المجمع؟ فأحصل على إجابة واضحة، وأفترض أنها جاءت من خادم مملوك ومُشغَّل مباشرةً من قِبل OpenGradient. كان هذا الافتراض خاطئاً بطريقة لم تصبح واضحة إلا عندما بدأت الحفر في البنية الأساسية بدافع الفضول في إحدى الليالي. BitQuant ليس مجرد منتج من OpenGradient. بل إنه أيضاً مُنشر كـ Subnet 15 على Bittensor، وهي شبكة ذكاء اصطناعي لامركزية منفصلة تماماً، لم يطّلع عليها معظم مستخدمي العملات المشفرة من قبل. كانت الأسئلة التي كتبتها عبر واجهة ويب نظيفة تُوجَّه إلى عقد عُمال مستقلين ليس لديّ أي صلة بهم، يتنافسون فيما بينهم لإنتاج أفضل إجابة، بينما كانت عقد التحقق تُقيّم عملهم وتدفع لهم في TAO. كنت أنا العميل. لم أكن أعلم أنني كنت أيضاً عبئ العمل المُوزَّع عبر سوق الحوافز الخاص بشخص آخر. ما لفتني لم يكن التعقيد. بل أن كل ذلك ظل غير مرئي تقريباً. تجربة المنتج لم تكشف شيئاً عن الآليات الكامنة تحت السطح، ووجود هذا الإخفاء مقصود، وليس صدفة. البنية التحتية الجيدة يُفترض أن تختفي. كانت الواجهة التي وثقت بها طبقة رقيقة فوق سوق لمشغّلين ذكاء اصطناعي متنافسين لا يتوجب عليّ التفكير فيهم، وكان النظام يعمل تحديداً لأنني لم أكن مضطراً لذلك. ما زلت لا أفهم تماماً آليات الحوافز في Bittensor. لكنني أفهم كثيراً أكثر الآن لماذا كانت إجابات BitQuant تبدو متسقة عبر مئات الاستفسارات غير المرتبطة. هل سبق لك أن اكتشفت أن أداة وثقت بها تم بناؤها بهدوء فوق بنية تحتية لم تسمع عنها من قبل؟
#opg $OPG @OpenGradient

العنوان: التطبيق الذي استخدمته لأشهر كان يعمل سراً على بلوكتشين آخر
استخدمت BitQuant لأسابيع قبل أن أفهم ما الذي كانت في الحقيقة تفعله عندما كانت تجيبني عن أسئلتي.
كنت أكتب مثلاً: ما هو خطر التصفية الخاص بهذا المجمع؟ فأحصل على إجابة واضحة، وأفترض أنها جاءت من خادم مملوك ومُشغَّل مباشرةً من قِبل OpenGradient. كان هذا الافتراض خاطئاً بطريقة لم تصبح واضحة إلا عندما بدأت الحفر في البنية الأساسية بدافع الفضول في إحدى الليالي.
BitQuant ليس مجرد منتج من OpenGradient. بل إنه أيضاً مُنشر كـ Subnet 15 على Bittensor، وهي شبكة ذكاء اصطناعي لامركزية منفصلة تماماً، لم يطّلع عليها معظم مستخدمي العملات المشفرة من قبل. كانت الأسئلة التي كتبتها عبر واجهة ويب نظيفة تُوجَّه إلى عقد عُمال مستقلين ليس لديّ أي صلة بهم، يتنافسون فيما بينهم لإنتاج أفضل إجابة، بينما كانت عقد التحقق تُقيّم عملهم وتدفع لهم في TAO. كنت أنا العميل. لم أكن أعلم أنني كنت أيضاً عبئ العمل المُوزَّع عبر سوق الحوافز الخاص بشخص آخر.
ما لفتني لم يكن التعقيد. بل أن كل ذلك ظل غير مرئي تقريباً. تجربة المنتج لم تكشف شيئاً عن الآليات الكامنة تحت السطح، ووجود هذا الإخفاء مقصود، وليس صدفة. البنية التحتية الجيدة يُفترض أن تختفي. كانت الواجهة التي وثقت بها طبقة رقيقة فوق سوق لمشغّلين ذكاء اصطناعي متنافسين لا يتوجب عليّ التفكير فيهم، وكان النظام يعمل تحديداً لأنني لم أكن مضطراً لذلك.
ما زلت لا أفهم تماماً آليات الحوافز في Bittensor. لكنني أفهم كثيراً أكثر الآن لماذا كانت إجابات BitQuant تبدو متسقة عبر مئات الاستفسارات غير المرتبطة.
هل سبق لك أن اكتشفت أن أداة وثقت بها تم بناؤها بهدوء فوق بنية تحتية لم تسمع عنها من قبل؟
#opg $OPG @OpenGradient يتحدث الناس عن "الذكاء الاصطناعي القابل للتحقق" كما لو كان شيئًا واحدًا فقط. في الواقع، توجد ثلاث طرق مختلفة لإثبات أن استنتاج (inference) من الذكاء الاصطناعي صحيح، ولكل طريقة مقايضات مختلفة تمامًا بين انعدام الحاجة إلى الثقة (trustlessness) والسرعة والتكلفة. والاختيار بين هذه الطرق يعتمد على ما الذي تقوم ببنائه. يدعم OpenGradient الثلاثة معًا. تستخدم ZKML إثباتات المعرفة الصفرية (zero-knowledge proof)، وهي الطريقة الأكثر خلوًا من الحاجة إلى الثقة لأنك لا تحتاج إلى الوثوق بأي جزء من العتاد أو بأي طرف ثالث. لكن توليد الإثباتات يستهلك حوسبة كبيرة ويكون أبطأ بشكل ملحوظ، وهو مناسب للقرارات ذات القيمة العالية التي لا تتطلب real-time. أما تحقق TEE فيستخدم إسنادًا عتاديًا من بيئة تنفيذ موثوقة (trusted execution environment)، وهو أسرع بكثير ويمكنه التوسع مع نماذج LLM الكبيرة، مما يجعله مناسبًا للاستدلالات المتكررة التي تحتاج إلى زمن استجابة منخفض. أما التحقق التقليدي (Vanilla verification) فلا ينشئ أي إثبات على الإطلاق؛ بل يكتفي بكتابة النتيجة على السلسلة (chain). وهو مناسب لحالات الاستخدام التي تتطلب throughput مرتفعًا حيث يمكنك قبول استدلالًا يقوم به عقدة تحتاج إلى قدر من الثقة. هذه الطرق الثلاث لا تتنافس مع بعضها البعض. فهي تخدم ثلاثة أنواع مختلفة من حالات الاستخدام على نفس الشبكة، ويختار المطور الطريقة المناسبة وفقًا لمتطلباته عند طلب الاستدلال (inference). أهم شيء أراه هو أن OpenGradient لا تختار طريقة واحدة ثم تعلن أنها الأفضل. فالثلاثة موجودة معًا على شبكة واحدة، وتُسوى (settle) الإثباتات على نفس دفتر الأستاذ (ledger)، ويمكن لأي عقدة كاملة (full node) التحقق. يختار المطور الطريقة عند استدعاء الاستدلال بناءً على المتطلبات المحددة، وليس وفقًا لقيود البنية التحتية. السؤال الذي أتابعه هو: عندما تصبح ZKML أرخص وأسرع بفضل تحسينات العتاد، هل سيتغير التوازن بين الطرق الثلاث نحو الثقة-معدومة بالكامل (trustless تمامًا)، أم أن TEE ستحتفظ بموقعها المهيمن لأن نماذج LLM تتوسع بسرعة أكبر من ZK؟
#opg $OPG @OpenGradient

يتحدث الناس عن "الذكاء الاصطناعي القابل للتحقق" كما لو كان شيئًا واحدًا فقط. في الواقع، توجد ثلاث طرق مختلفة لإثبات أن استنتاج (inference) من الذكاء الاصطناعي صحيح، ولكل طريقة مقايضات مختلفة تمامًا بين انعدام الحاجة إلى الثقة (trustlessness) والسرعة والتكلفة. والاختيار بين هذه الطرق يعتمد على ما الذي تقوم ببنائه.

يدعم OpenGradient الثلاثة معًا. تستخدم ZKML إثباتات المعرفة الصفرية (zero-knowledge proof)، وهي الطريقة الأكثر خلوًا من الحاجة إلى الثقة لأنك لا تحتاج إلى الوثوق بأي جزء من العتاد أو بأي طرف ثالث. لكن توليد الإثباتات يستهلك حوسبة كبيرة ويكون أبطأ بشكل ملحوظ، وهو مناسب للقرارات ذات القيمة العالية التي لا تتطلب real-time. أما تحقق TEE فيستخدم إسنادًا عتاديًا من بيئة تنفيذ موثوقة (trusted execution environment)، وهو أسرع بكثير ويمكنه التوسع مع نماذج LLM الكبيرة، مما يجعله مناسبًا للاستدلالات المتكررة التي تحتاج إلى زمن استجابة منخفض. أما التحقق التقليدي (Vanilla verification) فلا ينشئ أي إثبات على الإطلاق؛ بل يكتفي بكتابة النتيجة على السلسلة (chain). وهو مناسب لحالات الاستخدام التي تتطلب throughput مرتفعًا حيث يمكنك قبول استدلالًا يقوم به عقدة تحتاج إلى قدر من الثقة.

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

أهم شيء أراه هو أن OpenGradient لا تختار طريقة واحدة ثم تعلن أنها الأفضل. فالثلاثة موجودة معًا على شبكة واحدة، وتُسوى (settle) الإثباتات على نفس دفتر الأستاذ (ledger)، ويمكن لأي عقدة كاملة (full node) التحقق. يختار المطور الطريقة عند استدعاء الاستدلال بناءً على المتطلبات المحددة، وليس وفقًا لقيود البنية التحتية.

السؤال الذي أتابعه هو: عندما تصبح ZKML أرخص وأسرع بفضل تحسينات العتاد، هل سيتغير التوازن بين الطرق الثلاث نحو الثقة-معدومة بالكامل (trustless تمامًا)، أم أن TEE ستحتفظ بموقعها المهيمن لأن نماذج LLM تتوسع بسرعة أكبر من ZK؟
#opg $OPG @OpenGradient العنوان: 158× التي تُغيّر المعادلات في الإثبات ذات مرة انتظرت أربع دقائق كي يتولّد إثباتٌ تشفيري لشيء كان يفترض أن يستغرق نصف ثانية فقط للحساب. أتذكّر أنني كنت أحدّق في مؤشر التحميل (loading spinner) وأفكّر في كيف أن أحدًا لن يستخدم هذا في الإنتاج أبدًا، مهما كانت ضمانة الدقة الرياضية مدهشة. فالإثبات الذي لا يستطيع أحد تحمّل الانتظار من أجله ليس ميزة فعلًا. إنه ورقة بحثية ترتدي ملابس منتج. عاد ذلك الشعور حين قرأت عن تكامل DeepProve مع "OpenGradient's Model Hub" عبر Lagrange. لطالما حمل ZKML تنازلاً قاسيًا. الضمان التشفيري حقيقي، محكمٌ رياضيًا من دون ثغرات—نوع الإثبات الذي لا يحتاج إطلاقًا إلى أن يثق فيه أي مُشغّل. لكن توليد هذا الإثبات لأي نموذج يتجاوز حجم الألعاب (toy size) كان تاريخيًا بطيئًا لدرجة أن شبه لا أحد استطاع تبريره لأي شيء حساس للوقت. كنت قد اعتبرته ذهنيًا مثاليًا نظريًا، وغير قابل للاستخدام عمليًا لمعظم أحمال العمل الواقعية. DeepProve تغيّر تلك المعادلة مباشرة. صمّمها Lagrange لتكون أسرع بـ 158 مرة من نهج zkML السابقة، مع الحفاظ على قابلية توسّع لا نهائية وأمان افتراضي. هذه ليست مجرد زيادة طفيفة في السرعة. إنها الفرق بين إثبات يصل بعد اللحظة التي كانت مهمة فيها، وإثبات يصل في الوقت المناسب ليكون مهمًا. النماذج المُتحقَّق منها من DeepProve تنشر الآن مباشرةً في "OpenGradient's Model Hub"، لذلك لم يعد مطوّرٌ يُضطر للاختيار بين السرعة والإثبات عند جلب نموذج. يحصل عليهما معًا—مُحضّرًا مسبقًا. الفجوة بين إثباتٍ كاملٍ تشفيريًا وإثباتٍ قابل للاستخدام فعليًا أصبحت أصغر بكثير. هل سبق وتخلّيت عن حلٍ صحيحٍ تقنيًا فقط لأنه كان بطيئًا جدًا بحيث يصعب استخدامه عمليًا؟
#opg $OPG @OpenGradient

العنوان: 158× التي تُغيّر المعادلات في الإثبات
ذات مرة انتظرت أربع دقائق كي يتولّد إثباتٌ تشفيري لشيء كان يفترض أن يستغرق نصف ثانية فقط للحساب. أتذكّر أنني كنت أحدّق في مؤشر التحميل (loading spinner) وأفكّر في كيف أن أحدًا لن يستخدم هذا في الإنتاج أبدًا، مهما كانت ضمانة الدقة الرياضية مدهشة. فالإثبات الذي لا يستطيع أحد تحمّل الانتظار من أجله ليس ميزة فعلًا. إنه ورقة بحثية ترتدي ملابس منتج.
عاد ذلك الشعور حين قرأت عن تكامل DeepProve مع "OpenGradient's Model Hub" عبر Lagrange.
لطالما حمل ZKML تنازلاً قاسيًا. الضمان التشفيري حقيقي، محكمٌ رياضيًا من دون ثغرات—نوع الإثبات الذي لا يحتاج إطلاقًا إلى أن يثق فيه أي مُشغّل. لكن توليد هذا الإثبات لأي نموذج يتجاوز حجم الألعاب (toy size) كان تاريخيًا بطيئًا لدرجة أن شبه لا أحد استطاع تبريره لأي شيء حساس للوقت. كنت قد اعتبرته ذهنيًا مثاليًا نظريًا، وغير قابل للاستخدام عمليًا لمعظم أحمال العمل الواقعية.
DeepProve تغيّر تلك المعادلة مباشرة. صمّمها Lagrange لتكون أسرع بـ 158 مرة من نهج zkML السابقة، مع الحفاظ على قابلية توسّع لا نهائية وأمان افتراضي. هذه ليست مجرد زيادة طفيفة في السرعة. إنها الفرق بين إثبات يصل بعد اللحظة التي كانت مهمة فيها، وإثبات يصل في الوقت المناسب ليكون مهمًا.
النماذج المُتحقَّق منها من DeepProve تنشر الآن مباشرةً في "OpenGradient's Model Hub"، لذلك لم يعد مطوّرٌ يُضطر للاختيار بين السرعة والإثبات عند جلب نموذج. يحصل عليهما معًا—مُحضّرًا مسبقًا.
الفجوة بين إثباتٍ كاملٍ تشفيريًا وإثباتٍ قابل للاستخدام فعليًا أصبحت أصغر بكثير.
هل سبق وتخلّيت عن حلٍ صحيحٍ تقنيًا فقط لأنه كان بطيئًا جدًا بحيث يصعب استخدامه عمليًا؟
#opg $OPG @OpenGradient العنوان: البرهان الذي لا يمكن قراءته إلا منك كادت أن لا أرسل الرسالة. كنت أكتب سؤالًا لمساعدٍ للذكاء الاصطناعي عن وضعٍ مالي يتضمن أرقامًا حقيقية، وتفاصيل حساب، وقرارات كانت تهم. ظلّ المؤشر الخاص بي متوقفًا على زر الإرسال لوقتٍ طويل، لأنني كنت أفكر باستمرار: إلى أين يذهب ذلك النص فعليًا بعد أن يغادر شاشتي؟ إلى بعض الخوادم. إلى ملف سجلات ما. إلى لوحة تحكم موظفٍ ما، ربما، في يومٍ يحدث فيه خطأ. هذا التردد هو السبب الكامل لوجود استدلال TEE، والجزء الذي جعل الأمر يَتّضح لي أخيرًا لم يكن ادعاء الخصوصية نفسه. بل كان تعلّم كيفية عمل البرهان. عندما تمرّ الطلبات عبر عُقد بروكسي TEE التابعة لـ OpenGradient إلى مزوّد مثل Anthropic أو OpenAI، لا يستطيع مشغّل العقدة الذي يشغّل هذه العتاد رؤية المطالَبة الفعلية أو تسجيلها، لأن البيانات تتم معالجتها داخل بيئةٍ محصورة لا يملكون إليها أي وصول. بعد تنفيذ الاستدلال، يتم توقيع المخرجات ويُكتب تجزئة (هاش) على السلسلة. يمكن لأي شخص أن يرى أن هناك تجزئة موجودة. لا يمكن لأي أحد غيري أن يقرأ ما الذي أنتجها، لأن إعادة بناء تلك التجزئة تتطلب امتلاك النتيجة الأصلية أولًا. هذا نوعٌ غريب من البرهان. هو علنيّ وخاصّ في الوقت نفسه. تؤكد السلسلة أن شيئًا حدث دون أن تكشف أبدًا عمّا. أخيرًا أرسلت الرسالة. ما أكثر سؤالٍ حساسٍ كتمته عن كتابته في ذكاءٍ اصطناعي، فقط لأنك لم تكن متأكدًا إلى أين سيؤول؟
#opg $OPG @OpenGradient

العنوان: البرهان الذي لا يمكن قراءته إلا منك
كادت أن لا أرسل الرسالة.
كنت أكتب سؤالًا لمساعدٍ للذكاء الاصطناعي عن وضعٍ مالي يتضمن أرقامًا حقيقية، وتفاصيل حساب، وقرارات كانت تهم. ظلّ المؤشر الخاص بي متوقفًا على زر الإرسال لوقتٍ طويل، لأنني كنت أفكر باستمرار: إلى أين يذهب ذلك النص فعليًا بعد أن يغادر شاشتي؟ إلى بعض الخوادم. إلى ملف سجلات ما. إلى لوحة تحكم موظفٍ ما، ربما، في يومٍ يحدث فيه خطأ.
هذا التردد هو السبب الكامل لوجود استدلال TEE، والجزء الذي جعل الأمر يَتّضح لي أخيرًا لم يكن ادعاء الخصوصية نفسه. بل كان تعلّم كيفية عمل البرهان.
عندما تمرّ الطلبات عبر عُقد بروكسي TEE التابعة لـ OpenGradient إلى مزوّد مثل Anthropic أو OpenAI، لا يستطيع مشغّل العقدة الذي يشغّل هذه العتاد رؤية المطالَبة الفعلية أو تسجيلها، لأن البيانات تتم معالجتها داخل بيئةٍ محصورة لا يملكون إليها أي وصول. بعد تنفيذ الاستدلال، يتم توقيع المخرجات ويُكتب تجزئة (هاش) على السلسلة. يمكن لأي شخص أن يرى أن هناك تجزئة موجودة. لا يمكن لأي أحد غيري أن يقرأ ما الذي أنتجها، لأن إعادة بناء تلك التجزئة تتطلب امتلاك النتيجة الأصلية أولًا.
هذا نوعٌ غريب من البرهان. هو علنيّ وخاصّ في الوقت نفسه. تؤكد السلسلة أن شيئًا حدث دون أن تكشف أبدًا عمّا. أخيرًا أرسلت الرسالة.
ما أكثر سؤالٍ حساسٍ كتمته عن كتابته في ذكاءٍ اصطناعي، فقط لأنك لم تكن متأكدًا إلى أين سيؤول؟
#opg $OPG @OpenGradient العنوان: وجدت أحفورة داخل عقد ذكي كنت أقرأ عبر عقد ABI الأسبوع الماضي، النوع من المراجع التقنية الجافة التي يتخطاها معظم الناس، عندما لاحظت شيئًا غريبًا. كانت الوظائف تحمل أسماء buyShares و sellShares. لكن في كل مكان آخر في الوثائق، كان يُطلق على نفس الأصل اسم مفتاح. هذا التباين ليس خطأ. إنه أحفورة. في عام 2023، أطلق Friend.tech السماح للناس بشراء وبيع أسهم حسابات X. أخبر محامي تشفير مراسلًا في ذلك الوقت أن جرس الإنذار القانوني لديه رن عندما رأى كلمة أسهم، لأن اختبار هاوي يعتمد على ما إذا كان المشترون يتوقعون بشكل معقول الربح من جهد شخص آخر، وكلمة أسهم هي بالضبط الكلمة التي تدعو لذلك التوقع. أعادت Friend.tech بهدوء تسمية الأسهم إلى مفاتيح خلال أسابيع. نفس الآلية، كلمة مختلفة، موقف قانوني مختلف تمامًا. Twin.fun، سوق OpenGradient للتوائم الرقمية AI، تسمي وحدات منحنى الربط مفاتيح منذ اليوم الأول. لكن الوثائق نفسها تعترف بأن المفاتيح كانت تُسمى سابقًا أسهمًا في النسخ المبكرة من العقد، ولا يزال بإمكانك العثور على buyShares و sellShares موجودة داخل ABI اليوم. تعلم الفريق الدرس قبل الإطلاق بدلاً من بعد تحذير محامٍ أصبح شائعًا. ما تسميه شيئًا على السلسلة ليس تجميليًا. إنه الإشارة الأولى حول ما إذا كان الفريق يبني مع الأخطاء من الدورة السابقة في الاعتبار أو يكررها بشكل أعمى. هل قرأت يومًا عقدًا ذكيًا عن كثب بما يكفي لتجد أثر قرار لم يرغب الفريق بوضوح في تكراره?
#opg $OPG @OpenGradient

العنوان: وجدت أحفورة داخل عقد ذكي
كنت أقرأ عبر عقد ABI الأسبوع الماضي، النوع من المراجع التقنية الجافة التي يتخطاها معظم الناس، عندما لاحظت شيئًا غريبًا. كانت الوظائف تحمل أسماء buyShares و sellShares. لكن في كل مكان آخر في الوثائق، كان يُطلق على نفس الأصل اسم مفتاح.
هذا التباين ليس خطأ. إنه أحفورة.
في عام 2023، أطلق Friend.tech السماح للناس بشراء وبيع أسهم حسابات X. أخبر محامي تشفير مراسلًا في ذلك الوقت أن جرس الإنذار القانوني لديه رن عندما رأى كلمة أسهم، لأن اختبار هاوي يعتمد على ما إذا كان المشترون يتوقعون بشكل معقول الربح من جهد شخص آخر، وكلمة أسهم هي بالضبط الكلمة التي تدعو لذلك التوقع. أعادت Friend.tech بهدوء تسمية الأسهم إلى مفاتيح خلال أسابيع. نفس الآلية، كلمة مختلفة، موقف قانوني مختلف تمامًا.
Twin.fun، سوق OpenGradient للتوائم الرقمية AI، تسمي وحدات منحنى الربط مفاتيح منذ اليوم الأول. لكن الوثائق نفسها تعترف بأن المفاتيح كانت تُسمى سابقًا أسهمًا في النسخ المبكرة من العقد، ولا يزال بإمكانك العثور على buyShares و sellShares موجودة داخل ABI اليوم. تعلم الفريق الدرس قبل الإطلاق بدلاً من بعد تحذير محامٍ أصبح شائعًا.
ما تسميه شيئًا على السلسلة ليس تجميليًا. إنه الإشارة الأولى حول ما إذا كان الفريق يبني مع الأخطاء من الدورة السابقة في الاعتبار أو يكررها بشكل أعمى.
هل قرأت يومًا عقدًا ذكيًا عن كثب بما يكفي لتجد أثر قرار لم يرغب الفريق بوضوح في تكراره?
#opg $OPG @OpenGradient "النموذج الذي بنيته اختفى. لا أحد سألني أولاً." لقد قمت ببناء أداة صغيرة فوق DALL-E 3 العام الماضي. لا شيء فاخر، مجرد سير عمل استخدمه عدد قليل من الأشخاص في فريقي يوميًا. ثم في نوفمبر 2025، تلقيت بريدًا إلكترونيًا. إشعار إلغاء، الإزالة مجدولة في 12 مايو 2026، بديل موصى به ينتج نتائج مختلفة لنصف أوامري. لا تصويت، لا تفاوض. النموذج الذي كنت أعتمد عليه كان ببساطة يختفي على جدول شخص آخر. تلك التجربة غيرت كيف أقيم بنية الذكاء الاصطناعي الآن. توقفت عن السؤال أي نموذج يقدم أفضل أداء وبدأت أسأل من يتحكم فعلاً فيما إذا كان سيستمر غدًا. أغلقت OpenAI وحدها DALL-E 2 وDALL-E 3 في مايو، وتعتزم إيقاف واجهة برمجة التطبيقات المساعدين تمامًا في أغسطس مع ما تسميه وثائقها الخاصة لا وضع متدهور ولا فترة سماح، وقد دارت عبر متغيرات GPT-4o، o1، codex-mini، وRealtime Beta على جدول إلغاء متداول حتى 2026. كل واحدة من تلك القرارات اتخذتها شركة تقوم بتحسين خريطتها الخاصة، وليس من قبل المطورين الذين بنوا منتجات فوقها. تخزن OpenGradient's Model Hub كل نموذج تم تحميله على تخزين Walrus اللامركزي تحديدًا بحيث لا يمكن إزالته أو فرض رقابة عليه أو فقدانه عندما يغير مزود الخدمة شروطه. النموذج لا يعيش داخل قرار بنية تحتية لشركة. إنه يعيش في موقع دائم، موجه بالمحتوى لا يمكن لأحد أن يلغي سلطته بشكل أحادي. لا أعتقد أن كل نموذج يحتاج إلى تلك الضمانة. ولكن تلك التي أبني عليها عملًا تجاريًا ربما يجب أن تكون كذلك. هل تم إلغاء نموذج أو واجهة برمجة التطبيقات التي كنت تعتمد عليها يومًا من تحتك، وكم كلفتك عملية الانتقال فعليًا؟
#opg $OPG @OpenGradient

"النموذج الذي بنيته اختفى. لا أحد سألني أولاً."
لقد قمت ببناء أداة صغيرة فوق DALL-E 3 العام الماضي. لا شيء فاخر، مجرد سير عمل استخدمه عدد قليل من الأشخاص في فريقي يوميًا. ثم في نوفمبر 2025، تلقيت بريدًا إلكترونيًا. إشعار إلغاء، الإزالة مجدولة في 12 مايو 2026، بديل موصى به ينتج نتائج مختلفة لنصف أوامري. لا تصويت، لا تفاوض. النموذج الذي كنت أعتمد عليه كان ببساطة يختفي على جدول شخص آخر.
تلك التجربة غيرت كيف أقيم بنية الذكاء الاصطناعي الآن. توقفت عن السؤال أي نموذج يقدم أفضل أداء وبدأت أسأل من يتحكم فعلاً فيما إذا كان سيستمر غدًا.
أغلقت OpenAI وحدها DALL-E 2 وDALL-E 3 في مايو، وتعتزم إيقاف واجهة برمجة التطبيقات المساعدين تمامًا في أغسطس مع ما تسميه وثائقها الخاصة لا وضع متدهور ولا فترة سماح، وقد دارت عبر متغيرات GPT-4o، o1، codex-mini، وRealtime Beta على جدول إلغاء متداول حتى 2026. كل واحدة من تلك القرارات اتخذتها شركة تقوم بتحسين خريطتها الخاصة، وليس من قبل المطورين الذين بنوا منتجات فوقها.
تخزن OpenGradient's Model Hub كل نموذج تم تحميله على تخزين Walrus اللامركزي تحديدًا بحيث لا يمكن إزالته أو فرض رقابة عليه أو فقدانه عندما يغير مزود الخدمة شروطه. النموذج لا يعيش داخل قرار بنية تحتية لشركة. إنه يعيش في موقع دائم، موجه بالمحتوى لا يمكن لأحد أن يلغي سلطته بشكل أحادي.
لا أعتقد أن كل نموذج يحتاج إلى تلك الضمانة. ولكن تلك التي أبني عليها عملًا تجاريًا ربما يجب أن تكون كذلك.
هل تم إلغاء نموذج أو واجهة برمجة التطبيقات التي كنت تعتمد عليها يومًا من تحتك، وكم كلفتك عملية الانتقال فعليًا؟
#opg $OPG @OpenGradient لقد اشتريت توكن pump.fun في الساعة الثانية من عمره. كانت الشارت تبدو unstoppable. بحلول الساعة السادسة، كان المُنشئ قد باع في كل طلب شراء في طريقه للأعلى واختفى. لم أكن محظوظًا. كنت أنا السيولة الخارجة، وآلية منحنى الربط التي جعلت التوكن يرتفع بهذا الشكل النظيف كانت نفس الآلية التي سمحت للمُنشئ بالابتعاد بدون أي مشاكل. تلك التجربة جعلتني أشك في منحنيات الربط كفئة، حتى قرأت كيف تستخدم twin.fun نفس الرياضيات لشيء مختلف هيكليًا. منحنى الربط يعمل بشكل جيد بقدر ما يكون الشيء المُسعّر. في منصة إطلاق الميمات، الشيء المُسعّر ليس شيئًا، مجرد اسم وشارت، لذا فإن الوظيفة الحقيقية للمنحنى هي فقط نقل المال من المشترين المتأخرين إلى المُنشئ قبل أن يلاحظ أي شخص. twin.fun تقيّم الوصول إلى توأم رقمي ذكاء اصطناعي مُصمم على مُنشئ حقيقي، مؤسس، أو مستثمر. شراء مفتاح يمنحك الدخول إلى عقل ذلك التوأم، ودردشته، وأدواته، ومجتمعه. الأصل تحت المنحنى له وظيفة قبل أن تصبح عملية التفريغ مهمة. الجزء الذي غير رأيي حقًا هو تقسيم الحوافز. يكسب المُنشئون خمسين في المئة من رسوم التداول على توأمهم الخاص بشكل دائم، وليس من قفزة إطلاق واحدة. هذا يربط دخلهم ببقاء التوأم مفيدًا ومتداولًا، وليس بجني الأرباح مبكرًا مثل المؤسس الذي خدعني. يمكن أن يُسعر المنحنى أي شيء. لكنه لا يستطيع تصنيع سبب يجعل أي شخص لا يزال يرغب فيه غدًا. هل كنت يومًا السيولة الخارجة على إطلاق منحنى ربط، وما الذي جعلك تدرك ذلك في وقت متأخر?
#opg $OPG @OpenGradient

لقد اشتريت توكن pump.fun في الساعة الثانية من عمره. كانت الشارت تبدو unstoppable. بحلول الساعة السادسة، كان المُنشئ قد باع في كل طلب شراء في طريقه للأعلى واختفى. لم أكن محظوظًا. كنت أنا السيولة الخارجة، وآلية منحنى الربط التي جعلت التوكن يرتفع بهذا الشكل النظيف كانت نفس الآلية التي سمحت للمُنشئ بالابتعاد بدون أي مشاكل.
تلك التجربة جعلتني أشك في منحنيات الربط كفئة، حتى قرأت كيف تستخدم twin.fun نفس الرياضيات لشيء مختلف هيكليًا.
منحنى الربط يعمل بشكل جيد بقدر ما يكون الشيء المُسعّر. في منصة إطلاق الميمات، الشيء المُسعّر ليس شيئًا، مجرد اسم وشارت، لذا فإن الوظيفة الحقيقية للمنحنى هي فقط نقل المال من المشترين المتأخرين إلى المُنشئ قبل أن يلاحظ أي شخص. twin.fun تقيّم الوصول إلى توأم رقمي ذكاء اصطناعي مُصمم على مُنشئ حقيقي، مؤسس، أو مستثمر. شراء مفتاح يمنحك الدخول إلى عقل ذلك التوأم، ودردشته، وأدواته، ومجتمعه. الأصل تحت المنحنى له وظيفة قبل أن تصبح عملية التفريغ مهمة.
الجزء الذي غير رأيي حقًا هو تقسيم الحوافز. يكسب المُنشئون خمسين في المئة من رسوم التداول على توأمهم الخاص بشكل دائم، وليس من قفزة إطلاق واحدة. هذا يربط دخلهم ببقاء التوأم مفيدًا ومتداولًا، وليس بجني الأرباح مبكرًا مثل المؤسس الذي خدعني.
يمكن أن يُسعر المنحنى أي شيء. لكنه لا يستطيع تصنيع سبب يجعل أي شخص لا يزال يرغب فيه غدًا.
هل كنت يومًا السيولة الخارجة على إطلاق منحنى ربط، وما الذي جعلك تدرك ذلك في وقت متأخر?
تمّ التحقق
#opg $OPG @OpenGradient كنت أعتقد أن المزيد من الأمان هو دائمًا أفضل. ثم عملت مع نظام يقوم بتشفير كل شيء بنفس مستوى الهوس، سجلات الدردشة المؤقتة والسجلات المالية معًا، وشاهدت كل ذلك يتعثر تحت حذره الخاص. الأمان الذي يتجاهل السياق ليس حماية. إنه ضريبة يدفعها الجميع بغض النظر عن المخاطر الفعلية. عادت تلك الذاكرة عندما قرأت كيف يدير OpenGradient التحقق من الذكاء الاصطناعي. معظم المشاريع تروج للموثوقية على أنها مفتاح واحد تقوم بتبديله. يعامل OpenGradient الأمر كطيف، لأن فرض نفس متطلبات الإثبات على كل استنتاج سيكون نوعًا من الفشل. ردود الدردشة الآلية تحصل على تصديق TEE، إثبات على مستوى الأجهزة أن الشفرة الصحيحة تعمل داخل منطقة محكمة، بسرعة تكفي أنك لن تلاحظ أنها حدثت. نموذج تصفية DeFi أو قرار مالي ذو مخاطر عالية يحصل على ZKML، وهو إثبات تشفيري صارم لدرجة أنه يعمل ببطء من ألف إلى عشرة آلاف مرة، محجوز للحالات التي يكلف فيها الخطأ شخصًا ما المال. يمكن للأحمال ذات المخاطر المنخفضة تخطي التحقق الثقيل تمامًا وتشغيلها فقط على فحوصات التوقيع. ما يدهشني هو الانضباط وراء ذلك الخيار. سيكون من الأسهل تسويق "كل شيء مثبت تشفيرياً" كادعاء جريء واحد. بدلاً من ذلك، تعترف الوثائق أن فرض ZKML في كل مكان سيجعل الشبكة غير قابلة للاستخدام للدردشة العادية. البنية التحتية الجيدة لا تحمي كل شيء بشكل متساوٍ. إنها تحمي ما يهم حقًا، وتبتعد عن كل شيء آخر. هل سبق لك أن رأيت نظامًا يفشل لأنه حاول تأمين كل شيء بنفس المستوى بدلاً من مطابقة الحماية مع المخاطر الفعلية؟
#opg $OPG @OpenGradient

كنت أعتقد أن المزيد من الأمان هو دائمًا أفضل. ثم عملت مع نظام يقوم بتشفير كل شيء بنفس مستوى الهوس، سجلات الدردشة المؤقتة والسجلات المالية معًا، وشاهدت كل ذلك يتعثر تحت حذره الخاص. الأمان الذي يتجاهل السياق ليس حماية. إنه ضريبة يدفعها الجميع بغض النظر عن المخاطر الفعلية.
عادت تلك الذاكرة عندما قرأت كيف يدير OpenGradient التحقق من الذكاء الاصطناعي. معظم المشاريع تروج للموثوقية على أنها مفتاح واحد تقوم بتبديله. يعامل OpenGradient الأمر كطيف، لأن فرض نفس متطلبات الإثبات على كل استنتاج سيكون نوعًا من الفشل.
ردود الدردشة الآلية تحصل على تصديق TEE، إثبات على مستوى الأجهزة أن الشفرة الصحيحة تعمل داخل منطقة محكمة، بسرعة تكفي أنك لن تلاحظ أنها حدثت. نموذج تصفية DeFi أو قرار مالي ذو مخاطر عالية يحصل على ZKML، وهو إثبات تشفيري صارم لدرجة أنه يعمل ببطء من ألف إلى عشرة آلاف مرة، محجوز للحالات التي يكلف فيها الخطأ شخصًا ما المال. يمكن للأحمال ذات المخاطر المنخفضة تخطي التحقق الثقيل تمامًا وتشغيلها فقط على فحوصات التوقيع.
ما يدهشني هو الانضباط وراء ذلك الخيار. سيكون من الأسهل تسويق "كل شيء مثبت تشفيرياً" كادعاء جريء واحد. بدلاً من ذلك، تعترف الوثائق أن فرض ZKML في كل مكان سيجعل الشبكة غير قابلة للاستخدام للدردشة العادية.
البنية التحتية الجيدة لا تحمي كل شيء بشكل متساوٍ. إنها تحمي ما يهم حقًا، وتبتعد عن كل شيء آخر.
هل سبق لك أن رأيت نظامًا يفشل لأنه حاول تأمين كل شيء بنفس المستوى بدلاً من مطابقة الحماية مع المخاطر الفعلية؟
سجّل الدخول لاستكشاف المزيد من المُحتوى
انضم إلى مُستخدمي العملات الرقمية حول العالم على Binance Square
⚡️ احصل على أحدث المعلومات المفيدة عن العملات الرقمية.
💬 موثوقة من قبل أكبر منصّة لتداول العملات الرقمية في العالم.
👍 اكتشف الرؤى الحقيقية من صنّاع المُحتوى الموثوقين.
البريد الإلكتروني / رقم الهاتف
خريطة الموقع
تفضيلات ملفات تعريف الارتباط
شروط وأحكام المنصّة