كنت أظن أن كل ترقية جادة للبلوكتشين تدور حول شيء واحد فقط: جعل المعاملات أسرع وأرخص. كان ذلك هو المعيار الذي يقارن به الجميع. زمن الاستجابة، سعة المعالجة، الرسوم. كل ذلك كان يشير إلى الاتجاه نفسه. تحسين التنفيذ، وستتبع بقية الأمور ذلك.
لكن بعد أن قضيت وقتًا في القراءة عن @NewtonProtocol ونسخته التجريبية Mainnet Beta، بدأت تلك الفرضية تَشعر بأنها ناقصة. ليست خاطئة. مجرد غير كافية. لأن السرعة لا تَهم إلا بعد أن تتأكد أن الفعل نفسه ينبغي أن يحدث.
بدأت فكرة أن النسخة التجريبية تعني أيضًا أنها غير مكتملة تَشعر بأنها مُضلِّلة. ففي معظم الحالات، تشير beta إلى أن شيئًا ما ما زال قيد الاختبار أو أنه ليس موثوقًا بالكامل. لكن هنا، الأمر مختلف. النظام ليس غير مكتمل. إنه مُتحكَّم فيه. فبيئة التنفيذ مُقيَّدة عمدًا بحيث يمكن ملاحظة التنفيذ والتحقق منه وتشكيله قبل التوسع. وهذا ليس عائقًا. إنه اختيار تصميم.
أدى هذا التحول في منظور التفكير إلى أن أتعمق أكثر في كيفية عمل النظام فعليًا.
على مستوى بسيط، يقدّم نيوتن طبقة سياسة قبل التنفيذ. بدلًا من أن تنتقل المعاملة مباشرةً من نية المستخدم إلى تسوية العقد الذكي، فإنها تمر عبر نقطة تحقق (checkpoint). تُقيّم نقطة التحقق ما إذا كان الإجراء يحقق الشروط المحددة مسبقًا. يمكن أن تشمل هذه الشروط متطلبات الهوية، ومعلمات المخاطر، وقواعد الامتثال، أو قيود الاستراتيجية.
التفصيل المهم هو أن هذا التقييم لا يعتمد على الثقة العمياء. فهو يستخدم مزيجًا من الحوسبة خارج السلسلة والتحقق داخل السلسلة. يقوم المشغّلون بمعالجة النية، ويقيّمونها مقابل السياسة، ثم يُنتجون نتيجة موقعة. تُجمَّع هذه التواقيع وتُتحقق منها قبل السماح بالمعاملة كي تمضي قدمًا.
هذا يعني أن النظام يفصل بين ثلاثة أمور تكون عادةً ممزوجة معًا. تعريف السياسة، ومنطق التنفيذ، والتحقق. لكل جزء دوره الخاص. ويمكن فحص كل جزء.
من الخارج، قد تبدو التدفقات مألوفة. ما زال هناك مخزن (Vault). وما زال هناك مدير يوقّع. وما زالت النية تتحول إلى تنفيذ. لكن المسار مختلف. لم تعد التعليمات تذهب مباشرةً إلى العقد. بل يتم اعتراضها وفحصها، ثم يُسمح لها فقط بالاستمرار.
عندها يصبح التصميم مقصودًا بدلًا من كونه مجرد مظهر.
تفترض معظم أنظمة البلوك تشين أنه بمجرد أن تكون المعاملة صالحة، ينبغي أن تُنفّذ. يتم تعريف الصلاحية من خلال الكود. إذا تطابقت المدخلات مع القواعد، يمضي النظام. لكن الكود لا يفهم السياق. لا يعرف إن كان الإجراء محفوفًا بالمخاطر أو غير مناسب، أو أنه ببساطة مُجرى في وقت سيئ.
يُبنى نيوتن على فكرة أن الصلاحية ليست كافية. فالتفويض مهم. والسياق مهم. وهذه العوامل ينبغي فرضها قبل التنفيذ، لا تحليلها بعده.
يصبح هذا أكثر أهمية مع دخول الذكاء الاصطناعي إلى الصورة.
تركز أغلب المناقشات حول الذكاء الاصطناعي في مجال العملات المشفرة على الإمكانية. هل يمكنه التداول بشكل أفضل؟ هل يمكنه تحسين العائد؟ هل يمكنه الاستجابة بشكل أسرع من البشر؟ هذه أسئلة مفيدة، لكنها تتجاهل سؤالًا أصعب. ماذا يحدث عندما تتحكم هذه الأنظمة في مبالغ ذات معنى من رأس المال؟
عند تلك النقطة، لم يعد الذكاء وحده هو عنق الزجاجة. السيطرة هي العنق.
إن كان وكيل ذكاء اصطناعي ينفّذ استراتيجية معيبة بسرعة عالية، فلن يخلق كفاءة. بل سيخلق خسائر أسرع. وبدون قيود، تعمل الأتمتة على تضخيم الأخطاء بدلًا من منعها.
هنا تبدأ معمارية نيوتن بالتواصل مع اتجاه أوسع. فهي لا تحاول بناء متداول أفضل. بل تحاول تحديد الحدود التي يمكن لأي متداول—بشريًا كان أم آليًا—أن يعمل ضمنها.
قد يبدو هذا التمييز دقيقًا، لكنه يغيّر مكان تركز القيمة. بدلًا من التنافس على التنفيذ، يتنافس النظام على سلامة القرار.
إذا نجح هذا النهج، فقد يعيد تشكيل الطريقة التي يفكر بها الناس في البنية التحتية. سينتقل التركيز من مدى سرعة تسوية المعاملات إلى مدى ثقة الموافقة عليها. من الإنتاجية الخام إلى مشاركة مُتحكَّم بها.
كما يثير أسئلة ليست سهلة الإجابة.
مع انتقال المزيد من القواعد إلى السلسلة (onchain)، من يعرّفها؟ ومع تعقّد السياسات، من يَتحقق منها؟ ومع ازدياد مستوى التحكم، كيف نضمن ألا يتحول ذلك إلى مركزية مخفية؟
هذه ليست أسئلة تقنية وحدها. إنها أسئلة تصميم وحوكمة.
في الوقت الحالي، ما يبرز هو الاتجاه. @NewtonProtocol لا يحاول إزالة البشر من النظام. إنه يحاول تقليل الثقة العمياء. فهو لا يستبدل التنفيذ. بل يعيد صياغته.
وقد يكون ذلك التحول أكثر أهمية.
إذا كان الذكاء الاصطناعي سيتولى إدارة رأس المال، فهل ينبغي أن نُعطي الأولوية لجعله أكثر ذكاءً أم لجعله مسؤولًا؟
إذا كان بإمكان فحص كل معاملة قبل تنفيذها، فهل تظل السرعة هي المؤشر الأساسي؟
وإذا أصبحت السياسة هي بوابة التحكم، فمن الذي يتحكم في البوابة في النهاية؟
ليس نصيحة مالية. ابحث بنفسك (DYOR).
