كنت أظن أن كلمة "بيتا" تعني غير مكتمل. شيئًا خشنًا. شيئًا غير جاهز. شيئًا تحاول مرة واحدة، ثم تنتظر النسخة الحقيقية.
لم يعد هذا الافتراض صحيحًا كما كان من قبل.
لاحظت مدى اعتيادية أن يكتفي الناس بالنقر على زر الموافقة في التمويل اللامركزي دون التفكير فيما يتم تنفيذه فعليًا. يبدو الأمر كفؤًا. يبدو روتينيًا. حتى يأتي الوقت الذي لا يكون كذلك. موافقة خاطئة واحدة، والنظام ما يزال ينفّذ بالضبط ما أمرته به.
هذا ليس خللًا. هكذا يعمل التصميم.
قراءة ورقة البروتوكول الخاصة بـ Newton وقضاء وقت مع شبكة Newton Mainnet Beta، تجعل التحوّل يبدو هادئًا لكنه من النوع البنيوي. فهو لا يحاول جعل المعاملات أسرع. بل يحاول إزالة الحاجة إلى أن يقوم المستخدمون بإنشائها يدويًا من الأساس.
من المعاملات اليدوية إلى التنفيذ المدفوع بالنية.
ذلك السطر يبدو بسيطًا. لكنه يغيّر التدفق بالكامل.
بدلًا من تعريف كل خطوة، يعرّف المستخدم النتيجة. ثم يتولى النظام التنفيذ ضمن مجموعة من السياسات المحددة مسبقًا. وهذا يعني أن المنطق لم يعد موجودًا في الواجهة فقط. بل أصبح مدمجًا في كيفية السماح للتنفيذ بأن يحدث.
هنا يبدأ التصميم في الظهور وكأنه مقصود.
معظم أمن الويب3 اليوم تفاعلي. نحلل الثغرات بعد وقوعها. نبني لوحات بيانات لشرح الإخفاقات. نحسّن المراقبة. لكن المعاملة لا تزال تمر أولًا. ويفترض النظام أنه إذا وقّع المستخدم على شيء ما، فيجب تنفيذه.
نيوتن يتحدى هذا الافتراض.
ماذا لو كان النظام قادرًا على فلترة الإجراءات الخطرة قبل التنفيذ. لا بعده. ولا أثناءه. بل قبله.
ذلك يغيّر دور البنية التحتية.
بدلًا من أن يكون منفذًا سلبيًا، يصبح البروتوكول طبقة قرار نشطة. فهو لا يعالج التعليمات فحسب. بل يقيّم ما إذا كان ينبغي السماح لتلك التعليمات بالوجود من الأساس.
تفاعل أقل. وقاية أكثر.
هنا تصبح طبقة الميمات حقيقية. لقد أمضينا سنوات في تحسين النقرات. نقرات أسرع. نقرات أرخص. واجهات أنظف. لكننا نادرًا ما تساءلنا عمّا إذا كان ينبغي للمستخدمين أن يمروا أصلًا بتدفقات معاملات معقدة عبر النقر.
نيوتن لا يحاول تحسين النقرة. بل يحاول إزالتها.
ذلك اتجاه مختلف عن معظم ترقيات البنية التحتية.
تعكس النسخة التجريبية من الشبكة الرئيسية هذا التفكير. فهي لا تبدو كعرض للميزات. بل تبدو كبيئة مضبوطة لاختبار ما إذا كان التنفيذ القائم على النية يمكنه الصمود في الظروف الحقيقية. وما إذا كانت السياسات قادرة على تقليل أخطاء المستخدم بشكل ملموس. وما إذا كان يمكن الوثوق بالأتمتة من دون أن تتحول إلى تفويض أعمى.
لأن هذا هو التوتر الحقيقي.
الأتمتة تزيد من الراحة. لكنها أيضًا تُدخل أشكالًا جديدة من المخاطر إذا لم تُحَدَّد بشكل صحيح. ويبدو أن نيوتن واعٍ لذلك. إن التركيز على التنفيذ المحدد بالسياسات يشير إلى أن الأتمتة ليست هدفها استبدال تحكم المستخدم. بل تنظيمه.
ذلك التمييز مهم.
إذا نجح هذا النموذج، تتوقف الواجهة عن كونها طبقة الثقة الأساسية. ويبدأ البروتوكول نفسه في فرض الحدود. لم يعد المستخدمون مسؤولين عن التقاط كل الحالات الحدّية يدويًا. ويستوعب النظام جزءًا من تلك المسؤولية.
ذلك يغيّر مكان وجود المخاطر.
كما أنه يغيّر من المستفيد.
يمكن للمطورين التصميم حول النتائج بدلًا من التدفقات خطوة بخطوة. ويتفاعل المستخدمون مع تجريدات أبسط. ويصبح البروتوكول المكان الذي تُفرض فيه القواعد باستمرار، لا الذي تُفسَّر فيه بشكل فضفاض.
البدايات مبكرة، لكن الاتجاه واضح.
قد يتحرك التمويل على السلسلة نحو أنظمة تقرر ما الذي لا ينبغي أن يحدث، لا ما الذي يمكن أن يحدث فحسب. هذا تحول أعمق من تحسين الإنتاجية أو خفض الرسوم. إنه تحول في كيفية اتخاذ القرارات قبل أن يبدأ التنفيذ أصلًا.
أصبحت أرى المزيد عن نيوتن مؤخرًا، وتبدو النسخة التجريبية من الشبكة الرئيسية خطوة مقصودة في ذلك الاتجاه. ليست صاخبة. وليست مبالغًا في طرحها. لكنها مختلفة بنيويًا.
إذا نجحوا فعلًا في تبسيط الأتمتة مع الحفاظ على التحكم، فقد يفتح ذلك طبقة جديدة من المشاركة لا تعتمد على انتباه المستخدم المستمر.
وربما هذا هو السؤال الحقيقي.
هل ما زلنا نصمم أنظمة تتوقع من المستخدمين أن يفكروا كآلات. أم أننا أخيرًا نصمم أنظمة قادرة على التفكير ضمن حدود نيابةً عن المستخدمين.
في أي نقطة يتوقف التنفيذ عن كونه شيئًا تبدأه أنت، ويبدأ في أن يصبح شيئًا يديره النظام بمسؤولية.
وإذا بدأت البروتوكولات تقرر ما الذي لا ينبغي تنفيذه، فمن يعرّف تلك الحدود.
ليست نصيحة مالية. قم ببحثك بنفسك.