العنوان الأصلي: الموت والضرائب وتوازي EVM
المؤلف الأصلي: ريفورج للأبحاث
المصدر الأصلي: ريفورجي للأبحاث
تم إعداده بواسطة: Mars Finance، MK
يقدم
في المجال الحالي لأنظمة الكمبيوتر، غالبًا ما يتم تحقيق تحسينات التسريع والكفاءة من خلال إكمال المهام المتوازية بدلاً من التنفيذ المتسلسل. ولدت هذه الظاهرة، التي يطلق عليها على نحو مناسب الموازاة، مع ظهور بنيات المعالجات متعددة النواة في أجهزة الكمبيوتر الحديثة. تم الآن تحسين المهام التقليدية خطوة بخطوة من خلال منظور التزامن، مما يزيد من أداء المعالج. وبالمثل، في شبكة blockchain، يمكن أيضًا تطبيق مبدأ التنفيذ المتزامن متعدد المهام على مستوى المعاملة، على الرغم من أنه لا يعتمد على معالجات متعددة، ولكنه يعتمد على قوة التحقق الجماعي للعديد من المدققين على الشبكة. تتضمن أمثلة التنفيذ المبكر ما يلي:
في عام 2015، قدمت Nano (XNO) بنية شبكة بلوكات حيث يمتلك كل حساب بلوكشينًا مستقلًا، ما يمكّن المعالجة المتوازية للمعاملات ويلغي الحاجة إلى تأكيدات على مستوى الشبكة.
في عام 2018، نُشرت ورقة محرك تنفيذ متوازي على شبكة Block-STM (ذاكرة معاملات برمجية)، كما حققت Polkadot التوازي عبر بنية متعددة السلاسل، وقدمت EOS محرك معالجة متعدد الخيوط.
في عام 2020، قدمت Avalanche آلية توافق متوازية (وليس c-chain الخاص بـEVM—والذي يكون تسلسليًا)، بينما أطلقت Solana تقنية مبتكرة مماثلة باسم Sealevel.
بالنسبة لـEVM، منذ لحظة إنشائه، كانت تنفيذ المعاملات والعقود الذكية يتم بشكل تسلسلي. يحد تصميم التنفيذ أحادي الخيط من الإنتاجية وقابلية التوسع الكلية للنظام، ويصبح ذلك أكثر وضوحًا خلال فترات الذروة لطلب الشبكة. ومع مواجهة المُتحققين (validators) لأحمال عمل متزايدة، يتباطأ زمن الشبكة لا محالة، ما يجعل المستخدمين يواجهون تكلفة أعلى ويضطرون إلى المزايدة لتحديد أولوية معاملاتِهم في بيئة شبكة مزدحمة.
استكشفت مجتمع Ethereum على المدى الطويل المعالجة المتوازية كحل، بدءًا من اقتراح Vitalik في عام 2017 ضمن EIP. كانت الأهداف الأولى هي تحقيق التوازي عبر سلاسل التجزئة (sharding) أو تجزئة. لكن مع التطور السريع واعتماد حلول L2 rollups، وبسبب بساطتها وتقديمها مباشرةً ميزة التوسع، تحوّلت أنظار Ethereum إلى التقنية التي تُعرف حاليًا بـdanksharding. في danksharding، تعمل التجزئة أساسًا كطبقة توفر البيانات، وليس كتنفيذ معاملات متوازية. ومع ذلك، وبما أن التنفيذ الشامل لـdanksharding لا يزال قيد التقدم، فقد اتجه التركيز إلى بعض شبكات L1 رئيسية متوافقة مع EVM وتتضمن توازيًا محوريًا، ولا سيما Monad وNeon EVM وSei وغيرها.
بالنظر إلى التطور التقليدي لهندسة أنظمة البرمجيات وإنجازات قابلية التوسع في شبكات أخرى، يبدو أن التنفيذ المتوازي لـEVM أمر لا مفر منه. على الرغم من أننا واثقون من هذا التحول، إلا أن المستقبل بعده لا يزال مليئًا بالمجهول والأمل. بالنسبة لأكبر نظام بيئي لمطوري العقود الذكية على مستوى العالم—والذي تتجاوز قيمته السوقية 80 مليار دولار—فإن لذلك آثارًا عميقة. ماذا يحدث عندما تجعل الوصولات إلى الحالة المحسّنة أسعار الغاز تنخفض إلى بضعة أجزاء من المائة من سنت؟ ما مقدار مساحة التصميم المتاحة لمطوري طبقة التطبيقات؟
التوازي هو وسيلة وليس هدفًا.
توسيع نطاق البلوكشين مسألة معقدة متعددة الأبعاد، ويُمهد التنفيذ المتوازي الطريق لتطور البنية التحتية الأساسية، مثل تخزين حالة البلوكشين. التحديات الرئيسية التي تواجه مشاريع EVM المتوازي لا تقتصر فقط على تنفيذ الحساب بالتوازي؛ بل أيضًا تحسين الوصول إلى الحالة وتعديلها داخل بيئة متوازية. وتتضمن المسائل الأساسية عادةً:
يستخدم عميل Ethereum وهنا: Ethereum نفسه هياكل بيانات تخزين مختلفة (B-tree/LSM-tree مقابل Merkle Patricia Trie). وعندما تُضمَّن بنية بيانات داخل أخرى، قد يؤدي ذلك إلى انخفاض الأداء.
أثناء التنفيذ المتوازي، تكون القدرة على إدخال/إخراج غير متزامن لعمليات القراءة/الكتابة للمعاملات (async I/O) بالغة الأهمية؛ وإلا فقد يدخل النظام في حالة تعطل بسبب انتظار متبادل، مما يهدر إمكانات زيادة السرعة.
إن زيادة مهام الحساب، مثل إجراء عدد كبير من عمليات SHA-3 أو عمليات حسابية أخرى، لا تُذكر تقريبًا مقارنةً بتكلفة القراءة/الكتابة إلى التخزين. ولتقليل وقت معالجة المعاملات وتكلفة الغاز، تحتاج البنية التحتية للقاعدة البيانية إلى تحسينات. لا يتعلق الأمر فقط باستبدال استخدام البنى التقليدية للقاعدة البيانية كحل تخزين رئيسي/مفتاح-قيمة (مثل قواعد بيانات SQL DB) كبديل خام. إن نموذج العلاقات لحالة EVM يضيف تعقيدًا ونفقات غير ضرورية؛ كما أن تكلفة عمليتي 'sload' و'sstore' أعلى مقارنةً بتخزين مفتاح-قيمة بسيط. لا تحتاج حالة EVM إلا إلى عمليات قراءة/كتابة نقطية (point reads and writes)، ويتم تنفيذ عمليات الكتابة بشكل مستقل عن نهاية كل كتلة. لذلك ينبغي أن تركز نقطة التحسين على المجالات الأساسية مثل: قابلية التوسع، وتقليل التأخير في القراءة/الكتابة، والتحكم المتزامن الفعّال، وتقليم/قص الحالة (state pruning) والأرشفة، والتكامل السلس مع EVM. على سبيل المثال، تقوم Monad ببناء قاعدة بيانات حالة مخصصة من الصفر تُسمى MonadDB، تستفيد من دعم النواة الحديثة للعمليات غير المتزامنة، وتنفّذ محليًا بنية بيانات patricia trie، سواء على القرص أو في الذاكرة.
نتوقع رؤية المزيد من إعادة بناء قاعدة بيانات المفاتيح والقيم الأساسية، وتحسنًا كبيرًا في البنية التحتية الداعمة لقدرات تخزين البلوكشين.
لنُهنئ مجددًا القيمة الاستثنائية للدفتر المركزي للأوامر الحدية القابل للبرمجة (pCLOBs).
مع انتقال DeFi إلى مستويات أعلى من الدقة (fidelity)، أصبحت دفاتر الأوامر الحدية المركزية (CLOBs) بشكل متزايد طريقة مهيمنة لتصميم التداول. منذ ظهورها الأولي في عام 2017، أصبحت صانعات السوق الآلية (AMMs) قوة محورية في عالم DeFi، وتُعد موضع تقدير واسع بفضل بساطتها وقدرتها الفريدة على توليد السيولة. تُحدث AMMs ثورة في عالم DeFi عبر استخدام مجمعات سيولة وخوارزميات تسعير، لتصبح البديل المفضل للنظم التقليدية للتداول مثل دفاتر الأوامر. ومع أن CLOBs تؤدي دورًا أساسياً في التمويل التقليدي، إلا أنها واجهت صراعًا صعبًا عند إدخالها إلى عالم Ethereum بسبب قيود قابلية التوسع في السلسلة.
يتطلب هذا التصميم عددًا كبيرًا من خطوات التداول، بما في ذلك تقديم كل أمر وتنفيذه وإلغاؤه أو تعديله، حيث تتطلب كل خطوة معاملة جديدة على السلسلة. وبالنظر إلى أن أعمال توسع Ethereum كانت في مراحلها الأولية، فإن تكلفة هذه المتطلبات جعلت CLOBs غير مناسبة تمامًا لـDeFi في بداياته، مما أدى إلى فشل نسخ مبكرة مثل EtherDelta. ومع ذلك، وعلى الرغم من الشعبية الكبيرة لـAMMs، إلا أن لديها أيضًا قيودًا جوهرية. ومع نضج DeFi وجذب المزيد من المتداولين المتقدمين والمؤسسات، أصبحت هذه القيود أكثر وضوحًا.
بعد إدراك مزايا CLOBs، بدأ الناس في بذل جهود أكبر لدمج منصات تداول قائمة على CLOB في DeFi على سلاسل بلوكشين أخرى ذات قابلية توسع أعلى. ومن الأمثلة البارزة مشاريع مثل Kujira وSerum (RIP ☠) وDemex وdYdX وDexalot، فضلًا عن Aori وHyperliquid مؤخرًا، والتي تهدف إلى تقديم تجربة تداول على السلسلة أفضل من منافسيها القائمين على AMM.
ومع ذلك، بالإضافة إلى التركيز على مشروعات خاصة بمجال بعينه—مثل dYdX وHyperliquid التي تركز على العقود الدائمة—فإن CLOBs في هذه الشبكات البديلة تواجه تحدياتها الخاصة، بما في ذلك:
مشكلة تجزئة السيولة: نظرًا لأن بروتوكولات DeFi على Ethereum عالية القابلية للتراكيب والتكامل السلس، فإن ذلك يخلق تأثيرات شبكية قوية تجعل CLOBs على سلاسل أخرى صعبة في جذب سيولة وحجم تداول كافيين، ما يعوق اعتمادها وترويجها.
الـMeme币: لتوجيه السيولة داخل CLOB على السلسلة، يلزم حد أدنى من أوامر بسعر محدد. وبالنظر إلى أن الأصول الجديدة وغير المألوفة مثل عملات الميم تُعد أكثر تحديًا، فإن السؤال “أيّهما يأتي أولًا، الدجاجة أم البيضة؟” يصبح أكثر صعوبة.
CLOB مع blob
أما بالنسبة لطبقة L2، فبالمقارنة مع الشبكة الرئيسية لـEthereum، فقد حققت حلول L2 الحالية على Ethereum تحسينات ملحوظة في قدرات معالجة المعاملات والتكاليف، خاصة بعد hard fork Dencun الأخير. وباستخدام الأجسام الثنائية خفيفة الوزن (blobs) بدلًا من calldata التي كانت تستهلك كمية كبيرة من الغاز، تنخفض تكاليف المعاملات بشكل كبير. ووفقًا لبيانات growthepie، حتى 1 أبريل، بلغت رسوم Arbitrum وOptimism 0.028 دولار و0.064 دولار على التوالي، وكانت رسوم Mantle الأقل عند 0.015 دولار فقط.
مقارنةً برسوم ما قبل hard fork Dencun، فإن نسبة الانخفاض هذه كبيرة بشكل واضح، لأن calldata كانت تشكل 70%-90% من التكلفة سابقًا. للأسف، وعلى الرغم من انخفاض الرسوم بشكل كبير، لا تزال رسوم النشر/الإلغاء البالغة حوالي 0.01 دولار تُعتبر مرتفعة. على سبيل المثال، عادةً ما يمتلك المتداولون المؤسسيون وصانعو السوق نسبًا أعلى من تداول الأوامر: في كومة كبيرة من الأوامر، يتم تنفيذ عدد قليل فقط من الصفقات الفعلية. حتى في تسعير رسوم L2 الحالي، فإن تقديم كميات كبيرة من الأوامر عبر دفاتر مختلفة ثم تعديلها أو إلغاؤها لاحقًا قد يؤثر بشكل كبير على ربحية المشاركين المؤسسيين وقراراتهم الاستراتيجية، حتى لو كانت تكلفة كل معاملة أقل من 0.01 دولار.
The pCLOB
مع ظهور EVM المتوازي، نتوقع زيادة حادة في نشاط DeFi بقيادة CLOBs القابلة للتنفيذ على السلسلة. وبوجه خاص، pCLOBs لأنها بحكم طبيعتها قابلة بدرجة عالية للتركيب داخل DeFi، ويمكنها التفاعل مع بروتوكولات متنوعة (مع قيود فقط تتمثل في الغاز)، ما يولد مجموعات تداول غنية. وبفضل هذه الميزة، يمكن لـpCLOB دمج منطق مخصص أثناء تقديم الطلب، بحيث يتم تشغيل هذا المنطق قبل تقديم الأمر أو بعده. على سبيل المثال، يمكن لعقود pCLOB الذكية أن:
التحقق من معلمات الأمر وفق قواعد مُعرّفة مسبقًا أو ظروف السوق (مثل السعر والكمية)؛
تنفيذ مراجعة مخاطر فورية للتأكد من أن معاملات الرافعة تمتلك ضمانات/هامشًا كافيًا؛
حساب الرسوم بشكل ديناميكي وفقًا لمختلف المعلمات (مثل نوع الأمر وحجم التداول وتذبذب السوق، إلخ)؛
تنفيذ الأوامر بناءً على شروط محددة؛ وبتكلفة أقل بكثير من أنماط التداول الحالية.
تُجسد فكرة السيولة “الفورية” (JIT) بوضوح هذه الميزة. لا تبقى السيولة في أي بورصة واحدة؛ بل يتم تحريكها بنشاط من أماكن أخرى لحظة مطابقة الأوامر، محققة عائدًا سابقًا على المنصات الأساسية. ومن الذي يمكنه رفض جني كل عائد قبل البحث عن سيولة تدفق التداول؟ تُظهر منهجية Mangrove Exchange المبتكرة “العرض ككود” هذا الإمكان: بمجرد مطابقة عرض الأسعار، يتم تنفيذ الكود المضمن، ومهمته الأساسية هي العثور على السيولة التي يحتاجها متلقي الأمر. وعلى الرغم من وجود تحديات—خصوصًا فيما يتعلق بالتوسع والـتكلفة في الطبقة الثانية (L2)—فإن EVM المتوازي يعزز بشكل كبير كفاءة محرك المطابقة في pCLOBs. حاليًا، يمكن لـpCLOB نشر محرك مطابقة متوازي، عبر معالجة الأوامر بالتوازي عبر عدة “قنوات” وتنفيذ حسابات المطابقة. تعالج كل قناة جزءًا من دفتر الأوامر، مما يلغي قيد أولوية السعر مقابل الوقت، ولا يتم التنفيذ إلا عند العثور على تطابق. هذا يقلل التأخير بين تقديم الطلب وتنفيذه وتعديله، ما يسمح بتحديث دفتر الأوامر بأفضل كفاءة.
بالنسبة للأصول “ذات الذيل الطويل” ذات السيولة المنخفضة، قد تظل AMMs مستخدمة على نطاق واسع؛ ومع ذلك، بالنسبة لأسهم/أصول الصف الأول (blue-chip)، فإن pCLOBs ستُظهر بالتأكيد تفوقها.
في نقاش مع Keone Hon، المؤسس المشارك والرئيس التنفيذي لشركة Monad، عبّر عن ثقته الكاملة في أن عدة pCLOBs ستلفت الانتباه في سلاسل بيئية مختلفة عالية الإنتاجية، وأن تأثيرها العميق على منظومة DeFi بأكملها سيأتي من قدرتها على خفض الرسوم بشكل كبير.
حتى لو كانت هذه الإنجازات وحدها، نتوقع أن تُحدث pCLOBs تأثيرًا كبيرًا على كفاءة رأس المال، وأن تقود موجةً جديدة في عالم DeFi.
لقد أدركنا أنه على الرغم من حاجتنا إلى المزيد من التطبيقات، فإن الأولوية هي…
يجب على التطبيقات الحالية والجديدة تصميم نفسها بطريقة تمكنها من الاستفادة بشكل كافٍ من ميزات التوازي في الطبقة الأساسية.
حاليًا، تفتقر معظم تطبيقات اللامركزية إلى القدرة على العمل بالتوازي، وتفاعلها مع البلوكشين بطبيعته تتابعي. ومع ذلك، تُظهر الخبرات التاريخية أن التقنية والتطبيقات تتطور تلقائيًا للاستفادة من التقدم التقني الجديد، حتى وإن لم تكن مصممة لذلك في البداية. فعندما تم إطلاق أول iPhone، كانت التطبيقات المصممة له مثالًا على ذلك. نحن في فترة انتقالية شبيهة، كما لو كنا نضيف قدرات معالجة متعددة الأنوية إلى البلوكشين، الأمر الذي سيُنتج تطبيقات أكثر روعة.
تطور التجارة الإلكترونية، من عرض أدلة المجلات عبر الإنترنت إلى تشكيل أسواق ثنائية متماسكة، يوضح نموذج هذا النوع من التحول. ومع تنفيذ EVM المتوازي، سنشهد تحولًا مماثلًا في تطبيقات اللامركزية. وهذا يبرز قيدًا محوريًا آخر: إذا لم تكن التطبيقات مصممة للتوازي ابتداءً، فلن تستفيد بحكم طبيعتها من مكاسب الكفاءة التي يجلبها EVM المتوازي. لذلك، لا يكفي تنفيذ التوازي في طبقة البنية التحتية فقط؛ بل يجب أيضًا إعادة تصميم طبقة التطبيقات لتتوافق معه.
تنازع الحالة
حتى دون تغيير تطبيقاتنا نفسها، ما زال متوقعًا رؤية تحسن في الأداء بنسبة 2-4 أضعاف. لكن لماذا نتوقف هنا، خاصةً عندما تكون إمكانات تحسين الأداء أكبر؟ التحدي الجوهري الذي تحمله هذه النقلة هو أن التطبيقات تحتاج إلى إعادة تصميم جوهرية لتلائم الفروق الدقيقة في المعالجة المتوازية.
تظهر التعارضات عندما تحاول معاملات متعددة ضمن تطبيق لامركزي تعديل نفس الحالة في الوقت نفسه. تحتاج هذه المعاملات المتعارضة إلى المعالجة بالتسلسل لحل المشكلة، لكن ذلك يُلغي ميزة التوازي.
لن نخوض هنا في طرق حل التعارضات بالتفصيل، لكن عدد التعارضات المحتملة التي يواجهها مطورو التطبيقات يعتمد إلى حد كبير على تصميماتهم هم. بعض التطبيقات اللامركزية الشعبية مثل Uniswap لم تُراعِ هذا القيد في تصميمها وتنفيذها. قام Aori، المؤسس المشارك له 0xTaker، وهي شركة أوامر عالية التردد لأجل المصنع (high-frequency offline order book)؛ بالتعمق في المشاكل الرئيسية المتعلقة بالتنافس على الحالة التي تظهر في سياق المعالجة المتوازية. بالنسبة لـAMM، قد يجذب نموذج المسبح الندّي (pooled pair/peer pool) عددًا كبيرًا من المشاركين للتداول على نفس المسبح في آن واحد؛ ومن عدة معاملات إلى أكثر من مئة معاملة قد يؤدي ذلك إلى تنافس على الحالة، وبالتالي يجب على مصممي AMM أن يخططوا بعناية لكيفية توزيع السيولة وإدارتها داخل المسبح بما يعظم فائدتها.
أكد المطور الأساسي لدى Sei Steven أهمية أخذ التنافس (contention) في الحسبان عند تطوير متعدد الخيوط، وأشار إلى أن Sei تستكشف بنشاط معنى التوازي وتأثيره على استغلال الموارد.
قابلية التنبؤ بالأداء
أكد أيضًا Yilong، المؤسس المشارك والرئيس التنفيذي في MegaETH، على أهمية السعي نحو قابلية التنبؤ بالأداء في تطبيقات اللامركزية. يُقصد بقابلية التنبؤ بالأداء أن يتمكن تطبيق لامركزي من تنفيذ المعاملات بشكل متسق ضمن إطار زمني محدد، دون أن تتأثر بازدحام الشبكة أو العوامل الخارجية الأخرى. ومن إحدى طرق تحقيق ذلك اختيار سلسلة محددة. لكن على الرغم من أن سلاسل مخصصة للتطبيقات تقدم أداءً يمكن التنبؤ به، فإنها تضحي بقابلية التركيب.
يوفر التوازي طريقة لتقليل تنازع الحالة عبر تجارب “أسواق الرسوم” المحلية.
يقول Aori، المؤسس المشارك لـ0xTaker: بفضل التوازي المتقدم وآليات الرسوم متعددة الأبعاد، يمكن توفير أداء أكثر قابلية للتحديد لكل تطبيق مع الحفاظ على قابلية التركيب الإجمالية.
تملك Solana نظامًا ممتازًا لسوق الرسوم، وهو “محلي” بطبيعته؛ وبالتالي إذا زار عدة مستخدمين نفس الحالة، فإنهم يدفعون رسومًا أعلى قليلًا (تسعير الاندفاع) بدلًا من التنافس ضد بعضهم البعض داخل سوق رسوم عالمي. هذه الآلية مفيدة بشكل خاص للبروتوكولات المترابطة بشكل غير محكم والتي تحتاج إلى قابلية التنبؤ بالأداء وقابلية التركيب. تخيل طريقًا سريعًا به عدة حارات ورسوم ديناميكية: في أوقات الذروة، يمنح ذلك حارات “سريعة” مخصصة للمركبات التي تقبل دفع رسوم مرور أعلى، مما يضمن أن تكون أزمنة الرحلات لهؤلاء المستخدمين الذين يفضلون السرعة وعلى استعداد لدفع تكلفة إضافية قابلة للتنبؤ وسريعة. وفي الوقت نفسه، تظل الحارات العادية متاحة لجميع المركبات، ما يحافظ على الاتصال العام عبر النظام الكامل للطريق السريع.
إمكانيات تخيلية
قد يبدو أن إعادة تصميم البروتوكولات لتلائم البنية الأساسية للتوازي تتسم بتحديات كبيرة، لكن مساحة التصميم تتوسع بشكل ملحوظ في DeFi وغيرها من المجالات. ويمكننا توقع ظهور تطبيقات جديدة أكثر تعقيدًا وكفاءة وعالية الأداء، تركز على حالات استخدام كانت صعبة تحقيقها سابقًا بسبب قيود الأداء.
بالعودة إلى عام 1995، كانت الخطة الوحيدة للإنترنت هي دفع 0.10 دولار مقابل كل 1MB يتم تنزيله، ما دفع الناس إلى أن يكونوا حذرين عند اختيار مواقع الويب التي يزورونها. ومن هذا التحول إلى الاستخدام غير المُقيد حاليًا، نرى كيف تغيّرت أنماط سلوك الناس، وكيف أُتيحت إمكانيات جديدة.
قد نعود إلى نوع “حروب الحصول على المستخدمين” الذي شهدته بورصات مركزية في بداياتها، حيث ستتخذ تطبيقات DeFi—وخاصة بورصات التداول اللامركزية—خططًا تنافسية تتمثل في برامج إحالة (مثل النقاط، وairdrops) وتجربة مستخدم أفضل. نحن نتطلع إلى عالم قد تصبح فيه أي لعبة على السلسلة ذات تفاعل معقول حقيقة واقعية. وجود دفاتر أوامر هجينة–AMMs أصبح أمرًا واقعًا، لكن وضع مُرتّب (CLOB sorter) كعُقدة مستقلة وتحقيق اللامركزية عبر الحوكمة ليس بقدر ما يفيد من مجرد نقله مباشرة إلى السلسلة: فهذا يرفع درجة اللامركزية ويخفض التأخير ويعزز قابلية التركيب. كما أن التفاعلات الاجتماعية المبنية على السلسلة أصبحت ممكنة بالكامل الآن. وبطبيعة الحال، أي سيناريو يتضمن عددًا كبيرًا من الناس أو الوكلاء يقومون بنشاط محدد في الوقت نفسه، أصبح الآن قابلًا للتحقق.
بالإضافة إلى البشر، قد تصبح سيطرة الوكلاء الذكيين على تدفقات التداول على السلسلة أكثر وضوحًا. كان للذكاء الاصطناعي دور كمشارك في الألعاب لفترة من الوقت، مثل تنفيذ عمليات التحكيم والتداول الآلي، لكن من المتوقع أن يتزايد حضوره بمعدل يتجاوز ما نتخيله حاليًا بشكل كبير وبسرعة غير مسبوقة. نحن نعتقد أن كل أشكال المشاركة على السلسلة—إلى حد ما—ستتم تعزيزها بالذكاء الاصطناعي. وسيصبح التأخير في تداول الوكلاء أكثر أهمية مما نتصوره حاليًا.
في النهاية، التقدم التقني هو عامل تمكين أساسي فقط. الفائز في الأخير هو من يستطيع التفوق على منافسيه في جذب المستخدمين وبناء حجم التداول والسيولة. والفرق اليوم هو أن لدى المطورين موارد أكثر تحت تصرفهم يمكن الاستفادة منها.
تجربة مستخدمي العملات المشفرة سيئة… لكن الأمور ستتحسن الآن.
توحيد تجربة المستخدم (UXU) ليس ممكنًا فحسب، بل ضروري—ومن الواضح أن الصناعة ستتجه نحو تحقيق هذا الهدف.
تجربة مستخدم اليوم على البلوكشين مجزأة ومُرهقة: يحتاج المستخدمون إلى التبديل بين عدة بلوكشينات ومحافظ وبروتوكولات، والانتظار بصبر حتى تكتمل المعاملة، مع وجود أيضًا مخاطر ثغرات أمنية أو التعرض للاختراق. المستقبل المثالي هو أن يتفاعل المستخدمون بسلاسة مع أصولهم بأمان، دون القلق بشأن البنية التحتية الأساسية للبلوكتشين. نسمي العملية التي تنتقل فيها تجربة المستخدم من حالة التجزؤ الحالية إلى تجربة موحدة وسلسة باسم توحيد تجربة المستخدم (UXU).
في جوهر الأمر، يؤدي تحسين أداء البلوكشين—خصوصًا عبر تقليل التأخير وخفض التكاليف—إلى معالجة كبيرة لمشكلات تجربة المستخدم. تاريخيًا، كان لتحسين الأداء تأثير إيجابي على جوانب متعددة من تجربة المستخدم الرقمية لدينا. على سبيل المثال، لا يؤدي ازدياد سرعة الإنترنت إلى جعل التفاعل عبر الإنترنت أكثر سلاسة فحسب، بل يحفز أيضًا الطلب على محتوى رقمي أكثر ثراءً وغمرًا. ساهم ظهور تقنيات النطاق العريض والألياف الضوئية في بث فيديو عالي الجودة بتأخير منخفض وتشغيل ألعاب عبر الإنترنت لحظيًا، ما رفع توقعات المستخدمين للمنصات الرقمية. أدى هذا النمو في الحاجة إلى العمق والجودة إلى دفع الشركات إلى استمرار الابتكار لبناء “الأمر الكبير والمثير القادم”—من محتوى تفاعلي شبكي متقدم إلى خدمات معقدة قائمة على السحابة، وصولًا إلى تجارب الواقع الافتراضي/المعزز. إن تحسين سرعة الإنترنت لا يُحسن التجربة عبر الإنترنت فحسب، بل يوسّع كذلك نطاق الطلب لدى المستخدمين.
وبالمثل، فإن تحسين أداء البلوكشين لا يعزز تجربة المستخدم مباشرةً فقط من خلال تقليل التأخير، بل يحقق ذلك أيضًا بشكل غير مباشر عبر تمكين ظهور بروتوكولات تُوحّد تجربة المستخدم الشاملة وتدفعها إلى الأمام. الأداء هو العنصر الحاسم لوجودها. وبالنسبة لهذه الشبكات، ولا سيما EVM المتوازي، فإن ارتفاع الأداء وانخفاض رسوم الغاز يعنيان أنه بالنسبة للمستخدمين النهائيين سيكون ركوب/نزول المركبات (الصعود/الهبوط) أكثر سلاسة دون عوائق، مما يجذب المزيد من المطورين. في حوارنا مع Sergey، المؤسس المشارك لدى Axelar، تصوّر عالمًا لا يكون متداخل التشغيل فحسب، بل أكثر تكاملًا وتعايشًا.
إذا كان لديك منطق معقد على سلسلة ذات إنتاجية عالية (مثل EVM المتوازي)، وبحكم أن السلسلة نفسها تتمتع بأداء مرتفع يمكنها “استيعاب” تعقيد هذا المنطق ومتطلبات الإنتاجية، فبإمكانك استخدام حلول التوافق/التداخل (interoperability) لتصدير هذه الوظيفة بكفاءة إلى سلاسل أخرى.
ومع معالجة مشكلات قابلية التوسع وزيادة قابلية التشغيل البيني بين الأنظمة البيئية المختلفة، سنشهد ظهور بروتوكولات تُطابق تجربة مستخدمي web3 مع تجربة web2. تشمل بعض الأمثلة: بروتوكولات قائمة على النوايا (intent-based) v2، وبنية RPC متقدمة، وتمكين تجريد السلسلة، وبنية حوسبة مفتوحة مدعومة بالذكاء الاصطناعي.
يتم تسريع تخطيط (تنسيق) حالة عقدنا بسبب زيادة إنتاجية الشبكة، إذ يمكن للمحلل (المفسر/المحلِّل) حل نوايانا بسرعة كبيرة.
جدير بالذكر
مع زيادة متطلبات الأداء، سيصبح سوق الـOracles أكثر عرضة للفقاعات.
يشير EVM المتوازي إلى أن الطلب على أداء الـOracles سيزداد، وهي ساحة كانت في السنوات القليلة الماضية أقل بكثير من التطور. إن زيادة الطلب من طبقة التطبيقات ستشجع سوقًا مكتفيًا بوسائل تؤدي إلى أداء غير كفء وأمان سيئ. وهذا ضروري لتحسين قابلية تركيب DeFi. على سبيل المثال، عمق السوق وحجم التداول هما مؤشرين قويين للعديد من بدائلهما في DeFi مثل أسواق العملات. نتوقع أن تتمكن الشركات الكبيرة القائمة مثل Chainlink وPyth من التكيف بسرعة نسبيًا، لأن اللاعب/اللاعبين الجدد في هذا العصر الجديد سيهددون حصصهم السوقية. وبعد حديثنا مع أحد كبار أعضاء Chainlink، اتفقت أفكارنا مع ما يلي حرفيًا: “إذا أصبح EVM المتوازي هو السائد، فقد نرغب في إعادة هيكلة عقودنا للاستفادة منه (مثل تقليل الاعتمادية بين العقود، بحيث لا تعتمد المعاملات/الاستدعاءات على بعضها بلا داع، وبالتالي لا يتم استغلالها عبر MEV)، لكن بما أن EVM المتوازي يستهدف زيادة الشفافية ورفع الإنتاجية للتطبيقات التي تعمل أصلًا على EVM، فلا ينبغي أن يؤثر في استقرار الشبكة.”
كما تتطلع أيضًا شبكات EVM المتوازي L2 إلى الانضمام إلى هذه المتعة. ومن الزاوية التقنية، فإن إنشاء حل EVM متوازي عالي الأداء على L2 قد يكون أسهل من بناء L1؛ لأن إعداد المُرتِّب (sorter) في L2 يكون أبسط بكثير من الآليات المعتمدة في أنظمة L1 التقليدية مثل Tendermint ومشتقاته.
نتوقع أن تهيمن في الأجل القصير EVM المتوازي L2 المبني على التفاؤل (optimistic). وفي النهاية، نتوقع فعلاً الانتقال من OP-based rollups إلى zk-rollups، عبر أطر zk عامة مثل RISC0، بدلًا من الأساليب التقليدية المستخدمة في zk-rollups الأخرى.
ميزة Rust… على الأقل حتى الآن. نميل أساسًا إلى Reth، تنفيذ Ethereum بـRust، بدلًا من أي بديل آخر. هذا التفضيل ليس اعتباطيًا، لأن Rust تمتلك العديد من المزايا مقارنةً بلغات أخرى، بما في ذلك أمان الذاكرة دون جامِع نفايات (garbage collection)، وتجريدات بتكلفة صفرية، ونظام أنواع غني، وغيرها.
سيلعب اختيار اللغة دورًا مهمًا في تطوير هذه الأنظمة. نحن واثقون أن Rust ستنتصر في النهاية. ومع ذلك، فإن نقل تنفيذ من لغة إلى أخرى ليس مهمة سهلة. يتطلب ذلك موارد كبيرة ووقتًا وخبرة، ما يزيد من التأكيد على أهمية اختيار اللغة الصحيحة منذ البداية.
في سياق التنفيذ المتوازي، لا يمكن تجاهل Move أيضًا. يقدم Move مفهوم “الموارد” (resources)، وهي موارد لا يمكن نسخها؛ بل يمكن فقط إنشاؤها أو نقلها أو إتلافها. يضمن ذلك أن تكون الموارد فريدة دائمًا، ويمنع مشاكلًا شائعة قد تظهر في التنفيذ المتوازي مثل ظروف السباق وتنافس البيانات.
التحقق الرسمي والأنواع الثابتة: يعد Move لغة أنواع ثابتة تركز على الأمان. وهي تتضمن ميزات مثل استدلال الأنواع، وتتبع الملكية، والتحقق من overflow. تساعد هذه الميزات على منع أخطاء برمجية وثغرات شائعة. وتعد هذه الخصائص الأمنية مهمة بشكل خاص في سياق التنفيذ المتوازي، لأن العيوب قد يكون من الصعب كشفها وإعادة إنتاجها. تعتمد دلالات اللغة ونظام أنواعها على المنطق الخطي (linear logic)، على غرار Rust وHaskell، ما يجعل الاستدلال على صحة برامج Move أسهل؛ وبالتالي يمكن للتحقق الرسمي أن يساعد في ضمان أن العمليات المتزامنة آمنة وصحيحة.
يدعو Move إلى أسلوب تصميم معياري (modular)، حيث تتكون العقود الذكية من وحدات أصغر وقابلة لإعادة الاستخدام. يمكن لهذا الهيكل المعياري أن يجعل من الأسهل الاستدلال على سلوك المكونات الفردية، ويمكن أن يعزز التنفيذ المتوازي عبر السماح بتنفيذ وحدات مختلفة بالتوازي.
اعتبار للمستقبل: يجب أن يعالج EVM مخاوفه الأمنية.
رغم أن لدينا نظرة متفائلة لمستقبل “الكون على السلسلة” وEVM المتوازي بعد ذلك، فإن الأمور ستبقى بلا معنى إذا لم نُعالج ثغرات EVM والعقود الذكية. على عكس أمان الاقتصاد الشبكي والتوافق (consensus security)، يستغل القراصنة بشكل متكرر ثغرات العقود الذكية في بروتوكولات DeFi على Ethereum؛ وقد تجاوز مبلغ السرقة في 2023 وحده 1.3 مليار دولار. لذلك يميل المستخدمون إلى استخدام CEXs محمية بجدران حماية، أو بروتوكولات “لامركزية” تحتوي على مُتحققين/validators مركزية، للحصول على إحساس أعلى بالأمان (وكذلك الأداء)، وبذلك تحسين تجربة المستخدم على السلسلة.
الخصائص الأمنية المفقودة في تصميم EVM هي الجذر الذي تنطلق منه هذه الثغرات الأمنية. عند مقارنة إجراءات أمان البلوكشين بمعايير السلامة الصارمة في قطاع الطيران، فإن ارتفاع مستوى الأمان هناك يدعم الاهتمام بحماية الحياة والممتلكات. الاختبارات الشاملة، والتكرار (redundancy)، وقدرات تحمل الأعطال، ومعايير التطوير الصارمة هي ما يحمي سجلات أمان الطيران—بينما تفتقر EVM وحتى معظم الـVMs الأخرى إلى هذه السمات الأساسية.
أحد الحلول هو اعتماد بنية مزدوجة للـVMs، بحيث يراقب VM مستقل، مثل CosmWasm، تنفيذ عقود EVM الذكية بشكل فوري—على غرار برنامج مكافحة الفيروسات في أنظمة التشغيل. تسمح هذه البنية بإجراء فحوصات متقدمة، مثل فحص مكدس الاستدعاء، لتقليل وقوع حوادث الهجمات. ومع ذلك، يتطلب ذلك إجراء تغييرات كبيرة على الأنظمة البلوكشينية الحالية. نتوقع أن تتمكن حلول أفضل مثل Arbitrum Stylus وArtela من تطبيق هذه البنية بفاعلية منذ البداية.
معظم بدائل الأمان المتاحة حاليًا تتعامل بصورة ردّ فعل مع تهديدات محتملة أو تجريبية، عبر التدقيق في mempools أو كود العقود الذكية. يساعد هذا في ضمان الأمان، لكنه لا يعالج—بشكل جذري—ثغرات تصميم VM نفسها. يجب أن يكون هناك نهج أكثر استباقية، مع استثمار المزيد من الموارد لتحسين أمان شبكات البلوكشين وطبقة التطبيقات بشكل شامل.
نحن ندعو إلى إجراء إعادة هيكلة جذرية لبنية VM الخاصة بالبلوكشين، عبر إدخال حماية فورية وميزات أمان محورية أخرى، وذلك عبر مثلًا بنية Double VM، بما يحاكي معايير صناعية خاضت التجربة في العالم الواقعي مثل معايير قطاع الطيران الذي أثبت نجاحه. وفي المستقبل، ندعم تحسينات في البنية التحتية تركز على الإجراءات الوقائية لضمان أن يرتبط تحسن الأمان بتقدم الصناعة في جانب الأداء (مثل EVM المتوازي).
الخلاصة
يمثل صعود EVM المتوازي بداية عصر جديد في تطور تقنيات البلوكشين. من خلال تمكين التنفيذ المتوازي للمعاملات وتحسين الوصول إلى الحالة، يفتح آفاقًا جديدة للتطبيقات اللامركزية. بدءًا من إحياء CLOBs القابلة للبرمجة وحتى ظهور تطبيقات أكثر تعقيدًا وعالية الأداء، فإن EVM المتوازي يضع الأساس لنظام بلوكشين أكثر توحيدًا وسهولة للمستخدم. ومع قبول الصناعة تدريجيًا لهذا التحول، يمكننا توقع نموٍ انفجاري لإمكانات التقنيات اللامركزية. وفي النهاية، ستعتمد نجاح هذه الثورة على قدرة المطورين ومقدمي البنية التحتية والمجتمع الأوسع على التكيف مع مبادئ المعالجة المتوازية، لاستقبال مستقبل يمتزج فيه التقدم التقني بسلاسة مع الحياة اليومية.
يمتلك صعود EVM المتوازي القدرة على تغيير تطبيقات اللامركزية وتجربة المستخدم جذريًا. فهو يحل قيود قابلية التوسع والأداء التي كانت تعيق منذ فترة طويلة تطور مجالات رئيسية مثل DeFi، ويفتح طريقًا جديدًا لازدهار تطبيقات معقدة وعالية الإنتاجية، مع الحفاظ على معالجة متوازنة لمعضلة الثلاثية. وتحقيق هذه الرؤية لا يتطلب تقدمًا في البنية التحتية وحده؛ بل يجب أيضًا على المطورين إعادة التفكير جذريًا في بنية تطبيقاتهم لتكييفها مع مبادئ المعالجة المتوازية: تقليل تنازع الحالة، وزيادة قابلية التنبؤ بالأداء إلى أقصى حد. ورغم أن المستقبل واعد، نؤكد أن السعي نحو قابلية التوسع يجب ألا يطغى على أهمية الأمان—فهي لا غنى عنها.