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

يتبع تصميم المدفوعات المنطق نفسه. فبدلًا من تسوية كل طلب على السلسلة، يفتح طرفان قناة، ويتبادلان آلاف التحديثات الموقّعة خارج السلسلة، ثم يغلقانها بمعاملة ثانية.

تشير الوثائق إلى زمن استجابة يقل عن 100ms، بتكلفة تقارب $1 لكل مليون طلب.
وهنا أود أن أراجع حماسي بشيء من التحفظ. تصف الوثائق أيضًا قواعد مشروطة، مثل خفض حد الوكيل عند ارتفاع التقلبات. وتتطلب قاعدة كهذه مدخلًا من مصدر بيانات خارجي، لكنني لم أجد من يزوّده أو ما الذي يحدث إذا كانت بياناته خاطئة. كذلك، فإن الأرقام الكبيرة لشبكة الاختبار (مئات الملايين من المعاملات) جاءت من بيئة اختبار، لذا لا تقول الكثير عن الطلب المتكرر على الشبكة الرئيسية، التي أُطلقت في 30 أبريل 2026.

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

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

#KiteBBW $KITE @KITE AI 中文 #KiteBBW