كيف تتمّ المحاسبة بين آلة وأخرى؟
كلما فكرت في هذا السؤال، ازددت اقتناعًا بأنه لا يمكن تجاهله. عندما يشتري الناس شيئًا، هناك منصة تضمن المعاملة وإجراءات لاسترداد الأموال. لكن إذا استدعى وكيلٌ واجهة API ولم تبلغ الخدمة المستوى المطلوب، بعد أن يكون المال قد دُفع، فلمن يلجأ؟
قدّمت Kite فكرةً: الدفع وفق مستوى الخدمة (Pay-on-SLA). يُدفع المبلغ بحسب مستوى الخدمة، وتُحتجز العملات المستقرة أولًا، ثم تُحوَّل الأموال بعد التحقق من إنجاز المطلوب. وإن لم يتحقق المستوى المطلوب، فلا تُحوَّل الأموال.
ما أقنعني ليس المصطلح التقني، بل الافتراض الذي ينطلق منه: حتى الآلات تحتاج إلى آلية لبناء الثقة فيما بينها. فهو لا يفترض أن الآلات موثوقة دائمًا. هذا الافتراض أكثر صدقًا من مشاريع كثيرة تبدأ بالحديث عن الكفاءة.
وماذا عن المعاملات الصغيرة والمتكررة؟ يمكن استخدام قنوات الدفع المصغر، مع تسجيل المعاملات خارج السلسلة وتسويتها دوريًا. وإلا فسيكون تسجيل كل استدعاء على السلسلة مكلفًا برسوم تتجاوز تكلفة الخدمة نفسها، فضلًا عن أن زمن التأخير لا يُحتمل. هذا النهج ليس جديدًا، لكنه ضرورة في سياق الوكلاء.
بدأت أتخيل المشهد: وكيل يستعين بوكيل آخر للبحث عن بيانات، وكل معاملة لا تكلف سوى بضعة سنتات، وتتكرر عدة مرات في الثانية، من دون أي تدخل بشري. أنظمة الدفع التقليدية لا تستطيع استيعاب هذا النوع من التدفق، ومعظم سلاسل الكتل الحالية بالكاد تستطيع ذلك.
والخطوة التالية هي توزيع الإيرادات. في المهمة الواحدة، ينبغي أن يحصل مزوّد البيانات ومزوّد النموذج والعقدة على حصصهم، وهنا يأتي دور Proof of Attributed Intelligence في تحديد مصدر الإسهام. إن تعذّر قياس المساهمات بدقة، فلن يتمكن النظام البيئي من الاحتفاظ بمزوّدي الخدمات. وإذا رحلوا، توقفت عجلة النمو. $BTC
بالطبع، التصميم شيء والتطبيق شيء آخر. ما المقصود بـ«تحقيق المستوى المطلوب»؟ ومن يقرره؟ وكيف تُحكَم النزاعات؟ هذه هي العقدة الأصعب.
سأُبقي هذه الأسئلة مفتوحة الآن، وأواصل متابعة هذا المسار.
#KiteBBW $KITE
كلما فكرت في هذا السؤال، ازددت اقتناعًا بأنه لا يمكن تجاهله. عندما يشتري الناس شيئًا، هناك منصة تضمن المعاملة وإجراءات لاسترداد الأموال. لكن إذا استدعى وكيلٌ واجهة API ولم تبلغ الخدمة المستوى المطلوب، بعد أن يكون المال قد دُفع، فلمن يلجأ؟
قدّمت Kite فكرةً: الدفع وفق مستوى الخدمة (Pay-on-SLA). يُدفع المبلغ بحسب مستوى الخدمة، وتُحتجز العملات المستقرة أولًا، ثم تُحوَّل الأموال بعد التحقق من إنجاز المطلوب. وإن لم يتحقق المستوى المطلوب، فلا تُحوَّل الأموال.
ما أقنعني ليس المصطلح التقني، بل الافتراض الذي ينطلق منه: حتى الآلات تحتاج إلى آلية لبناء الثقة فيما بينها. فهو لا يفترض أن الآلات موثوقة دائمًا. هذا الافتراض أكثر صدقًا من مشاريع كثيرة تبدأ بالحديث عن الكفاءة.
وماذا عن المعاملات الصغيرة والمتكررة؟ يمكن استخدام قنوات الدفع المصغر، مع تسجيل المعاملات خارج السلسلة وتسويتها دوريًا. وإلا فسيكون تسجيل كل استدعاء على السلسلة مكلفًا برسوم تتجاوز تكلفة الخدمة نفسها، فضلًا عن أن زمن التأخير لا يُحتمل. هذا النهج ليس جديدًا، لكنه ضرورة في سياق الوكلاء.
بدأت أتخيل المشهد: وكيل يستعين بوكيل آخر للبحث عن بيانات، وكل معاملة لا تكلف سوى بضعة سنتات، وتتكرر عدة مرات في الثانية، من دون أي تدخل بشري. أنظمة الدفع التقليدية لا تستطيع استيعاب هذا النوع من التدفق، ومعظم سلاسل الكتل الحالية بالكاد تستطيع ذلك.
والخطوة التالية هي توزيع الإيرادات. في المهمة الواحدة، ينبغي أن يحصل مزوّد البيانات ومزوّد النموذج والعقدة على حصصهم، وهنا يأتي دور Proof of Attributed Intelligence في تحديد مصدر الإسهام. إن تعذّر قياس المساهمات بدقة، فلن يتمكن النظام البيئي من الاحتفاظ بمزوّدي الخدمات. وإذا رحلوا، توقفت عجلة النمو. $BTC
بالطبع، التصميم شيء والتطبيق شيء آخر. ما المقصود بـ«تحقيق المستوى المطلوب»؟ ومن يقرره؟ وكيف تُحكَم النزاعات؟ هذه هي العقدة الأصعب.
سأُبقي هذه الأسئلة مفتوحة الآن، وأواصل متابعة هذا المسار.
#KiteBBW $KITE