تتسارع مؤخرًا الاستثمارات الضخمة في سلاسل وكلاء الذكاء الاصطناعي وعلى الأتمتة على البلوكشين؛ وقد حللتُ بشكل عميق البنية التحتية لـ بروتوكول Newton. السرد غنيّ ومُشبع، لكن التنفيذ الهندسي على أرض الواقع قاسٍ للغاية. ميزته الأساسية المتمثلة في «الاستقلال بنطاقات»—أي تقييد صلاحيات الذكاء الاصطناعي عبر zkPermissions وتنفيذ ذلك داخل بيئة TEE (مثل Phala)—تبدو كأنها توفّق بين الخصوصية وقابلية التحقق. غير أنه بمجرد إخضاعها لاختبارات ضغط «جادة» داخل بيئة EVM، تتضح الشقوق الأساسية بوضوح.
1) التكاليف التي تُسقط منطق الأعمال
يستخدم Newton Groth16 للتحقق على السلسلة. فكل عملية تحقق ZKP واحدة تستهلك ضمانًا قرابة 300 ألف Gas، أي أنها أعلى بنحو عشرات المرات من تحويل عادي. في السيناريوهات منخفضة التكرار يمكنها أن تتحمّل الأمر بصعوبة، لكن إذا استُخدم الوكيل في جدولة أصول RWA عالية التواتر أو في استراتيجيات شبكية (grid) معقّدة، فستتضخم خسائر الـGas بشكل شبه أسي. الأتمتة اللامركزية لا ينبغي أن تتحول إلى لعبة أغنياء لا تُراعي جدوى اقتصادية.
2) أزمة «اللحام» بين أكثر من إطار طبقة أساسية
النظام يتصل في الوقت نفسه بـ Succinct وRisc Zero، وهما أداتان كبيرتان لِـ zkVM. غير أن الأصول التشفيرية ومسارات تجميع البراهين الأساسية لكل منهما مختلفة جذريًا. إن التعاون عبر الأطر بسهولة قد يؤدي إلى تعارضات منطقية داخل تفاعلات عقود ذكية معقدة. وبالاطلاع على سجلات التزامات GitHub الأخيرة لديهم، لم أرَ معيارًا موحدًا للتعامل مع اختلاف حالة الطبقة الأساسية. وفي حال حدوث تباين في التحقق تحت ظروف سوقية قصوى، ستواجه الشبكة اللامركزية مخاطر توافق (consensus) شديدة.
3) ثغرة مميتة تتعلق بالهجوم بإعادة التشغيل
تصميم مفاتيح الجلسة يتضمن مدة صلاحية، لكنه يفتقر إلى آلية سحب/إبطال حاسمة ومحددة على السلسلة. فإذا قام عقد خبيث أو مهاجم بالاستفادة من نافذة قصيرة قرب انتهاء صلاحية المفتاح، مستخدمًا تأخير RPC لاعتراض الرسائل وإعادة تشغيل إثبات ZK صالح، فإن النظام يتحقق فقط من شرعية التشفير ويتجاهل إعادة استخدام الحالة (state reuse). هكذا يمكن استكمال سحب الأصول. في عالم المعاملات، أولوية البقاء. إن الإعداد الذي يكتفي بالتحقق من الشهادات دون فحص الحالة يشبه تمامًا تعليق مفتاح الخزنة على الباب.
لا يمكن للامركزية في الثقة أن تبقى حبيسة ورقة الـwhitepaper. لكي يثبت Newton نفسه، يجب عليه أولًا تقديم بيانات اختبارات الضغط في البيئة الحقيقية للشبكة الرئيسية وخطة صارمة لمكافحة إعادة التشغيل؛ وإلا فلن تكون حتى السرديات الأكثر فخامة سوى برج هوائي هش. لا أنصح أبدًا بالرهان الثقيل بشكل أعمى.
$NEWT #Newt @NewtonProtocol
1) التكاليف التي تُسقط منطق الأعمال
يستخدم Newton Groth16 للتحقق على السلسلة. فكل عملية تحقق ZKP واحدة تستهلك ضمانًا قرابة 300 ألف Gas، أي أنها أعلى بنحو عشرات المرات من تحويل عادي. في السيناريوهات منخفضة التكرار يمكنها أن تتحمّل الأمر بصعوبة، لكن إذا استُخدم الوكيل في جدولة أصول RWA عالية التواتر أو في استراتيجيات شبكية (grid) معقّدة، فستتضخم خسائر الـGas بشكل شبه أسي. الأتمتة اللامركزية لا ينبغي أن تتحول إلى لعبة أغنياء لا تُراعي جدوى اقتصادية.
2) أزمة «اللحام» بين أكثر من إطار طبقة أساسية
النظام يتصل في الوقت نفسه بـ Succinct وRisc Zero، وهما أداتان كبيرتان لِـ zkVM. غير أن الأصول التشفيرية ومسارات تجميع البراهين الأساسية لكل منهما مختلفة جذريًا. إن التعاون عبر الأطر بسهولة قد يؤدي إلى تعارضات منطقية داخل تفاعلات عقود ذكية معقدة. وبالاطلاع على سجلات التزامات GitHub الأخيرة لديهم، لم أرَ معيارًا موحدًا للتعامل مع اختلاف حالة الطبقة الأساسية. وفي حال حدوث تباين في التحقق تحت ظروف سوقية قصوى، ستواجه الشبكة اللامركزية مخاطر توافق (consensus) شديدة.
3) ثغرة مميتة تتعلق بالهجوم بإعادة التشغيل
تصميم مفاتيح الجلسة يتضمن مدة صلاحية، لكنه يفتقر إلى آلية سحب/إبطال حاسمة ومحددة على السلسلة. فإذا قام عقد خبيث أو مهاجم بالاستفادة من نافذة قصيرة قرب انتهاء صلاحية المفتاح، مستخدمًا تأخير RPC لاعتراض الرسائل وإعادة تشغيل إثبات ZK صالح، فإن النظام يتحقق فقط من شرعية التشفير ويتجاهل إعادة استخدام الحالة (state reuse). هكذا يمكن استكمال سحب الأصول. في عالم المعاملات، أولوية البقاء. إن الإعداد الذي يكتفي بالتحقق من الشهادات دون فحص الحالة يشبه تمامًا تعليق مفتاح الخزنة على الباب.
لا يمكن للامركزية في الثقة أن تبقى حبيسة ورقة الـwhitepaper. لكي يثبت Newton نفسه، يجب عليه أولًا تقديم بيانات اختبارات الضغط في البيئة الحقيقية للشبكة الرئيسية وخطة صارمة لمكافحة إعادة التشغيل؛ وإلا فلن تكون حتى السرديات الأكثر فخامة سوى برج هوائي هش. لا أنصح أبدًا بالرهان الثقيل بشكل أعمى.
$NEWT #Newt @NewtonProtocol
