الفيديو الأخير جاهز: فهم نموذج تطوير BTC L2 في نفس واحد ~ https://www.bilibili.com/video/BV1dw411575M/?vd_source=e88bbc11f1ecd88d1c5847538efee51c
أصبحت المنافسة في Alt L1 شرسة، وقد أطلقت شركة Near حل DA، كما أن شبكة TVL الخاصة بـ Sui آخذة في الارتفاع. ولا تزال Ethereum هي الوحيدة التي لا تزال تقوم بتحديث شبكتها الرئيسية ببطء. وقد ظهرت نقطتان رئيسيتان للمنافسة في L2: EVM المتوازي والتسلسل اللامركزي.
في الوقت الحاضر وفي المستقبل، الحقيقة الأساسية هي أنه من الصعب زعزعة وضع Ethereum، وسيتم تعميم مفهوم النمطية. إذا لم ينجح قمع Vitalik لـ Celestia، فسيختار السوق الأفضل لا تحدث فقط في نفس المكان، داخل النظام، ستشجع مبادئ السوق أطراف المشروع على تجميع عناصر مختلفة بحرية، مثل التوافر المشترك للسلاسل العامة المختلفة، L2 وBitcoin، كما يتضح من شعبية BTC L2.
إذا تمكنت Near من القيام بعمل DA، فستصبح سلاسل عامة عالية الأداء مثل Aptos وSolana وSui أيضاً «L2»، وفي النهاية تصبح متوافقة مع إيثيريوم ويتم «الاستيعاب» فيها.
يمكن فهم EVM المتوازي كأنه سلاسل/L2 متوافقة مع EVM تم توازيها. ويمكن البدء من سرعة البلوكشين: نظرياً، لا توجد سوى طريقتان لحل بطء تشغيل البلوكشين:
زيادة العتاد وتحسين مستمر للتوليف. مثل إعدادات العتاد الفريدة الرفيعة لدى Solana: إدارة وتكوين «غرفة الخوادم» يمكن أن تمنح Solana شبكة فائقة السرعة وتزيد الإنتاجية؛
توازي على عدة نوى + تزامن على خيوط متعددة. بعد تحسين العتاد، يمكن للـ multi-core أن تحقق فعلاً تعدد المهام. بالإضافة إلى ذلك، فإن تقسيم المهام باستمرار إلى أجزاء أدق يمكن أن يرفع الكفاءة، وهذا أيضاً نهج شائع في الحوسبة العامة.
بافتراض أن استغلال العتاد وصل إلى أقصى حد، يمكن تصنيف وفهم EVM المتوازي عبر ثلاث طبقات من التالي:
التوازي أسلوب شائع في مجال الحوسبة، ويمكن لأي سلسلة عامة وL2 استخدامه. مثل Aptos وSui وSolana كـ Alt L1، أو Sei التي تدّعي أنها أول L1 متوافق مع EVM، وكذلك مشاريع L2 على الإيثيريوم مثل Scroll (خارطة الطريق 2024)، وLumio، وEclipse، وحلول التوافق مع EVM على السلاسل غير المتجانسة مثل Neon EVM. Neon EVM ينتمي إلى نظام Solana البيئي، ويزعم أيضاً أنه أول من يتوافق مع EVM.
بالمعنى الضيق، يشير EVM المتوازي إلى L1/L2 القادر على التوافق مع EVM. نظرياً، يمكن لإيثيريوم نفسها أيضاً إجراء تعديل للتوازي؛ وهذا هو EVM المتوازي الأكثر مطابقة للتعريف. لكن حجم التغيير كبير لدرجة أنه شبه مستحيل وجوده؛
بالمعنى الواسع، يمكن توسيع مفهوم EVM المتوازي ليشمل أي سلسلة حوسبة متوازية. سواء كانت متوافقة مع EVM أم لا، طالما يمكن ربطها بـ EVM، فيمكن إدراجها ضمن هذا التصنيف. مثل اعتبار Aptos «معزّزاً» لإيثيريوم.
دراسة Alt L1 غير المتوافق مع EVM لها أيضاً معنى خاص: يمكن ربطها بالنظام البيئي لـ EVM. إضافة إلى ذلك، فإن خطة Block-STM التي ابتكرتها Aptos أصبحت مصدراً فعلياً لقالب ومصدر أفكار لكثير من حلول EVM المتوازي الناشئة. وسنتناول ذلك بالتفصيل في ما يلي.
تمهيد: شرح مبسط للـ threads وprocesses والتوازي والتزامن، وعلاقتها بـ EVM
أنا صنّفت الفكرة على طول مسار تفكيك EVM المتوازي، لكن شرح مفهوم التوازي ما زال غير كامل. ولو أننا انتقلنا مباشرة إلى منطق تنفيذ المشاريع، سيشوش الأمر على الناس—كأننا نوصلها بطريقة تجعل الفهم مستغلقاً وكأنها تُدخلهم في غفلة من غير قصد.
وبالمثل، مثل تفسير: «الـ process هو أصغر وحدة لتخصيص الموارد، و الـ thread هو أصغر وحدة لجدولة المعالج CPU». ورغم أنه تفسير احترافي، إلا أنه لا يكون مناسباً لمعظم الناس. لذلك أريد استخدام مثال شراء البطيخ لشرح العملية.
لِنمهّد أولاً: أعمق طبقة في حاسوبنا هي العتاد الفيزيائي، وفوقه تأتي أنظمة التشغيل وتطبيقات مختلفة. عندما يعالج الحاسوب مهمة، فإنه يوزّع موارد البرامج والعتاد بناءً على الأولوية. ولتوضيح هذه العملية سنستخدم مثال اشتراء البطيخ من هوا تشيانغ:
العلاقة بين الـ threads وprocesses والتوازي والتزامن
يركب هوا تشيانغ دراجته ليشتري بطيخاً واحداً—هذا فعل واحد، وأيضاً الوحدة الأصغر. إنه thread واحد: بطيخ واحد هنا هو الموارد الفيزيائية القابلة للاستدعاء، ولا يوجد أكثر؛
اثنان من هوا تشيانغ يذهبان معاً ليشتريا بطيخاً واحداً. هذا سلوك مركّب لأن لدينا شخصين يريدان أكل البطيخ. لكن انتبه: ما زال هناك بطيخ واحد فقط، ولا يزيد. واتفقا أيضاً على أن يقطعا البطيخ معاً؛ ومن لا يذهب ليس أخاً. لذا فإن ذهاب الاثنين لشراء البطيخ هو process واحد. وما زال أكل كل واحد يتم عبر thread واحد؛ لذلك داخل process واحد يوجد threadان.
في هذه اللحظة، حالة وجود بطيخ واحد لكن يجب أن يأكل منه عدة أشخاص هي التزامن (concurrency). النقطة الأساسية هنا أن الجميع يأكل لقمة على الأقل. فمهما كان عدد آكلي البطيخ، وكيف يتم ترتيب المقاعد أو التسلسل فيما بينهم، لا يؤثر ذلك في النتيجة النهائية: نفس البطيخ يُؤكل منه الجميع.
أكيد أن ذكاءك لاحظ المشكلة: لماذا نحتاج كل هذه الأعداد كي يأكلوا بطيخاً واحداً معاً؟ في جوهر الأمر، صاحب كشك البطيخ هو نفسه صاحب متجر الفواكه. ويمكنك أيضاً تناول موز! نعم، هذا بالضبط سبب الحاجة إلى إصلاح جانب العرض. والآن يعلن صاحب الكشك أن الموز أصبح متاحاً في السوق. عندها تزداد الموارد الفيزيائية (الفواكه)، فيمكن لهوا تشيانغ أن ينقسم إلى صفّين: كل صف يأخذ نوعاً مختلفاً من الفاكهة ليأكل. هذا هو التوازي: صفّان جنباً إلى جنب، كل واحد يأخذ ما يحبه.
(تنبيه ضد سوء الفهم): الشرح أعلاه مبسّط أكثر من كونه احترافياً؛ إن كانت هناك خلافات فمرجعها هو فهم المبرمجين، وأنا من خريجي النصف-تعليم/الوسط؛
الخطوة التالية هي دمجها مع EVM معاً، وتجميع الفهم الحقيقي لـ EVM المتوازي.
مع أن EVM يُذكر كثيراً، إلا أن المقصود الحقيقي منه غير واضح ومبهم، خصوصاً أن الآلة الافتراضية (VM) توحي دائماً بشيء بعيد عن الواقع. في الحقيقة، إذا لم نُدقق كثيراً: الآلة الافتراضية هي نظام تشغيل متخصص. لا يحتاج المبرمجون إلى التطوير باتجاه الكيانات الفيزيائية؛ كل ما يحتاجونه هو التكيّف على مستوى البرمجيات.
تبسيطاً: وظيفة EVM هي تنفيذ المعاملات. يقوم المستخدم بإرسال التعليمات، وبعد ذلك ينفذ EVM بدوره كل ما يحتاجه المستخدم—مثل التحويل أو SWAP أو الرهن أو أي سلوك آخر يتفاعل مع عقد ذكية. النقطة الأساسية هنا هي «التعليمات» و«تنفيذها واحداً تلو الآخر». يمكن فهم متطلبات المستخدم عبر EVM، لكن التنفيذ يحتاج إلى طابور ولا يمكن تغيير الترتيب بشكل عشوائي.
لذلك فإن EVM المتوازي، في جوهره، هو تغيير ترتيب التنفيذ، ما يسمح لعدة عقود ذكية (تعليمات) بالعمل في نفس الوقت. تخيّل الأمر كأنك تنصّب صاحب كشك يبيع البطيخ ويستأجر عمّالاً: يبيع هو عصير البطيخ، بينما يبيع أتباعه موزاً… وفي النهاية الربح يعود إلى صاحب الكشك.
شرح EVM
الأكثر نموذجية هو ما ذكرته في مقالي السابق حول BTC L2. في الوقت الحالي، معظم BTC L2 تهدف إلى ربط بيتكوين بنظام EVM البيئي. في الواقع، هي في حد ذاتها مجرد آلة افتراضية فوق البيتكوين. لذلك عندما يطوّر المطوّرون عليها، لن يضطروا إلى التفكير في قيود بنية بيتكوين ولغة البرمجة؛ يمكنهم إتمام التطوير مباشرة بخطوات عملية تطوير EVM المألوفة.
EVM في هذا يشبه ذلك تماماً. وبإيجاز شديد: إذا كنت مجرد Frontend، فيمكنك حتى بناءً على وثائق بدون أن تفهم عتاد الحاسوب أو مبادئ نظام التشغيل أو مبادئ الإيثيريوم؛ كل ما تحتاجه هو فهم شرح أدوات تطوير EVM وواجهاته. مثلاً كتابة واجهة frontend لـ DEX (للتفسير النظري فقط—وفي الواقع الأمر معقد جداً).
بعبارة واحدة: الآلة الافتراضية (VM) هي ورشة عمل بعد تجريد العتاد والمبادئ. فمثلاً إذا كان هوا تشيانغ يريد أن يصنع عصير بطيخ، فالآلة الافتراضية هي عصّارة. كوب عصير بطيخ يحتاج ثلاث خطوات فقط: افتح الغطاء، ضع البطيخ، ثم اعصر… وانتهى الأمر.
وبالطريقة نفسها، EVM هو عصّارة إيثيريوم، والتوافق مع EVM هو عصّارة «بديل من باكيت متعدد البائعين» اشتراها L1/L2. ورغم وجود بعض العيوب، يمكن استخدامها. أما EVM المتوازي فهو أن تعمل عدة عصّارات معاً.
ليس أن اليدوي غير ممكن، لكن العصّارة أكثر فعالية من حيث التكلفة.
وأخيراً، ظهر مفهوم EVM المتوازي مجدداً في الساحة. جوهره أن إيثيريوم لا تستطيع معالجة معاملة واحدة في كل مرة إلا بشكل متسلسل، وبالتالي حدود السرعة تنشأ من ذلك؛ فتستطيع شبكة mainnet TPS البقاء مستقراً عند حوالي 10 فقط. حتى سلاسل EVM المتوافقة وأكثر مركزية مثل BNB Chain (BSC) لا تستطيع إلا رفعها إلى حوالي 200. ومع عدم وجود اختراق ثوري في العتاد الفيزيائي، وعدم إمكانية تعديل إيثيريوم نفسها لتصبح آلية توازي، فإن سوق EVM المتوازي سيظل حاراً على المدى الطويل… لأن لا أحد يكره السرعة العالية.
الوضع الحالي: التحقق المتفائل صار إجماعاً، وكأن Move أخذ يلوح له إنقاذ
مفهوم التوازي وVM موجودان منذ وقت طويل، لكن إدخالهما إلى البلوكشين—وخاصة مفهوم EVM المتوازي—انطلق فعلياً من عام 2022. أصدرت Aptos ورقة بعنوان (Block-STM: Scaling Blockchain Execution by Turning Ordering Curse to a Performance Blessing). بعدها حاولت سلسلة Polygon PoS إضافة هذه الوظيفة في نهاية ذلك العام. وليس ذلك فقط؛ فالعديد من الخطط والأفكار التي طرحتها Aptos في تلك الورقة أصبحت أيضاً خيارات مشتركة في الصناعة وتتطلب تقديمها.
مشاريع EVM المتوازي وتصنيفاتها
نقطة الانطلاق من الحلم: Block-STM
يمكن القول إن Aptos هي المجمّع الأكبر لإنجازات توازي السلاسل. صحيح أن Solana وNear قد استكشفتهما مسبقاً، لكن Aptos تعيد ترتيب المعاملات من جديد عبر STM (Software Transactional Memory) المستخدم في تطبيقات البلوكشين. الفكرة الأساسية: نفترض أن المعاملات بعد الترتيب صحيحة؛ ثم نُنفّذ بالتوازي؛ وعند اكتشاف معاملات غير صحيحة، نحل مشكلاتها لوحدها، وفقاً لقاعدة 80/20. وبهذا يمكن تسريع معظم المعاملات. وهذا ما يُسمى آلية «التحقق المتفائل». وهي مشابهة جداً لفكرة التحقق المتفائل في Rollup.
Block-STM
بالتحديد، يقسم Block-STM عملية تنفيذ سلسلة الكتل إلى مرحلتين: مرحلة الترتيب ومرحلة التنفيذ.
في مرحلة الترتيب، يستخدم Block-STM STM لترتيب المعاملات وضمان تسلسلها الصحيح؛
في مرحلة التنفيذ، يستخدم Block-STM نتيجة الترتيب لتنفيذ المعاملات بشكل متوازٍ، مما يحسن كفاءة التنفيذ.
بعد ذلك، فإن معظم EVM المتوازي تشبه هذا الأسلوب في الأساس، مع أن هناك اختلافات في ترتيب التنفيذ وآلياته الفعلية، كما يلزم إضافة التوافق مع EVM. مثل Neon EVM وPolygon PoS اللذين ينتميان إلى هذه الفئة.
تعديل Sui: كل شيء كائن
Sui وAptos من نفس المدرسة/المصدر (أصدقاء/أشقاء في الأصل)، وكلاهما متشابه جداً، لكن أكبر فرق هو أن Sui يجعل «الكائن (Object)» محوراً. مثلاً في عملية التحويل من Alice إلى Bob تكون الطريقة كما يلي:
Aptos: حساب Alice يُطرح منه 1 USDT، وحساب Bob يُضاف إليه 1 USDT. هذا يشمل معلومات المحاسبة وتغيّر الرصيد في حسابين.
Sui: تبقى 1 USDT كما هي، لكن يتم تغيير صفة ملكيتها فقط: تنتقل الملكية من Alice إلى Bob، وبذلك يتم فقط تعديل معلومات 1 USDT؛
كما ترى، نقطة انطلاق Sui لا تبحث عن حسابات الطرفين في المعاملة، بل عن تغيّر خصائص الأشياء. ومن خلال التعميم، لا يقتصر الأمر على نقل الرموز؛ بل يمكن أن يشمل أصولاً مثل NFT أيضاً.
ثم نوسع قليلاً: إذا كانت إحدى الأصول لا تتضمن إلا تغييرات في خصائصها بين طرفين فقط، فليس هناك حاجة لمزامنة العقدة بالكامل. يكفي أن يتفق الطرفان على هذه المعاملة. وبهذا الشكل يمكن معالجة مثل هذه المعاملات بشكل متوازٍ.
بالطبع، التنفيذ المحدد لكليهما أعقد بكثير، كما أن التوازي يجلب معه مشاكل كثيرة. لكن فهمنا حتى هنا يكفي.
Solana وNeon EVM: طرح تحت نفس الغطاء
الطريقة التي تعتمدها Solana أصلاً لتحقيق المعالجة المتوازية هي عبر آلية Sea Level، وهي شبيهة بـ Block-STM (وبالواقع يجب أن نعكس: Sea Level طرحت في 2019، بينما Block-STM ظهر في 2022). وفي الحالتين تحتاجان إلى ترتيب المعاملات، ثم تنفيذها.
الـ«ابتكار» في Solana يتمثل في تحسين مخصص لموارد العتاد. نظرياً، لا يمكنه فقط ترتيب جميع التعليمات، بل إن خيوط العمل المتعددة بعد تحسينها يمكن أن تستفيد من كامل كفاءة المعالج لتحقيق تأثير تزامن عالي. القيمة النظرية لـ TPS هي 50 ألف، وبالقياس الفعلي قد يصل القمم إلى حوالي 5 آلاف.
فما علاقة ذلك بـ Neon EVM؟
تكلفة Neon EVM
ما الذي ستفعله Neon؟ هي مزامنة معلومات معاملات EVM أولاً، ثم تستخدم Solana للقيام بالحساب. بهذه الطريقة يمكنها الاستفادة من ثراء dApp ضمن نظام EVM ومن ضمانات الأمان، وفي الوقت نفسه الاستفادة من Solana لتسريع التنفيذ وخفض التكاليف. مقارنةً بالشبكة الرئيسية للإيثيريوم الباهظة والبطيئة، فإن تصريح Neon، والتحويل، واقتراض/إيداع الأموال تكون أساساً أقل من 0.1 وحتى 0.01 دولار.
وإن لم يكن ذلك دقيقاً تماماً، فإن Neon حوّلت Solana إلى L2 بديل لإيثيريوم. ومن هذا المنطلق يمكن أن يكون L1/L2 المتوافق مع EVM ليس فقط قادراً على تنفيذ التوازي بنفسه؛ بل يمكن أيضاً أن يعمل كوسيط: يحتفظ لنفسه مهمة التوافق مع EVM أو القيام بدور L1/L2 فقط، بينما يتم تفويض بقية الأجزاء لطرف خارجي.
وهذا أيضاً ما قلته في البداية: المعنى الحقيقي للتجزيء/التعميم المعياري. يمكن أن يكون EVM المتوازي على مستوى L1/L2 ناتجاً عن تركيب ثلاثة مشاريع بالكامل. وحتى يمكن أن يكون تركيباً عبر سلاسل مختلفة. وبذلك تصبح طريقة اللعب متنوعة جداً.
Sei V2 وMonad: سعادة معاً، توافق Byte
من ناحية التنفيذ التقني، فإن Sei V2 وMonad متشابهان جداً: كلاهما توافق EVM على مستوى الـ byte مع الإيثيريوم. وفي الواقع، في جانب فكرة التوازي، اختارت كلتاهما نفس النهج بالضبط دون اتفاق مسبق: التحقق المتفائل المألوف. ترتّب أولاً، وتنّفذ ما يمكن تنفيذه، وإذا حدث خطأ فتعالج التبعيات بشكل منفصل.
شرح حل التوازي لـ Sei V2
بالطبع، يمكن للجميع استخدام المنتجات والأفكار الناضجة، لكن انتبه: مثل BTC L2، الابتكار التقني الحقيقي ليس كثيراً؛ ما زال الاعتماد الأكبر على «التركيبات». Solana هي الوحيدة التي طبقت التوازي على نطاق واسع، وأيضاً التي حققت نتائج تزامن عالي من خلال تناغم العتاد والبرمجيات. أما غيرها، فغالباً ما تكون «باقة EVM متوافق + توازي».
لا بد أن الجميع قد فكر: بما أن Solana يمكن اعتبارها «معزّزاً»، فمن الممكن أيضاً أن تكون Aptos وغيرها مثل ذلك. في الواقع، Lumio أيضاً تفكر بهذه الطريقة. طالما أن نفسك تعمل كوسيط: من جهة تتوافق مع EVM، ومن جهة أخرى تنفذ التوازي، فيمكن تسميته EVM متوازي. لذلك لن أشرح Lumio بإفراط بعد الآن.
الخاتمة: مأزق EVM المتوازي
في هذه المقالة، أركز على أن جوهر EVM المتوازي هو توزيع موارد العتاد وتنفيذ المهام مع مراعاة ترتيبها، وهاتان لا غنى لأحدهما عن الأخرى. الحد الأعلى للتحسين البرمجي مقيد بإعدادات العتاد الفيزيائي—لأن حتى يوسين بولت لا يمكنه تجاوز سرعة الضوء. لكن حتى الآن، فإن معظم حلول EVM المتوازي هي في الأساس تعديلات وتقليد لـ Block-STM في Aptos، وهذه حقيقة أساسية.
بالإضافة إلى ذلك، حالياً لا يلزم استكشاف مبالغ فيه لممارسات التوازي على L2 الخاصة بإيثيريوم؛ فهي أكثر حاجة لحل مشكلة مركزية المُرتّب/الـ sorter. والكفاءة حالياً كافية.
EVM المتوازي ليس شيئاً غامضاً. في كتابتي، أغفلت تفاصيل آليات القراءة/الكتابة لدى كل مشروع، ومقارنات TPS، وتسجيل البيانات ومزامنة الحالة وغيرها من التفاصيل التقنية. ولا حاجة لعامة الناس لتعلّم هذه الأمور. يكفي أن تحفظ أن الوضع حالياً هو «تحقق متفائل» يملأ كل الساحة: الفكرة هي التنفيذ أولاً ثم تصحيح الأخطاء. وإذا ظهر تحديث، سأضيفه فوراً لكم.