شجرة الحالة

ما هي شجرة الحالة في الكريبتو؟

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

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

توضح وثائق Ethereum الرسمية حول Merkle Patricia Trie أن Ethereum لديها شجرة حالة عالمية واحدة تُحدَّث كلما عالج العميل كتلة.

تُعد شجرة الحالة العالمية هذه من أهم أجزاء طبقة التنفيذ في Ethereum، لأنها تمثل الحالة الفعلية للشبكة بعد تطبيق المعاملات.

لا تساوي شجرة الحالة قائمة المعاملات التاريخية.

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

على سبيل المثال، إذا أرسل مستخدم ETH من حساب إلى آخر، تُسجل المعاملة في كتلة، لكن شجرة الحالة تتغير بسبب تحديث رصيدي الحسابين.

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

ببساطة، شجرة الحالة هي قاعدة البيانات الموثقة لحالة الحسابات الحالية على البلوكشين.

أهمية شجرة الحالة

تكتسب شجرة الحالة أهميتها لأن شبكات البلوكشين تحتاج إلى طريقة آمنة لإثبات الحالة الحالية.

قد تشمل حالة البلوكشين ملايين الحسابات والعقود الذكية والأرصدة وإدخالات التخزين والقيم الأخرى.

يجب أن تتفق العقد على هذه الحالة لتحديد ما إذا كانت المعاملات الجديدة صالحة.

إذا لم يكن لدى المرسل رصيد كافٍ، فينبغي أن تفشل المعاملة.

وإذا احتوت خانة تخزين عقد على قيمة محددة، فقد يتصرف استدعاء العقد الذكي بصورة مختلفة.

وإذا كان nonce مستخدمًا مسبقًا، فلا ينبغي قبول معاملة مُعاد تشغيلها.

توفر شجرة الحالة للعملاء بنية حتمية لتخزين هذه القيم والتحقق منها.

كما تنتج جذر حالة واحدًا يمكن وضعه في ترويسة الكتلة.

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

لذلك تُعد شجرة الحالة محورية لإجماع البلوكشين والتحقق وإثباتات العملاء الخفيفين ومزامنة العقد وتنفيذ العقود الذكية وسلامة البيانات.

شجرة الحالة وجذر الحالة

جذر الحالة هو هاش الجذر لشجرة الحالة بعد معالجة جميع معاملات الكتلة.

تتضمن ترويسات كتل Ethereum قيمة stateRoot، التي تمثل التزامًا تشفيريًا بالحالة العالمية الكاملة عند تلك الكتلة.

توضح وثائق Ethereum حول Merkle Patricia Trie أن ترويسات كتل طبقة التنفيذ تحتوي على جذور لشجرة الحالة وشجرة المعاملات وشجرة الإيصالات.

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

لا يحتاج المستخدم إلى تنزيل كل حساب وكل قيمة تخزين للعقود للتحقق من ادعاء محدد عند توفر إثبات صالح.

بدلًا من ذلك، يمكنه التحقق من أن القيمة تنتمي إلى الحالة التي يلتزم بها جذر الحالة.

إذا تغير أي رصيد حساب أو جذر تخزين عقد أو nonce أو codeHash، يتغير مسار الهاشات المؤدي إلى الجذر.

وهذا يعني أن حالة مختلفة ينبغي أن تنتج جذر حالة مختلفًا.

لذلك يمثل جذر الحالة بصمة للحالة الكاملة للبلوكشين عند كتلة محددة.

ويساعد على تحويل قاعدة بيانات حالة ضخمة إلى قيمة واحدة قابلة للتحقق.

كيفية عمل شجرة الحالة

تستخدم شجرة حالة Ethereum بنية Merkle Patricia Trie معدلة.

تجمع Merkle Patricia Trie بين أفكار أشجار Merkle ومحاولات radix ومحاولات Patricia.

الـ trie بنية تشبه الشجرة لقيم وأزواج مفاتيح، ويعتمد مسارها داخل الشجرة على المفتاح.

تضغط Patricia trie المسارات كي لا تهدر الشجرة مساحة على سلاسل طويلة من العقد الفارغة.

وتضيف شجرة Merkle هاشات تشفيرية، بحيث يمكن التحقق من البيانات عبر مسارات الهاش.

تجمع Ethereum هذه الميزات لتمكين العملاء من تخزين حالة الحسابات وتحديثها بكفاءة والتحقق منها باستخدام هاشات الجذر وإثباتات Merkle.

في شجرة حالة Ethereum، يعتمد المسار على هاش Keccak-256 لعنوان الحساب.

والقيمة المخزنة على هذا المسار هي كائن الحساب المشفر باستخدام RLP.

تنص وثائق Ethereum الرسمية على أن كائن حساب Ethereum عبارة عن مصفوفة من أربعة عناصر تشمل nonce وbalance وstorageRoot وcodeHash.

ويجعل هذا التصميم كل حساب قابلًا للوصول عبر مسار تشفيري حتمي.

ما البيانات المخزنة في شجرة الحالة؟

تخزن شجرة الحالة كائنات الحسابات، بدلًا من تخزين كل قيمة لتخزين العقود مباشرةً داخل الشجرة العالمية الرئيسية.

يحتوي كل كائن حساب في Ethereum على nonce ورصيد وstorageRoot وcodeHash.

يساعد nonce في منع إعادة تشغيل المعاملات وتتبع نشاط الحساب.

ويسجل الرصيد مقدار العملة الأصلية التي يحتفظ بها الحساب.

ويشير storageRoot إلى شجرة أخرى تخزن بيانات العقد الذكي لهذا الحساب.

ويمثل codeHash التزامًا تشفيريًا ببايت كود العقد الذكي المرتبط بحساب العقد.

عادةً ما تكون لدى الحسابات المملوكة خارجيًا شيفرة فارغة وتخزين عقود فارغ.

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

شجرة الحالة مقابل شجرة التخزين

ترتبط شجرة الحالة وشجرة التخزين ببعضهما، لكنهما مختلفتان.

شجرة الحالة هي البنية العالمية التي تربط عناوين الحسابات بكائنات الحسابات.

شجرة التخزين هي شجرة منفصلة تُستخدم لتخزين حساب عقد ذكي محدد.

توضح وثائق Ethereum أن لكل حساب يحتوي على تخزين عقد شجرة تخزين منفصلة.

ويخزن كائن الحساب في شجرة الحالة قيمة storageRoot، وهي جذر شجرة تخزين ذلك الحساب.

لذلك لا تحتوي شجرة الحالة العالمية مباشرةً على كل خانة تخزين لكل عقد.

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

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

تخزن شجرة الحالة العالمية كائن حساب عقد التوكن، ويشير ذلك الكائن إلى جذر تخزين عقد التوكن.

يساعد هذا التصميم متعدد الطبقات على فصل الحالة على مستوى الحساب عن التخزين على مستوى العقد.

شجرة الحالة مقابل شجرة المعاملات

تختلف شجرة الحالة عن شجرة المعاملات.

تخزن شجرة الحالة حالة الحسابات الناتجة بعد تنفيذ المعاملات.

أما شجرة المعاملات فتخزن المعاملات المضمنة في كتلة محددة.

ولكل كتلة شجرة معاملات خاصة بها.

لا تُحدَّث شجرة المعاملات باستمرار عبر الكتل بالطريقة نفسها التي تُحدَّث بها شجرة الحالة العالمية.

تتطور شجرة الحالة من كتلة إلى أخرى مع تغيير المعاملات لأرصدة الحسابات وتخزين العقود.

يمكن فهم المعاملة باعتبارها تعليمة، بينما يمكن فهم شجرة الحالة باعتبارها النتيجة بعد تطبيق التعليمات.

وهذا التمييز مهم لأن البلوكشين ليس مجرد سجل معاملات مرتب.

إنه أيضًا آلة حالات تنقل كل معاملة صالحة النظام من حالة إلى أخرى.

شجرة الحالة مقابل شجرة الإيصالات

تختلف شجرة الحالة كذلك عن شجرة الإيصالات.

تخزن شجرة الإيصالات إيصالات معاملات الكتلة.

يسجل الإيصال نتائج التنفيذ، مثل الحالة والغاز المستخدم والسجلات وبيانات الأحداث.

بينما تسجل شجرة الحالة حالة الحسابات النهائية بعد التنفيذ.

تساعد الإيصالات التطبيقات على فهم ما حدث أثناء تنفيذ المعاملة.

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

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

كلتا البنيتين مهمتان، لكنهما تجيبان عن سؤالين مختلفين.

تجيب شجرة الإيصالات عن ناتج المعاملة، بينما تجيب شجرة الحالة عن حالة السلسلة الآن.

عقد Merkle Patricia Trie

تستخدم Merkle Patricia Trie المعدلة في Ethereum عدة أنواع من العقد.

تصف وثائق Ethereum الرسمية عقد الفروع وعقد الأوراق وعقد الامتداد والعقد الفارغة.

يمكن لعقدة الفرع أن تشير إلى ما يصل إلى 16 مسارًا فرعيًا محتملًا، وقد تحتفظ أيضًا بقيمة.

تخزن عقدة الورقة المسار المشفر النهائي والقيمة.

تضغط عقدة الامتداد جزءًا مشتركًا من المسار كي تتجنب الـ trie سلاسل طويلة من العقد المتناثرة.

يفيد هذا التصميم لأن مفاتيح Ethereum طويلة ومتناثرة.

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

وباستخدام عقد الامتداد والأوراق، تصبح trie Ethereum أكثر إحكامًا من radix trie أساسية.

وباستخدام الهاشات، تصبح قابلة للتحقق تشفيريًا.

ولهذا تسمى هذه البنية Merkle Patricia Trie معدلة.

ترميز RLP والهاش

تستخدم Ethereum ترميز Recursive Length Prefix، المعروف غالبًا باسم RLP، لتسلسل كثير من هياكل البيانات في طبقة التنفيذ.

في شجرة الحالة، تُشفَّر كائنات الحسابات باستخدام RLP قبل وضعها كقيم.

كما تُشفَّر عقد الـ trie قبل تجزئتها أو تخزينها.

توضح وثائق Ethereum حول Merkle Patricia Trie أنه عندما تشير عقدة إلى أخرى، قد يكون المرجع هو هاش Keccak-256 للعقدة المشفرة بـ RLP، تبعًا للطول المشفر.

وهذا مهم لأن كل عقدة يجب أن تُشفَّر بطريقة حتمية.

إذا شفر عميلان الحالة نفسها بطريقة مختلفة، فقد يحسبان جذورًا مختلفة ويفشلان في الاتفاق.

لذلك يشكل الترميز الحتمي تفصيلًا حاسمًا للإجماع.

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

والنتيجة هي قاعدة بيانات قابلة للتحقق للمفاتيح والقيم، يلتزم فيها هاش جذر واحد بكل القيم المضمنة.

وهذا هو الأساس التشفيري لإثباتات الحالة.

إثباتات الحالة

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

يوضح مقترح EIP-1186 الخاص بـ eth_getProof أن حالة Ethereum القائمة على شجرة Merkle تتيح التحقق من قيم الحسابات والتخزين عبر إثباتات Merkle.

يتضمن الإثبات عادةً العقد اللازمة لإعادة بناء المسار من القيمة المستهدفة إلى جذر الحالة.

إذا تطابق الهاش المعاد بناؤه مع جذر الحالة الموثوق، يمكن التحقق من القيمة دون الثقة الكاملة بمزود البيانات.

يفيد ذلك العملاء الخفيفين والجسور والتطبيقات عبر السلاسل ومحافظ الهاتف والمدققين وأنظمة العقود الذكية التي تحتاج إلى التحقق من حالة خارجية.

على سبيل المثال، يمكن لإثبات أن يبين أن حسابًا كان يملك رصيدًا معينًا عند كتلة محددة.

كما يمكنه أن يثبت أن خانة تخزين لعقد كانت لها قيمة معينة عند كتلة محددة.

إثباتات الحالة قوية لأنها تتيح تحققًا انتقائيًا بدل تنزيل قاعدة بيانات الحالة كاملةً.

وتجعل شجرة الحالة هذه الإثباتات ممكنة.

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

eth_getProof

eth_getProof هي طريقة Ethereum JSON-RPC مصممة لإرجاع قيم الحساب والتخزين مع إثباتات Merkle الخاصة بها.

يعرّف EIP-1186 طريقة eth_getProof بأنها طريقة تُرجع قيم الحساب وقيم تخزين الحساب المحدد مع بيانات الإثبات.

يمكن أن يشمل الإثبات بيانات accountProof التي تتبع المسار من جذر الحالة.

ويمكن أن يشمل أيضًا بيانات storageProof التي تتبع المسار من جذر تخزين العقد.

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

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

يعرض استعلام الرصيد البسيط قيمة فقط.

أما استعلام الإثبات فيعرض القيمة والبيانات التشفيرية اللازمة للتحقق منها.

وهذا التمييز مهم لأن مزودي RPC قد يكونون مخطئين أو خاضعين للرقابة أو معيبين أو خبيثين.

تتيح إثباتات Merkle للمستخدمين تقليل الثقة في المزود عبر فحص الإثبات مقابل ترويسة كتلة موثوقة.

شجرة الحالة والعقد الكاملة

تحتاج العقد الكاملة إلى الحالة الحالية للتحقق من الكتل والمعاملات الجديدة.

توضح وثائق عقد الأرشيف في Ethereum أن البيانات العالمية لكل حساب وعقد تُخزن في قاعدة بيانات trie تسمى الحالة.

تتابع العقدة الكاملة أحدث حالة للشبكة لتتمكن من التحقق من الكتل والمعاملات الواردة.

لا تحتفظ العقد الكاملة عادةً بكل حالة تاريخية إلى الأبد.

قد تحتفظ بأحدث حالة وما يكفي من بيانات الحالة الحديثة للتعامل مع إعادة تنظيم السلسلة وتشغيل الشبكة المعتاد.

غالبًا يمكن تقليم الحالة التاريخية الأقدم لأنها ليست مطلوبة للتحقق القياسي من أحدث طرف للسلسلة.

ولهذا قد يكون الاستعلام عن أرصدة قديمة أو تخزين عقود قديم صعبًا على عقدة كاملة عادية.

الحالة الحالية ضرورية لتشغيل الشبكة.

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

لذلك تؤثر شجرة الحالة في عتاد العقد والمزامنة والتخزين واللامركزية.

شجرة الحالة وعقد الأرشيف

تخزن عقدة الأرشيف الحالات التاريخية بدلًا من الاحتفاظ بالحالة الحالية والحالات الحديثة فقط.

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

وهذا مهم لمستكشفي البلوكشين والمدققين والباحثين وفرق الأمن وأدوات الضرائب ومزودي التحليلات ومطوري dApp.

فعلى سبيل المثال، قد يسأل مستخدم عن رصيد حساب عند كتلة من عدة أعوام.

قد تحتاج العقدة الكاملة إلى إعادة تنفيذ المعاملات التاريخية لإعادة بناء تلك الحالة.

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

تأتي هذه السرعة على حساب متطلبات تخزين أكبر بكثير.

لذلك يكون تاريخ شجرة الحالة ذا قيمة لكنه مكلف.

ولهذا يعتمد كثير من المستخدمين على مزودي البنية التحتية لاستعلامات الحالة التاريخية.

لكن الاعتماد على مزود قد يضيف مخاطر الثقة والتوافر والرقابة.

شجرة الحالة والعقود الذكية

تعتمد العقود الذكية بدرجة كبيرة على شجرة الحالة وأشجار التخزين.

يظهر كائن حساب العقد في شجرة الحالة العالمية.

ويُلتزم بكود العقد من خلال codeHash، وبالتخزين الدائم للعقد من خلال storageRoot.

عند تنفيذ عقد ذكي، قد يقرأ ويكتب خانات التخزين.

تؤدي هذه التغييرات إلى تحديث شجرة تخزين العقد.

ويحدّث storageRoot الجديد للعقد كائن الحساب في شجرة الحالة العالمية.

ثم يغير كائن الحساب المحدّث جذر الحالة العالمي.

لذلك حتى تحديث صغير لتخزين عقد يمكن أن يغير جذر الحالة النهائي للكتلة.

وتُعد شجرة الحالة جزءًا من الكيفية التي تصبح بها نتائج العقود الذكية مرئية للإجماع.

شجرة الحالة وأرصدة التوكنات

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

فعلى سبيل المثال، قد يخزن عقد توكن قابل للاستبدال تعيينًا يربط عناوين المستخدمين بأرصدة التوكنات.

يوجد هذا التعيين داخل شجرة تخزين عقد التوكن.

وتخزن شجرة الحالة العالمية كائن حساب عقد التوكن، بما يشمل storageRoot لهذا العقد.

وهذا يعني أن رصيد العملة الأصلية ورصيد التوكن يُخزنان بطرق مختلفة.

رصيد العملة الأصلية جزء من كائن حساب في شجرة الحالة العالمية.

أما رصيد التوكن فهو عادةً قيمة تخزين داخل شجرة تخزين عقد توكن معين.

ويهم هذا التمييز للإثباتات وعمليات التدقيق.

لإثبات رصيد عملة أصلية، يكفي عادة إثبات الحساب.

ولإثبات رصيد توكن، قد يحتاج الإثبات إلى إثبات الحساب لعقد التوكن وإثبات التخزين لخانة الرصيد المعنية.

شجرة الحالة والعملاء الخفيفون

العملاء الخفيفون هم عملاء يتحققون من بيانات البلوكشين دون تخزين الحالة الكاملة.

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

يمكن للعميل الخفيف الوثوق بترويسة كتلة أو التحقق منها، ثم استخدام إثباتات Merkle لفحص قيم حالة محددة.

وهذا أقل تكلفة بكثير من تخزين الحالة كاملةً محليًا.

قد ترغب محفظة هاتف، مثلًا، في التحقق من قيمة تخزين عقد دون تشغيل عقدة تنفيذ كاملة.

وقد يرغب جسر في التحقق من إدراج حدث سحب أو حالة حساب ضمن حالة سلسلة أخرى.

توفر شجرة الحالة البنية الموثقة اللازمة لهذه التدفقات.

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

وهذا أحد أسباب استكشاف باحثي Ethereum بدائل مثل أشجار Verkle.

والهدف هو جعل التحقق من الحالة أخف وأكثر قابلية للتوسع بمرور الوقت.

شجرة الحالة والعملاء عديمو الحالة

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

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

تتصل شجرة الحالة بهذا المفهوم لأن شهود Merkle Patricia Trie الحاليين قد يكونون كبارًا.

وقد تجعل الشهود الكبيرة التحقق عديم الحالة غير فعال.

توضح مقالة بنية شجرة Verkle الصادرة عن Ethereum Foundation أن أشجار Verkle تعمل على نحو مشابه لأشجار Merkle، لكنها يمكن أن تنتج شهودًا أصغر كثيرًا عبر التزامات المتجهات.

ولهذا جرى بحث أشجار Verkle بوصفها بديلًا محتملًا لبنية التزام الحالة الحالية في Ethereum.

شجرة الحالة الحالية آمنة ومجربة عمليًا، لكنها لم تُصمم لأصغر شهود عديمي الحالة ممكنين.

يرتبط بحث انعدام الحالة جزئيًا بتقليل العبء الذي تضعه شجرة الحالة على العقد.

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

وبالنسبة إلى المطورين، يعني ذلك أن أنماط الوصول إلى الحالة وأنظمة الإثبات قد تتطور مع تقدم أبحاث البروتوكول.

شجرة الحالة وأشجار Verkle

شجرة Verkle هي بنية مقترحة للالتزام بالحالة تستخدم التزامات المتجهات بدلًا من روابط الهاش فقط.

تذكر Ethereum.org أن Ethereum تخطط للانتقال إلى بنية Verkle Tree مستقبلًا، مع أن الجداول الزمنية للبروتوكول وتفاصيل التنفيذ قد تتغير.

صُممت أشجار Verkle لجعل الإثباتات أصغر من إثباتات Merkle Patricia Trie.

توضح مقالة Ethereum Foundation أن تصاميم Verkle Tree تدمج كذلك أشجار الحسابات والتخزين في تخطيط مختلف.

وسيكون ذلك تغييرًا كبيرًا لأن Ethereum تستخدم اليوم شجرة حالة عالمية مع أشجار تخزين لكل حساب.

قد يجعل نموذج الحالة القائم على Verkle العملاء عديمي الحالة أكثر عملية.

لكن الانتقال من شجرة حالة مستخدمة منذ وقت طويل إلى بنية التزام جديدة معقد.

فهو يؤثر في العملاء والإثباتات والمحافظ والعقد وقواعد التنفيذ وتخطيط التخزين وافتراضات المطورين.

لذلك تعد شجرة الحالة أساسًا حاليًا ومجالًا رئيسيًا للبحث المستمر في البروتوكول.

يساعد فهم شجرة الحالة المستخدمين على فهم أهمية أبحاث Verkle.

شجرة الحالة وتضخم الحالة

يعني تضخم الحالة أن تصبح الحالة النشطة للبلوكشين أكبر وأصعب في الصيانة.

تنمو شجرة الحالة عندما تظل مزيد من الحسابات والعقود وخانات التخزين وبيانات التطبيقات نشطة.

تزيد الحالة الكبيرة استخدام القرص ووقت المزامنة وعبء قاعدة البيانات ومتطلبات العتاد.

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

وقد يضعف ذلك اللامركزية.

يختلف تضخم الحالة عن نمو تاريخ البلوكشين، لأن الحالة النشطة مطلوبة لمعالجة المعاملات الجديدة.

المعاملات التاريخية مهمة، لكن الحالات الوسيطة القديمة يمكن أحيانًا تقليمها أو إعادة إنشائها.

أما الحالة الحالية فيجب أن تكون متاحة للتحقق.

لذلك يعد نمو الحالة أحد أصعب مشكلات التوسع في شبكات البلوكشين للعقود الذكية.

وشجرة الحالة هي بنية البيانات التي يظهر فيها هذا النمو للعملاء.

شجرة الحالة وتكاليف الغاز

صُممت تكاليف الغاز جزئيًا لتسعير الحوسبة والوصول إلى الحالة.

تعد كتابة التخزين الدائم مكلفة لأنها تزيد الحالة التي يجب على العقد صيانتها أو تغيرها.

وقد تحمل القراءة من الحالة تكاليف أيضًا لأن الوصول إلى الحالة يؤثر في أداء التنفيذ.

عندما ينشئ عقد ذكي تخزينًا جديدًا، قد تحتاج شجرة التخزين وجذر الحالة العالمي إلى تحديثات.

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

ترتبط آليات الغاز هذه بشجرة الحالة لأن الحالة الدائمة مورد مشترك للشبكة.

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

ولو كانت باهظة جدًا، لصار بناء التطبيقات المفيدة أكثر صعوبة.

يجب على مصممي البروتوكولات موازنة سهولة الاستخدام والأمن واستدامة الحالة.

وتقع شجرة الحالة في مركز هذه المفاضلة الاقتصادية.

شجرة الحالة ومزودو RPC

يتيح مزودو RPC طرقًا تمكّن المحافظ والتطبيقات من قراءة حالة البلوكشين.

تشمل طرق الحالة الشائعة استعلامات الرصيد والتخزين والكود وعدد المعاملات واستدعاءات العقود.

تصف وثائق Ethereum JSON-RPC الرسمية طرق الحالة بأنها طرق تعرض البيانات المخزنة الحالية، مثل أرصدة الحسابات وبيانات العقود وتقديرات الغاز.

عندما تطلب محفظة رصيد حساب، يقرأ مزود RPC بيانات الحالة من عقدة.

وعندما يطلب dApp قيمة عقد، قد يقرأ مزود RPC خانة تخزين أو يحاكي استدعاءً مقابل الحالة الحالية.

يعتمد المستخدمون كثيرًا على مزودي RPC دون التفكير في شجرة الحالة خلف الاستجابة.

لكن شجرة الحالة هي ما يجعل تلك القيم جزءًا من حالة بلوكشين قابلة للتحقق.

بالنسبة إلى التطبيقات التي تتطلب درجة ثقة عالية، قد لا تكفي استجابات RPC الأولية.

يمكن لإثباتات الحالة تقديم ضمان أقوى عند دعمها والتحقق منها على النحو الصحيح.

وهذا مهم للجسور وعمليات التدقيق وأدوات الامتثال والأنظمة عبر السلاسل.

شجرة الحالة ومستكشفو البلوكشين

يستخدم مستكشفو البلوكشين بيانات الحالة لعرض الأرصدة وحيازات التوكنات وتخزين العقود وآثار المعاملات ومعلومات الحسابات التاريخية.

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

تجعل الفهرسة عمليات البحث أسرع وواجهات المستخدم أسهل في البناء.

لكن البيانات المفهرسة تأتي في النهاية من حالة البلوكشين والمعاملات والسجلات والإيصالات ونتائج التنفيذ.

إذا عرض مستكشف رصيد حساب عند كتلة محددة، ترتبط هذه المعلومة بالحالة عند تلك الكتلة.

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

يمكن لعقد الأرشيف مساعدة المستكشفين على الإجابة سريعًا عن أسئلة الحالة التاريخية.

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

لا تكون شجرة الحالة مرئية عادة لمستخدمي المستكشفين العاديين.

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

شجرة الحالة والجسور

تحتاج الجسور غالبًا إلى التحقق من حالة أو أحداث من بيئة بلوكشين أخرى.

يمكن لأشجار الحالة وإثباتات Merkle دعم هذا التحقق.

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

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

ولهذا يشير EIP-1186 إلى أن إثباتات Merkle مهمة لتقنيات Layer 2.

يمكن لإثباتات الحالة مساعدة الأنظمة على التحقق من الادعاءات المتعلقة بالأرصدة وخانات التخزين وحالة العقود.

لكن أمن الجسر يعتمد على أكثر بكثير من بنية الإثبات.

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

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

لا ينبغي للمستخدمين افتراض أن الجسر آمن لمجرد أنه يذكر إثباتات Merkle.

شجرة الحالة وشبكات Layer 2

تستخدم شبكات Layer 2 غالبًا جذور الحالة والإثباتات وبنى الالتزام لتلخيص التنفيذ خارج السلسلة أو على سلسلة منفصلة.

قد تنشر شبكة Layer 2 جذور الحالة إلى سلسلة Layer 1.

وقد تستخدم إثباتات الاحتيال أو إثباتات الصلاحية أو آليات توافر البيانات لإثبات صحة انتقالات الحالة.

يعتمد التصميم الدقيق على بنية Layer 2.

توفر شجرة حالة Ethereum سياقًا مهمًا لأنها تبين كيف يمكن للبلوكشين الالتزام بحالة كبيرة عبر جذور مضغوطة.

قد تستخدم أنظمة Layer 2 هياكل بيانات مختلفة، لكن المفهوم متشابه.

تُلخص حالة تنفيذ كبيرة عبر التزام.

ثم يتحقق المستخدمون والعقود من الادعاءات مقابل هذا الالتزام.

ولهذا لا تعد أشجار الحالة موضوعًا منخفض المستوى للعملاء فقط.

بل هي أيضًا جزء من التوسع وتصميم rollup والتحقق عبر السلاسل.

شجرة الحالة والأمن

تعزز شجرة الحالة الأمن بجعل العبث بالحالة قابلًا للكشف.

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

وإذا كذب مزود بشأن قيمة تخزين، فينبغي أن يفشل إثبات Merkle صالح مقابل جذر الحالة الموثوق.

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

وهذا يجعل شجرة الحالة عنصرًا حاسمًا للإجماع.

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

لذلك يجب أن تنفذ عملاء التنفيذ منطق الـ trie والترميز والهاش وتحديثات الحالة بعناية.

يعتمد أمن شجرة الحالة أيضًا على مقاومة هاشات التشفير.

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

تعتمد أشجار حالة البلوكشين الحديثة على افتراضات تشفيرية تجعل ذلك غير عملي في ظل الظروف الحالية.

تنفيذات العملاء

تنفذ عملاء تنفيذ Ethereum المختلفة قواعد الحالة نفسها، لكنها قد تستخدم قواعد بيانات داخلية وتحسينات مختلفة.

يجب أن تكون النتيجة الحاسمة للإجماع هي جذر الحالة نفسه.

قد تختلف طريقة تخزين العميل لعقد الـ trie على القرص، وطريقة تخزين الحالة مؤقتًا، وطريقة تقليم الحالة القديمة، وطريقة خدمة الاستعلامات التاريخية.

وهذا يعني أن شجرة الحالة مفهوم بروتوكولي وتحدٍ للتنفيذ في آن واحد.

على مستوى البروتوكول، يجب أن تتفق العملاء على الجذر وقواعد الانتقال.

وعلى مستوى قاعدة البيانات، يمكن لفرق العملاء تحسين تخطيط التخزين وسرعة الوصول والتقليم واللقطات وسلوك المزامنة.

يختبر المستخدمون هذه الفروقات عادةً في أداء العقد واستخدام القرص ووقت المزامنة وموثوقية RPC.

شجرة الحالة وتصحيح أخطاء المطورين

يصادف المطورون شجرة الحالة بصورة غير مباشرة عبر خانات التخزين وإثباتات الحسابات واستعلامات الحالة التاريخية.

قد يحتاج مطور عقد ذكي إلى معرفة كيفية تخزين التعيينات في تخزين العقد.

وقد يحتاج باحث أمني إلى إثبات أن خانة تخزين كانت لها قيمة محددة عند كتلة ما.

وقد يحتاج مطور جسر إلى التحقق من قيمة حالة عقد من بيئة أخرى.

وقد يحتاج مطور محفظة إلى شرح سبب اعتماد استعلام الرصيد على وسم كتلة مثل latest أو finalized.

وقد يحتاج مطور dApp إلى عقدة أرشيف عند تصحيح حالة عقد قديمة.

يساعد فهم شجرة الحالة المطورين على تفسير هذه المشكلات على نحو صحيح.

كما يساعدهم على تجنب الخلط بين سجل المعاملات والحالة الحالية.

تأتي أخطاء كثيرة من افتراض أن الأحداث والتخزين والأرصدة وحالة الحساب هي الشيء نفسه.

توضح شجرة الحالة موقع كل جزء من هذه البيانات.

شجرة الحالة وتجربة المستخدم الشائعة

لا يتفاعل معظم مستخدمي الكريبتو مباشرة مع شجرة الحالة.

بل يتفاعلون مع المحافظ وdApps والمستكشفين ومزودي RPC.

عندما تعرض المحفظة رصيدًا، فهي تقرأ الحالة.

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

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

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

شجرة الحالة بنية تحتية خفية، لكنها تؤثر في نشاط المستخدمين اليومي.

إذا كان الوصول إلى الحالة بطيئًا، فقد تبدو dApps بطيئة.

وإذا قدم مزود RPC حالة خاطئة، فقد يرى المستخدمون أرصدة غير صحيحة أو معاملات فاشلة.

وإذا لم تتوفر الحالة التاريخية، فقد يواجه المستخدمون صعوبة في تدقيق النشاط القديم.

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

من المفاهيم الخاطئة الشائعة أن شجرة الحالة تخزن كل معاملة.

تخزن شجرة الحالة حالة الحسابات الحالية، بينما تُخزن المعاملات بصورة منفصلة في الكتل وأشجار المعاملات.

ومن المفاهيم الخاطئة الأخرى أن تخزين العقود الذكية يُخزن مباشرة في شجرة الحالة العالمية.

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

ومن المفاهيم الخاطئة الثالث أن العقدة الكاملة تخزن دائمًا كل حالة تاريخية.

تحتفظ عقد كاملة كثيرة بالحالة الحالية والحديثة، مع تقليم الحالات الوسيطة الأقدم.

والمفهوم الخاطئ الرابع هو أن جذر الحالة هو الحالة نفسها.

جذر الحالة التزام تشفيري مضغوط بالحالة، وليس قاعدة بيانات الحالة الكاملة.

والمفهوم الخاطئ الخامس هو أن إثبات Merkle يثبت كل حقيقة ممكنة عن عقد.

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

فوائد شجرة الحالة

الفائدة الأولى لشجرة الحالة هي قابلية التحقق.

يمكن للمستخدمين والعملاء التحقق من قيم الحالة عبر إثباتات مرتبطة بجذر الحالة.

الفائدة الثانية هي الحتمية.

ينبغي للعملاء الذين يعالجون الكتلة الصالحة نفسها أن يصلوا إلى جذر الحالة نفسه.

الفائدة الثالثة هي كفاءة البحث.

تتيح مسارات الـ trie للعملاء العثور على بيانات الحسابات والتخزين عبر مفاتيح حتمية.

الفائدة الرابعة هي كشف العبث.

تغيير قيمة واحدة يغير مسار الهاشات والجذر النهائي.

الفائدة الخامسة هي دعم العملاء الخفيفين.

يمكن للإثباتات الانتقائية التحقق من البيانات دون تنزيل الحالة الكاملة.

الفائدة السادسة هي بنية واضحة لانتقال الحالة.

تغير كل كتلة الحالة السابقة إلى حالة جديدة بجذر جديد.

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

قيود شجرة الحالة

القيد الأول هو نمو التخزين.

كلما تراكمت مزيد من الحسابات وقيم تخزين العقود، أصبحت الحالة أثقل على العقد.

القيد الثاني هو حجم الإثبات.

قد تكون إثباتات Merkle Patricia Trie أكبر من المرغوب للعملاء عديمي الحالة والتحقق واسع النطاق.

القيد الثالث هو تعقيد التنفيذ.

يصعب تنفيذ ترميز الـ trie والهاش والتقليم والتخزين المؤقت وتخزين قواعد البيانات بصورة صحيحة.

القيد الرابع هو تكلفة الحالة التاريخية.

يتطلب الاحتفاظ بكل حالة تاريخية مساحة قرص أكبر بكثير من تشغيل العقدة الكاملة العادية.

القيد الخامس هو التباس المطورين.

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

تفسر هذه القيود سبب بقاء إدارة الحالة مجالًا نشطًا للبحث والهندسة.

تعمل شجرة الحالة، لكنها تخلق تحديات حقيقية للتوسع وسهولة الاستخدام.

أفضل الممارسات للمطورين

افهم الفرق بين حالة الحساب وتخزين العقد قبل بناء أنظمة قائمة على الإثباتات.

استخدم وثائق Ethereum الرسمية عند تعلم آليات Merkle Patricia Trie.

استخدم eth_getProof بعناية عند بناء أنظمة تحتاج إلى إثباتات الحسابات أو التخزين.

تحقق من الإثباتات مقابل ترويسات كتل موثوقة بدلًا من الثقة العمياء باستجابات RPC.

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

استخدم عقد الأرشيف أو مزودي بيانات الأرشيف عندما تحتاج إلى وصول سريع إلى الحالات التاريخية القديمة.

صمم العقود الذكية لتقليل التخزين الدائم غير الضروري.

ضع تكاليف الغاز في الحسبان عند الكتابة إلى التخزين لأن الحالة الدائمة مكلفة.

تابع أبحاث البروتوكول مثل أشجار Verkle إذا كان نظامك يعتمد بكثافة على إثباتات الحالة.

لا تفترض أن تنسيق الإثبات الحالي سيبقى دون تغيير إلى الأبد عبر ترقيات البروتوكول المستقبلية.

أفضل الممارسات للمستخدمين

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

تحقق من أرقام الكتل عند مقارنة الأرصدة أو قيم العقود عبر أدوات مختلفة.

افهم أن الرصيد الحالي والرصيد التاريخي قد يتطلبان وصولًا مختلفًا إلى البيانات.

استخدم التحقق القائم على الإثبات عند الحاجة إلى ضمان عالٍ وعندما تدعمه الأداة.

لا تفترض أن استجابة RPC البسيطة تعادل إثباتًا تشفيريًا.

توخ الحذر عند استخدام الجسور أو التطبيقات التي تدعي التحقق من حالة سلسلة أخرى.

راجع ما إذا كان التطبيق يستخدم الحالة الحالية أو التاريخية أو السجلات أو الفهرسة خارج السلسلة.

افهم أن تغييرات تخزين العقود الذكية قد تؤثر في سلوك التطبيق حتى عندما لا تكون تحويلات التوكنات واضحة.

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

شجرة الحالة غير مرئية لمعظم المستخدمين، لكنها تساعد في جعل بيانات السلاسل العامة قابلة للتحقق.

الأسئلة الشائعة

ماذا تعني شجرة الحالة؟

شجرة الحالة هي شجرة تشفيرية للمفاتيح والقيم تخزن الحالة الحالية للبلوكشين وتنتج هاش جذر يلتزم بهذه الحالة.

ما هي شجرة حالة Ethereum؟

شجرة حالة Ethereum هي Merkle Patricia Trie عالمية معدلة تربط عناوين الحسابات المجزأة بكائنات حسابات مشفرة باستخدام RLP.

ما الذي يُخزن في كائن حساب Ethereum؟

يحتوي كائن حساب Ethereum على nonce وbalance وstorageRoot وcodeHash.

ما هو جذر الحالة؟

جذر الحالة هو هاش الجذر لشجرة الحالة بعد تنفيذ معاملات الكتلة.

هل شجرة الحالة هي نفسها شجرة التخزين؟

لا، تخزن شجرة الحالة كائنات الحسابات، بينما تخزن أشجار التخزين بيانات العقود لحسابات العقود الفردية.

هل شجرة الحالة هي نفسها سجل المعاملات؟

لا، تخزن شجرة الحالة حالة الحسابات الحالية، بينما يسجل تاريخ المعاملات المعاملات المرتبة المضمنة في الكتل.

ما هو إثبات Merkle؟

إثبات Merkle هو مجموعة من عقد الـ trie يمكنها إثبات أن قيمة محددة مضمنة في الحالة التي يلتزم بها هاش جذر.

ما هو eth_getProof؟

eth_getProof هي طريقة Ethereum JSON-RPC تُرجع قيم الحسابات والتخزين مع بيانات إثبات Merkle.

لماذا تهم عقد الأرشيف لشجرة الحالة؟

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

هل ستستخدم Ethereum دائمًا شجرة الحالة الحالية؟

تستخدم Ethereum حاليًا Merkle Patricia Tries في طبقة التنفيذ، لكن أبحاث Ethereum استكشفت أشجار Verkle بوصفها بنية مستقبلية للالتزام بالحالة.

الخلاصة

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

تخزن الحالة الحالية للحسابات وتتيح للعملاء تلخيصها عبر جذر تشفيري واحد.

في Ethereum، تربط شجرة الحالة العالمية عناوين الحسابات المجزأة بكائنات حسابات تتضمن nonce وbalance وstorageRoot وcodeHash.

يمكن لكل عقد بعد ذلك أن يمتلك شجرة تخزين خاصة به، يُخزن جذرها داخل كائن حساب العقد.

يلتزم جذر الحالة في ترويسة كل كتلة بالحالة الكاملة الناتجة بعد معالجة جميع معاملات تلك الكتلة.

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

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

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

بالنسبة إلى المستخدمين، تختفي شجرة الحالة غالبًا خلف المحافظ والمستكشفين وdApps.

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

في سياق معجم الكريبتو، تعني State Trie قاعدة بيانات حالة البلوكشين الموثقة التي تسجل حالة الحسابات الحالية وتنتج جذر الحالة المستخدم للتحقق منها.

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