مشروع Avail | مقابلة حصرية مع Anurag Arjun المؤسس المشارك للمشروع
مع استمرار تطور تكنولوجيا البلوكشين ونظم Web3، أصبحت التحديات المتعلقة بقابلية التوسع والتشغيل البيني وتوفر البيانات أكثر أهمية من أي وقت مضى. لمواجهة هذه التحديات بشكل مباشر، يظهر مشروع Avail كواحد من المشاريع الرائدة التي تقدم حلولًا تهدف إلى توحيد الأنظمة المجزأة وإعادة تعريف طريقة تفاعل التطبيقات اللامركزية.
في هذه المقابلة الحصرية، يجري فريق أفق الكريبتو حوارًا مع Anurag Arjun، أحد الشخصيات البارزة في مجال البلوكشين، والذي يشغل الآن منصب المؤسس المشارك لمشروع Avail. يشارك أنوراغ معنا قصة انطلاق المشروع، ونهجه الفريد في التعامل مع توفر البيانات، ورؤيته لتبسيط وتعزيز بنية البلوكشين التحتية.
انضموا إلينا في هذه المقابلة لاكتشاف الابتكارات التكنولوجية لـ Avail، ودوره في معالجة التحديات الرئيسية في مشهد Web3، وخطة المشروع الطموحة لعام 2025 وما بعده.
حوار أفق الكريبتو مع Anurag – المؤسس المشارك في مشروع Avail
نترككم مع المقابلة. قراءة مثرية!
القصة وراء مشروع Avail: هل يمكنك مشاركة رحلة تأسيس Avail؟ ما الذي ألهمك لتأسيس المشروع، وكيف يواجه التحديات الرئيسية التي تواجه نظم البلوكشين وويب 3 اليوم؟
بدأت مسيرة Avail في عام 2020، خلال فترة عملي مع Polygon، حيث تعاونت بشكل وثيق مع شريكي المؤسس في Avail، برابال، للعمل على حلول توفر البيانات. في ذلك الوقت، كنا نبني حلاً للتوسع يعتمد على تقنية Plasma، لكننا واجهنا مشكلة أساسية: لم نتمكن من ضمان أن جميع بيانات المعاملات متاحة للمستخدمين بشكل فعال. لذلك اضطررنا إلى التحول إلى PoS (إثبات الحصة)، وهناك بدأنا نرى الصورة الأوسع – بدون توفر قوي للبيانات، لا يمكنك بناء حلول توسع آمنة للبلوكشين.
بدأنا كفريق مكون من شخصين فقط ينظران في هذه المشكلة، وبمرور الوقت أصبح لدينا فريق مكون من خمسة عشر شخصًا في Polygon يعملون على حلها. عندها أدركنا الحاجة إلى طبقة محايدة تمامًا لتوفير البيانات. لو أبقينا المشروع تحت مظلة Polygon، لكانت المشاريع الأخرى مثل zkSync أو Arbitrum قد امتنعت عن استخدام حل توفير البيانات الذي يعتمد على رمز MATIC، حيث أن ذلك لن يتماشى مع أهدافها.
من هنا، قررنا إطلاق مشروع Avail بشكل مستقل، والباقي أصبح تاريخًا. كنا حريصين جدًا في إدارة عملية الانتقال. أعطينا كل فرد في فريقنا الخيار للانضمام إلينا. العلاقات التي بنيناها في Polygon لا تزال قوية حتى اليوم، وكان لذلك قيمة كبيرة للطرفين، حيث نسعى جميعًا لحل تحديات التوسع لصالح النظام البيئي بالكامل.
توحيد أنظمة Web3: تهدف Avail إلى أن تكون طبقة توحيد لأنظمة Web3 من خلال معالجة مشكلة التجزئة في تقنية Rollup على نطاق واسع. كيف تسهل Avail التشغيل البيني السلس بين شبكات البلوكشين المتنوعة، وما هي التحديات الرئيسية التي تتوقعها لتحقيق هذه الرؤية؟
تعاني Web3 من مشكلة تجزئة كبيرة، وتزداد سوءًا مع تزايد عدد الشبكات. لذلك، نحن في Avail نعمل على بناء إطار عمل للتوحيد. إنه مكدس تطوير تطبيقات معياري يجمع بين ثلاثة عناصر رئيسية: توفر البيانات (Avail DA)، والأمان المشترك متعدد الأصول (Avail Fusion)، والتشغيل البيني (Avail Nexus). الهدف هنا واضح — نريد أن يتمكن أي شخص من التفاعل مع شبكات بلوكشين مختلفة بطريقة آمنة وسهلة.
اسمح لي أن أوضح لماذا هذا الأمر مهم. إذا نظرت إلى بيئة L2 حاليًا، ستجد أن المستخدمين يعانون من تجربة مجزأة جدًا. أصولهم موزعة عبر شبكات L2 مختلفة، وعليهم التعامل مع العديد من الجسور، ولكل جسر رموزه المغلفة الخاصة، مما يضيف تعقيدات غير ضرورية. هذا هو بالضبط ما نعالجه من خلال طبقة Nexus الخاصة بنا، التي تأخذ إثباتات من شبكات مختلفة وتخلق مصدرًا موثوقًا واحدًا للحقيقة.
إحدى أكبر التحديات في هذا السياق هي التعامل مع الأنواع المختلفة من تقنية الـ Rollups. لدينا الـ Optimistic Rollups والـ ZK Rollups، ولكل منهما طرقه الخاصة في التحقق. مع الـ ZK Rollups، نتعامل مع أوقات توليد وإثبات البيانات، بينما تتطلب الـ Optimistic Rollups فترات تحدي. جعل هذه الأنظمة المختلفة تعمل معًا بسلاسة يمثل تحديًا كبيرًا.
تحدٍ آخر هو جاهزية مكدسات الـ Rollups. في الوقت الحالي، العديد منها لا يزال يعتمد فقط على Ethereum كطبقة لتوفر البيانات (DA) ، أو في حال استخدامهم لحلول بديلة لتوفر البيانات، فإنهم لا يستخدمون الجسور بكفاءة. الهدف هو جعل جميع هذه العناصر تعمل معًا، وهذا دائمًا يتطلب وقتًا.
ومع ذلك، نحن نعمل على تجاوز هذه التحديات خطوة بخطوة، مع التأكد من بناء شيء ليس فقط سليمًا من الناحية النظرية ولكنه أيضًا عملي ومفيد للمستخدمين والمطورين.
الابتكارات التقنية: مع إطلاق Avail DA Mainnet، هل يمكنك توضيح الابتكارات التقنية الأساسية التي تميزها عن الحلول الأخرى في السوق؟
الأمر يتعلق بنهجنا الأساسي في توفير البيانات. لقد قمنا بتطوير نظام يمكّن المستخدمين من التحقق من توفر البيانات بأنفسهم بسرعة كبيرة. يحتاج المستخدمون فقط إلى تنزيل أجزاء صغيرة من البيانات، ومع ذلك يحصلون على ضمانات تشفير قوية تؤكد أن جميع البيانات متوفرة. نحن نستخدم التزامات التشفير KZG، ويمكن للمستخدمين أخذ عينات بناءً على هذه الالتزامات، مما يعني أنك لست بحاجة إلى الوثوق بأي مشغل لأداء عمله بشكل صحيح.
ثم هناك حلول مثل EigenDA، التي تتبع نهجًا مختلفًا تمامًا. حيث تعتمد على مفهوم يسمى “لجنة توفر البيانات”، حيث يتم الاعتماد على مجموعة صغيرة من أعضاء اللجنة للتأكيد على أن البيانات متوفرة. إنه نموذج اقتصادي تشفيري — إذا كنت تثق في الضمانات الاقتصادية التشفيرية لهؤلاء المشغلين، فيمكنك أن تثق بأن بياناتك متوفرة، لكنك لا تحصل على ضمان تشفيري.
المميزات
ما يميز نهجنا هو أننا نستخدم إثبات الصلاحية (validity proof)، مما يوفر ضمانًا تشفيريًا بفضل التزامات KZG. هذا يعني أننا لا نحتاج إلى الاعتماد على إثباتات الاحتيال أو الانتظار خلال فترات التحدي. هذا النهج أكثر قوة، لأنه يسمح للمستخدمين بالتحقق من الأمور بأنفسهم بدلًا من الاعتماد على اللجان أو الانتظار لفترات طويلة.
كما قمنا ببناء نظام طبقة تراكبية من نظير إلى نظير (peer-to-peer overlay system). لذلك، حتى إذا حدث شيء ما لسلسلة Avail، تظل البيانات متوفرة وقابلة للتحقق. بمجرد نشر البيانات، يصبح من الصعب جدًا فرض الرقابة عليها، تمامًا مثلما يصعب إزالة فيلم بمجرد وجوده على شبكة تورنت. ولكننا نستخدم هذا المفهوم لغرض إيجابي – ضمان توفر البيانات ومقاومة الرقابة.
جانب آخر مهم هو كيفية تعاملنا مع مقاييس الأداء. عندما يتحدث الناس عن طبقات توفر البيانات (DA layers)، غالبًا ما يركزون على مقاييس مثل الميجابيت في الثانية. ومع ذلك، هذه ليست الطريقة الصحيحة لقياس طبقات توفر البيانات. ما يهم هو الضمان الذي تحصل عليه عند نشر شيء ما. يجب أن تأخذ في الاعتبار نوع الضمانات التي تحصل عليها ومدة الوقت الذي يستغرقه الحصول على تلك الضمانات، لأن هذا هو القيمة الأساسية التي يتم تقديمها.
التطلع إلى عام 2025: مع اقتراب عام 2025، ما هي الأولويات والأهداف الرئيسية لـ Avail في العام القادم؟ وكيف تتصورون مساهمة Avail في تعزيز تبني تقنيات Web3 ونموها على المستوى العالمي؟
لدينا عدة أولويات رئيسية في المستقبل. أولاً، نعمل على توسيع قدرات الأمان المشترك متعدد الأصول. معظم سلاسل الطبقة الأولى (L1) تعتمد حاليًا على أصل واحد فقط للأمان. نحن نعمل على نظام يسمح بمساهمة أصول متعددة في الأمان. ولكننا نأخذ هذا الأمر بحذر شديد. لا يمكنك ببساطة دمج أصول متعددة دون النظر في العواقب. يجب التعامل مع تقلب الأسعار، الخسارة المؤقتة، وضمان عدم سيطرة أي أصل أجنبي على أمان النظام.
نحن نركز أيضًا بشكل كبير على تحسين طبقة Nexus لدينا. هناك الكثير من العمل الجاري لتحسين كيفية تعاملنا مع الاتصال بين الأنواع المختلفة من تقنية الـ Rollups – سواء كانت ZK أو Optimistic. نحن متحمسون بشكل خاص لعملنا على تجميع إثباتات ZK وتقديم ضمانات أسرع. لكن مرة أخرى، نتبع نهجًا مدروسًا في هذا الأمر. عندما يتعلق الأمر بأمان البلوكشين، لا يمكنك ببساطة التحرك بسرعة وكسر الأشياء.
على صعيد الحوكمة، نحن نخطط لتطور تدريجي. حاليًا، لدينا ما نطلق عليه الحوكمة v1، وهي شكل أبسط مما خططنا له في الأصل باستخدام نظام حوكمة Polkadot. تعلمنا خلال مرحلة اختبار الشبكة (testnet) أننا بحاجة إلى مزيد من الوقت لنضج المجتمع قبل تسليم الحوكمة بشكل كامل. الأمر يتعلق بإيجاد التوازن الصحيح بين اللامركزية والاستقرار.
الجزء الكبير الآخر لعام 2025 هو توسيع طبقة نظير إلى نظير (peer-to-peer). نحن نعمل على جعل أخذ عينات توفر البيانات أكثر كفاءة وتحسين شبكة التراكب من نظير إلى نظير. هذا الأمر بالغ الأهمية لأنه ما يسمح للمستخدمين بالتحقق من توفر البيانات بأنفسهم، وهو جزء أساسي من نموذجنا الخالي من الثقة.
ولكن في نهاية المطاف، نسعى لتحقيق مستقبل لا يضطر فيه المستخدمون للتفكير في أي سلسلة بلوكشين يستخدمونها أو القلق بشأن توفر البيانات. يجب أن تعمل الأمور بسلاسة. في الوقت نفسه، نحن لا نقدم أي تنازلات فيما يتعلق بالأمان أو اللامركزية. كل مورد في البلوكشين له تكلفة، ونحن واعون جدًا لبناء شيء ليس فقط قويًا تقنيًا ولكنه أيضًا مستدام اقتصاديًا.
