Fiona crypto 01

ظننت أن الجزء المثير للاهتمام سيكون عامل الضمان الخاص ببايابلون. اتضح أنه السلوك التشغيلي المخفي وراء ذلك الرقم الواحد.
بدأت بمقارنة إعدادات الضمان مع تدفق الإيداع وتوزيع مسؤوليات المُتحققين. في البداية بدا العامل كمعلمة مخاطر نمطية. ثم لاحظت أن نفس الضمان يجب أن يتحمل في الوقت ذاته تذبذب الأسعار وخطر أداء المُتحققين وتأخر حل النزاعات.
الجزء الذي غيّر طريقة تفكيري كان التوقيت. نهائية البيتكوين تأتي وفق وقت البيتكوين، بينما يعمل مُتحققو بايابلون على إيقاع أسرع بكثير. عامل الضمان ليس مجرد خصم لقيمة ما. إنه حاجز يجب أن يصمد خلال فترة تصل فيها المعلومات بسرعات مختلفة عبر نظامين.
تحققت بعد ذلك من مناقشات الحوكمة المتعلقة بإدارة المخاطر وعمليات الخزينة. أصبح النمط أكثر وضوحًا. تُقلل عوامل الضمان المنخفضة كفاءة رأس المال، لكنها أيضًا تُقلل احتمال أن يُجبر تحرّك مفاجئ في السوق على تنسيق طارئ بين مديري خزينة المُتحققين ومشاركي الحوكمة. هذا ليس قرارًا سوقيًا. إنه قرار تشغيلي.
ثم نظرت إلى ظروف السيولة. إذا أصبح الحصول على الضمان أصعب أثناء الضغوط، فإن البروتوكول لا يواجه فقط قدرة إقراض أقل. بل يواجه تعافيًا أبطأ لأن المشاركين يحتاجون وقتًا لإعادة موازنة المراكز عبر السلاسل.
بحثت عن معلمة للرافعة وانتهيت بقراءة وثيقة حول التنسيق في ظل عدم اليقين.
@BabylonLabs_io
#baby $BABY

اعتقدت أن الجزء المثير للاهتمام هو الاقتراض بسعر فائدة ثابت نفسه. اتضح أن الأمر هو ما يقوله السعر الثابت عن بقية النظام.
بعد أن قضيت وقتًا في قراءة مواد Babylon، توقفت عن التفكير في الاقتراض كميزة إقراض بسيطة. بدأت أبحث في كل ما يجب أن يبقى قابلًا للتنبؤ به قبل أن يمكن لِسعر فائدة ثابت أن يكون له معنى فعليًا.
يُنشئ تَسْتَيْك البيتكوين أصلًا يدر عائدًا بينما يبقى مرتبطًا بأمن البيتكوين. طبقة الاقتراض تعتمد على بقاء هذا الأصل محافظًا على دوره الاقتصادي مع مرور الوقت. ثم توجد تصميمات الخزائن (vaults) حيث توجد كل خِزنة لتطبيقٍ محدد واحد بدل أن تصبح ضمانًا مشتركًا لكل شيء. بدا ذلك مُقيِّدًا في البداية، لكنه أيضًا يُقلِّل عدد التفاعلات غير المعروفة التي قد تؤثر على المراكز المقترَضة.
تضيف تدفقات السداد طبقة أخرى. يجب أن تتوصل الأدلة إلى اتفاق قبل أن تكتسب قيمة. يجب الوثوق بمعلومات التسعير. يجب أن تكون عمليات التصفية بشروط واضحة. يبدو أن السعر الثابت مستقر فقط لأن قدرًا مفاجئًا من البنية التحتية يستمر في التغيّر بطرق مُسيطر عليها تحته.
واصلت أيضًا التفكير في فترات فك الارتباط المختلفة بين رهن بيتكوين (Bitcoin stake) ورهن BABY (BABY stake). تعملان على ساعات مختلفة، ومع ذلك لا يزال نظام الاقتراض بحاجة إلى أخذ كلٍ منهما في الحسبان دون خلق ضغوط سيولة غير ضرورية. هذا أقل ما يكون عن التمويل وأكثر عن التنسيق عبر أنظمة مستقلة.
كلما قارنتُ المزيد من الوثائق بدا الاقتراض بسعر فائدة ثابت أقل كونه منتجًا ماليًا. بدأ يبدو كأنه قياسٌ لمقدار عدم اليقين التشغيلي الذي يعتقد البروتوكول أنه يستطيع استيعابه دون أن يُخِلَّ بافتراضاته الخاصة.
@BabylonLabs_io
#baby $BABY

اعتقدت أن الجزء المثير للاهتمام هو تجزئة كتلة البيتكوين نفسها. لكن اتضح أن الأمر يتعلق بما تتوقعه بابل من حيث الحجم.
في البداية يبدو ذلك كتفصيل تنفيذي عادي. تجزئة الكتلة لها صيغة معروفة، لذا فإن تحديد الحجم المتوقع لها يبدو شبه غير ضروري. بعد أن قضيت وقتًا أطول في قراءة منطق التحقق جنبًا إلى جنب مع معالجة نقاط التحقق والتكامل مع البيتكوين، بدأت أنظر إليه بشكل مختلف.
يعتمد بروتوكول مثل بابل على وصول معلومات من سلسلة أخرى دون أن يتغير معناها على طول الطريق. يبدأ كل نقطة تحقق، كل إثبات، وكل قرار يتخذه المُتحققون، بافتراض أن البيانات التي تتم معالجتها تطابق ما أنتجته البيتكوين فعليًا. إذا جرى التعامل مع شيء أساسي مثل الحجم المتوقع لتجزئة كتلة على نحو غير صارم، فإن كل طبقة فوقه ترث حالة عدم يقين إضافية.
أصبح الأمر أكثر إثارة للاهتمام عند مقارنته بالطريقة التي تتحقق بها بابل من بيانات الجينيسيس وتعيد بناء الحالة من البداية. يبذل الشبكة قدرًا مدهشًا من الجهد في رفض معلومات تبدو صحيحة تقريبًا، لأن «الصحيح تقريبًا» يكفي لتقسيم الحالة بين المشاركين. قواعد التحقق الصغيرة هي في الحقيقة قواعد تنسيق.
كما ظللت أفكر في التكلفة التشغيلية. رفض البيانات المشوّهة في أقرب خطوة ممكنة يكون أرخص من السماح لها بالتحرك عبر تخزين التحقق والإجماع قبل اكتشاف الخطأ. القيمة ليست أمنًا فحسب. إنها استخدام موارد يمكن التنبؤ به عبر كل مُتحقق.
بحثت في علم التشفير وانتهيت بالتفكير في الانضباط. أحيانًا تبدأ الموثوقية بالامتناع عن معالجة بيانات لا تفصل عنها خطوة واحدة—بيان واحد—عن أن تكون خاطئة.
@BabylonLabs_io
#baby $BABY

بدأتُ بقراءة التنويهات القانونية متوقّعًا تخطّيها. وبعد فترة أدركت أنها تشرح نموذج تشغيل بابيلون أكثر من العديد من المخططات التقنية.

كانت الجملة التي تقول إن مؤسسة بابيلون وشركاتها التابعة لا تقدّم أي تمثيل أو ضمان تبدو في البداية كصياغة قانونية روتينية. ثم قارنت ذلك مع بنية البروتوكول وطريقة تنسيق استيكينغ البيتكوين عبر مشاركين مستقلين. صار من الصعب تجاهل هذا الارتباط.

النظام الذي يعتمد على موفّري الإنهائية والمُصدّقين وستيكرز البيتكوين والتطبيقات الخارجية لا يمكنه الاعتماد على مؤسسة واحدة تقف خلف كل نتيجة. ولو كان الأمر كذلك، لكان من الممكن أن يرثّت الشبكة تدريجيًا نقطةً مركزية للمسؤولية التشغيلية حتى لو بقي الكود نفسه لامركزيًا.

غيّر ذلك أيضًا نظرتي إلى الحوكمة وحوافز المُصدّقين. فالأمن الاقتصادي مُوزّع لأن المسؤولية مُوزّعة. يشجّع البروتوكول المشاركين على التحقق من انتقالات الحالة عبر الحوافز بدلًا من توقع ضمان دقيق من مؤسسة بعد حدوث خطأ ما.

كما تتوافق الصياغة القانونية مع تركيز المشروع على تقليل افتراضات الثقة. فالتوثيق يدفع مرارًا المسؤولية نحو قواعد شفافة وإثباتات تشفيرية وبنية تحتية مُشغّلة بشكل مستقل، بدلًا من الوعود المؤسسية. هذه طرق مختلفة جدًا لبناء الثقة.

ما استوقفني أكثر هو أن اللامركزية ليست ظاهرة فقط في الإجماع أو توزيع الرموز. بل تظهر أيضًا في رفض الوعد بنتائج لا يستطيع أي مشارك واحد التحكم بها بشكل واقعي.

بدت الإحاطة القانونية كحماية قانونية على السطح. وبعد قراءة بقية النظام شعرت أنها أقرب إلى وصف لكيفية أن المسؤولية نفسها مُوزَّعة عمدًا عبر الشبكة.
@BabylonLabs_io
#baby $BABY

ظننت أن العدد المثير للاهتمام هو مبلغ 40 مليار دولار في حجم تداول DEX. وبعد أن حدقت فيه لفترة، اتضح أنه أقل الأجزاء إثارة.
ما كان يجذبني للعودة هو مكان تواجد تلك السيولة فعليًا بالنسبة إلى نموذج أمان Babylon. يبدو حجم التداول مثيرًا للإعجاب وحده، لكن السيولة لا تصبح متينة إلا عندما يثق المشاركون بالبنية التحتية التي تقع تحتها. وهذا دفعني من لوحات معلومات الـ DEX إلى تصميم المُصدِّقين (validators)، وآليات الـ staking، ومناقشات الحوكمة.
كلما قارنتهما أكثر، شعرت بأن نشاط التداول ومعمارية الأمان يعالجان أجزاء مختلفة من المشكلة نفسها المتعلقة بالتنسيق.
يمكن لـ DEX معالجة مليارات الصفقات، لكن ذلك لا يعني تلقائيًا إنشاء سيولة مرنة. صانعو السوق والمُصدِّقون ومشاركو الحوكمة جميعهم يتفاعلون مع حوافز مختلفة. إذا ضعفت افتراضات الأمان أو أصبحت الحوكمة غير قابلة للتوقع، يمكن أن تختفي السيولة بسرعة أكبر بكثير مما وصلت إليه. القياس بحجم مرتفع يدل على النشاط. لا يقيس الثقة.
جعلتني Babylon أفكر في هذا التمييز بشكل مختلف. يجلب الـ staking على Bitcoin وزنًا اقتصاديًا، ويوفر المُصدِّقون ضمانات تشغيلية، وتحدد الحوكمة كيفية تطور تلك الضمانات مع مرور الوقت. لا تزيد أي من هذه الأجزاء بشكل مباشر حجم التداول، ومع ذلك فإنها معًا تؤثر في ما إذا كان مزودو السيولة مرتاحين للبقاء خلال فترات عدم اليقين بدلًا من الظهور فقط عندما تكون الظروف مواتية.
بدأت بالنظر إلى إحصائية تداول. وانتهى بي الأمر إلى إيلاء اهتمام أكبر بكثير للتنسيق المطلوب لجعل تلك الإحصائية مستدامة، لأن البنية التحتية غالبًا ما تصبح مرئية فقط بعد أن يتوقف السوق عن اعتبارها أمرًا مسلمًا به.
@BabylonLabs_io
#baby $BABY

واصلت القراءة حتى غيّر تفصيل صغير واحد الصورة بأكملها. لم يكن الأمر هو معرّف الالتزام الخاص بالإصلاح نفسه. بل كان التوقع الهادئ بأن كل ما أُضيف بعد تلك الإصلاحات يرث تلقائياً الافتراضات الأمنية نفسها. بدا هذا التساؤل أكبر من مجرد التصحيح.

بدأت أتعقّب ما يحدث بعد التزامات الإصلاح بدل أن أقرأ الثغرة التي جاءت قبلها. ثم قارنت عمليات التنفيذ اللاحقة مع البنية المحيطة لأرى هل كانت الميزات الجديدة مُقيّدة فعلاً بنفس الافتراضات التي كُتبت من أجلها الإصلاحات. أخذت فنجان قهوة وعدت عبر سجلّ المستودع لأن التسلسل كان أكثر أهمية من التغييرات الفردية.

عندها صار من الصعب تجاهل شيء ما. يغلِق التزام الإصلاح مسار فشل معيّن، لكن كل ميزة تُضاف بعد ذلك تُنشئ تفاعلات جديدة لم تكن الحجّة الأمنية الأصلية قد غطّتها صراحةً. منطقيّاً من الناحية الميكانيكية أن ذلك يحدث لأن التطوير لا يمكن أن يتوقف بعد كل إصلاح. لكن بنيوياً يروي قصة مختلفة. تبدأ الأمانة بالاعتماد بدرجة أقل على ما إذا كان العيب القديم قد اختفى، وأكثر على ما إذا كانت كل عملية تنفيذ جديدة ما تزال تحترم الحدود التي أرستها الإصلاحات بهدوء.

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

ربما هذا مقصود. ربما يجعل التطوير المستمر هذا التنازل أمراً لا مفرّ منه، لا ضعفاً. ما زلت أحاول أن أحدد ما إذا كانت المعلم الأمني الحقيقي هو التزام الإصلاح نفسه، أم أول ميزة تنجح بالفعل في إثبات أن تلك الافتراضات ما تزال قائمة بعد أن يتغيّر البروتوكول مرة أخرى.
@BabylonLabs_io
#baby $BABY

اعتقدت أن الجزء المثير للاهتمام سيكون حوافز المُصدِّقين. اتضح أنها جملة قانونية واحدة تقول إن النزاعات تُحكم وفقًا لقوانين جزر كايمان. كدت أتجاوزها، لكن بعد أن قرأت وثائق البروتوكول مرة أخرى بدأت أشعر أنها مرتبطة بكل ما عداها.
يُبذل في بابل قدرًا كبيرًا من الجهد لتقليل مستوى الثقة على مستوى البروتوكول. فالرهان المدعوم من بيتكوين، ومسارات الاسترداد المُهيكلة، وتنسيق المُصدِّقين، والمسؤوليات المُعرَّفة بعناية—كل ذلك يدفع القرارات نحو الكود بدلًا من المشغّلين الأفراد. ثم تُعرِّف المستندات القانونية بهدوء طبقةً مختلفة تمامًا من التنسيق في الحالات التي لا يعود فيها الكود هو الذي يُسوي النتيجة.
غيّر ذلك نظرتي إلى العبارات المتكررة التي تحد من مسؤولية أطراف بابل. في البداية تعاملت معها باعتبارها صياغة قانونية اعتيادية. لكن قراءتها إلى جانب بند الاختصاص والهيكل المعماري للبروتوكول جعلها تبدو أكثر كحدود تفصل بين نظامين. أحدهما يتولى معالجة السلوك المتوقع عبر قواعد تشفيرية. والآخر يتولى معالجة الحالات غير المتوقعة عبر إطار قانوني محدد.
ما برز لي هو أن اللامركزية لا تُزيل الحاجة إلى الاختصاص. بل تُضيّق عدد اللحظات التي يصبح فيها الاختصاص ذا صلة. كل تحسين في تصميم البروتوكول يقلل من الحالات التي تتطلب تفسيرًا بشريًا، لكنه لا يُلغيها أبدًا إلى الصفر.
دخلت في الوثائق متوقعًا أن أتعلم كيف توزّع بابل الأمان عبر المُصدِّقين. لكنني خرجت وأفكر بقدرٍ مماثل في كيفية توزيع المسؤولية عبر القواعد التقنية والاتفاقيات القانونية. تبدو هاتان الطبقتان مستقلتين إلى أن تقرأهما معًا، وعندها تبدأان في وصف البنية نفسها من اتجاهين مختلفين.
@BabylonLabs_io
#baby $BABY

اعتقدت أن الجزء المثير للاهتمام هو الوعد بعدم الحاجة إلى أي اتحاد من المُوقّعين لإطلاق الأموال. واتضح أن الأمر يتعلق بما الذي يزيله ذلك من النظام أكثر مما يضيفه.
كنت أُقارن باستمرار بين تصميم الاستيكينغ في Babylon وبين اللغة القانونية المتعلقة بالمسؤولية وبنية البروتوكول. في البداية بدا أن هذه مستندات غير مترابطة. وبعد قراءتها معًا، بدأت تصف الفكرة نفسها من زوايا مختلفة.
عندما يعتمد البروتوكول على اتحاد، فلابد في النهاية من شخص ما أن يُنسّق إدارة المفاتيح وتوافر المُوقّعين والترقيات والاستجابات للطوارئ. حتى إذا كانت التشفيريات سليمة، فإن التشغيل ما يزال يعتمد على بقاء مجموعة ما تعمل. وهذا يخلق مؤسسة داخل ما يُفترض أن يكون بنية تحتية.
يبدو أن Babylon تُكلّف نفسها بقدر مدهش من جهود التصميم لتفادي هذا الاعتماد التشغيلي. يتم إطلاق الأموال وفق قواعد البروتوكول بدل انتظار قيام لجنة ما بذلك. وهذا يغيّر نوع المخاطر التي يتحملها المشاركون. بدل التساؤل عمّا إذا كان المُوقّعون سيتعاونون، يتجه التركيز إلى ما إذا كانت قواعد البروتوكول ونهائية بيتكوين وسلوك المُدققين تظل متوافقة مع مرور الوقت.
كما أن البيان الذي ينص على أن أطراف Babylon ليست مسؤولة عن نتائج مختلفة أصبح أكثر منطقية بعد النظر إلى البنية. إذا لم يتحكم اتحاد في عمليات الإطلاق، فهناك ببساطة مساحة أقل للتدخل التقديري عندما يحدث شيء ما. البروتوكول، عمدًا، يمنح نفسه فرصًا أقل للتدخل.
بدأت قراءة المستندات متوقعًا نقاشًا حول الحيازة. وانتهيت إلى الاعتقاد بأن الأمر في الحقيقة يتعلق بإزالة مسؤوليات التنسيق التي غالبًا ما تبقى غير مرئية حتى يوم تفشل.
@BabylonLabs_io
#baby $BABY $BANK $LAB

اعتقدت أن الجزء المثير للاهتمام سيكون بروتوكول التحدّي. لكن اتضح أن الأمر يتعلق بتكلفة الاستعداد للتحديات التي لا تكاد تحدث.
كنت أعود باستمرار إلى الملاحظة بأن التكلفة الأساسية خارج السلسلة تتمثل في توليد دوائر مشوّهة وتخزينها لاحتمالات النزاعات. في البداية بدا ذلك كأنه مجرد تفاصيل تنفيذية. كلما جلست معه مدة أطول، زاد شعوري بأن البروتوكول يُنقل موضع الأمان حيث “يعيش” فعليًا.
ينظر معظم الناس إلى تسوية بيتكوين لأنها الجزء المرئي. ما جذب انتباهي هو كل ما يوجد قبل أن تصبح التسوية ضرورية. يتعين على المشغّلين إنفاق الحوسبة والتخزين للبقاء جاهزين لتحدّي قد لا يأتي أبدًا. لا تُنتج هذه الموارد أي إيراد مباشر، ومع ذلك فإن غيابها يجعل تهديد التحقق أقل مصداقية.
هذا يغيّر الاقتصاديات بطريقة دقيقة. لا يطلب البروتوكول من المشاركين إثبات كل شيء طوال الوقت. بل يطلب منهم الاستثمار بشكل مستمر في القدرة على إثبات شيء ما إذا تم الطعن فيه. وبالقراءة جنبًا إلى جنب بين آلية التحدّي في Babylon والتسوية النهائية في بيتكوين، يبدأ نموذج الأمان في الظهور بشكل أقل كونه تحققًا مستمرًا وأكثر كونه الحفاظ على جاهزية ذات مصداقية.
كما يفسّر أيضًا لماذا تستحق البنية التحتية خارج السلسلة اهتمامًا بقدر ما تحظى به الأنشطة داخل السلسلة. تصبح التخزين الفعّال وإدارة البيانات الموثوقة والانضباط التشغيلي جزءًا من نموذج الثقة بهدوء، رغم أن أيًا منها لا يظهر في مُستكشف الكتل.
بعد أن قرأته عدة مرات، توقفت عن التفكير في توليد الإثبات باعتباره ميزة تشفيرية. بدا أقرب إلى كونه تكلفة تشغيلية مستمرة للحفاظ على خيار التحقق حيًا.
@BabylonLabs_io
#baby $BABY

ظننت أن الجزء المثير هو زاوية الذكاء الاصطناعي. لكن اتضح أن الأمر يتعلق بتوقيت القرارات بدلًا من ذلك.
بعد قضاء وقت في مقارنة مستكشف نيوتن ومعماره وكيف يتعامل RedStone مع تسليم البيانات، كنت أعود في كل مرة إلى تفصيل واحد. ما زالت معظم أنظمة البلوك تشين تفترض أن اللحظة المهمة هي عندما تصل المعاملة إلى السلسلة. كل ما قبل ذلك يُعامل كمجرد إعداد.
يبدو أن نيوتن ينقل الانتباه إلى وقت أبكر.
إذا جرى تقييم السياسات قبل التنفيذ بينما يوفّر RedStone بيانات خارجية حديثة فقط عند الحاجة الفعلية إليها، فإن البروتوكول لا يقوم فقط بالتحقق من المعاملات. بل يقرر ما إذا كان ينبغي أصلاً أن تتحول خطوة ما إلى معاملة في ظل الظروف الحالية.
قد يبدو ذلك دقيقًا، لكنه عمليًا يغيّر مكان تعيش المخاطر.
الخزائن الآلية والأدراج التلقائية ووكلاء الذكاء الاصطناعي غالبًا ما يفقدون الكفاءة لأنهم يتفاعلون بعد تغيّر المعلومات. عندها تكون المعاملة بالفعل منافِسة على مساحة الكتل، والأسعار تكون قد تحركت، أو تكون الحدود الداخلية قد تجاوزت قيمًا مسموحًا بها بالفعل. نقل تقييم السياسات إلى أقرب ما يمكن من البيانات الحية يقلل الفجوة بين ملاحظة العالم واتخاذ القرار بشأنه.
كما أن المستكشف يجعلني أفكر بشكل مختلف في مؤشرات النشاط. إن احتساب عمليات التنفيذ الناجحة لا يقول الكثير إذا كانت قرارات كثيرة يتم تصفيتها عمدًا قبل أن تصل إلى السلسلة. انخفاض حجم التنفيذ لا يعني تلقائيًا انخفاض الاستخدام، خصوصًا عندما يكون تصميم البنية التحتية يهدف إلى منع الإجراءات غير الضرورية بدلًا من تعظيمها.
كلما نظرت أكثر، قلّ شعوري بأنها مجرد قصة أتمتة أخرى.
لقد بدت كأنها بنية تحتية تعتبر الحكم جزءًا من التنفيذ بدلًا من شيء يُتوقع من المستخدمين توفيره بأنفسهم، وهي تغيّر بهدوء مكان حدوث التنسيق قبل وقت طويل من إنتاج الكتل.
@NewtonProtocol
#newt $NEWT

كلما أمضيت وقتًا أطول على السلسلة (onchain)، كلما لاحظت أن الثقة غالبًا ما تختفي قبل وقت طويل من تحريك الأموال.
تركز معظم المحادثات حول الامتثال على حجب المعاملات أو تجميد المحافظ. لكن الاحتكاك الحقيقي غالبًا يبدأ في وقت أبكر بكثير. تتردد الفرق قبل إرسال رأس المال. يقوم صانعو السوق بالتأكد من الأطراف المقابلة مرتين. ويطلب مديرو الخزينة بهدوء من شخص ما التحقق من العنوان مرة إضافية. لقد جعلت العملات المشفرة هذه الانقطاعات الصغيرة أمرًا طبيعيًا حتى أصبحت جزءًا من العمليات اليومية. تكيف الناس بصمت مع تجربة استخدام سيئة دون أن يتساءلوا فعلًا عن سبب أن كل تحويل يحمل طبقة أخرى من عدم اليقين.
هذا ما جعلني أفكر بطريقة مختلفة حول كيفية تعامل المشاريع مع البنية التحتية. لفتتني بروتوكول نيوتن لأن اهتمامه لا يتمثل في إزالة الثقة، بل يبدو أنه يسعى لتقليل عدد الافتراضات التي يجب على الناس أن يضعوها قبل أن يتخذوا أي إجراء.
ومن الأمثلة على ذلك استخدام رؤى Chainalysis لفهم ما إذا كان العنوان مرتبطًا بعقوبات US OFAC. على الورق يبدو هذا كميزة امتثال. لكن في الواقع يغيّر شيئًا أكثر عادية بكثير. بدلًا من أن يبني كل مشارك عملية تحقق مجزأة خاصة به، يمكن أن يصبح جزء من هذا القرار جزءًا من سير العمل نفسه. التحول المثير للاهتمام ليس أن المخاطر تختفي. بل أن عددًا أقل من الأشخاص يحتاج إلى التوقف وإعادة صياغة نفس الحكم يدويًا في كل مرة.
بدأت أتساءل عما إذا كانت أكبر أوجه القصور في العملات المشفرة لم تكن أبدًا مرتبطة فقط بالإنتاجية أو بتكاليف المعاملات. ربما كانت مخبأة داخل كل اللحظات غير المرئية التي يتوقف فيها المشغلون، يبحثون، يتحققون، ويأملون أنهم لم يفوتوا شيئًا.
قد يفهم بروتوكول نيوتن الإرهاق التشغيلي أفضل من معظم الجهات. ليس لأنه يزيل عدم اليقين، بل لأنه يعامل عدم اليقين كجزء من البنية التحتية بدلًا من ترك كل مشارك يحل هذه المشكلة بمفرده.
@NewtonProtocol
#newt $NEWT

بينما كنت أقرأ @NewtonProtocol today، كانت فكرة واحدة تلازمني باستمرار.
يُحبّ عالم العملات المشفرة الإعلان عمّا تمّ بناؤه.
لكن السوق يهتمّ بكثير أكثر بما يمكنه الشعور به فورًا.
وهذان الأمران مختلفان تمامًا.
يمكن لإطار تفويض جديد أن يجعل البروتوكول أكثر موثوقية دون أن يجعل الرمز أكثر إثارة بين ليلة وضحاها.
ولا تُنتج مُحرك سياسة أفضل التأثير نفسه الذي يخلقه إدراج مفاجئ أو ارتفاع سريع في حجم التداول.
ليس ذلك لأن التكنولوجيا تفتقر إلى القيمة.
بل لأن الموثوقية يصعب ملاحظتها عندما يعمل كل شيء كما هو متوقع.
نادراً ما يحتفل الناس بالمعاملة التي فشلت لأسباب صحيحة.
بل يحتفلون بالتي جلبت لهم المال.
وهذا يخلق تحديًا مثيرًا للاهتمام لمشاريع مثل $NEWT .
إذا نجح البروتوكول، فإن جزءًا كبيرًا من أفضل أعماله يحدث بهدوء في الخلفية.
تنفّذ السياسات.
يتم فحص الأذونات.
يقلّ الخطر.
ولا يحدث شيء درامي.
والأمر الساخر أن هذا النوع من النجاح ينتج عناوين أقل بكثير من بروتوكول يستعيد نفسه بعد فشل.
بدأت أتساءل عما إذا كانت رموز البنية التحتية تواجه مشكلة في الظهور أكثر من كونها مشكلة تقنية.
كلما تقوّت القاعدة، قلّ وضوح مساهمتها من الخارج.
الماركت بطبيعتها تكافئ الأحداث الظاهرة.
البنية التحتية تُوجد ثقة غير مرئية.
وهذه أشكال مختلفة تمامًا من القيمة.
ربما لهذا السبب تبدو عملية تقييم مشاريع مثل Newton غير مريحة.
الرسم البياني يقيس الانتباه.
والبروتوكول يحاول بناء الثقة.
قد يظهر الانتباه خلال يوم.
أما الثقة فعادةً ما تستغرق وقتًا أطول بكثير.
لست مقتنعًا بأن السوق يخطئ في تسعير Newton.
أظن فقط أنه يقيس شيئًا مختلفًا عمّا يحاول البنّاؤون تحسينه.
@NewtonProtocol
#newt $NEWT

توقفت عن النظر إلى نيوتن كـ«بروتوكول». وبدأت أفهمه أكثر كـ«معيار».
أعتقد أننا كنا نُمعن النظر إلى مشاريع مثل هذه من خلال عدسة خاطئة.
كل بلوكشين جديد، ومحفظة، وتطبيق DeFi يريدان تبنّيًا.
لكن المعايير لا تطارد التبنّي.
إنها تنتشر بهدوء حتى يبدأ الجميع في البناء حولها.
هذه هي الفَرْقـة التي أعود إليها باستمرار مع نيوتن.
قد لا يكون لقيمته طويلة الأمد علاقة كبيرة بمدى تعرف الناس باسمه.
السؤال الأكبر هو ما إذا كان المطورون في نهاية المطاف يصلون إلى نقطة يشعرون عندها بأن البناء دون طبقة تفويض مشتركة صار أمرًا عتيقًا.
فكّر فيما حدث مع معايير التوكن.
لا أحد يسأل بعد الآن ما إذا كان تطبيقٌ ما «يستخدم» معيارًا للتوكن.
إنه أمر مُتوقع فحسب.
أصبح المعيار جزءًا من الأساس.
أتساءل إن كانت التفويض يتجه في الاتجاه نفسه.
ومع ازدياد شيوع وكلاء الذكاء الاصطناعي، ستواجه كل بروتوكول التحدّي نفسه.
كيف تُعرّف ما الذي يُسمح للنظام المستقل بفعله؟
وكيف تُحدّث تلك القواعد دون إعادة بناء كل شيء؟
كيف تعتمد التطبيقات المختلفة على افتراضات الأمان نفسها؟
إذا حلّت كل مجموعة تلك الأسئلة بشكل مستقل، يصبح النظام البيئي مُجزّأ.
لكن إذا شاركت الجميع إطار التفويض ذاته، تصبح الطبقة الكاملة أكثر اتساقًا.
لهذا السبب لا أرى فرصة نيوتن كإنشاء ميزة أخرى.
أراها كتقليل مقدار البنية التحتية التي سيضطر كل تطبيق مستقبلي إلى اختراعها لنفسه.
الجزء المثير للاهتمام هو أن النجاح سيجعل نيوتن أقل وضوحًا، لا أكثر.
سيتوقف المطورون عن الحديث عن طبقة التفويض لأن وجودها سيصبح أمرًا بديهيًا.
تُظهر لنا التاريخ أن أقوى البنى التحتية نادرًا ما تصبح مشهورة.
إنها تصبح متوقعة.
إذا وصل نيوتن إلى تلك المرحلة، فلن يكون أكبر إنجاز له هو جذب الانتباه.
بل سيجعل التفويض يبدو أمرًا عاديًا إلى درجة أن أحدًا لن يفكّر بعد الآن في بنائه من الصفر.
@NewtonProtocol
#newt $NEWT

لقد بدأت ألاحظ شيئًا غريبًا أثناء الاطلاع على البنية التحتية للعملات المشفرة.
نقضي وقتًا كبيرًا في قياس ما يتم دمجه.
تقريبًا لا أحد يقيس ما يتم كشفه فعليًا.
يبدو أن هذا هو الشيء نفسه.
لا أعتقد ذلك.
خذ بروتوكول نيوتن (NEWT) كمثال.
عندما يسمع الناس أن محافظ أو تطبيقات أو بروتوكولات تقوم بدمج بنية تحتية جديدة، تكون الافتراضات أن كل مستخدم يستفيد منها فورًا.
لكن البنية التحتية لا تتصرف مثل تحديث برمجيات.
إنها أقرب إلى الكهرباء.
يمكن توصيل مبنى بالشبكة بينما لا تزال الغرف بأكملها أضواءها مطفأة.
يشبه ذلك حال العملات المشفرة.
قد يدعم تطبيقٌ بنية تحتية متقدمة بينما تبقى الميزات الفردية غير مرئية ما لم يقم المطور بتعريضها عمدًا.
وهذا يخلق ديناميكية سوقية مثيرة للاهتمام.
تنتقل الإعلانات فورًا.
ينمو الظهور ببطء.
يحتفل المستخدمون بمعالم الدمج طويلًا قبل أن يتفاعلوا فعليًا مع الوظائف التي أطلقتها تلك المعالم.
لذا أتساءل ما إذا كنا نقيس التبنّي بشكل عكسي.
بدلًا من السؤال: "كم مشروعًا تم دمجه؟"
ربما يكون السؤال الأفضل هو:
"كم مستخدمًا اختبره فعليًا اليوم؟"
يمكن أن تكون هذه الأرقام مختلفة بشكل كبير.
لهذا أعتقد أن الميزة التنافسية القادمة لن تكون مجرد بناء بنية تحتية أفضل.
بل ستكون جعل البنية التحتية لا يمكن تجاهلها.
لأن الوظائف المخفية تخلق قيمة مخفية.
والقيمة المخفية يصعب على الأسواق تسعيرها بشكل صحيح.
لقد جعلني النظر إلى NEWT أدرك أن التبنّي ليس حدثًا واحدًا.
بل له مرحلتان منفصلتان تمامًا.
تصل التكنولوجيا أولًا.
ويلحظ المستخدم ذلك لاحقًا بكثير.
قد ينتهي هذا الفجوة بين النشر والظهور لتصبح واحدة من أكثر أوجه القصور التي يتم تجاهلها في عالم العملات المشفرة.
@NewtonProtocol
#newt $NEWT