Trie

ما هو Trie؟

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

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

تأتي كلمة trie من retrieval، ويُنطق المصطلح عادةً مثل «try».

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

تضيّق كل خطوة في المسار نطاق البحث إلى أن يصل النظام إلى القيمة المتصلة بالمفتاح الكامل.

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

في أنظمة البلوكشين، غالبًا ما تُدمج tries مع التجزئة التشفيرية لإنشاء هياكل بيانات موثقة.

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

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

أشهر مثال في الكريبتو هو modified Merkle Patricia trie في Ethereum، والذي يُستخدم عبر طبقة التنفيذ لتنظيم بيانات المفتاح والقيمة بطريقة حتمية وقابلة للتحقق تشفيريًا.

لماذا تهم Tries في الكريبتو؟

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

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

إذا عالجت عقدتان الكتلة نفسها، فينبغي أن تنتهيا إلى state root نفسه.

state root هو ملخص تشفيري مضغوط للحالة الكاملة.

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

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

توضح Ethereum.org أن Merkle Patricia trie حتمية وقابلة للتحقق تشفيريًا، وأن أي محاولة لتعديل الحالة بقيم مختلفة تؤدي إلى هاش state root مختلف، عبر وثائق Merkle Patricia Trie.

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

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

كيف يعمل Trie الأساسي؟

يخزن Trie الأساسي البيانات عبر تقسيم المفاتيح إلى رموز أصغر.

فعلى سبيل المثال، قد يخزن Trie قائم على الكلمات «cat» و«car» و«cap» من خلال مشاركة الحرفين الأولين «ca» ثم التفرع عند الحرف الأخير.

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

في أنظمة الكريبتو، لا تكون المفاتيح عادةً كلمات إنجليزية بسيطة.

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

يتبع Trie المفتاح جزءًا بعد جزء حتى يصل إلى القيمة.

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

يمكن لهذا الهيكل نظريًا دعم البحث والإدراج والحذف بسرعة.

لكن Trie العادي قد يكون غير فعال إذا كانت المفاتيح طويلة وكانت مسارات عديدة تحتوي على فرع واحد فقط.

ولهذا تستخدم أنظمة البلوكشين غالبًا أشكال Trie محسنة مثل Patricia tries وMerkle Patricia tries.

Trie مقابل Tree

Trie هو نوع من الأشجار، لكنه مصمم حول المفاتيح والبادئات.

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

أما Trie فينظم القيم عبر المرور في رموز المفتاح.

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

في البلوكشين، قد تكون المفاتيح سلاسل bytes طويلة، لذلك لا تكون الشجرة البسيطة مثالية دائمًا.

يمكن لـ Trie جعل المسار إلى القيمة يعتمد مباشرةً على المفتاح نفسه.

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

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

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

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

Trie مقابل Merkle Tree

ينظم Trie البيانات عبر مسارات المفاتيح، بينما تنظم Merkle tree البيانات عبر تجزئة الأوراق معًا إلى أن يتبقى هاش جذر واحد.

تُعد Merkle tree مفيدة لأنها تنشئ التزامًا تشفيريًا بمجموعة من البيانات.

يمكن لبرهان Merkle أن يوضح أن جزءًا من البيانات ينتمي إلى المجموعة الملتزم بها دون كشف المجموعة بالكامل أو تنزيلها.

ويُعد Trie مفيدًا لأنه يدعم بحثًا فعالًا عن المفتاح والقيمة.

يجمع Merkle Patricia trie بين هاتين الفكرتين.

فهو يستخدم مسارات مفاتيح شبيهة بـ Trie للبحث وتجزيئات بأسلوب Merkle للتحقق.

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

يمكن لـ Trie العادي العثور على القيم، لكنه لا يثبت تلقائيًا أن القيم جزء من state root موثوق.

يمكن لـ Merkle tree العادية إثبات العضوية، لكنها ليست مصممة دائمًا لتحديثات المفتاح والقيمة الفعالة.

يوفر Merkle Patricia trie لأنظمة Ethereum أسلوبًا لإدارة الحالة المتغيرة مع الحفاظ على التزام جذر قابل للتحقق.

ما هو Patricia Trie؟

Patricia trie هو Trie محسّن يضغط المسارات عندما توجد امتدادات طويلة من دون تفرع.

PATRICIA اختصار لـ Practical Algorithm To Retrieve Information Coded in Alphanumeric.

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

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

يمكن لـ Patricia trie تخزين جزء مسار مشترك بصورة أكثر ضغطًا.

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

توضح Ethereum.org أن هيكل بيانات Ethereum يستعير خصائص من PATRICIA لأنه مصمم لاسترجاع عناصر حالة Ethereum بكفاءة في دليل Patricia Merkle trie.

يساعد ضغط المسار على تقليل عدد العقد التي يجب اجتيازها وتخزينها وإثباتها.

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

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

ما هو Merkle Patricia Trie؟

Merkle Patricia trie هو هيكل بيانات موثق للمفتاح والقيمة يجمع بين تجزئة Merkle والبحث بأسلوب Trie وضغط مسار Patricia.

ويُختصر أحيانًا بـ MPT.

تستخدم Ethereum modified Merkle Patricia trie لبيانات مهمة في طبقة التنفيذ.

تذكر وثائق هياكل بيانات Ethereum الرسمية أن Patricia Merkle tries ترمز أزواج المفتاح والقيمة في Trie حتمي وموثق تشفيريًا.

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

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

إذا حسبت عقدة state root مختلفًا عن مقترح الكتلة، تعرف العقدة أن هناك خطأ ما.

وهذا أحد أسباب أهمية MPTs البالغة لنموذج تنفيذ Ethereum.

فهي تربط تحديثات قاعدة البيانات المحلية بالإجماع العالمي.

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

Modified Merkle Patricia Trie في Ethereum

يُطلق على إصدار Ethereum غالبًا modified Merkle Patricia trie.

تنص Ethereum Yellow Paper على أن Ethereum تحافظ على تعيين حالة العالم في modified Merkle Patricia tree، وأن هاش عقدة الجذر يمكن أن يعمل كهوية آمنة لحالة النظام كاملةً، في Ethereum Yellow Paper.

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

تشمل حالة الحساب بيانات مثل nonce والرصيد وجذر التخزين وهاش الكود.

ويُنظم تخزين العقود الذكية أيضًا عبر هياكل Trie.

عندما تغير معاملة رصيدًا أو قيمة تخزين عقد، يتغير مسار Trie المعني.

ويؤثر هذا التغيير في هاشات العقد الأصلية وصولًا إلى الجذر.

يعكس state root النهائي عندئذ حالة البلوكشين المحدثة.

هكذا يمكن لهاش صغير تمثيل كمية ضخمة من بيانات الحالة المتغيرة.

يُعد modified MPT أحد أسباب قدرة عقد Ethereum على التحقق بصورة مستقلة من صحة تنفيذ الكتلة.

العقد في Merkle Patricia Trie

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

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

تمثل العقدة الفارغة قيمة فارغة.

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

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

وتخزن عقدة الامتداد جزء مسار مشتركًا وتشير إلى عقدة أخرى.

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

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

غالبًا ما تُمثل مفاتيح Ethereum في nibbles، حيث يمثل nibble الواحد نصف byte.

يوفر استخدام nibbles لـ Trie ما يصل إلى 16 خيارًا للمسار عند كل عقدة تفرع.

يتيح هذا التصميم لـ Trie التنقل في مسارات مفاتيح سداسية عشرية بطريقة قابلة للتوقع.

State Trie

State trie هو Trie الذي يلتزم بحالة العالم في Ethereum.

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

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

يربط state trie عناوين الحسابات ببيانات الحساب المرمزة.

يُعد state root هاش جذر هذا Trie بعد معالجة معاملات الكتلة.

عندما يتحقق المدققون من كتلة، يعيدون تنفيذ المعاملات ويحسبون state root الناتج.

توضح صفحة خارطة طريق Verkle trees في Ethereum.org أن الكتلة المُتحقق منها هي التي يطابق هاش state root المحسوب فيها الجذر الذي قدمه مقترح الكتلة.

وهذا يجعل state trie أساسيًا للتحقق من الكتل.

فهو ليس مجرد تفصيل تخزين مخفي في برنامج العميل.

بل هو جزء من طريقة إثبات Ethereum لصحة انتقالات الحالة.

Storage Trie

يخزن storage trie تخزين العقد الذكي لحساب محدد.

يمتلك كل حساب عقد ذكي storage root يشير إلى storage trie الخاص به.

يربط storage trie هذا مفاتيح التخزين بقيم التخزين.

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

يمكن تمثيل كل من هذه القيم عبر storage slots.

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

ويحدّث تغيير التخزين هذا جذر storage trie للعقد.

ثم تتغير بيانات الحساب في state trie لأن storage root للحساب قد تغير.

ينشئ ذلك سلسلة من الالتزامات التشفيرية من فتحة تخزين واحدة إلى state root الكلي.

هذه السلسلة هي ما يجعل براهين التخزين ممكنة.

Transaction Trie

يلتزم transaction trie بالمعاملات المدرجة في كتلة.

تحتوي كل كتلة على transaction root يلخص معاملات تلك الكتلة.

وهذا يسمح للعقد والعملاء بالتحقق من تضمين المعاملة مقابل بيانات الكتلة.

تختلف transaction tries عن state trie لأنها تصف محتويات الكتلة بدلًا من حالة الحساب الحالية.

يتغير state trie عندما تحدّث المعاملات الحسابات والعقود.

يسجل transaction trie المعاملات التي أُدرجت في كتلة محددة.

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

يمكن إدراج معاملة في كتلة ثم تفشل أثناء التنفيذ.

يمكن لـ transaction trie إثبات التضمين، بينما يمكن لـ receipt trie إظهار تفاصيل نتيجة التنفيذ.

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

Receipt Trie

يلتزم receipt trie بإيصالات المعاملات الخاصة بكتلة.

يسجل الإيصال نتيجة تنفيذ المعاملة.

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

تُعد الإيصالات مهمة للمحافظ والمستكشفات وأدوات الفهرسة والتطبيقات اللامركزية.

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

يساعد receipt trie على الالتزام بهذه النتائج في بيانات الكتلة.

وهذا يسمح للعملاء بالتحقق من أن إيصالًا معينًا ينتمي إلى كتلة.

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

بالنسبة إلى المستخدمين، يكون receipt trie غير ظاهر عادةً.

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

Trie Root

Trie root هو هاش على المستوى الأعلى يلخص جميع البيانات في Trie.

إذا تغيرت أي قيمة داخل Trie، فينبغي أن يتغير الجذر.

يجعل هذا الجذر التزامًا مضغوطًا بمجموعة البيانات الكاملة.

في Ethereum، تتضمن رؤوس الكتل جذورًا تلخص هياكل بيانات مهمة.

يلخص state root الحالة بعد الكتلة.

ويلخص transaction root معاملات الكتلة.

ويلخص receipt root إيصالات معاملات الكتلة.

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

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

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

براهين Merkle وTries

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

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

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

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

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

فعلى سبيل المثال، قد يثبت البرهان أن حسابًا معينًا كان لديه رصيد محدد عند state root معروف.

وقد يثبت البرهان أيضًا أن storage slot لعقد ذكي كان يحمل قيمة معينة.

تُعد براهين التخزين مفيدة للجسور والتطبيقات عبر السلاسل وrollups والتحقق من الحالة التاريخية.

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

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

Tries والعملاء الخفيفون

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

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

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

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

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

لكن براهين Merkle Patricia trie الحالية قد تصبح كبيرة لبعض حالات الاستخدام.

توضح Ethereum.org أن witnesses الخاصة بـ Merkle trie الحالية كبيرة جدًا بحيث لا تدعم العملاء عديمي الحالة بكفاءة في وثائق Verkle trees.

ولهذا يدرس باحثو Ethereum Verkle trees وتحسينات أخرى للالتزام بالحالة.

الهدف هو جعل التحقق أخف دون إضعاف الأمان.

لذلك لا تهم tries عقد اليوم فقط، بل تهم أيضًا تصاميم قابلية توسع البلوكشين المستقبلية.

Tries والعملاء عديمو الحالة

العميل عديم الحالة هو عميل يستطيع التحقق من الكتل دون تخزين الحالة الحالية الكاملة محليًا.

بدل الاحتفاظ بقاعدة بيانات الحالة كاملةً، يتلقى العميل witness مع الكتلة.

يحتوي witness على أجزاء الحالة وبيانات البرهان اللازمة للتحقق من انتقال حالة الكتلة.

توضح Ethereum.org أن العملاء عديمي الحالة يستخدمون witness لبيانات الحالة بدلًا من نسختهم المحلية من قاعدة بيانات الحالة كاملةً، عبر خارطة طريق العملاء عديمي الحالة وVerkle trees.

يكمن التحدي في أن witnesses القائمة على هياكل Merkle trie الحالية قد تكون كبيرة جدًا.

تُعد witnesses الكبيرة مشكلة لأنها يجب أن تُشارك بسرعة عبر شبكة الند للند.

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

يمكن لهياكل Trie أو Tree الأفضل تقليل حجم witness وتسهيل التحقق لعدد أكبر من المستخدمين.

ولهذا يرتبط تصميم هيكل البيانات مباشرةً باللامركزية.

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

Tries وVerkle Trees

تمثل Verkle trees مسار ترقية مقترحًا لهيكل بيانات حالة Ethereum.

تشبه Verkle tree Merkle tree من حيث الغرض، لكنها تستخدم vector commitments لدعم witnesses أصغر.

توضح Ethereum.org أن Verkle trees قد تساعد العقد على التوقف عن تخزين كميات كبيرة من بيانات الحالة من دون فقدان القدرة على التحقق من الكتل، عبر خارطة طريق Verkle trees الرسمية.

وهذا مهم لأن state trie الحالية في Ethereum كبيرة وصعبة للتحقق الخفيف.

صُممت Verkle trees لجعل witnesses أصغر وأكثر عملية للعملاء عديمي الحالة.

وهي ليست مثل Merkle Patricia tries.

بل هي جزء من جهد مستقبلي لتحسين الوصول إلى الحالة والتحقق منها.

بالنسبة إلى قراء المسرد، النقطة الأساسية هي أن tries ليست موضوعًا جامدًا حُسم بالكامل.

تستمر هياكل بيانات البلوكشين في التطور لأن الشبكات تحتاج إلى قابلية توسع أفضل ومتطلبات أجهزة أقل وكفاءة أقوى للبراهين.

يسهّل فهم tries إدراك سبب البحث في Verkle trees.

Tries وتكاليف الغاز

يمكن لعمليات Trie أن تؤثر في أداء البلوكشين وتكاليف المعاملات.

عندما تقرأ معاملة حالة أو تكتبها، قد يحتاج العميل إلى الوصول إلى البيانات المتعلقة بـ Trie وتحديثها.

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

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

قد يؤدي تحويل توكن إلى تحديث الأرصدة في تخزين العقد.

وقد تحدّث معاملة DeFi العديد من storage slots عبر عقود متعددة.

يمكن لكل تحديث أن يسهم في نمو الحالة وأعمال صيانة Trie.

وهذا أحد أسباب اهتمام مطوري البلوكشين بتحسين التخزين.

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

بل تتعلق أيضًا بتقليل ضغط الحالة طويل الأجل على الشبكة.

Tries وتخزين العقود الذكية

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

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

يلتزم storage root للعقد بـ storage trie الخاص بالعقد.

يُمثل كل متغير تخزين في النهاية عبر storage slots.

تُرمز أنواع بيانات Solidity المعقدة، مثل mappings وarrays، إلى storage slots وفق قواعد المترجم.

عندما يتفاعل المستخدمون مع عقد، قد تُقرأ هذه الفتحات أو تتغير.

ينبغي للمطورين فهم أن التخزين ليس مجرد وسيلة برمجية مريحة.

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

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

وقد يجعل تصميم التخزين الجيد العقود أرخص وأوضح وأسهل للتدقيق.

Tries ومستكشفات البلوكشين

تعتمد مستكشفات البلوكشين على هياكل بيانات البلوكشين والفهرسة وبيانات العميل لعرض معلومات قابلة للقراءة للمستخدمين.

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

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

تساعد tries على الالتزام بتلك البيانات، بينما تفهرسها المستكشفات وتعرضها.

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

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

إذا تأخر مستكشف أو واجه خطأ في الفهرسة، فقد تظل السلسلة الأساسية صحيحة.

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

تمنح Trie roots السلسلة أساسًا تشفيريًا يمكن للمستكشفات البناء عليه.

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

Tries وRollups

قد تستخدم rollups أشجار حالة أو tries خاصة بها لتتبع الحالة خارج السلسلة أو حالة Layer 2.

تحتاج rollup إلى طريقة للالتزام بحالتها الحالية وإثبات صحة انتقالات الحالة.

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

حتى عندما لا يكون هيكل البيانات الدقيق هو MPT الخاص بـ Ethereum، تظهر الفكرة الأساسية نفسها غالبًا.

يلتزم النظام بحالة كبيرة باستخدام جذر مضغوط.

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

ولهذا يساعد تعلم tries في فهم بنية rollups.

لا تتعلق rollups بالمعاملات الأرخص فقط.

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

تُعد الهياكل الشبيهة بـ Trie إحدى الركائز التي تجعل هذه الأنظمة ممكنة.

Tries والجسور

تستخدم الجسور أحيانًا البراهين للتحقق من الأحداث أو الأرصدة أو الرسائل أو قيم التخزين من سلسلة أخرى.

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

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

لكن أمان الجسر يعتمد على أكثر بكثير من برهان Trie نفسه.

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

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

ولهذا لا ينبغي للمستخدمين افتراض أن كلمة «برهان» تجعل الجسر خاليًا من المخاطر.

يجب ربط البرهان بنموذج تحقق آمن.

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

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

Tries والأمان

تحسن tries الأمان عبر جعل العبث بالبيانات أسهل في الاكتشاف.

إذا غيّر شخص قيمة مخزنة، فينبغي أن تتغير الهاشات على طول المسار.

وينبغي أن يؤدي ذلك التغيير إلى جذر مختلف.

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

وهذا جزء أساسي من السلامة التشفيرية.

لكن Trie ليس حلًا أمنيًا كاملًا بمفرده.

فلا يستطيع Trie منع المستخدم من توقيع معاملة ضارة.

ولا يستطيع Trie إصلاح خطأ في عقد ذكي.

ولا يستطيع Trie جعل سعر Oracle الخاطئ صحيحًا.

ولا يستطيع Trie حماية الأموال إذا كان الجسر يثق في جذر خاطئ.

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

مزايا Tries في أنظمة البلوكشين

الميزة الأولى لـ Trie هي التخزين المنظم للمفتاح والقيمة.

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

الميزة الثالثة هي ضغط البادئات المشتركة عند استخدام تحسين بأسلوب Patricia.

الميزة الرابعة هي التحقق التشفيري عند دمج Trie مع تجزئة Merkle.

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

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

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

توضح هذه المزايا سبب ظهور tries في تصميم بروتوكولات البلوكشين الجادة.

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

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

قيود Tries

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

يجب اتباع قواعد الترميز بدقة، وإلا لن تتطابق الجذور.

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

قد يجعل نمو الحالة قاعدة البيانات الأساسية ثقيلة على العقد.

قد يتطلب تحديث الحالة كثيرًا من عمليات القراءة والكتابة في قاعدة البيانات.

يجب أن تتفق تطبيقات العملاء المختلفة على قواعد Trie نفسها.

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

تكون witnesses الخاصة بـ Merkle Patricia trie كبيرة إلى درجة أن Ethereum تبحث في Verkle trees كهيكل مستقبلي أكثر كفاءة.

لا تعني هذه القيود أن tries سيئة.

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

مفاهيم خاطئة شائعة حول Tries

سوء الفهم الأول هو أن Trie هو نفسه الشجرة العادية.

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

سوء الفهم الثاني هو أن Trie يوفر أمانًا تشفيريًا تلقائيًا.

لا يوفر Trie الأساسي أمان البراهين ما لم يُدمج مع التجزئة أو أسلوب التزام آخر.

سوء الفهم الثالث هو أن state root يخزن الحالة كاملةً مباشرةً.

state root ليس سوى التزام مضغوط بالحالة، وليس قاعدة البيانات الكاملة نفسها.

سوء الفهم الرابع هو أن برهان Merkle يثبت شيئًا إلى الأبد من دون سياق.

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

سوء الفهم الخامس هو أن المستخدمين لا يحتاجون أبدًا إلى الاهتمام بـ tries.

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

كيف ينبغي للمطورين التفكير في Tries

ينبغي للمطورين التفكير في tries كجزء من نظام الالتزام بحالة البلوكشين.

عندما يكتبون عقودًا ذكية، فإنهم ينشئون تغييرات حالة تؤثر في النهاية في Trie roots.

عندما يبنون محافظ أو أدوات فهرسة، فقد يعتمدون على بيانات تأتي من حالة مدعومة بـ Trie.

عندما يبنون جسورًا أو أنظمة براهين، فقد يحتاجون إلى التحقق من براهين Trie.

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

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

يمكن أن تؤثر احتياجات البراهين هذه في اختيار هيكل البيانات.

لا يحتاج المطور إلى تنفيذ Trie يدويًا لكل dApp.

لكن فهم tries يساعد المطورين على تجنب الافتراضات الخاطئة بشأن تخزين البلوكشين.

كما يساعدهم على فهم سبب أهمية قواعد العملاء منخفضة المستوى.

كيف ينبغي للمتداولين والمستخدمين التفكير في Tries

لا يحتاج المتداولون والمستخدمون العاديون إلى حساب Trie roots يدويًا.

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

إنها جزء من حالة عالمية قابلة للتحقق.

عندما تغير معاملة رصيدًا، يحدّث هذا التغيير الالتزامات التشفيرية داخل السلسلة.

ولهذا يمكن استخدام هاش المعاملة ورقم الكتلة وstate root للتحقق.

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

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

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

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

تساعد tries على جعل هذا التحقق ممكنًا خلف الكواليس.

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

ما هو Trie في الكريبتو؟

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

كيف يُنطق Trie؟

يُنطق Trie عادةً مثل «try».

لماذا تستخدم Ethereum tries؟

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

ما هو Merkle Patricia trie؟

Merkle Patricia trie هو هيكل بيانات يجمع بين البحث بأسلوب Trie وضغط مسار Patricia وتجزئة Merkle.

ما هو state trie؟

state trie هو هيكل البيانات الذي يلتزم بحالة الحسابات والعقود الحالية على البلوكشين.

ما هو storage trie؟

storage trie هو Trie خاص بعقد يلتزم بقيم تخزين حساب عقد ذكي.

ما هو Trie root؟

Trie root هو هاش المستوى الأعلى الذي يلخص كل البيانات المخزنة في Trie.

ماذا يحدث إذا تغيرت قيمة واحدة في Trie؟

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

هل Trie هو نفسه Merkle tree؟

لا، ينظم Trie البيانات عبر مسارات المفاتيح، بينما تنظم Merkle tree البيانات أساسًا عبر التجزئة المتكررة للأوراق.

ما هو برهان Merkle؟

برهان Merkle هو مجموعة بيانات تثبت أن قيمة تنتمي إلى هيكل بيانات أكبر ملتزم به بواسطة جذر معروف.

لماذا تهم tries العملاء الخفيفين؟

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

ما هي Verkle trees؟

Verkle trees هي ترقية مقترحة لهيكل بيانات الحالة يمكنها إنشاء witnesses أصغر من هياكل Merkle trie الحالية.

هل يتفاعل المستخدمون مع tries مباشرةً؟

لا يتفاعل معظم المستخدمين مع tries مباشرةً، لكنها تدعم التحقق وراء الأرصدة والإيصالات وبراهين التخزين والتحقق من الكتل.

هل tries خالية من المخاطر؟

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

الخلاصة

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

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

ينشئ هذا الدمج هياكل بيانات موثقة يمكنها الالتزام بكميات ضخمة من بيانات البلوكشين باستخدام هاشات جذور مضغوطة.

يُعد modified Merkle Patricia trie في Ethereum أشهر مثال لأنه يدعم state roots وstorage roots وtransaction roots وreceipt roots وبراهين Merkle.

تساعد tries العقد المستقلة على التحقق من وصولها إلى الحالة نفسها بعد معالجة كتلة.

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

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

تمثل هذه المفاضلات أحد أسباب بحث Ethereum في Verkle trees لتوفير witnesses أصغر ودعم أفضل للعملاء عديمي الحالة.

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

وبالنسبة إلى المستخدمين، تفسر tries سبب إمكانية التحقق من بيانات البلوكشين بدلًا من الوثوق بها فحسب.

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