MeeR⁰⁰⁷

في يومٍ ما أكملتُ طلبًا إلكترونيًا بشكلٍ مثالي، ثم فقدتُ النتيجة لأنني فاتتني عملية تأكيد أخيرة واحدة.

غيّرت هذه الإحباط الصغير طريقة تفكيري في مخاطر التفعيل داخل @BabylonLabs_io ’s Trustless Bitcoin Vaults.

يمكن لخزانة أن تُكمل الإعداد، وتصل إلى حالة Verified، ومع ذلك تظل غير قابلة للاستخدام حتى يكشف المودِع سر التفعيل الذي تم الالتزام به سابقًا عبر hashlock.

تقنيًا، هذا تصميمٌ ذكي.

فهو يربط موافقة جهة Ethereum بالمعاملة الصحيحة من جهة Bitcoin ويمنع تقدم الخزانة في ظل حالة غير متطابقة.

لكن ذلك يخلق أيضًا اعتمادًا أكثر هدوءًا.

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

ليس من الضروري أن تفشل الأمور بشكلٍ تشفيري.

لا يتعين سرقة أي BTC.

ومع ذلك، يمكن للمستخدم أن يفقد سبب فتح الخزانة من الأساس.

وهذا مهم بالنسبة لـ $BABY لأن أمن البروتوكول ليس فقط للحفاظ على قابلية الاسترداد. بل يتعلق أيضًا بمدى قدرة المستخدمين العاديين على إكمال الخطوة الأخيرة بشكل موثوق قبل أن تختفي الفرصة.

قد يكون @BabylonLabs_io قد حلّ الفشل الخطِر: فقدان البيتكوين.

والاختبار الأصعب للمنتج هو حل الفشل المعتاد: فقدان الوقت عند آخر ميل.

يجب أن تنجو المنظومة عديمة الثقة من المهاجمين.

ويجب أيضًا أن تنجو المنظومة القابلة للاستخدام من المستخدمين المشتتين.
@BabylonLabs_io #baby $BABY

مرةً حجزت خدمة قبل أشهر لأن السعر بدا مناسبًا.

وفي وقت تنفيذ العمل، كان كل ما حوله من تكاليف قد تغيّر. لكن اتفاقي لم يتغيّر.

هذا جعلني أتساءل إن كان السعر الثابت يحافظ أيضًا على الاهتمام الثابت.

قد توجد نفس هذه التوترات داخل عمولة مزوّد حسابات “Vault” التابعة لـ@BabylonLabs_io .

عند إنشاء حساب “vault”، تُضمَّن عمولة المزوّد داخل معاملات صرف مسبقة التوقيع (pre-signed payout transactions). يحصل المستخدم على يقين بالسعر قبل الالتزام بالـBTC، ولا يستطيع المزوّد رفع السعر لاحقًا.

هذا يحمي المودِع.

لكنّه أيضًا يُجمِّد مكافأة اسمية مقابل التكاليف الواقعية المتغيّرة.

قد يبقى الـvault نشطًا بينما ترتفع رسوم بيتكوين، ويصبح البنية التحتية أكثر تكلفة، وتزداد متطلبات المراقبة، أو يرتفع نشاط الاسترداد. يظل المزوّد مُعوَّضًا وفقًا للافتراضات التي أُجريت عند الإنشاء.

يمكن للبروتوكول أن يحافظ على الدفعة كما هي تمامًا.

لكن لا يمكنه ضمان أن تبقى الدفعة بنفس القيمة.

لا شيء يحتاج إلى أن “يتعطل” بشكل تشفيري. الخطر الأكثر هدوءًا هو أولوية اقتصادية: قد تقدم الـvaults الأحدث حوافز أفضل، بينما تصبح الـvaults الأقدم أقل جاذبية للمراقبة والدعم بنفس درجة الاستعجال.

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

$BABY يجب أن يحمي طرفي الاتفاق: ما الذي يُوعد به المستخدم، ولماذا يظل المزوّد متحفزًا لتقديمه.

سيحكم معظم الناس على العمولة عند لحظة الدخول.

والاختبار الأصعب يأتي بعد وقت طويل:

هل يمكن لـBabylon تجميد السعر دون أن يتراجع الحافز؟
@BabylonLabs_io #baby $BABY

يمكن للمفتاح أن يحمي غرفة واحدة بشكلٍ مثالي، ومع ذلك يصبح عديم الفائدة عندما تحتاج إلى الغرفة المجاورة.

لقد قيّمت عزل تطبيق بابل من خلال المنفعة الأمنية أولًا. يتم إرفاق خزانة BTC بتطبيق واحد عند إنشائها، لذلك لا ينبغي لخلل أو فشل سياسة في مكانٍ آخر أن ينتشر تلقائيًا إليها. تبدو هذه الحدود منطقية بجانب نظامٍ يمكن فيه لثغرة واحدة أن تنتقل بخلاف ذلك عبر عدة منتجات مترابطة. @BabylonLabs_io

لكن الفائدة الواضحة ليست هي المقايضة الكاملة.

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

إذا دعم BABY في النهاية العديد من التطبيقات، فهل يحافظ هذا العزل على تحكم المستخدم، أم يخلق بركًا منفصلة من BTC تكون من الناحية التقنية ذاتية الحراسة لكن يصعب إدارتها ونقلها عمليًا؟ وعندما تتطلب كل عملية تكامل مُعدّات (adapters) خاصة بها ومشاركين وإعداد خزانة، هل ينتج BABY حدودًا أكثر أمانًا—أم يعيد تكرار عبء التنسيق نفسه حول كل وجهة جديدة؟

بعض الاحتكاك طبيعي. قد لا يكون من الممكن أصلًا تقديم ضمانات محمولة دون مشاركة المخاطر، ولا يُعد العزل خيارًا للاحتجاز (lock-in) تلقائيًا.

الاختبار الحقيقي هو الحماية مقابل تكلفة الخروج. ينجح بابل إذا احتوت حدوده على حالات الفشل دون حبس المستخدمين داخل خيار الأمس. أنا أراقب ما إذا كان أكثر جدار في BABY أمانًا سيصبح بهدوء أصعب جدار يمكن تركه.
@BabylonLabs_io #baby $BABY

هاتفي يمكنه عرض رسالة على أنها مُسلَّمة حتى عندما لا يكون أحد قد قرأها بعد. التسمية ليست خاطئة. إنها ببساطة تصف مرحلة واحدة من عملية أطول.

ظل هذا التمييز يعود لي مرارًا بينما كنت أقرأ عن @BabylonLabs_io وشِبْاكاتهم لِـ Trustless Bitcoin Vaults.

يحتاج Aave إلى حدوث التصفية بسرعة. في تصميم TBV الحالي لدى Babylon، بمجرد أن تصبح إحدى المراكز غير صحية، يمكن لمُصَفٍّ بلا إذن (permissionless liquidator) سداد الدين واستلام WBTC فورًا عبر موفّر سيولة للتصفية (Liquidation Liquidity Provider). لكن البيتكوين الأصلي لا يتحرك في تلك اللحظة نفسها. يدخل الخزنة المُصادَرة إلى الضمان (escrow)، ثم يحصل عليها لاحقًا وسيط تحكيمي (arbitrageur) مُعتمد، وتستمر عملية الاسترداد على جانب البيتكوين عبر آلية تعتمد على التحدّي (challenge-based process) قد تستغرق أيامًا.

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

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

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

التنفيذ الحالي ما يزال على الشبكة التجريبية العامة، بينما تبقى تفاصيل المخاطر والإعدادات المهمة ضمن عملية الحوكمة.

ربما لا يكون السؤال الحقيقي بالنسبة إلى Babylon هو ما إذا كان بإمكانه جعل البيتكوين يتحرك بشكل أسرع.

هل يمكن لـ BABY أن يجعل سرعتي تسوية مختلفتين تبدوان كمنظومة واحدة موثوقة؟
@BabylonLabs_io $BABY #baby

ذات مرة جهزت كل شيء للرحلة، ومع ذلك نسيت الوثيقة الوحيدة التي جعلت الباقي بلا فائدة. المشكلة لم تكن في الرحلة نفسها. كانت في الإعداد.

هذا بالضبط هو التحول الذي تفرضه خزائن بابل علينا التفكير فيه. العمل الحقيقي لا يحدث بعد قفل الـ BTC. يجب أن يكتمل قبل ذلك. السداد والتصفية والاسترداد وحل النزاع — هذه ليست قرارات تُتخذ تحت ضغط. إنها مسارات مُعدّة مسبقًا داخل مخطط معاملات (graph)، وموقعة مسبقًا، وغير قابلة للتغيير، ومُنفَّذة عبر سكربت البيتكوين نفسه. بمجرد تفعيل الخزنة، لا يستطيع النظام ابتكار نتائج جديدة. بل يمكنه فقط السير في مسار كان مُجهزًا مسبقًا.

الكلمة التي أعود إليها هنا هي “الإنفاذ المُسبق” (pre‑enforcement).

معظم نماذج الأمان تفرض القواعد في لحظة التنفيذ. بابل تحرك الإنفاذ إلى الوراء في الزمن. البروتوكول لا يسأل “هل هذه النتيجة صحيحة؟” أثناء عملية التصفية. بل يطرح هذا السؤال في مرحلة الإعداد، قبل أن تتحرك الـ BTC أصلاً. النتيجة هي انعدام الثقة دون سلسلة عقود ذكية. لكن المقابل هو أن التعقيد لا يختفي — بل ينتقل إلى مرحلة التحضير. كل نتيجة إضافية تعني فروعًا أكثر، وتواقيع أكثر، وأطرافًا أكثر يجب أن تتفق مسبقًا.

عندما تعمل الخزنة، يكون التحضير غير مرئي. هذا هو الهدف. لكن توقيع واحد مفقود، أو شرط قديم، أو فجوة في التنسيق يمكن أن يُسقط الوضعية كاملة قبل أن تتاح لمنطق إنفاذ بابل المتعلقة بـ $BABY فرصة التشغيل.

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

@BabylonLabs_io $BABY #baby

**ما أكبر عنق زجاجة لدى خزائن بابل؟**

يمكن أن يكون من السهل فتح الباب من الداخل بينما يبقى من الصعب الدخول إليه. هذا الفرق يزعجني باستمرار بشأن تصميم خزنة BABY.

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

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

سيركز معظم الناس على السحب لأن خسارة ما يثير الخوف. ومع ذلك، تكمن الضغوط الهادئة عند نقطة الدخول: التنسيق، وتوفر الأطراف، وربما حجب الإيداع. يمكن لـ BABY أتمتة الإنفاذ بعد الموافقة، لكن الموافقة نفسها قد لا تزال تحمل قوة بشرية.

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

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

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

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

اعتدت أن أعتقد أن اختيار حزمة سياسات مُسمّاة كان كافيًا لمعرفة ما الذي سينفذه مشغّلو @NewtonProtocol.

كان اسم واحد يبدو وكأنه مجموعة واحدة ثابتة من القواعد.
لكن كلما تعمقت، أصبح الأمر أكثر تعقيدًا.

قد توجد السياسة كمعرّف وحدة (module ID)، أو عنوان PolicyData، أو WASM CID، أو سجل نشر (deployment record)، أو مخططات متعددة (schemas)، أو وثيقة تنفيذ نهائية (final execution manifest). يمكن لكل مكوّن أن يكون صالحًا بذاته بينما يشير إلى إصدار مختلف.

وهذا يخلق مشكلة خفية: انحراف الـ manifest.
قد تعرض تطبيق للمستخدم سياسة واحدة، وقد يجمع VaultKit وحداته، وقد يقوم المشغّلون بتقييم المكوّنات المدرجة في وثيقة التنفيذ. لكن هل يمكن لـ Newton إثبات أن الثلاثة يمثّلون بالضبط نفس القواعد في تلك اللحظة؟

هذا السؤال مهم بعد انتهاء المعاملة بوقت طويل.
بعد أشهر، قد يحتاج المُراجع (auditor) إلى ما هو أكثر من اسم السياسة. قد يحتاج إلى الرمز البرمجي الدقيق، وإعدادات المزود (provider configuration)، والمخططات (schemas)، وسجل النشر (deployment record)، والطابع الزمني للتنفيذ (execution timestamp) وراء الموافقة.
قد يجعل تثبيت الإصدارات بشكل صارم هذا التاريخ أسهل لإثباته، لكنه قد يبطّئ التحديثات الضرورية. تُحسّن التحديثات التلقائية من الاستمرارية، لكنها قد تُضعف اليقين بشأن ما الذي تم تشغيله فعليًا.
ربما لا تتمثل القيمة الأهدأ في Newton Protocol في فرض السياسات وحده.

إنها ذاكرة السياسات (policy memory).
اسم السياسة يخبرنا بما كان مقصودًا.
يجب أن تثبت الـ manifest ما الذي تم تنفيذه فعلًا.
#newt $NEWT @NewtonProtocol

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

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

يفصل نيوتن الأمر إلى مِلخّصين: يلخّص “مِلخّص الإجماع” ما تتفق عليه الشبكة جماعيًا، ما يتيح تجميعًا نظيفًا. أما “المِلخّص الكامل” فيحفظ الأساس الفريد لكل مُشغِّل لتصويته—سجلّ يبقى طويلًا بعد اكتمال تأكيد الكتلة.

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

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

#newt $NEWT

⚖️ الإجماع أم المساءلة؟

@NewtonProtocol اعتدت أن أظن أن الجزء الصعب في سياسة DeFi هو كتابة القاعدة الصحيحة. ثم لاحظت مشكلة أعمق: كل بروتوكول يعيد بناء القواعد نفسها تقريبًا من البداية.

غالبًا ما تُعامل فحوصات الأهلية وحدود التحويل والتحكم في الوجهات وظروف المخاطر كأنها شيفرة معزولة. تقوم تطبيق واحد بكتابتها واختبارها. ثم يكرر تطبيق آخر العمل بفرضيات مختلفة ونقاط فشل مختلفة.

وهذا ما يجعل @NewtonProtocol مثيرًا للاهتمام لسبب سهل التغاضي عنه.

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

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

إذا استطاعت @NewtonProtocol جعل القواعد المختبرة قابلة للنقل عبر أنظمة متعددة، فقد يعتمد المطورون تدريجيًا على طبقة السياسة تحت منتجاتهم، وليس فقط على المنتج نفسه. عندها سيقوم بروتوكول Newton بتنسيق القواعد، لا مجرد فرضها.

ليس هذا النتيجة مضمونًا. لكن البنية التحتية تصبح صعبة الاستبدال بكثير قبل أن يلاحظ معظم الناس أنها أصبحت ضرورية.

#newt $NEWT

هل يمكن للسياسات القابلة لإعادة الاستخدام أن تصبح بنية تحتية لـ DeFi؟

@NewtonProtocol كنت أعتقد أن الجزء الأصعب في وكلاء الذكاء الاصطناعي هو إيقافهم قبل أن يرتكبوا خطأ.

الآن أظن أن المشكلة الأصعب قد تظهر بعد أن تكون العملية قد أُنجزت بالفعل.

بمجرد أن يتصرف وكيل، هل يمكن لأي شخص أن يشرح لماذا سُمح له بذلك؟
يمكن لسجل onchain العادي أن يُظهر المحفظة والمبلغ والعقد والطابع الزمني والنتيجة. هذا مهم، لكنه يجيب في الغالب عن سؤال واحد:

ماذا حدث؟

قد يحتاج التمويل اللامركزي القائم على الوكالة (Agentic DeFi) إلى إجابة ثانية:

لماذا كان هذا الإجراء مقبولاً في تلك اللحظة؟

هنا يصبح @NewtonProtocol مثيراً للاهتمام بالنسبة لي. قد لا تكون الطبقة الخفية مجرد صلاحية/إذن قبل التنفيذ. قد تكون أيضاً ذاكرة صلاحية بعد التنفيذ.

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

بدون تلك الذاكرة، قد يكون فعل الوكيل صحيحاً تقنياً لكنه يصير صعب الدفاع عنه لاحقاً.

معها، يترك النظام مساراً للعودة إلى قرار التنفيذ.

تدفع طبقة السياسات في Newton Protocol، وسجل التدقيق، والمساءلة عن المشغّل، وآلية حل النزاعات نحو هذا النوع من البنية.

ربما لا تتمثل المخاطرة المستقبلية فقط في قيام الوكلاء بتنفيذ إجراءات على السلسلة.

ربما تكون المخاطرة هي قيام الوكلاء بتنفيذ إجراءات دون ذاكرة لسبب ثقتنا بهم.

#newt $NEWT

يحتاج وكلاء الذكاء الاصطناعي في التمويل اللامركزي إلى أكثر من مجرد التنفيذ. ما الأهم؟