Reusable Proofs of Work

في 15 أغسطس 2004 دعا هال فيني المشاركين في قائمة بريدية للتشفير إلى تجربة مشروعه الجديد. انطلق من Hashcash الذي وضعه آدم باك: يجرّب الحاسوب مدخلات مختلفة حتى يجد نتيجة تحقق شرطاً محدداً. يستغرق البحث وقتاً حسابياً، بينما يكون التحقق من النتيجة الجاهزة سريعاً. نسمي هذا Proof of Work، أي إثبات العمل. وفي مكافحة البريد المزعج يمكن أن يؤدي دور طابع بريدي تُدفع كلفته بالحسابات. تساءل فيني إن كان هذا الإثبات يستطيع الانتقال بين الناس، بدلاً من انتهاء فائدته بعد استخدام واحد. وهذا ما يعنيه اسم RPOW: إثباتات عمل قابلة لإعادة الاستخدام. [1] [2] [4]

لنتخيل أن آنا تملك رمزاً رقمياً صالحاً وترسله إلى بيتر. إذا أرسلت ملفاً فقط، فربما احتفظت بنسخة منه. لذلك يقدّم بيتر الرمز إلى خادم RPOW ويطلب استبداله. يتحقق الخادم من أنه لم يُستخدم، ويسجّله كمستهلك، ثم يوقّع رمزاً جديداً أعدّه برنامج بيتر. لن تصلح نسخة آنا من الرمز القديم لاستبدال آخر. يستطيع بيتر لاحقاً إرسال الرمز الجديد إلى إيفا، فتكرر الإجراء. ما يعاد استخدامه إذن هو القيمة المنقولة، لا الملف نفسه الذي يبقى صالحاً إلى الأبد. وما لم يُكمل المستلم الاستبدال بنجاح، قد يسبقه المرسل إلى إنفاق الرمز الأصلي. [2] [11]

قد يكون المدخل Hashcash حُسب للتو، أو رمز RPOW لم يُستخدم بعد. أما المخرج فهو رمز جديد يحمل توقيعاً رقمياً من نوع RSA، أي تأكيداً من الخادم يمكن التحقق منه رياضياً. RSA طريقة لحساب هذا التوقيع: يُستخدم مفتاح توقيع سري لإنشائه، ويكفي المفتاح العام المقابل للتحقق منه. فهو بيانات رقمية قابلة للتحقق، وليس صورة لتوقيع بخط اليد. يتيح التوقيع معرفة مصدر الرمز، لكنه لا يخبرنا وحده إن كان قد استُبدل سابقاً. لهذه الغاية وُجد سجل المدخلات المستخدمة. وفي عمليات النقل اللاحقة لم يكن من الضروري تكرار البحث المكلف الخاص بـHashcash كل مرة؛ بل يُمنح توقيع جديد مقابل إبطال الإثبات القديم. لم يكن ذلك إعادة تدوير للكهرباء، ولا وسيلة لمضاعفة الحق في عمل سابق مجاناً. [2]

كانت القيمة هنا مستوى من صعوبة الحساب، لا سعراً بالكورونة أو الدولار. استخدم Hashcash آنذاك دالة SHA-1 التي تنتج بصمة رقمية قصيرة للبيانات، وبحث عن بصمة تبدأ بعدد محدد من البتات الصفرية. والبت رقم ثنائي واحد. كل صفر إضافي مطلوب يضاعف تقريباً متوسط عدد المحاولات. لذلك مثّل رمز المستوى 21 العمل المتوقع نفسه الذي يمثّله رمزان من المستوى 20، وكان ممكناً تقسيمه إليهما. وكان يجب الحفاظ على مجموع هذه القيمة الحسابية عند الدمج أو التقسيم. لكن ذلك لم يثبت سعر صرف ولا يضمن قوة شرائية؛ فالحواسيب الأسرع تستطيع إنتاج النوع نفسه من الرموز بكلفة أقل. [2] [10]

يعني Double spend إنفاق القيمة نفسها مرتين. لمقاومته، احتاج RPOW إلى قائمة بالإثباتات التي استُبدلت. ولم تكن قاعدة البيانات كاملة داخل البطاقة المحمية، بل كان الحاسوب المضيف العادي يخزنها. احتفظت البطاقة ببصمة تحقق لحالة القاعدة، وفحصت أدلة تشفيرية عند الاستعلام. استخدمت مبدأ Merkle Tree، أي شجرة من البصمات تتيح التحقق من جزء من البيانات بالرجوع إلى بصمة مشتركة واحدة. كان المطلوب اكتشاف تعديل السجلات، وكذلك العودة إلى قاعدة قديمة لا تتضمن الرمز الذي أُنفق للتو. ومن دون هذه الحماية كان بوسع المشغّل تحويل المدخل نفسه إلى رموز جديدة مراراً. [3]

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

نشر الشيفرة المصدرية وحده لا يكفي؛ فقد يعرض المشغّل برنامجاً ويشغّل آخر. لذلك استخدم RPOW آلية remote attestation، أي التصديق عن بُعد على إعداد النظام. كانت البطاقة تصدر معلومات موقّعة عن البرنامج الذي تنفّذه. ويمكن للمهتم بناء البرنامج من الشيفرة المنشورة بالأدوات المناسبة، ثم مقارنة بصمة صورته التنفيذية الناتجة بالبصمة المعلنة. لم تكن المقارنة إذن بين نصوص ملفات المصدر فقط. وامتدت الثقة في التوقيعات عبر سلسلة شهادات حتى مفتاح IBM. يساعد ذلك على التأكد من البرنامج العامل فعلاً، لكنه لا يثبت خلوه من الأخطاء ولا عصمة الشركة المصنّعة وإجراءات إصدار شهاداتها من الفشل. [3] [9]

يشبه RPOW نظام eCash في تبادل الرموز الرقمية، لكن التشغيل الأصلي الموصوف لم يحمِ الخصوصية بالتوقيع الأعمى. اعتمد فيني على اتصال مشفّر يصل إلى البطاقة المحمية، وعلى برنامج قابل للتحقق لا يحتفظ بالروابط بين الرموز الصادرة والمستلمة. لذلك لا يفترض أن يرى الحاسوب المضيف محتواها مكشوفاً. لكنه يظل قادراً على ملاحظة عنوان العميل الشبكي وتوقيت الاتصال وحجمه. وقد يتيح تقديم الرمز نفسه مرة أخرى ربط بعض الأحداث أيضاً. تصف الوثائق المحفوظة بالفعل دعم Tor، وهي شبكة تمرر الاتصال عبر عدة وسطاء وتخفي عن الخادم عنوان الشبكة الأصلي للمستخدم. أما التوقيع الأعمى فتطرحه باعتباره إضافة محتملة لاحقاً. فلا يصح تقديم هذه الميزة المخطط لها كجزء من التشغيل الموصوف آنذاك. [8] [10]

لم يبقَ RPOW مقترحاً على الورق: كان له خادم يعمل وبرنامج عميل متاح. لكن فيني حذّر منذ البداية من أنه إصدار تجريبي مبكر؛ فقد يؤدي تغيير ضروري في برنامج الخادم إلى إبطال رموز صدرت سابقاً. خُصصت الرموز للاستخدام الشخصي والتجريبي وغير التجاري، لا لتكون نقوداً مضمونة القيمة. وحتى البطاقة المحمية لا تستطيع إجبار المشغّل على إبقاء الخادم يعمل. انتهى المشروع الأصلي، وأصبحت الصفحات والشيفرة المحفوظة مواد تاريخية. لذلك لا يُعد وصف SHA-1 وRSA والعتاد المستخدم آنذاك توصية لبناء خدمة دفع حديثة على النحو نفسه. [1] [4] [5] [7]

أراد فيني تجسيد جزء من فكرة Bit Gold لنيك زابو: يمكن أن يكون إنشاء شيء رقمي مكلفاً، ثم يمكن نقله بين الناس. كما توقعت وثائق RPOW تعاون عدة خوادم، فلا يصح اختزال التصميم كله في حاسوب وحيد إلى الأبد. ومع ذلك، كان كل رمز يحدد الخادم الذي يجب استبداله لديه؛ وإضافة آلات لا تلغي هذا الاعتماد بذاتها. اتخذ Bitcoin طريقاً آخر. تتحقق عُقد مستقلة، أي حواسيب تشغّل برامج للتحقق، من قواعد مشتركة وتاريخ علني. ويتنافس المعدّنون على إضافة كتل صالحة جديدة، وهي مجموعات معاملات مرتبطة بالسجل السابق. يساعدنا RPOW على فهم ما لا يحله Proof of Work وحده: كيف يتعرف الجميع إلى الترتيب الصحيح لعمليات النقل، وبمن يحتاجون إلى الثقة أثناء ذلك؟ [1] [6] [11]