ما الذي يمكن أن تتعلمه أرك من تقنية لايتنينج؟ اكتشف الآن!

يُعَدّ Ark البروتوكول الرئيسي الثالث من طبقة 2 الذي يتركز على آلية خروج أو تنفيذ أحادية الجانب في الطبقة الأساسية للاستعداد للإطلاق على شبكة البتكوين. كانت شبكة Lightning أول من أطلق عندما تم تفعيل C-Lightning في حملة Reckless عام 2018، ثم تلتها Statechains في عام 2021 عندما أُطلِق محفظة Mercury، والآن يقترب تنفيذ محفظة Ark Lab القادمة، Arkade، من تحقيق الهدف نفسه.

ميزانية clArk ومتطلبات التعاون

يحتوي clArk على بعض السلبيات مقارنة بتنفيذ Ark كامل، وأهمها الحاجة في النسخة اللاثقة لتعاون كافة المستخدمين داخل Ark الفردي لتوقيع المعاملات الخروجية بشكل مشترك في توقيع متعدد النمل (n-of-n) ضخم عند إنشائها. إذا توفر لدينا CTV أو اتفاقية مكافئة أخرى، فلن يحتاج المستخدمون للمشاركة في عملية توقيع تفاعلية، ويمكن لموفر خدمة Ark (ASP) ببساطة إنشاء Ark باستخدام اتفاقية، ويمكن للمستخدمين التأكد من أن لديهم كامل السيطرة على أموالهم بعد تأكيدها.

مقارنة Ark مع شبكة Lightning

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

معضلة سيولة Ark

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

استكشاف حلول لأزمة السيولة

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

يمكن لـ ASP يواجه أزمة سيولة أن “ينقل” المدفوعات من Arks الخاصة بهم إلى ASP آخر يمتلك مزيدًا من السيولة المتاحة، مما ينشئ ترابط ATLC بين Ark الأصلي للدفعة من ASP إلى Ark آخر لينتقل إلى ASP آخر. يؤدي ذلك إلى تقليل الرسوم على المستخدمين.

التعاون بين ASPs

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

الاعتبارات والتوقعات المستقبلية

هناك بعض الفوائد وبعض العيوب المحتملة، لكنني أعتقد أن هذا مفهوم يستحق الاستكشاف من حيث تحسين مشكلة أزمة السيولة في Ark.

الأسئلة الشائعة

• ما هي الميزة الرئيسية لـ Ark مقارنة بشبكة Lightning؟

  الميزة الرئيسية لـ Ark هي قدرته على تخصيص السيولة لأي مستخدم بواسطة منشأة ASP، مما يمكّن من إدارة السيولة بشكل أشمل وبمرونة أكبر.

• ما هي المشكلة الرئيسية التي يواجهها Ark فيما يتعلق بالسيولة؟

  تواجه Ark مشكلة السيولة عندما تضطر ASP لتقديم السيولة للدفعات العالقة داخل النظام، مما قد يؤدي إلى ارتفاع الرسوم حتى استعادة السيولة بإغلاق Arks.

• كيف يمكن تحسين مشكلة السيولة في Ark؟

  يمكن تحسين أزمة السيولة في Ark عبر تطبيق مفهوم تقنيات الطوبولوجيا القابلة للتوجيه، مما يسمح لـ ASPs بنقل المدفوعات بين بعضها البعض لتوفير السيولة وتقليل الرسوم.