26 / 736MRKL

Merkle Tree

شجرة ميركل

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

تجمع Merkle Tree البصمات التشفيرية للبيانات تدريجيًا في نتيجة واحدة. في Bitcoin، تنتج Merkle root المحفوظة في ترويسة الكتلة. تسمح بضع بصمات إضافية بالتحقق من توافق معاملة معينة مع هذا الجذر، من دون نقل جميع المعاملات الأخرى.

تُظهر المحفظة أن دفعتك أُدرجت في كتلة. كيف تتحقق من ذلك من دون تنزيل محتواها كله؟ هنا تفيد Merkle Tree. تُمثَّل المعاملات أولًا بقيم hash، أي بصمات تشفيرية قصيرة، ثم تُجمع تدريجيًا في بصمة مشتركة واحدة تسمى الجذر. تحتوي الترويسة على Merkle root هذه، فتربط الكتلة بمعاملاتها. الجذر ليس أرشيفًا يمكن استخراج كل المدفوعات منه، بل وسيلة للتحقق من البيانات المقدمة. [1] [2]

تخيّل أربع معاملات A وB وC وD. نأخذ بصماتها، ونصل A مع B، ثم نحسب بصمة جديدة AB. ونفعل الشيء نفسه مع C وD للحصول على CD. أخيرًا، نصل بصمتي AB وCD ونحسب الجذر. هذه الحروف مجرد أسماء للمعاملات والنتائج الوسيطة، وليست قيم hash فعلية. تشبه العملية شجرة مقلوبة: أوراق كثيرة تتلاقى عبر الفروع في جذر واحد. يضيف ازدياد المعاملات مستويات أخرى، لكن المبدأ يبقى نفسه. [3]

للتحقق من B، تكون بياناتها لديك وتحسب بصمتها. يكفي الحصول على بصمة A والبصمة المشتركة CD مع ترتيبها الصحيح. تحسب AB من A وB، ثم تحسب الجذر من AB وCD وتقارنه بالجذر في الترويسة. يسمى هذا المسار المكمّل Merkle proof. لا تحتاج إلى محتوى A أو C أو D. في شجرة متوازنة تضم 1024 معاملة، يحتوي المسار على 10 بصمات شقيقة. لذلك ينمو الدليل أبطأ بكثير من قائمة المعاملات الكاملة مع كبر الكتلة. [2] [3]

تطابق الدليل مع الجذر لا يعني الوثوق الأعمى بالترويسة المقدمة. يجب أيضًا التحقق من Proof of Work: هل تستوفي نتيجة حسابات التعدين مستوى الصعوبة المطلوب؟ ثم يُفحص اتصال الترويسة بالسلسلة المناسبة. وحتى بعد ذلك، لا يفحص Merkle proof جميع التواقيع والقواعد لكل معاملات الكتلة؛ فهذا ما تفعله Full Node. لذلك تعتمد آلية التحقق المبسط من المدفوعات SPV في whitepaper على افتراضات أمان مختلفة عن التحقق الكامل. وقد تُخرج إعادة تنظيم السلسلة الكتلة من الفرع النشط: يظل محتواها قابلًا للإثبات، لكن موقع الدفعة في التاريخ الحالي قد يتغيّر. [2]

في شجرة Bitcoin العادية، الأوراق هي معرّفات txid بترتيب معاملات الكتلة، بدءًا من Coinbase Transaction، وهي المعاملة الخاصة التي يطالب المعدّن من خلالها بمكافأة الكتلة. تُوصل الأزواج كبايتات وتُحسب بصمتها مرتين باستخدام SHA-256. إذا بقيت في نهاية أحد المستويات بصمة بلا شريك، تُكرر لهذا الحساب؛ ولا تنشأ دفعة إضافية. وإذا كانت هناك معاملة واحدة، يكون txid الخاص بها هو الجذر مباشرة. يتطلب هذا التكرار فحوصًا دقيقة للعناصر المكررة في التنفيذ. كما يفصل تحديث البروتوكول SegWit بيانات witness، مثل التواقيع. وتربط بصمة تشفيرية أخرى، مسجلة في Coinbase Transaction، هذه البيانات بالكتلة. تسمى هذه البصمة witness commitment. لذلك لا ينبغي الخلط بين شجرة txid العادية وشجرة witness. [3] [4]

للحصول على صورة أوضح، اقرأ هذا المدخل مع Block, معاملة, Block Header. تشير إلى هذا المدخل أيضًا Block Header, Hash, SHA-256, التأكيد.

DOC · 001Bitcoin Developer Guide — Merkle Treesتوثيق DOC · 002Bitcoin whitepaper — Simplified Payment Verificationمصدر أولي DOC · 003Bitcoin Core — Merkle tree implementationمصدر أولي DOC · 004BIP141: witness commitmentمصدر أولي
تمت المراجعة: المصادر أولًا · ليست نصيحة استثمارية