Ralph Merkle

تريد إرسال رسالة مشفّرة. يحتاج المستلم إلى مفتاح سري لقراءتها، لكن كيف تسلّمه المفتاح إذا كان شخص يراقب كل الرسائل؟ وصف Ralph Merkle في بحثه المنشور عام ⁦1978⁩ طريقة غير متوقعة: يُعدّ المرسل ألغازًا مشفّرة كثيرة، ويختار المستلم أحدها عشوائيًا ويحلّه، ثم يعيد علنًا المعرّف المخفي داخله. يعرف الطرفان بذلك مفتاحًا مشتركًا. يرى المتنصّت المعرّف أيضًا، لكنه لا يعرف اللغز الذي احتواه. في النموذج الموصوف، ينمو عمله تربيعيًا مع حجم المسألة، بينما ينمو عمل المشاركين خطيًا. الفارق تربيعي وليس أُسّيًا. كان ذلك إنجازًا تاريخيًا، لكنه ليس توصية معاصرة لطريقة تشفير الرسائل. [1]

لفهم بحث عام ⁦1978⁩، يجب الانتباه إلى قدرات الخصم. يستطيع الاستماع، لكن يبقى افتراض إمكان اكتشاف التعديل أو التزوير. تخيّل شخصًا يقرأ الرسائل، وآخر يعيد كتابتها ويوقّع باسمك أيضًا. الحالة الثانية تحتاج إلى حماية إضافية: التأكد ممن تتحدث إليه بالفعل. اختلاف الجهد الحاسوبي لا يجيب عن هذا السؤال. لذلك لا تعني الألغاز أن أي تواصل عبر وسيط يتدخل في الرسائل سيكون آمنًا. إسهامها هو إظهار إمكان الاتفاق دون مفتاح سري مشترك مسبقًا، ضمن الافتراضات المحددة. [1]

يعالج Merkle Tree مشكلة أخرى. وردت شجرة التوثيق هذه في أطروحة ميركل عام ⁦1979⁩. تخيّل أرشيف عقود تريد التحقق من عقد معين فيه دون تنزيل الأرشيف كله. تُحسب لكل عنصر قيمة hash، أي بصمة رقمية قصيرة. تُجمع البصمات في أزواج ثم تُحسب بصمة جديدة لكل زوج، حتى يبقى جذر مشترك. حساب البصمة لا يشفّر المحتوى، بل يساعد على التحقق من المطابقة. ولكي يكون الفحص ذا معنى، تحتاج إلى جذر موثّق مسبقًا: بصمة تأكدت من أنها تخص الأرشيف الصحيح. إذا استطاع محتال تقديم وثيقته وجذر اعتباطي معًا، فإن تطابقهما لا يثبت شيئًا عن الأرشيف الأصلي. [2]

لنأخذ شجرة ثنائية متوازنة تضم ⁦8⁩ عناصر. للتحقق من ورقة مختارة، تحتاج إلى ⁦3⁩ بصمات شقيقة: بصمة الفرع المجاور في كل مستوى. انطلاقًا من ورقتك وهذه البصمات، تحسب الجذر ثم تقارنه بالجذر الموثّق. لا تُحتسب الورقة نفسها ولا الجذر ضمن هذه البصمات المساعدة. ويجب أن تعرف بنية الشجرة وترتيب الجمع، أي هل يوضع العنصر المجاور إلى اليمين أم إلى اليسار؟ هذا التوفير ليس خدعة ببيانات مخفية. تمثّل البصمات الأجزاء البعيدة من الأرشيف، فلا تحتاج إلى وثائقها الكاملة لإجراء هذا الفحص المحدد. [2]

يثبت Merkle Tree العلاقة بين عنصر ومجموعة بيانات معينة. لكنه لا يحوّل معلومة خاطئة إلى حقيقة. قد يتضمن أرشيفنا عقدًا باسم غير صحيح؛ ويمكن للدليل أن يؤكد إدراجه بدقة دون اكتشاف الخطأ في الاسم. كذلك لا تثبت البصمة صلاحية الشخص الذي أنشأ الوثيقة. افصل بين الأسئلة: هل يطابق العنصر هذا الجذر؟ ومن أين أعرف الجذر؟ وما القواعد التي أقبل المحتوى وفقًا لها؟ يساعد هذا التمييز على فهم ما تفعله التقنية نفسها في Bitcoin وما يجب أن تتولاه أجزاء أخرى من النظام. [2]

يستخدم Bitcoin تقنية Merkle Tree لربط المعاملات بترويسة الكتلة، وهي سجلها المختصر. يقع الجذر داخل الترويسة؛ ويؤثر تعديل المعاملات المدرجة في بصمتها المشتركة. يشرح Satoshi Nakamoto هذا البناء في القسم ⁦7⁩ من whitepaper، ويورد عمل ميركل ضمن المراجع. يثبت ذلك تأثيرًا تقنيًا، وليس أن ميركل هو مؤلف Bitcoin. لا تختار الشجرة التاريخ الصالح، ولا تتحقق من توقيعات المعاملات بدلًا من العقد. يجمع Bitcoin بينها وبين قواعد أخرى، منها التحقق من المعاملات وProof of Work، أي إثبات بذل عمل حاسوبي. فهم وظيفة مكوّن واحد أنفع من نسب قدرات النظام كله إليه. [3]

يصف القسم ⁦8⁩ من whitepaper تقنية SPV، أي التحقق المبسّط من المدفوعات. يستخدم العميل الخفيف ترويسات الكتل وفرعًا يربط المعاملة بكتلة محددة. يوفر ذلك البيانات، لكنه يعتمد على افتراضات بشأن السلسلة ذات العمل التراكمي الأكبر وسلوك المعدّنين. دليل الإدراج وحده لا يفحص جميع قواعد المعاملات كما تفعل Full Node، وهي عقدة تتحقق بالكامل. ولا يخبرنا إن كان مخرج معين قد أُنفق لاحقًا؛ فذلك يتطلب معرفة الأحداث التالية. المهم للمبتدئ ألا يساوي بين «هذه الدفعة موجودة في هذه الكتلة» والتحقق الكامل من الأموال المتاحة الآن. [3]

تستخدم أطروحة عام ⁦1979⁩ شجرة التوثيق أيضًا لمجموعة محدودة من التوقيعات الرقمية أحادية الاستخدام. يتيح التوقيع الرقمي التحقق من أن صاحب مفتاح سري معين وافق على رسالة؛ وليس صورة لتوقيع على ورق. تستطيع الشجرة ربط قيم تحقق كثيرة بجذر واحد معروف. لكن عدد التوقيعات في هذا البناء محدود، ويجب تجديد الجذر في نهاية المطاف. ولا يسمح ذلك بإعادة استخدام المفتاح الأحادي نفسه بلا حدود. يوضح هذا الجانب المتقدم من عمل ميركل فكرة مشتركة: التحقق من الجزء المطلوب بدليل صغير، مع معرفة دقيقة بالافتراضات التي يستند إليها التحقق. [2]