---
title: "نموذج الحالة القائم على الحسابات"
description: "شرح نموذج الحسابات في Ethereum من خلال حقول الحساب وجذور الحالة والتخزين والتنفيذ المرتب للمعاملات والغاز والتراجع وتخزين الرموز وتفويض EIP-7702 وقوائم الوصول والتتبعات والنهائية."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# نموذج الحالة القائم على الحسابات

> لأغراض تعليمية فقط؛ لا يشكل ذلك نصيحة استثمارية أو توصية استثمارية. قد تؤدي الاستثمارات إلى خسائر.

<a id="answer"></a>

## الإجابة المباشرة

يمثل النموذج القائم على الحسابات حالة التنفيذ في صورة بيانات مفهرسة حسب العنوان. في طبقة تنفيذ Ethereum، تتضمن ورقة الحساب `[nonce, balance, storageRoot, codeHash]`. يقاس `balance` الأصلي بوحدة wei، وتقع بيانات العقد خلف `storageRoot` لذلك الحساب، ويلتزم `stateRoot` للكتلة بالحالة العالمية الناتجة بعد التنفيذ. تقرأ المحفظة أو مزود RPC أو مستكشف الكتل هذه الحالة ويفسرها، لكنها لا تخزن الرصيد المعتمد نيابة عن المستخدم.

أرصدة ERC-20 والمخصصات وديون الإقراض والضمانات تكون عادة قيما في تخزين العقود، وليست حقولا إضافية في حساب حاملها على مستوى البروتوكول. كذلك فإن ما يسميه المستكشف «معاملة داخلية» يكون عادة استدعاء رسالة EVM أعيد بناؤه بالتتبع، لا معاملة Ethereum مستقلة موقعة لها hash معاملة وnonce مرسل خاصان بها.

يظل التمييز التقليدي بين الحساب المملوك خارجيا (EOA) وحساب العقد مفيدا، لكن عبارة «EOA لا يحتوي أبدا على code» لم تعد مطلقة في سلسلة فعّلت EIP-7702. يمكن أن يحمل EOA مؤشر تفويض `0xef0100 || address` وينفذ code المفوض مع احتفاظه بسلطة إرسال معاملات EOA. لذلك يجب أن يستند التصنيف إلى قواعد السلسلة وcode الفعلي للحساب، لا إلى تسمية قديمة في واجهة المستخدم.

<a id="mechanism"></a>

## تدقيق انتقال الحالة في سبع خطوات

1. ثبّت نقطة الرصد: الشبكة و`chainId` وقواعد fork ورقم الكتلة وhash والطابع الزمني ووسم الكتلة مثل `pending` أو `latest` أو `safe` أو `finalized`. قد تتغير الحالة القريبة من رأس السلسلة بعد إعادة تنظيم؛ فلا تدمج حقائق من كتل مختلفة من دون تسميتها.
2. اقرأ حقول حساب البروتوكول: `nonce` و`balance` الأصلي و`storageRoot` و`codeHash`. إذا كان code مؤشر تفويض EIP-7702، فحل عنوان المفوض وفق قواعد ذلك fork. وبالنسبة إلى proxies والحسابات المفوضة، حدد على نحو منفصل code التنفيذ وسلطة الترقية وتخطيط التخزين.
3. حدد موضع أرصدة التطبيق. يغير ETH الرصيد الأصلي؛ أما رصيد ERC-20 فيغير عادة mapping في تخزين عقد الرمز؛ وقد تقع المخصصات والديون والضمانات والمكافآت في عقود وslots أخرى. decimals الرمز وlogs أدوات تفسير، وليست حقولا إضافية في ورقة الحساب.
4. فك ترميز المعاملة العليا وافحصها مسبقا: النوع ونطاق السلسلة والتوقيع وnonce المرسل والمستلم أو الإنشاء والقيمة وinput وحد gas وحدود الرسوم وقائمة الوصول الاختيارية أو تفويضات EIP-7702. يجب أن يغطي المرسل القيمة والحد الأقصى للرسوم. المعاملة المرفوضة لا تدرج ولا تستهلك gas على السلسلة.
5. نفذ المعاملات بترتيب الكتلة انطلاقا من الحالة السابقة. تعالج EVM استدعاءات الرسائل المتداخلة وأطر إنشاء العقود، ولكل إطار مستدع ومستدعى وقيمة وcalldata وgas وحالة إرجاع. تجعل القراءات والكتابات المشتركة النتائج معتمدة على الترتيب. تقوم قائمة وصول EIP-2930 بتسخين الحسابات وslots المسماة وتغير محاسبة gas؛ لكنها لا تمنع الوصول غير المعلن ولا تثبت سلامة التنفيذ المتوازي.
6. طبق حدود الالتزام والتراجع. يثبت الإطار الناجح حالته وlogs ما لم يتراجع إطار أب لاحقا. يعيد `REVERT` كتابات الإطار الفاشل وتحويلات القيمة وlogs مع إعادة gas غير المستخدم؛ ويمكن للعقد الخارجي التقاط فشل استدعاء فرعي والاستمرار بنجاح. يكون إيصال فشل أعلى مدرج `status = 0`، لكن nonce معاملة المرسل يزداد ويدفع gas المستهلك. ولمعالجة تفويض EIP-7702 قواعد ثبات خاصة بها حتى إذا تراجع التنفيذ اللاحق.
7. طابق الحالة اللاحقة. طابق تغيرات أرصدة الأصل والرموز وتغيرات التخزين وحالة الإيصال وgas المستخدم وسعر gas الفعلي وlogs وتتبع المزود مع الجذور التي التزمت بها الكتلة. تعامل مع traces بوصفها إعادة بناء من المزود لا معاملات إجماع مستقلة. انتظر مستوى النهائية المطلوب، ثم عالج الاستبدالات وإعادة التنظيم ومراجعات المفهرس والجسور وrollups والقيود المحاسبية العكسية صراحة.

<a id="example"></a>

## أربعة أمثلة محلولة

- **تحويل ETH وفق EIP-1559.** يبدأ A برصيد `5 ETH` وnonce قدره `12`، ويبدأ B برصيد `1 ETH`. يرسل A مقدار `1 ETH` باستخدام `21,000 gas`، مع base fee قدره `20 gwei` وpriority cap قدره `3 gwei` وmax fee قدره `40 gwei`. سعر gas الفعلي هو `min(40, 20 + 3) = 23 gwei`؛ وإجمالي الرسوم `21,000 × 23 gwei = 0.000483 ETH`، منها `0.000420 ETH` حرق base fee و`0.000063 ETH` priority fee. الحد الأقصى المطلوب وقت التوقيع هو `1 ETH + 21,000 × 40 gwei = 1.000840 ETH`. الأرصدة النهائية هي A `3.999517 ETH` وB `2 ETH`، ويصبح nonce لدى A هو `13`.
- **معاملة مدرجة تراجعت.** يبدأ A برصيد `2 ETH` وnonce قدره `7`. يستدعي A عقدا بقيمة `0.50 ETH`؛ ويتراجع التنفيذ الأعلى بعد `80,000 gas` بسعر فعلي `25 gwei`، فتكون الرسوم `80,000 × 25 gwei = 0.002000 ETH`. تتراجع كتابات تخزين العقد وlogs وتحويل `0.50 ETH`، بينما ينتهي A برصيد `1.998000 ETH` وnonce قدره `8` وإيصال `status = 0`. وفي المقابل يمكن أن يتعايش فشل استدعاء فرعي التقطه A مع إيصال خارجي `status = 1`.
- **رصيد الرمز هو تخزين عقد.** يسجل عقد رمز Alice بمقدار `1,000 units` وBob بمقدار `200 units`. ينتج عن تحويل ناجح قدره `250 units` رصيد Alice `750 units` ورصيد Bob `450 units`، مع بقاء المجموع `1,200 units`. إذا استخدمت معاملة Alice العليا `60,000 gas × 20 gwei = 0.001200 ETH`، ينخفض رصيد ETH الأصلي لديها بالرسوم بصورة منفصلة. يتغير `storageRoot` لحساب الرمز و`stateRoot` العالمي؛ ولم يصبح أصل الرمز يوما جزءا من الرصيد الأصلي لحساب Alice.
- **حد الثبات في EIP-7702.** يرسل راع معاملة set-code تتضمن تفويضا من الحساب A عند nonce `5` إلى التنفيذ D. يكتب البروتوكول المؤشر ذا `23-byte`، أي `0xef0100 || 20-byte address`، ويزيد nonce سلطة A إلى `6`. إذا تراجع التنفيذ اللاحق في تلك المعاملة الخارجية، يبقى مؤشر التفويض وnonce التفويض المعالجان مسبقا. وهذا يختلف عن حد تراجع تخزين EVM العادي الذي كتبه الاستدعاء الفاشل.

<a id="risks"></a>

## المخاطر والضوابط

- تؤدي قراءة سلسلة أو fork أو hash كتلة أو وسم كتلة خاطئ إلى لقطة حالة غير متسقة داخليا.
- قد يحذف مزود RPC قديم أو غير موثوق حالة الرأس أو يتأخر عنها أو يبلغها بصورة خاطئة.
- قد تبطل سباقات nonce المعلق والفجوات والاستبدالات افتراضات قائمة الانتظار.
- يكون «الإلغاء» في المحفظة عادة معاملة استبدال، لا حذفا على مستوى البروتوكول.
- يمنع نقص الرصيد اللازم للقيمة والحد الأقصى للرسوم إدراج المعاملة.
- قد تؤخر حركة base fee أو أخطاء حد الرسوم الإدراج أو تغير التكلفة.
- قد يؤدي code في EIP-7702 إلى تصنيف EOA خطأ باستخدام قواعد حساب قديمة.
- قد يعرض مفوض خبيث أو خلل تهيئة أو إعادة تشغيل تفويض حساب EIP-7702 للخطر.
- قد تجعل ترقيات proxy وdelegate calls تفسير code والتخزين يتغير بمرور الوقت.
- قد تسمح أخطاء المفتاح أو نطاق التوقيع أو chain ID بالسرقة أو إعادة التشغيل.
- قد تغير reentrancy وترتيب الحالة المشتركة الأرصدة خلال تنفيذ واحد.
- قد يفشل استدعاء فرعي ويلتقطه العقد بينما تظل المعاملة الخارجية ناجحة.
- يظل التراجع الأعلى أو فشل نفاد gas مستهلكا للgas ويزيد nonce المرسل.
- قد تبطل decimals الرمز ورسوم التحويل وإعادة الأساس وhooks حساب الرصيد البسيط.
- قد تسقط المخصصات والديون والضمانات والمكافآت عند مطابقة أرصدة المحفظة فقط.
- قد تغيب logs أو تتراجع أو تضلل أو لا تكفي لإثبات الحالة النهائية.
- قد تختلف «المعاملات الداخلية» وtraces المزود لأنها مشاهد أعيد بناؤها.
- قد تكون قائمة الوصول ناقصة أو مكررة أو غير اقتصادية، ولا تقفل مجموعة القراءة والكتابة.
- قد يغير ترتيب الحالة المشتركة وpriority fees وMEV نتائج التنفيذ.
- قد تعكس إعادة التنظيم أو pruning أو غياب proofs أو انتقالات L2 أو نهائية الجسر القيود المحاسبية أو تحجبها.

<a id="misconceptions"></a>

## مفاهيم خاطئة شائعة

- «المحفظة تخزن الرصيد على السلسلة.» تحتفظ المحفظة ببيانات الاعتماد وتعرض الحالة التي تحصل عليها من الشبكة.
- «كل عنوان إما EOA خال من code دائما أو عقد عادي.» يغير تفويض EIP-7702 هذه القاعدة الاستدلالية.
- «كل تحويل معروض هو معاملة Ethereum مستقلة.» أحداث الرموز وتتبع استدعاءات الرسائل الداخلية ليست معاملات عليا موقعة.
- «المعاملة الفاشلة لا تغير شيئا ولا تكلف شيئا.» يمكن أن يستهلك الفشل المدرج gas ويزيد nonce المرسل.
- «نموذج الحساب أو قائمة الوصول يضمن تنفيذا متوازيا أسرع من UTXO.» يعتمد الأداء والتعارض على البروتوكول وعبء العمل بالكامل.

<a id="related"></a>

## موضوعات ذات صلة

- [جذر الحالة](/ar/crypto/state-root/)
- [نموذج UTXO](/ar/crypto/utxo-model/)
- [تجريد الحساب](/ar/crypto/account-abstraction/)

<a id="sources"></a>

## المصادر

- [Ethereum accounts](https://ethereum.org/developers/docs/accounts/)
- [Ethereum Yellow Paper: a formal specification of Ethereum, a programmable blockchain](https://ethereum.github.io/yellowpaper/paper.pdf)
- [Transactions](https://ethereum.org/developers/docs/transactions/)
- [Blocks](https://ethereum.org/developers/docs/blocks/)
- [Merkle Patricia Trie](https://ethereum.org/developers/docs/data-structures-and-encoding/patricia-merkle-trie/)
- [EIP-7702: Set Code for EOAs](https://eips.ethereum.org/EIPS/eip-7702)
- [EIP-2930: Optional access lists](https://eips.ethereum.org/EIPS/eip-2930)
- [Proof-of-stake (PoS)](https://ethereum.org/developers/docs/consensus-mechanisms/pos/)

Source: https://wiki.fcontext.com/ar/crypto/account-based-model/index.mdx