تتجه البلوكشين نحو "السلسلة السحابية" مع تلاشي تجريد الغاز

كتابة: فوغي

ما يُسمى بـ"انهيار الغاز" لا يعني أن الغاز سيختفي، بل يعني أن قدرة الغاز على تفسيره كمجرد مورد موحد للبلوكشين تتراجع. هذا التقييم لا يأتي من ترقية تقنية في سلسلة واحدة، بل من أربعة اتجاهات مختلفة تمامًا، جميعها تشير إلى نفس النتيجة.

الاتجاه الأول يأتي من Hyperliquid. المستخدمون الأساسيون لهذا البورصة اللامركزية للعقود الآجلة الدائمة يرون رسوم التداول الخاصة بالـ Maker و Taker يوميًا، وليس رسوم الغاز مضروبة في سعر الغاز. لا يزال HyperEVM يستخدم HYPE كرسوم غاز، ولا تزال رسوم الأساس ورسوم الأولوية وفقًا لـ EIP-1559 قيد التشغيل، لكن طبقة التداول قد عَبَّأت تكلفة الموارد الأساسية ضمن رسوم خدمة التداول. عندما يفتح مستخدم مركزًا طويلًا على BTC، فإنه يشتري التوافق والتسوية، وليس تعليمات الحساب داخل مساحة الكتلة. لم يتم القضاء على الغاز هنا، بل تم إخفاؤه داخل السعر التجاري.

الاتجاه الثاني يأتي من Solana. كان SIMD-0553 في حالة مقبولة ومدمجة، لكن اقتراح الحوكمة المرافق SGP-0003 رُفض في أغسطس 2026، ولم يتم تطبيق نموذج رسوم الموارد على الشبكة الرئيسية حتى الآن. ومع ذلك، فقد أوضحت التقسيمة التي اقترحها — رسوم الإدراج الأساسية ورسوم الموارد المستندة إلى وحدات التكلفة المطلوبة — بوضوح أن Solana تفصل بين تسعير "الإدراج" و"استهلاك الموارد". فرسوم الإدراج الأساسية تجيب على السؤال: "هل تستحق هذه المعاملة الإدراج في الكتلة؟" بينما تجيب رسوم الموارد على السؤال: "ما مقدار الموارد التي تستهلكها هذه المعاملة بالضبط؟" وتعتمد رسوم الموارد على وحدات التكلفة المطلوبة، والتي تسرد بوضوح تكلفة التوقيع، وتكلفة قفل الكتابة، وتكلفة بيانات التعليمات، وتكلفة تنفيذ البرنامج، وتكلفة بيانات الحسابات المحملة. إن Solana نفسها تعيد تقسيم "الغاز" إلى الموارد المحددة التي كانت مخفية سابقًا.

الاتجاه الثالث يأتي من ICP. استخدم Internet Computer دائمًا الدورات بدلاً من Gas، حيث تكون الدورات مرتبطة بـ XDR وتقاس وفقًا للموارد الحقيقية مثل الحوسبة والتخزين وعرض النطاق الترددي والرسائل. وفي عام 2026، ستقدم Cloud Engines خطوة إضافية، حيث يمكن للمستخدمين اختيار العقد، ومزودي العقد، والموقع الجغرافي، وحجم النسخ، ليُكوّن البروتوكول بيئة تنفيذ مخصصة. تسمّي الشركة الرسمية هذا الأمر "شريحة مملوكة من قبل المستخدم من قدرات Internet Computer". عندما يشتري المستخدم بيئة حوسبة بدلاً من معاملة واحدة، فإن مفهوم Gas ينتقل تلقائيًا إلى الخلفية.

الاتجاه الرابع هو الأكثر إثارةً للانتباه، لأنه يأتي من Ethereum نفسه. في 17 أغسطس 2026، أطلقت Ethereum شبكة Platåberget التجريبية كبيئة اختبار علنية مبكرة لترقية Glamsterdam. حذرت الشركة رسمياً مسبقاً: قد تتعطل المحافظ وفهارس تقدير الغاز التي تعتمد على افتراضات ثابتة لحد الغاز بسبب هذه الترقية. قامت Glamsterdam بتعديل تكلفة الغاز لعمليات مثل الوصول إلى الحالة، ورفع EIP-8037 وEIP-8038 على التوالي تكلفة إنشاء الحالة والوصول إليها جزئياً بشكل مستقل، مما يجعل الغاز أقرب إلى العمل الحقيقي للعقد. كما يدفع EIP-7999 قدماً نحو سوق رسوم متعدد الأبعاد موحد. حتى Ethereum نفسها تعيد تقسيم الغاز إلى ما كان مخفيًا في الأصل: الوصول إلى الحالة، والحساب، والبيانات، وأنواع مختلفة من عمل العقد.

عند وضع هذه المسارات الأربعة معًا، يصبح الاستنتاج واضحًا تمامًا. إن الغاز يُجرَّد من كونه جوهر البلوكشين، ويعود ليكون آلية تسويات أساسية في سوق الموارد.

بما أن الغاز يتم تفكيكه، فقد كان من الخطأ منذ البداية أن يركز الصناعة بأكملها على VM خلال العقد الماضي.

EVM هو بيئة تنفيذ العقود الذكية الأقوى في النظام البيئي، ولا يزال تأثير الشبكة المكون من Solidity وOpenZeppelin وFoundry وMetaMask وUniswap وAave لا يُضاهى. لكن EVM كـ "نموذج تنفيذ أساسي للكمبيوتر العالمي" يصبح من الصعب عليه الآن تحمل مسؤولية كاملة كبنية تحتية عالمية للحسابات القابلة للتحقق من الجيل القادم. المشكلة ليست في عدم قدرته على تشغيل البرامج، بل في أنه يدمج التنفيذ والحالة والموارد والإثبات ضمن تجريد واحد.

من منظور نموذج التنفيذ، فإن EVM هي آلة مكدس، وكل عنصر مكدس هو 256-bit. تفضل وحدات المعالجة المركزية الحديثة بنية المسجلات، بينما يرافق كل عملية ADD وMUL في EVM كمًا كبيرًا من التلاعب بالمكدس. يستخدم FuelVM مسجلات بحجم 64-bit، وهي استجابة مباشرة لهذا العبء التاريخي.

من منظور النموذج المتوازي، لا تُعلن معاملات EVM عن تبعيات الحالة، لذا لا يمكن لطبقة التنفيذ جدولة المعاملات مسبقًا. ما إذا كانت معاملتان تصلان إلى نفس الحالة تقريبًا غير مرئي في EVM. أما Sealevel في Solana، فيجعل تبعيات الحالة شيئًا يمكن للمُجدول رؤيته مسبقًا، حيث تُعلن المعاملات عن الحسابات التي تحتاج إلى الوصول إليها، ويحدد المُجدول التبعيات، ثم يُنفّذ المعاملات بالتوازي. هذه الفكرة قريبة جدًا من رسم تبعيات وحدة المعالجة المركزية الحديثة. الثورة الحقيقية في Solana لا تكمن في مجموعة تعليمات sBPF، بل في جعل "من يمكنه التوازي" حالة مخفية في وقت التشغيل لتصبح مواطنًا من الدرجة الأولى في نموذج التنفيذ.

من منظور نموذج الإثبات، فإن بنية مكدس EVM بحجم 256 بت وأسلوب الوصول إلى الحالة غير ملائمة بشكل طبيعي لإثبات ZK. لقد عانى zkEVM لفترة طويلة من تكاليف إثبات مرتفعة جدًا، بينما يجب على السلاسل المستقبلية أن تفترض أن الإثبات سيتبع التنفيذ. إن سبب أهمية RISC-V المتزايدة هو أنه لأول مرة يمنح البلوكشين معيار تنفيذ أساسي يقارب وحدة المعالجة المركزية، مما يسمح بدمج بيئة LLVM وGCC وهندسة السجلات وتوحيد zkVM. إن اتجاه Ethereum وPolkadot نحو RISC-V في آنٍ واحد ليس صدفة.

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

لذلك، المنافسة بين أنظمة المحاكاة الافتراضية بحد ذاتها مسألة زائفة. يقدم EVM عقودًا ذكية عامة قابلة للتركيب، ويقدم SVM تبعيات صريحة وجدولة متوازية، ويقدم Move أمان الموارد، ويقدم RISC-V ISA تنفيذ عامة، ويقدم zkVM تنفيذًا قابلًا للإثبات. في المستقبل، لن يفوز نظام محاكاة افتراضية واحد بشكل منفصل، بل سيتم إعادة تصميم الحاسوب بأكمله.

البلوكشين لم يكن أول من اخترع تسعير الموارد. بل استغرق عشر سنوات لإعادة اكتشاف ما كان معروفًا في صناعة الحوسبة منذ عقود: أن الحوسبة ليست موردًا واحدًا، بل مجموعة من الموارد.

نموذج إيثيريوم الكلاسيكي هو غاز أحادي البُعد، حيث تساوي الرسوم عدد وحدات الغاز المستخدمة مضروبة في سعر الغاز. هذا النموذج بسيط للغاية، لكنه يعاني من مشكلة اقتصادية جوهرية: فالمصادر المختلفة لا يمكن استبدالها ببعضها البعض، ومع ذلك يتم تسعيرها جميعًا برقم واحد. فقد تُسعر معاملة ذات استهلاك عالٍ للـ CPU ولكن استهلاك منخفض للتخزين، ومعاملة أخرى ذات استهلاك منخفض للـ CPU ولكن استهلاك عالٍ للتخزين، ككل منهما 100 غاز. هذا السعر لا يعكس بدقة العوامل الحاسمة الحقيقية للعقد.

كانت EOS تُعالج موارد CPU وNET وRAM كموارد مستقلة منذ عام 2018. كانت RAM ملكية يمكن شراؤها واستخدامها وبيعها مرة أخرى، مع تغير سعرها ديناميكيًا عبر خوارزمية Bancor. أما CPU وNET فكانتا موارد مستأجرة، ثم تطورتا لتصبحا نموذج PowerUp، وهو في جوهره استئجار موارد الحوسبة والشبكة لفترة زمنية معينة. وقد فرّقت EOS مبكرًا بين الموارد المؤقتة والموارد الدائمة، وهو ما سبق تقسيم Sui للحوسبة والتخزين بسنوات عديدة.

تتبع ترون مسارًا مختلفًا. يتوافق Bandwidth مع بايتات المعاملات، وEnergy مع تنفيذ العقود، وTRON Power مع الحوكمة. يحصل المستخدمون على كمية الموارد من خلال رهن TRX، ويمكنهم تفويض الموارد لآخرين. كما تسمح ترون للمطورين الذين ينشئون تطبيقات لامركزية بتحديد نسبة استهلاك موارد المستخدم، مما يتيح لهم تحمل تكلفة Energy مباشرةً بدلاً من المستخدم. هذا يقترب جدًا من مفهومي Paymaster وSponsored Transaction اللذين ظهرا لاحقًا.

أما Hive، فقد تخلت تمامًا عن Gas، واعتمدت تحويل HP إلى RC. لا تعتبر Resource Credits عملات معدنية، بل هي موارد قابلة للتجديد يحصل عليها الحساب بناءً على Hive Power. بعد استهلاك RC، تتعافى تلقائيًا في دورة مدتها خمسة أيام. هذا في جوهره نموذج كوتا مناسب للتطبيقات الاجتماعية وتطبيقات المحتوى، لكنه غير مناسب للتطبيقات المعقدة DeFi والحسابات عالية التردد.

حلت هذه السلاسل القديمة مشكلة "قياس الموارد"، لكنها لم تحل مشكلة "سوق الموارد" و"تجريد الموارد". لا يزال المستخدمون بحاجة إلى فهم مفاهيم CPU وNET وRAM وEnergy وBandwidth لاستخدام السلسلة بشكل طبيعي. وهذا أحد الأسباب التي جعلتها في النهاية لا تصبح الإجابة القياسية من حيث تجربة المستخدم.

لكن أفكارها لم تختفِ. قسمت Solana الحساب إلى وحدات CU، وتحولت المعاملات إلى طلبات موارد. قسمت Sui الرسوم إلى الحساب والتخزين، لأول مرة في L1 رائدة، ووضحت بوضوح أن "التنفيذ مرة واحدة" و"الاحتفاظ الدائم بـ 1MB" هما سلوكان اقتصاديان مختلفان تمامًا. استخدمت Polkadot ref_time وproof_size لتكوين وزن ثنائي الأبعاد، بالإضافة إلى إيداع التخزين للتعامل مع النمو طويل الأجل للحالة. من الغاز إلى الموارد متعددة الأبعاد، ليس لأن السلاسل الجديدة أذكى من القديمة، بل لأن الصناعة بأكملها تُقر تدريجيًا: الموارد الحقيقية التي تستهلكها عقد البلوكشين أبعد من أن تكون واحدة فقط.

قياس الموارد هو مجرد الخطوة الأولى. المشكلة الحقيقية التي يجب حلها هي: من يحدد سعر هذه الموارد؟ كيف تُوزَّع الموارد؟ هل يمكن للموارد أن تشكل سوقًا؟

قدمت Hedera إجابة تستحق الدراسة. فقد قسمت تكاليف المعاملات إلى رسوم العقد (Node fee) ورسوم الشبكة (Network fee) ورسوم الخدمة (Service fee)، مع ترجيحها وفقًا للعرض والطلب على Bandwidth وProcessing وStorage وDuration، حيث تُمنح الموارد الأقل توفرًا أسعارًا أعلى. هذا ليس مجرد حساب غاز Opcode، بل هو حساب تكلفة الموارد (Resource Cost Accounting). والأكثر إثارة أن Hedera أطلقت في عام 2026 رسومًا بسيطة (Simple Fees)، حيث قامَت بتبسيط أسعار الموارد المعقدة إلى شكل قاعدة (Base) بالإضافة إلى إضافات (Extras). إن الطبقات الأساسية متعددة الأبعاد بينما واجهة المستخدم أحادية البعد — وهذا ممكن من الناحية الهندسية.

اتجاه ICP أصبح أكثر تقدمًا. يتم ربط الدورات بـ XDR، لذا فإن ارتفاع سعر الرمز لا يؤدي إلى ارتفاع متزامن في تكلفة موارد الخادم، مما يعني أن المطورين يواجهون أسعارًا ثابتة نسبيًا للموارد بالعملة الورقية. يتم فرض تخصيص الحوسبة بناءً على نسبة استخدام النواة، حيث يكون سعر الدورات لكل نسبة واحد بالمائة من النواة في الثانية ثابتًا.这不是 رسوم معاملات، بل هذه فاتورة حوسبة سحابية.

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

إضافةً إلى ذلك، فإن مساحة الكتلة تحتوي على بعد مورد يُهمل غالبًا: أولوية الإدراج (Inclusion Priority و Ordering Rights). إن رسوم الأولوية، ومزادات جيتو، وتذاكر التنفيذ، هي في جوهرها طرق لتحديد سعر "من يُدرج أولاً وبأي ترتيب يُنفذ". إذا كانت الحوسبة والتخزين والDA تمثل تكاليف العقد الفعلية والتحقق، فإن الأولوية تمثل المواقع النادرة داخل الكتلة. يمكن اعتبار MEV تسعيرًا خشنًا ومجزأً لهذا المورد الخاص؛ بينما يجب أن تدمج الأسواق الناضجة للموارد هذا المورد صراحةً، بدلاً من تركه لفترة طويلة خارج البروتوكول.

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

لم يكن World Computer أبدًا مثل Computer، ليس لأن VM غير سريعة بما يكفي، بل لأن لديه فقط "التنفيذ"، وليس إدارة الموارد الكاملة، والجدولة، والتسعير، والعزل، والسوق. لا تسمح حاسوب حقيقي لكل برنامج بتحديد سعر CPU بنفسه. ولا تجعل سحابة حقيقية المستخدمين يفهمون "كمية الـ RAM التي أحتاج شراؤها الآن".

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

أثبتت Hyperliquid و GameFi الاتجاه الآخر. مستخدمو Hyperliquid يشترون خدمة التداول، بينما يشترى لاعبو GameFi تجربة اللعبة. يسمح Orderbook الخاص بـ Immutable للمستخدمين بالتوقيع على عرض NFT بشكل كامل خالٍ من رسوم الغاز، حيث يتم فصل دافع الغاز عن الموقع للتوقيع. تتحول تكلفة الغاز من تكلفة المستخدم إلى تكلفة تشغيل المنصة. وهذا يتوافق تمامًا مع نموذج اقتصادي Web2: لا يدفع المستخدمون مقابل البنية التحتية، بل فقط مقابل المنتج.

ChainCloud ليس AWS زائد Token. إنه حقل عالمي من موارد الحوسبة القابلة للتحقق، يُدار من قبل البروتوكول، ويُسعر من قبل السوق، ويُقدّم من قبل العقد، ويُثبت بالالتقنيات التشفيرية، ويُربط عبر معايير تنفيذ موحدة.

ادفع هذا المنطق إلى نهايته، فإن بنية البلوكشين التالي لن تكون "سلسلة واحدة"، بل خمس طبقات مكدسة.

الأعلى هو طبقة الخدمة. التطبيقات مثل Trading و Game و Storage و AI توجه مباشرةً للمستخدمين، ويُرى للمستخدمين السعر التجاري، وليس سعر الموارد.

ما يلي هو Resource Abstraction. تُشرف هذه الطبقة على تغليف الموارد متعددة الأبعاد من المستوى الأساسي في واجهات خدمة يمكن للطبقة العليا فهمها. لقد قام Ethereum بتصميم EIP-7999 في هذا الاتجاه: الموارد الأساسية متعددة الأبعاد، وواجهة المستخدم أحادية البعد، حيث يكفي المستخدم أن يقدم رسومًا قصوى موحدة واحدة، ويقوم البروتوكول داخليًا بتوزيع الميزانية على الموارد المختلفة.

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

تحت سوق الموارد يوجد Parallel Runtime. هذه الطبقة مسؤولة عن تحليل رسم التبعيات، الجدولة المتزامنة، وإدارة الوصول إلى الحالة. Sealevel و Block-STM و Sui Object Model تنتمي جميعها إلى هذه الطبقة.

الأساس هو Execution ISA وDistributed State. RISC-V موجود هنا، وهو مجرد معيار تنفيذ عام أساسي للسلاسل السحابية، وليس جوهره. الجوهر الحقيقي هو مزيج ISA وRuntime وState وResource Market وProof.

لا ينبغي للمستخدمين في المستقبل رؤية مصطلحات مثل Gas و Gwei و CU و ref_time و proof_size و storage deposit. يجب أن يرى المستخدمون فقط: "استبدال 100 USDC بـ ETH" أو "شراء سيف" أو "إيداع 1 جيجابايت للحفظ لمدة 100 عام" أو "فتح مركز طويل على BTC".

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

الغاز ليس موتًا، بل تنحيًا. لقد تحول من كونه موردًا ذاته إلى طبقة تغليف لسوق الموارد.

مسار تطور البلوكشين أصبح واضحًا تدريجيًا: من البلوكشين إلى حاسوب عالمي، ثم حاسوب موارد، ثم سوق موارد، ثم السحابة اللامركزية، وأخيرًا إلى تشين-كلود.

السلسلة تحل مشكلة الثقة، والسحابة تحل مشكلة الموارد. مهمة البلوكشين من الجيل التالي ليست نقل جميع العمليات الحسابية إلى السلسلة، بل تحويل موارد الحوسبة العالمية إلى بنية تحتية عامة قابلة للتحقق، وقابلة للتداول، وقابلة للبرمجة. عندما يكتمل هذا التحول، لن تكون البلوكشين سلسلة أسرع فحسب، بل ستكون سحابة حقيقية مضمونة بالتشفير.