إيثيريوم في جوهرها آلة حالات قائمة على المعاملات. في علوم الحاسوب، تستطيع آلة الحالات قراءة سلسلة من المدخلات، ثم الانتقال إلى حالة جديدة بناءً على تلك المدخلات.

تبدأ آلة الحالات في إيثيريوم من حالة التكوين الفارغة، ثم تدفعها المعاملات واحدة تلو الأخرى لتنتقل من حالة إلى أخرى.

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

لكي تُعدّ المعاملة صالحة، يجب إدراجها في كتلة والتوصل إلى توافق بشأنها من قِبل الشبكة. قبل «الدمج» (The Merge) في سبتمبر 2022، استخدمت إيثريوم، مثل بيتكوين، إثبات العمل (PoW)، حيث تنافس المعدّنون باستخدام القدرة الحاسوبية لإنتاج الكتل؛ وبعد الدمج، انتقلت إيثريوم رسميًا إلى إثبات الحصة (PoS).

في آلية PoS، لم يعد هناك «معدّنون» يستهلكون القدرة الحاسوبية، وحلّ محلهم المدققون (Validators). يتعين على المدقق إيداع 32 إيثر (Ether) كضمان، ثم يجري اختياره عبر خوارزمية شبه عشوائية لاقتراح كتلة جديدة، بينما تصادق عليها لجنة مؤلفة من مدققين آخرين (Attestation). إذا عمل المدقق بنزاهة، حصل على إيثر مكافأةً؛ أما إذا تصرف بسوء أو انقطع عن العمل، فتُصادَر حصته من الإيثر (Slashing).

1.2 اختيار التفرع وآلية التوافق (Gasper)

كما ذُكر سابقًا، إيثريوم آلة حالات تتشاركها عُقد في أنحاء العالم، ويجب أن تكون حالتها موحدة؛ فوجود حالات متعددة (أو سلاسل متعددة) سيقضي على هذا النظام. فإذا تفرعت السلسلة، فقد تملك 10 عملات على إحدى السلاسل، و20 على سلسلة أخرى، و40 على ثالثة. وفي هذه الحالة، يستحيل تحديد السلسلة «الأكثر صلاحية».

كلما ظهرت مسارات متعددة، نشأ «تفرع». ونرغب عادةً في تجنب التفرعات لأنها تضر بالنظام وتجبر الناس على اختيار السلسلة التي يثقون بها.

في حقبة PoW، استخدمت إيثريوم بروتوكول GHOST (Greedy Heaviest Observed Subtree) لاختيار المسار الذي أُنجزت عليه أكبر كمية من العمليات الحسابية، منعًا لظهور سلاسل متعددة. وبعد «الدمج» في 2022، انتقلت مسؤولية تحديد السلسلة الرئيسية إلى المدققين، واعتمدت إيثريوم آلية توافق تُسمى Gasper.

يتألف Gasper من جزأين:

قاعدة اختيار التفرع LMD-GHOST: تختار العقد دائمًا الفرع الذي يحظى بأكبر وزن من أصوات المدققين (أي أكبر حصة مودعة) ليكون السلسلة الرئيسية.

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

2 الحسابات

حساب إيثريوم كيان يمتلك رصيدًا من الإيثر (ETH) ويمكنه إرسال معاملات على إيثريوم. وقد يكون الحساب خاضعًا لتحكم المستخدم أو منشورًا بوصفه عقدًا ذكيًا.

يوجد نوعان من الحسابات في إيثريوم:

الحساب الخارجي: يتحكم فيه مفتاح خاص ولا يرتبط به أي كود.

حساب العقد: يتحكم فيه كود العقد ويرتبط به كود.

يمكن لكلا نوعَي الحسابات استقبال ETH والرموز وتخزينها وإرسالها، والتفاعل مع العقود الذكية المنشورة.

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

يتضمن حساب إيثريوم أربعة حقول:

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

balance: كمية Wei التي يملكها هذا العنوان. وWei هي وحدة قياس الإيثر، حيث إن 1 Ether = 10^18 Wei.

storageRoot: يُسمى أيضًا تجزئة التخزين، وهو تجزئة عقدة الجذر في شجرة Merkle Patricia.

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

لطالما ميّزت إيثريوم بصرامة بين الحسابات الخارجية (EOA) وحسابات العقود. لكن هذا فرض عوائق كبيرة أمام المستخدمين: إذ يتعين عليهم حفظ مفاتيحهم الخاصة بعناية، كما يجب أن يمتلكوا ETH لدفع رسوم الغاز. وقد أتاح معيار ERC-4337، الذي نُشر في 2023، «تجريد الحسابات»، بحيث يمكن أن يكون حساب المستخدم عقدًا ذكيًا بطبيعته.

وقد أتاح ذلك نقلة نوعية في تجربة الاستخدام: دعم الاسترداد الاجتماعي (إذ يمكن استعادة المفتاح الخاص المفقود بمساعدة الأصدقاء)، وإمكانية دفع رسوم الغاز باستخدام رموز مثل USDT، بل وحتى معالجة المعاملات على دفعات (إتمام التفويض والمبادلة بنقرة واحدة). ثم أتاح تحديث Pectra في مايو 2025، عبر EIP-7702، لحسابات EOA التقليدية ضبط تفويض مؤقت للكود، ما يمكّنها من تنفيذ المنطق مثل العقود الذكية، ويجلب إمكانات تجريد الحسابات إلى الحسابات القديمة. ويعمل تجريد الحسابات على طمس الحدود بين حسابات EOA وحسابات العقود، وهو بنية تحتية أساسية لانتقال إيثريوم نحو الانتشار الواسع لـ Web3.

3 الكتل

تُجمَع جميع المعاملات في «كتلة». وتتألف سلسلة الكتل من سلسلة من هذه الكتل المترابطة.

3.1 ترويسة الكتلة

تحتوي كل كتلة على «ترويسة» تضم الحقول التالية:

parentHash: تجزئة ترويسة الكتلة الأب (وهذا أيضًا ما يجعل الكتل سلسلة كتل)

beneficiary (يُسمى الآن غالبًا feeRecipient): عنوان الحساب الذي يتلقى رسوم الأولوية الخاصة بهذه الكتلة

stateRoot: تجزئة عقدة جذر شجرة الحالة

transactionsRoot: تجزئة عقدة جذر شجرة Merkle التي تضم جميع معاملات هذه الكتلة

receiptsRoot: تجزئة عقدة جذر شجرة Merkle التي تضم إيصالات جميع معاملات هذه الكتلة

logsBloom: مرشح Bloom مُكوَّن من معلومات السجلات

prevRandao: رقم عشوائي توفره سلسلة المنارة (وقد حلّ محل mixHash من حقبة PoW بعد الدمج)

number: رقم الكتلة الحالية (رقم كتلة التكوين هو 0، ويزداد رقم كل كتلة لاحقة بمقدار 1)

gasLimit: الحد الحالي للغاز في كل كتلة

gasUsed: إجمالي كمية الغاز المستخدمة في معاملات هذه الكتلة

timestamp: الطابع الزمني لنظام Unix عند إنشاء هذه الكتلة

baseFeePerGas: سعر الرسوم الأساسية لهذه الكتلة (أُضيف مع تحديث لندن / EIP-1559 في 2021)

withdrawalsRoot: تجزئة عقدة جذر شجرة Merkle التي تضم بيانات سحب حصص المدققين (أُضيفت مع تحديث شنغهاي في 2023)

blobGasUsed / excessBlobGas: يسجل استخدام بيانات Blob (أُضيف مع تحديث كانكون في 2024)

parentBeaconBlockRoot: تجزئة جذر كتلة المنارة الأب، ما يتيح لـ EVM الوصول إلى حالة سلسلة المنارة (أُضيف مع تحديث كانكون)

requestsHash: تجزئة أنواع طلبات طبقة التنفيذ المختلفة (الإيداعات والسحوبات ودمج المدققين) (أُضيفت مع تحديث Pectra في 2025)

extraData: بيانات إضافية مرتبطة بهذه الكتلة

ملاحظة: بعد الدمج، خرجت بعض حقول حقبة PoW من الاستخدام التاريخي؛ إذ حلّ prevRandao محل mixHash، بينما لا يزال ommerHash وdifficulty وnonce موجودة في البروتوكول كحقول شكلية، لكنها ثُبّتت على قيم ثابتة ولم يعد لها تأثير فعلي. ولا يعكس المخطط الكلاسيكي لترويسة الكتلة أدناه هذه التغييرات، إذ ما زال يوضح التخطيط القديم.

تحتوي كل كتلة على ثلاثة تراكيب شجرية، تقابل:

الحالة (stateRoot)

المعاملات (transactionsRoot)

الإيصالات (receiptsRoot)

3.2 شجرة MPT

تستخدم إيثريوم بنية بيانات تُسمى Merkle Patricia Tree (MPT) للتخزين. وشجرة MPT بنية بيانات مطوّرة تجمع مزايا كل من شجرة Merkle وشجرة البادئات، وهي بنية مهمة تستخدمها إيثريوم لإدارة بيانات الحسابات وإنشاء تجزئة مجموعة المعاملات.

تُعد كفاءة تخزين المعلومات في شجرة MPT مفيدة جدًا في «العملاء الخفيفين» و«العُقد الخفيفة» في إيثريوم. وبوجه عام، هناك نوعان من العُقد في إيثريوم: العُقد الكاملة والعُقد الخفيفة.

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

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

تنجح هذه الآلية لأن التجزئات في شجرة MPT تنتقل إلى الأعلى؛ فإذا حاول مستخدم خبيث استبدال معاملة في أسفل الشجرة بمعاملة مزيفة، فستتغير تجزئة العقدة التي تعلوها، وسيؤدي تغيّر قيمة تلك العقدة إلى تغيّر تجزحة العقدة التي تعلوها، وهكذا دواليك حتى الوصول إلى عقدة الجذر.

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

على الرغم من أن شجرة MPT أدت أداءً ممتازًا على مدى السنوات الماضية، فإن تضخم بيانات حالة إيثريوم إلى مئات الجيجابايت جعل حجم إثباتات MPT كبيرًا للغاية، ما أدى إلى زيادة متطلبات الأجهزة اللازمة لتشغيل عقدة كاملة. ولمعالجة هذه المشكلة، تخطط مرحلة «The Verge» في خارطة طريق إيثريوم للانتقال من بنية MPT إلى Verkle Trees (أشجار فيركل).

تجمع أشجار Verkle بين مزايا الالتزامات المتجهية (Vector Commitments) وأشجار Merkle، ويمكنها تقليص حجم الإثباتات المشفّرة (witness) بأكثر من مرتبة عشرية. وهذا سيتيح حتى للهواتف أو الحواسيب ذات المواصفات المتدنية جدًا تشغيل «عملاء عديمي الحالة» (Stateless Clients) لإيثريوم بسهولة، محققًا لامركزية قصوى. تجدر الإشارة إلى أن الانتقال إلى Verkle، حتى عام 2026، ما زال قيد التطوير، ولم يُدرج بعد في أي خطة مؤكدة لتحديثات الانقسام الصلب.

3.3 أوقات إنتاج الكتل والإيقاع (Slots & Epochs)

في حقبة إثبات العمل (PoW)، كان وقت إنتاج الكتل احتماليًا (بمتوسط يقارب 13 إلى 15 ثانية)، وتعدّله صعوبة التعدين ديناميكيًا. أما في آلية إثبات الحصة (PoS) الحالية، فقد أصبح مرور الوقت في إيثريوم دقيقًا كالساعة.

تقسم إيثريوم الوقت إلى وحدات ثابتة:

الفترة الزمنية (Slot): مدتها ثابتة، 12 ثانية، وهي النافذة الزمنية التي يحاول النظام خلالها إنشاء كتلة جديدة. وفي كل فترة، يختار النظام مدققًا واحدًا شبه عشوائي لاقتراح كتلة، بينما يصادق عليها المدققون الآخرون (Attestation).

العهد (Epoch): يتألف كل عهد من 32 فترة زمنية، أي 6.4 دقائق. ويُعد Epoch الدورة الأساسية التي يجري فيها النظام تسوية مكافآت المدققين وعقوباتهم، وإعادة توزيع أدوارهم (خلطهم)، وتحقيق «النهائية» للكتل.

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

4 الغاز والرسوم

تُعد الرسوم من المفاهيم المهمة في إيثريوم؛ إذ تترتب رسوم على كل عملية حسابية تنفذها المعاملات عبر شبكة إيثريوم. وتُدفع هذه الرسوم باستخدام الغاز.

الغاز وحدة تُستخدم لقياس الرسوم اللازمة لتنفيذ عملية حسابية معينة. وWei هي أصغر وحدة من الإيثر، حيث إن 1 Ether = 10^18 Wei؛ ويُقاس سعر وحدة الغاز عادةً بوحدة gwei، حيث إن 1 gwei = 10^9 Wei.

بعد تحديث لندن في 2021 (EIP-1559)، شهد سوق الرسوم في إيثريوم تغييرًا جذريًا. وتتألف رسوم المعاملة الآن من جزأين:

الرسوم الأساسية (Base Fee): يحسبها البروتوكول تلقائيًا بناءً على مستوى الازدحام في الكتلة السابقة، وتُطبّق القيمة نفسها على جميع المعاملات ضمن الكتلة الواحدة. ولا تُدفع هذه الرسوم إلى المدققين، بل تحرقها الشبكة مباشرةً (Burned).

رسوم الأولوية (Priority Fee / Tip): إكرامية إضافية يدفعها المستخدم طوعًا إلى مقترح الكتلة (المدقق) لتحفيزه على إدراج معاملته قبل غيرها.

لذلك، لم يعد المستخدم يحدد قيمة واحدة لـ gasPrice عند إرسال المعاملة، بل يحدد maxFeePerGas (أعلى سعر إجمالي لكل وحدة غاز مستعد لدفعه) وmaxPriorityFeePerGas (أعلى إكرامية مستعد لدفعها). ومع ذلك، لا يزال يتعين تحديد gasLimit لكل معاملة، وهو الحد الأقصى لكمية الغاز التي يقبل المرسل دفعها لتنفيذها.

على سبيل المثال، لنفترض أن المرسل حدد gasLimit بقيمة 50,000 وmaxFeePerGas بقيمة 20 gwei؛ فهذا يعني أنه مستعد لدفع 50,000 × 20 gwei = 1,000,000,000,000,000 Wei = 0.001 Ether كحد أقصى لتنفيذ هذه المعاملة.

يكون السعر الفعلي الذي تدفعه المعاملة هو min(maxFeePerGas, Base Fee + maxPriorityFeePerGas). إذا كان رصيد حساب المستخدم من الإيثر كافيًا لتغطية الحد الأقصى للرسوم، فلن تكون هناك مشكلة؛ وعند انتهاء المعاملة، يُعاد أي غاز غير مستخدم إلى المرسل.

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

إلى أين تذهب أموال الغاز هذه؟

الرسوم الأساسية: تُحرق نهائيًا (Burned) وتُزال من إجمالي معروض ETH. وعندما يكون النشاط على السلسلة مرتفعًا، قد تؤدي كمية الحرق إلى دخول ETH في حالة انكماش.

رسوم الأولوية: تُدفع إلى المدقق الذي اقترح الكتلة بنجاح (أي «المعدّن» سابقًا). ويحصل المدقق على هذه المكافأة مقابل تكاليف الحوسبة والنطاق الترددي التي تكبدها لإدراج المعاملات وتنفيذها والتحقق منها.

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

ما أهمية رسوم إيثريوم؟

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

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

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

5 المعاملات والرسائل

إيثريوم آلة حالات قائمة على المعاملات. وبعبارة أخرى، تؤدي المعاملات بين الحسابات المختلفة إلى نقل الحالة العامة لإيثريوم من حالة إلى أخرى.

المعاملة تعليمة مشفّرة وموقّعة، ينشئها حساب خارجي ويحوّلها إلى صيغة متسلسلة ثم يرسلها إلى سلسلة الكتل. وتنقسم المعاملات إلى نوعين: استدعاءات الرسائل (message calls) وإنشاء العقود (contract creations).

تتضمن جميع المعاملات العناصر التالية، بصرف النظر عن نوعها:

nonce: عدّاد لعدد المعاملات التي أرسلها المرسل

gasPrice: كمية Wei التي يقبل المرسل دفعها مقابل كل وحدة غاز لازمة لتنفيذ المعاملة. وبعد EIP-1559، حلّ محله تدريجيًا maxFeePerGas وmaxPriorityFeePerGas (راجع القسم 4 للتفاصيل)

gasLimit: الحد الأقصى لكمية الغاز التي يقبل المرسل دفعها لتنفيذ المعاملة. ويُخصم هذا المقدار مسبقًا قبل إتمام أي عملية حسابية

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

value: كمية Wei المنقولة من المرسل إلى المستلم. وفي معاملات إنشاء العقود، تمثل value الرصيد الأولي لحساب العقد الجديد

v, r, s: قيم تُستخدم لإنشاء التوقيع الذي يحدد هوية مرسل المعاملة

init: لا يظهر إلا في معاملات إنشاء العقود، وهو مقطع من كود EVM يُستخدم لتهيئة حساب العقد الجديد. تُنفذ قيمة init مرة واحدة ثم تُهمَل. وعند تنفيذ init للمرة الأولى، تُرجع جسم كود الحساب، أي مقطع الكود المرتبط بحساب العقد بصورة دائمة

data: حقل اختياري لا يظهر إلا في اتصالات الرسائل، ويحتوي على بيانات الإدخال (أي المعاملات). على سبيل المثال، إذا كان العقد الذكي خدمة لتسجيل أسماء النطاقات، فقد يتوقع استدعاء العقد معاملَي إدخال: اسم النطاق وعنوان IP

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

لكن هذا لا يعني أن العقد لا يستطيع التواصل مع عقد آخر. إذ يمكن للعقود الموجودة ضمن الحالة العامة لإيثريوم التواصل مع العقود الأخرى ضمن النطاق نفسه. ويكون ذلك عبر «الرسائل» أو «المعاملات الداخلية». فعندما يرسل عقد معاملة داخلية إلى عقد آخر، يُنفذ الكود المرتبط بحساب العقد المستقبِل.

من المهم الانتباه إلى أن المعاملات الداخلية أو الرسائل لا تتضمن gasLimit، لأن منشئ المعاملة الخارجية الأصلية (أي الحساب الخارجي) هو من يحدد حد الغاز. ويجب أن يكون حد الغاز الذي يحدده الحساب الخارجي كافيًا لإتمام المعاملة، بما في ذلك أي «تنفيذات فرعية» تنتج عنها، مثل الرسائل المرسلة بين العقود.

مع اعتماد إيثريوم مسار توسع «يتمحور حول Rollup (شبكات الطبقة الثانية)»، بات على Layer 2 نشر كميات كبيرة من البيانات على الشبكة الرئيسية لضمان الأمان. وفي السابق، لم يكن أمام هذه البيانات سوى أن تُحشر في المعاملات العادية مرتفعة التكلفة (مستهلكةً مساحة calldata).

أدخل تحديث كانكون في مارس 2024 نوعًا جديدًا كليًا من المعاملات، هو معاملات Blob (معاملات النوع 3). وBlob (Binary Large Object) مساحة تخزين مؤقتة مخصصة لحمل كتل كبيرة من البيانات. ومن أبرز خصائصها أن البيانات تبقى على السلسلة نحو 18 يومًا فقط، ثم تحذفها العُقد تلقائيًا، فلا تزيد عبء حالة إيثريوم بصورة دائمة. وقد خفّض هذا الابتكار رسوم معاملات Layer 2 بأكثر من 90%، معلنًا دخول إيثريوم رسميًا عصر التطبيقات منخفضة التكلفة.

ثم أدخل تحديث Fusaka في ديسمبر 2025 تقنية PeerDAS (أخذ عينات توافر البيانات من نظير إلى نظير)، فزاد سعة بيانات Blob بنحو مرتبة عشرية، ما خفّض تكاليف Layer 2 أكثر.

6 آلة إيثريوم الافتراضية

لا يوجد بروتوكول إيثريوم بحد ذاته إلا لضمان استمرار تشغيل آلة الحالات الخاصة هذه بلا انقطاع وبصورة متواصلة وثابتة.

أما آلة إيثريوم الافتراضية فهي البيئة التي تعتمد عليها جميع حسابات إيثريوم وعقودها الذكية. ففي أي كتلة على السلسلة، لا توجد لإيثريوم إلا حالة «معيارية» واحدة، وتحدد آلة إيثريوم الافتراضية قواعد حساب الحالة الجديدة الصالحة من كتلة إلى أخرى.

غالبًا ما يُستخدم تشبيه «دفتر الأستاذ الموزع» لوصف سلاسل الكتل مثل بيتكوين. ولإيثريوم أيضًا عملتها المشفّرة الأصلية (ETH)، التي تتبع قواعد متشابهة إلى حد كبير، لكنها تدعم أيضًا وظائف أكثر قوة، هي العقود الذكية. لذا، فإيثريوم ليست مجرد دفتر أستاذ موزع؛ والأدق وصفها بأنها آلة حالات موزعة.

حالة إيثريوم بنية بيانات ضخمة تُعرف بشجرة MPT. وهي لا تحفظ جميع الحسابات وأرصدتها فحسب، بل تحفظ أيضًا حالة آلة يمكن تغييرها بين الكتل المختلفة وفق مجموعة محددة مسبقًا من القواعد، ويمكنها تنفيذ أي كود آلي. وتحدد EVM القواعد الدقيقة لتغيير الحالة داخل الكتل.

تعمل EVM بوصفها آلة مكدس، ويبلغ عمق مكدسها 1024 عنصرًا، كل عنصر منها كلمة بعرض 256 بت. وقد اختير التشفير بعرض 256 بت لتسهيل الاستخدام.

تحتوي EVM على ذاكرة تُخزّن مدخلاتها في مصفوفات بايتات معنونة بالكلمات (word-addressed byte arrays). والذاكرة متطايرة، ولا تحتفظ بمحتوياتها بين المعاملات.

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

ولـ EVM لغتها الخاصة أيضًا: بايت كود EVM. عندما يكتب المبرمجون عقودًا ذكية على إيثريوم، يستخدمون عادةً لغة عالية المستوى مثل Solidity. ثم يمكن تجميع الكود إلى بايت كود EVM لكي تتمكن EVM من فهمه وتنفيذه.

يُنفذ بايت كود العقد الذكي المُجمّع كسلسلة من تعليمات EVM (opcodes)، التي تنفذ عمليات المكدس القياسية مثل XOR وAND وADD وSUB وغيرها. وتنفذ EVM أيضًا بعض عمليات المكدس الخاصة بسلاسل الكتل، مثل ADDRESS وBALANCE وBLOCKHASH وغيرها.

على الرغم من النجاح الهائل الذي حققته EVM، لم يطرأ على تنسيق البايت كود الأساسي فيها أي تحسين بنيوي يُذكر منذ نشأتها، ما أدى إلى بطء تحليل الكود وزيادة احتمالات الثغرات. ويعمل مطورو إيثريوم على تحديث EOF (EVM Object Format)، الذي يقدم للعقود الذكية بنية «حاوية» واضحة تفصل مقاطع الكود والبيانات ومعلومات الأنواع. ولا يقتصر ذلك على خفض استهلاك الغاز لنشر العقود، بل يزيل أيضًا من جذورها أنواعًا معينة من ثغرات القفز، ويجعل التدقيق الأمني أكثر أمانًا. لكن نظرًا إلى اتساع نطاق التغيير، كان من المخطط إطلاق EOF مع تحديث Fusaka في أواخر 2025، ثم أُزيل من التحديث بسبب مخاطر الجدول الزمني. وحتى عام 2026، لم يُعتمد ضمن أي تحديث للانقسام الصلب.

إضافةً إلى ذلك، وعلى الرغم من استمرار هيمنة Solidity، يتزايد التنوع في منظومة EVM. فاللغة Vyper، التي تضع الأمان في المقام الأول، والاستكشافات المتعلقة باستخدام بنية RISC-V لتشغيل كود Rust/C++ المُجمّع، تواصل توسيع آفاق آلة إيثريوم الافتراضية.

تابعني كي لا تفوتك القراءة السريعة التالية للسوق.