ما زال ما يزعجني في Space and Time ليس إثبات نتيجة SQL.
بل عبارة WHERE الكامنة تحتها.
عنوان عقد واحد مفقود.
هذا كل شيء. وهذا يكفي لجعل رقم إيرادات موثَّق تمامًا يبدو سخيفًا لاحقًا.
وليس بالضرورة أن يكتشف SXT ذلك.
وهذا... لا بأس. فلم يكن من المفترض أن يفعل.
هذا هو الجزء المزعج.
@SpaceandTime تسحب عُقد الفهرسة أحداث Ethereum إلى جداول علائقية. وتُثبّت النصاب القانوني للمدقّقين حالة الجدول. وينفّذ المُثبِت استعلام SQL على تلك الالتزامات. ويتحقق إثبات SQL من العملية الحسابية.
جيد. آلية معقدة.
ومع ذلك، لا أحد يجادل في العنوان المفقود.
لنفترض أن وكيل ذكاء اصطناعي استخرج رسوم بروتوكول إقراض لمدة 30 يومًا عبر SXT Chain. تبدو الإيرادات أقل مما كان متوقعًا. يُنفّذ الاستعلام. ويتحقق إثبات المعرفة الصفرية. ثم يُدرج رقم دقيق في مذكرة للمخاطر.
ويبدأ أحدهم الحديث عن حدود التعرّض.
ثم ماذا؟
يتضح أن أحد العقود المُدرّة للرسوم لم يُدرج قط في مرشح SQL.
يا لها من روعة.
ليس جدولًا مزوّرًا. ولا مُثبِت SXT مخادعًا. ببساطة، لم يطلب الاستعلام تلك الأحداث.
ما زلت عالقًا عند هذه النقطة.
لأن التزام الجدول الموقّع من المدقّقين قد يكون صحيحًا. وقد يكون إثبات SQL صحيحًا. وحتى سجلات Ethereum التاريخية الموجودة في Space and Time قد تكون سليمة تمامًا.
أما عبارة WHERE في استعلام الوكيل؟
فما زالت تُسقط إيرادات.
والآن تتضمن مذكرة المخاطر رقمًا مرفقًا بإثبات صحيح. ولا يكلف أحد نفسه عناء إعادة فتح قائمة العقود. يرى فريقٌ رسومًا موثّقة، ويبدأ فريق آخر بالتعامل مع الانخفاض على أنه حقيقي. ثم يرسل أحدهم الرقم إلى الآخرين قبل أن يعيد فتح قائمة العقود.
كارثة تنتظر في سطر SQL واحد.
سبق أن رأيت هذا النوع من الاطمئنان إلى الحسابات النظيفة. لا أحد يريد الاعتراض على الرياضيات بعد ظهور الإثبات.
حسنًا.
لكن Space and Time أثبت الاستعلام الذي تلقّاه، لا الاستعلام الذي كان ينبغي لوكيل ذكاء اصطناعي أن يكتبه.
وهذا تمييز خطير.
ذلك العقد المستبعَد ما زال على Ethereum. لكنه ليس ضمن نتيجة SQL.
فمن يلتقط ذلك العنوان قبل أن تبدأ نتيجة SXT المُثبتة بتحريك حدّ حقيقي للتعرّض؟
المُثبِت؟
أم الشخص الذي يفتح عبارة WHERE أخيرًا؟
#sxt $SXT @SpaceandTime
بل عبارة WHERE الكامنة تحتها.
عنوان عقد واحد مفقود.
هذا كل شيء. وهذا يكفي لجعل رقم إيرادات موثَّق تمامًا يبدو سخيفًا لاحقًا.
وليس بالضرورة أن يكتشف SXT ذلك.
وهذا... لا بأس. فلم يكن من المفترض أن يفعل.
هذا هو الجزء المزعج.
@SpaceandTime تسحب عُقد الفهرسة أحداث Ethereum إلى جداول علائقية. وتُثبّت النصاب القانوني للمدقّقين حالة الجدول. وينفّذ المُثبِت استعلام SQL على تلك الالتزامات. ويتحقق إثبات SQL من العملية الحسابية.
جيد. آلية معقدة.
ومع ذلك، لا أحد يجادل في العنوان المفقود.
لنفترض أن وكيل ذكاء اصطناعي استخرج رسوم بروتوكول إقراض لمدة 30 يومًا عبر SXT Chain. تبدو الإيرادات أقل مما كان متوقعًا. يُنفّذ الاستعلام. ويتحقق إثبات المعرفة الصفرية. ثم يُدرج رقم دقيق في مذكرة للمخاطر.
ويبدأ أحدهم الحديث عن حدود التعرّض.
ثم ماذا؟
يتضح أن أحد العقود المُدرّة للرسوم لم يُدرج قط في مرشح SQL.
يا لها من روعة.
ليس جدولًا مزوّرًا. ولا مُثبِت SXT مخادعًا. ببساطة، لم يطلب الاستعلام تلك الأحداث.
ما زلت عالقًا عند هذه النقطة.
لأن التزام الجدول الموقّع من المدقّقين قد يكون صحيحًا. وقد يكون إثبات SQL صحيحًا. وحتى سجلات Ethereum التاريخية الموجودة في Space and Time قد تكون سليمة تمامًا.
أما عبارة WHERE في استعلام الوكيل؟
فما زالت تُسقط إيرادات.
والآن تتضمن مذكرة المخاطر رقمًا مرفقًا بإثبات صحيح. ولا يكلف أحد نفسه عناء إعادة فتح قائمة العقود. يرى فريقٌ رسومًا موثّقة، ويبدأ فريق آخر بالتعامل مع الانخفاض على أنه حقيقي. ثم يرسل أحدهم الرقم إلى الآخرين قبل أن يعيد فتح قائمة العقود.
كارثة تنتظر في سطر SQL واحد.
سبق أن رأيت هذا النوع من الاطمئنان إلى الحسابات النظيفة. لا أحد يريد الاعتراض على الرياضيات بعد ظهور الإثبات.
حسنًا.
لكن Space and Time أثبت الاستعلام الذي تلقّاه، لا الاستعلام الذي كان ينبغي لوكيل ذكاء اصطناعي أن يكتبه.
وهذا تمييز خطير.
ذلك العقد المستبعَد ما زال على Ethereum. لكنه ليس ضمن نتيجة SQL.
فمن يلتقط ذلك العنوان قبل أن تبدأ نتيجة SXT المُثبتة بتحريك حدّ حقيقي للتعرّض؟
المُثبِت؟
أم الشخص الذي يفتح عبارة WHERE أخيرًا؟
#sxt $SXT @SpaceandTime
