#sxt $SXT @SpaceandTime هناك سؤال أظن أن من السهل جدًا تجاوزه بعبارة «بيانات قابلة للتحقق»: لا تستطيع العقود الذكية في الأصل سوى الاطلاع على حالة السلسلة، فلماذا تثق بنتيجة استعلام آتية من قاعدة بيانات خارج السلسلة؟ تبدو براهين المعرفة الصفرية وكأنها الإجابة، لكن معظم الناس لا يفهمون تمامًا ما الذي تثبته هذه البراهين.
كنت أعتقد أن الإجابة تكمن أساسًا في Proof of SQL. لكن بعد دراسة عُقد الفهرسة في Space and Time، وتعهدات المدقّقين، وآلية توليد البراهين، أدركت أن المفتاح الحقيقي هو تحويل البيانات أولًا إلى «موضوع مُتعَهَّد به». يجلب Indexer البيانات من مختلف السلاسل ويفك ترميزها ليحوّلها إلى جداول، فيما ينشئ Validator تعهدات تشفيرية بشأن حالة هذه البيانات ويوقّعها بتوقيع عتبي. بعد ذلك، أيًّا كان من يجري الاستعلام، يجب أن تكون النتيجة مرتبطة بهذا التعهد: فإذا عُدّلت البيانات سرًا قبل الاستعلام، فلن يجتاز الإثبات.
هذه الخطوة بالغة الأهمية. فـSpace and Time لا تجعل العقود الذكية قادرة على الاستعلام من قواعد البيانات، بل تحوّل «تنفيذ الاستعلام» إلى عملية حسابية قابلة للتحقق. يشغّل Prover استعلام SQL خارج السلسلة وينشئ برهان ZK، ولا يحتاج العقد سوى إلى التحقق من التعهد والبرهان، من دون الوثوق بـProver. وينطبق الأمر نفسه على وكيل الذكاء الاصطناعي: إذ يمكن تدقيق البيانات التي يعتمد عليها في اتخاذ قراراته.
لذلك، أرى أن ما تحله Space and Time فعليًا ليس «منح البلوك تشين قاعدة بيانات»، بل تحويل العمليات الحسابية خارج السلسلة إلى تعهدات يمكن التحقق منها على السلسلة. والتكلفة واضحة أيضًا: اكتمال البيانات المفهرسة، وما إذا كان التعهد يشمل اللقطة الصحيحة، وقدرة توليد البراهين على مواكبة متطلبات زمن الاستجابة؛ أي خلل في أي حلقة من هذه السلسلة سيقلل من «قابلية التحقق». والأهم أن Proof of SQL لا يثبت سوى أن «الاستعلام نُفّذ بأمانة»، ولا يثبت أن البيانات الأصلية صحيحة — فالمدخلات الرديئة تؤدي إلى مخرجات رديئة.
ما يستحق المتابعة طويلًا في Space and Time ليس قدرتها على إثبات أن استعلام SQL لم يُعبث به، بل ما إذا كان خط الأنابيب هذا — «تعهد البيانات ← استعلام قابل للتحقق ← استخدام العقد» — قادرًا على العمل بسرعة واستقرار في ظل أحمال حقيقية. فالذكاء الاصطناعي والتمويل اللامركزي لا يحتاجان إلى تشفير أنيق فحسب، بل إلى بنية هندسية لا تتعثر فيها أي حلقة.
كنت أعتقد أن الإجابة تكمن أساسًا في Proof of SQL. لكن بعد دراسة عُقد الفهرسة في Space and Time، وتعهدات المدقّقين، وآلية توليد البراهين، أدركت أن المفتاح الحقيقي هو تحويل البيانات أولًا إلى «موضوع مُتعَهَّد به». يجلب Indexer البيانات من مختلف السلاسل ويفك ترميزها ليحوّلها إلى جداول، فيما ينشئ Validator تعهدات تشفيرية بشأن حالة هذه البيانات ويوقّعها بتوقيع عتبي. بعد ذلك، أيًّا كان من يجري الاستعلام، يجب أن تكون النتيجة مرتبطة بهذا التعهد: فإذا عُدّلت البيانات سرًا قبل الاستعلام، فلن يجتاز الإثبات.
هذه الخطوة بالغة الأهمية. فـSpace and Time لا تجعل العقود الذكية قادرة على الاستعلام من قواعد البيانات، بل تحوّل «تنفيذ الاستعلام» إلى عملية حسابية قابلة للتحقق. يشغّل Prover استعلام SQL خارج السلسلة وينشئ برهان ZK، ولا يحتاج العقد سوى إلى التحقق من التعهد والبرهان، من دون الوثوق بـProver. وينطبق الأمر نفسه على وكيل الذكاء الاصطناعي: إذ يمكن تدقيق البيانات التي يعتمد عليها في اتخاذ قراراته.
لذلك، أرى أن ما تحله Space and Time فعليًا ليس «منح البلوك تشين قاعدة بيانات»، بل تحويل العمليات الحسابية خارج السلسلة إلى تعهدات يمكن التحقق منها على السلسلة. والتكلفة واضحة أيضًا: اكتمال البيانات المفهرسة، وما إذا كان التعهد يشمل اللقطة الصحيحة، وقدرة توليد البراهين على مواكبة متطلبات زمن الاستجابة؛ أي خلل في أي حلقة من هذه السلسلة سيقلل من «قابلية التحقق». والأهم أن Proof of SQL لا يثبت سوى أن «الاستعلام نُفّذ بأمانة»، ولا يثبت أن البيانات الأصلية صحيحة — فالمدخلات الرديئة تؤدي إلى مخرجات رديئة.
ما يستحق المتابعة طويلًا في Space and Time ليس قدرتها على إثبات أن استعلام SQL لم يُعبث به، بل ما إذا كان خط الأنابيب هذا — «تعهد البيانات ← استعلام قابل للتحقق ← استخدام العقد» — قادرًا على العمل بسرعة واستقرار في ظل أحمال حقيقية. فالذكاء الاصطناعي والتمويل اللامركزي لا يحتاجان إلى تشفير أنيق فحسب، بل إلى بنية هندسية لا تتعثر فيها أي حلقة.