تقرير بحثي عن العمق في الحوسبة المتوازية Web3: المسار النهائي للتوسع الأصلي

1. المقدمة: التوسع هو موضوع أبدي، والتوازي هو ساحة المعركة النهائية

واجه نظام blockchain منذ نشأته مشكلة التوسع هذه. عدد المعاملات في الثانية لبيتكوين وإيثيريوم (TPS) منخفض جداً، ولا يمكن مقارنته بنظام Web2 التقليدي. هذه ليست مشكلة يمكن حلها ببساطة عن طريق زيادة عدد الخوادم، بل هي قيود نظامية في التصميم الأساسي لل blockchain، أي "اللامركزية، والأمان، وقابلية التوسع".

على مدى العقد الماضي، تطورت تقنيات التوسع باستمرار، من الجدل حول توسيع البيتكوين إلى تقسيم الإيثيريوم، ومن قنوات الحالة وPlasma إلى Rollup وblockchain القابلة للتعديل، وقد سلكت الصناعة بأكملها طريق توسيع مليء بالخيال. يعد Rollup حلاً شائعًا حاليًا للتوسع، حيث حقق هدفًا كبيرًا في زيادة TPS. لكنه لم يصل بعد إلى الحد الأقصى الحقيقي لـ"أداء السلسلة الواحدة" في الطبقة الأساسية من blockchain، خاصة في جانب التنفيذ، حيث لا يزال مقيدًا بنموذج الحساب التسلسلي داخل السلسلة هذا.

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

في الواقع، في نموذج حساب Web2، تم استبدال البرمجة المتزامنة منذ زمن طويل بالبرمجة المتوازية، والجدولة غير المتزامنة، وغيرها من النماذج. ومع ذلك، لم تتمكن تقنية blockchain كنظام حسابي أكثر بدائية وحفاظًا من الاستفادة الكاملة من هذه الأفكار المتوازية. قدمت سلاسل جديدة مثل Solana وSui وAptos التوازي على مستوى البنية، وفتحت هذه الاستكشافات أولاً؛ بينما قامت مشاريع مثل Monad وMegaETH برفع التوازي داخل السلسلة إلى اختراقات أعمق، مما يظهر خصائص تقترب بشكل متزايد من أنظمة التشغيل الحديثة.

يمكن القول إن الحوسبة المتوازية ليست مجرد وسيلة لتحسين الأداء، بل هي نقطة تحول في نموذج تنفيذ blockchain. إنها تتحدى النموذج الأساسي لتنفيذ العقود الذكية، وتعاد تعريف المنطق الأساسي لمعالجة المعاملات. إذا كانت Rollup تعني "نقل المعاملات إلى التنفيذ الخارجي"، فإن الحوسبة المتوازية على السلسلة تعني "بناء نواة حوسبة فائقة على السلسلة"، وهدفها هو توفير بنية تحتية مستدامة حقًا لدعم تطبيقات Web3 الأصلية في المستقبل.

بعد تقارب مسار Rollup، أصبحت المعالجة المتوازية داخل السلسلة متغيرًا حاسمًا في المنافسة الجديدة لطبقة 1. هذه ليست مجرد مسابقة تقنية، بل هي أيضًا معركة من أجل النموذج. من المحتمل أن يولد الجيل التالي من منصات التنفيذ السيادية في عالم Web3 من هذه المعركة على المعالجة المتوازية داخل السلسلة.

٢. صورة شاملة لنموذج التوسيع: خمس مسارات، كل منها يركز على جانب معين

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

النوع الأول من الطرق هو التوسع المباشر على السلسلة، ويمثل الممارسات مثل زيادة حجم الكتلة، وتقليل وقت إنتاج الكتلة، أو تحسين الهيكل البيانات وآلية الإجماع لزيادة القدرة على المعالجة. لقد أصبحت هذه الطريقة محور النقاش في صراع توسيع بيتكوين، مما أدى إلى ظهور انقسامات "الكتل الكبيرة" مثل BCH وBSV، كما أثرت على أفكار تصميم سلاسل الكتل ذات الأداء العالي المبكرة مثل EOS وNEO. تتمثل مزايا هذه الطرق في الحفاظ على بساطة التوافق في السلسلة الواحدة، مما يسهل فهمها ونشرها، لكنها أيضًا عرضة لمخاطر المركزية، وزيادة تكاليف تشغيل العقد، وصعوبة المزامنة، وبالتالي لم تعد الحلول الأساسية السائدة في تصميم اليوم، بل أصبحت أكثر تكاملًا مع آليات أخرى.

النوع الثاني من المسارات هو توسيع خارج السلسلة، ويمثله قنوات الحالة (State Channels) وسلاسل جانبية (Sidechains). الفكرة الأساسية لهذه المسارات هي نقل معظم نشاط المعاملات إلى خارج السلسلة، وكتابة النتائج النهائية فقط في السلسلة الرئيسية، حيث تعمل السلسلة الرئيسية كطبقة تسوية نهائية. من الناحية الفلسفية التقنية، فإنها قريبة من فكرة الهيكل غير المتزامن في Web2. بالرغم من أن هذه الفكرة يمكن أن تتوسع نظريًا بلا حدود في القدرة على المعالجة، فإن نموذج الثقة في المعاملات خارج السلسلة، وأمان الأموال، وتعقيد التفاعلات، وغيرها من القضايا تجعل تطبيقها مقيدًا. على سبيل المثال، على الرغم من أن شبكة Lightning لها موضع مالي محدد، إلا أن حجم النظام البيئي لم يتفجر أبدًا؛ بينما التصميمات العديدة المعتمدة على السلاسل الجانبية، مثل Polygon POS، كشفت في الوقت نفسه عن العيوب في القدرة على وراثة أمان السلسلة الرئيسية.

النوع الثالث من الطرق هو مسار Layer2 Rollup الأكثر شعبية والأكثر انتشارًا حاليًا. هذه الطريقة لا تغير مباشرةً سلسلة الكتل الرئيسية نفسها، ولكنها تحقق التوسع من خلال آلية التنفيذ خارج السلسلة والتحقق داخل السلسلة. يتمتع Optimistic Rollup و ZK Rollup بمزايا مختلفة: الأول سريع وذو توافقية عالية، لكن لديه مشاكل في فترة التحدي وآلية إثبات الاحتيال؛ بينما الثاني يتمتع بأمان قوي وقدرة جيدة على ضغط البيانات، لكنه معقد في التطوير ولا يتوافق بشكل كافٍ مع EVM. بغض النظر عن نوع Rollup، فإن جوهره هو تفويض حقوق التنفيذ، مع الاحتفاظ بالبيانات والتحقق على السلسلة الرئيسية، مما يحقق توازنًا نسبيًا بين اللامركزية والأداء العالي. النمو السريع لمشاريع مثل Arbitrum وOptimism وzkSync وStarkNet يثبت جدوى هذا المسار، ولكنه يكشف أيضًا عن الاعتماد المفرط على توفر البيانات (DA)، والتكاليف المرتفعة، وتجربة التطوير المقطعة كعقبات متوسطة المدى.

النمط الرابع هو بنية blockchain المعيارية التي ظهرت في السنوات الأخيرة، مثل Celestia و Avail و EigenLayer. يدعو النموذج المعياري إلى فك ارتباط الوظائف الأساسية لل blockchain تمامًا، حيث تقوم عدة سلاسل متخصصة بأداء مهام مختلفة، ثم يتم تجميعها في شبكة قابلة للتوسع بواسطة بروتوكولات عبر السلاسل. يتأثر هذا الاتجاه بشكل عميق بهياكل أنظمة التشغيل المعيارية ومفاهيم الحوسبة السحابية القابلة للتجميع، وتتمثل مزاياه في القدرة على استبدال مكونات النظام بمرونة، وزيادة كفاءة معينة في ( مثل DA). ولكن التحديات واضحة جدًا: بعد فصل المكونات، فإن تكاليف التزامن والتحقق والثقة المتبادلة بين الأنظمة مرتفعة جدًا، كما أن النظام البيئي للمطورين متشظي للغاية، ومتطلبات المعايير البروتوكولية على المدى المتوسط والطويل والأمن عبر السلاسل أعلى بكثير من تصميم السلاسل التقليدية. في جوهرها، لا يبني هذا النموذج "سلسلة"، بل يبني "شبكة سلاسل"، مما يضع عتبة غير مسبوقة لفهم الهيكل العام والصيانة.

آخر نوع من المسارات، وهو ما سيتم تحليله重点 في هذا المقال، هو مسار تحسين الحوسبة المتوازية داخل السلسلة. على عكس الأنواع الأربعة السابقة التي تعتمد بشكل رئيسي على "التقسيم الأفقي" من منظور هيكلي، تركز الحوسبة المتوازية على "الترقية العمودية"، أي معالجة المعاملات الذرية بشكل متزامن من خلال تغيير بنية محرك التنفيذ داخل سلسلة واحدة. وهذا يتطلب إعادة كتابة منطق جدولة VM، وإدخال تحليل الاعتماد على المعاملات، وتوقع تضارب الحالة، والتحكم في درجة التوازي، والاستدعاء غير المتزامن، وغيرها من آليات جدولة أنظمة الحاسوب الحديثة. تعتبر Solana من أوائل المشاريع التي وضعت مفهوم VM المتوازية في نظام السلسلة، من خلال تحقيق تنفيذ متوازي متعدد النواة عبر تحديد تضارب المعاملات بناءً على نموذج الحساب. أما المشاريع من الجيل الجديد مثل Monad وSei وFuel وMegaETH، فقد حاولت أكثر من ذلك من خلال إدخال تنفيذ خطي، وتزامن متفائل، وتقسيم التخزين، وفصل التوازي، وغيرها من الأفكار المتقدمة، لبناء نواة تنفيذ عالية الأداء تشبه CPU الحديثة. تتمثل الميزة الأساسية في هذا الاتجاه في أنه يمكن تحقيق اختراق حدود الإنتاجية دون الاعتماد على بنية متعددة السلاسل، بينما يوفر نفس الوقت مرونة حسابية كافية لتنفيذ العقود الذكية المعقدة، وهو شرط تقني مهم لتطبيقات مثل AI Agent، والألعاب الكبيرة على السلسلة، والمشتقات عالية التردد.

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

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

ثلاثة، خريطة تصنيف الحوسبة المتوازية: خمسة مسارات من الحسابات إلى التعليمات

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

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

استنادًا إلى نموذج الحساب، نتعمق أكثر في المستوى التقني للتوازي على مستوى الكائنات. يقدم التوازي على مستوى الكائنات تجريدًا دلاليًا للموارد والوحدات، حيث يتم جدولة التزامن بناءً على وحدات "كائن الحالة" ذات الحبيبات الدقيقة. تُعتبر Aptos وSui من المستكشفين المهمين في هذا الاتجاه، خصوصًا أن الأخيرة من خلال نظام النوع الخطي للغة Move، تحدد ملكية الموارد وقابليتها للتغيير في وقت الترجمة، مما يسمح بالتحكم الدقيق في تضارب الوصول إلى الموارد في وقت التشغيل. هذه الطريقة تعتبر أكثر عمومية وقابلية للتوسع مقارنة بالتوازي على مستوى الحساب، حيث يمكنها تغطية منطق قراءة وكتابة الحالة الأكثر تعقيدًا، وتخدم بشكل طبيعي مجالات مثل الألعاب، الاجتماعية، والذكاء الاصطناعي، التي تتميز بدرجة عالية من التباين. ومع ذلك، فإن التوازي على مستوى الكائنات يقدم أيضًا عائقًا لغويًا أعلى وتعقيدًا في التطوير، حيث أن Move ليست بديلًا مباشرًا لـ Solidity، وتكلفة التحول البيئي مرتفعة، مما يحد من سرعة انتشار نمط التوازي الخاص بها.

العمق في المعاملات المتوازية هو الاتجاه الذي تستكشفه سلاسل الجيل الجديد عالية الأداء مثل Monad وSei وFuel. لم يعد هذا المسار يعتبر الحالة أو الحساب كوحدة التوازي الدنيا، بل يقوم ببناء مخطط الاعتماد حول المعاملة التجارية بأكملها. وهو يعتبر المعاملة كوحدة عملية ذرية، من خلال التحليل الثابت أو الديناميكي لبناء مخطط المعاملة )Transaction DAG(، ويعتمد على المجدول لتنفيذ التدفقات المتزامنة. يسمح هذا التصميم للنظام بتعظيم الاستفادة من التوازي دون الحاجة إلى فهم كامل لبنية الحالة الأساسية. يُعتبر Monad بارزًا بشكل خاص، حيث يجمع بين التحكم المتفائل في التزام المعاملات )OCC(، جدولة التدفقات المتوازية، والتنفيذ غير المرتب، وغيرها من تقنيات محركات قواعد البيانات الحديثة، مما يجعل تنفيذ السلسلة أقرب إلى نموذج "مجدول GPU". في الممارسة العملية، تتطلب هذه الآلية مديري اعتماد معقدين للغاية وكاشفات تعارض، وقد يصبح المجدول نفسه عنق الزجاجة، ولكن