---
title: "جذر الحالة"
description: "جذر الحالة هو التزام إيثريوم الموجز بالحالة العالمية بعد تنفيذ الكتلة. يشرح المقال طريقة حسابه وما تثبته براهين الحساب والتخزين وما لا يضمنه الجذر."
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>

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

جذر الحالة هو التزام تشفيري بطول 32 بايت في ترويسة كتلة إيثريوم بالحالة العالمية بعد معالجة تلك الكتلة. تربط الحالة العالمية العناوين بالحسابات. يلتزم كل حساب بالرقم المتسلسل والرصيد وجذر التخزين وتجزئة الشيفرة؛ ويلتزم جذر تخزين كل عقد بدوره بخانات تخزين ذلك الحساب.

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

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

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

## آلية العمل

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

`S_n = Υ(S_(n-1), B_n)`

هنا `S_(n-1)` هي حالة الأصل، و`B_n` هي كل المعالجة التي يحددها البروتوكول للكتلة الجديدة، و`S_n` هي الحالة الناتجة. يرمّز العميل الحالة بطريقة حتمية في شجرة الحالة ويحسب تجزئة جذرها. يجب أن تحتوي ترويسة الكتلة الصالحة النتيجة نفسها؛ ويعني عدم التطابق أن الكتلة غير صالحة لذلك العميل.

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

يختلف جذر الحالة عن جذري المعاملات والإيصالات في الترويسة نفسها. يلتزم جذر المعاملات ببيانات المعاملات المرتبة، ويلتزم جذر الإيصالات بإيصالات التنفيذ، ولا يحل أحدها محل الآخر.

يعرّف EIP-1186 الأمر `eth_getProof` الذي يمكنه إرجاع برهان حساب وبراهين التخزين المطلوبة لكتلة محددة. يظل المتحقق بحاجة إلى تجزئة كتلة أو جذر حالة موثق، وقواعد الشجرة والترميز الصحيحة، وسياسة مناسبة للتأكيد أو النهائية.

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

## مثال

افترض أن معاملة تنقل ETH من Alice إلى Bob. قد يغيّر التنفيذ الصحيح الرقم المتسلسل ورصيد Alice، ورصيد Bob، ورصيد متلقي الرسوم. وإذا استدعت المعاملة عقدًا فقد تتغير خانات التخزين وجذر تخزين العقد أيضًا. تنتج هذه التحديثات جذر حالة عالميًا جديدًا رغم عدم المساس بمعظم الحسابات.

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

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

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

## المخاطر

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

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

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

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

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

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

- [النموذج القائم على الحسابات](/ar/crypto/account-based-model/)
- [شجرة Merkle](/ar/crypto/merkle-tree/)
- [العقدة الكاملة](/ar/crypto/full-node/)
- [العميل الخفيف](/ar/crypto/light-client/)
- [تأكيد الكتلة](/ar/crypto/block-confirmation/)

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

## المصادر

- [Ethereum Execution Specifications: Block Header](https://ethereum.github.io/execution-specs/src/ethereum/forks/frontier/blocks.py.html) - Ethereum Foundation (تاريخ الاطلاع: 2026-08-21)
- [Merkle Patricia Trie](https://ethereum.org/developers/docs/data-structures-and-encoding/patricia-merkle-trie/) - Ethereum Foundation (تاريخ الاطلاع: 2026-08-21)
- [EIP-1186: RPC-Method to get Merkle Proofs](https://eips.ethereum.org/EIPS/eip-1186) - Ethereum Improvement Proposals (تاريخ الاطلاع: 2026-08-21)

Source: https://wiki.fcontext.com/ar/crypto/state-root/index.mdx