Wei Dai

حين يريد المبرمج تشفير رسالة أو التحقق من توقيع رقمي، لا يحتاج إلى كتابة جميع الإجراءات من الصفر. يمكنه استخدام مكتبة تشفير، أي مجموعة دوال جاهزة للتعامل مع البيانات المحمية. كتب Wei Dai في الأصل مكتبة من هذا النوع، هي ⁦Crypto++⁩ بلغة ⁦C++⁩. إنها برمجيات فعلية يمكن دمجها في تطبيق. أما b-money فهو مساهمة مختلفة: اقتراح مكتوب لنظام نقدي. وجود مكتبة تعمل لا يثبت أن شبكة تنفذ ذلك الاقتراح قد عملت أيضًا. ولتقدير مساهمته، ينبغي تتبع هذين المسارين كلًّا على حدة. [3]

في نوفمبر ⁦1998⁩ طرح Wei Dai سؤالًا مألوفًا حتى في التسوق عبر الإنترنت: كيف يتعاون الناس من دون كشف هوياتهم؟ اقترح في b-money بروتوكولين، أي مجموعتين من القواعد للحسابات المشتركة والعقود. تستخدم المفاتيح العامة أسماءً مستعارة وتحمل الرسائل توقيعات رقمية. لكن وجود شبكة لا تسمح بتتبع المشاركين كان افتراضًا ابتدائيًا، لا نتيجة يضمنها الاقتراح نفسه. وصف المؤلف النسخة الأولى بأنها غير عملية بسبب متطلباتها الصعبة لبث الرسائل. نحن إذن نقرأ تصميمًا مدروسًا، لا تعليمات لخدمة مجهولة الهوية تعمل بالفعل. [1]

لنفترض أن آنا تملك ⁦5⁩ وحدات من b-money وترسل إلى توم ⁦2⁩. في النسخة الأولى يحتفظ كل مشارك بنسخته من الحسابات. توجّه رسالة آنا الموقعة الآخرين إلى خصم المبلغ من حسابها وإضافته إلى حساب توم، فيتبقى لها ⁦3⁩ وحدات. تُتجاهل الرسالة إذا كانت ستجعل الرصيد سالبًا. يتيح التوقيع التحقق من صلاحية إصدار الأمر، لكن الحسابات المشتركة تحتاج أيضًا إلى قواعد لتوصيل الرسائل. استخدم Bitcoin لاحقًا نموذج UTXO الذي يتتبع مخرجات معاملات محددة ما زال بالإمكان إنفاقها. لذلك لا تعني الغاية المتشابهة طريقة تسجيل متطابقة. [1]

تعهد النسخة الثانية من b-money بالحسابات إلى قسم من المشاركين يسمَّون الخوادم. يقل عمل الآخرين، لكن تظهر مسألة مراقبة من يدير السجلات. على الخوادم إيداع ضمان مالي يمكن أن يغطي العقوبات، ونشر قواعد بياناتها دوريًا والالتزام علنًا بمحتوى تلك السجلات. يتحقق المستخدم من رصيده ومن أن مجموع الحسابات لا يتجاوز المال الصادر. ويتحقق مستلم الدفعة أيضًا من معالجتها لدى خوادم تُختار عشوائيًا. لا يزيل الضمان الحاجة إلى الثقة بطريقة سحرية؛ بل هو جزء من الرقابة المقترحة على الأشخاص والآلات التي تدير الحسابات. [1]

في b-money الأصلي تُنشأ الوحدات مقابل حل مسألة حسابية. وتُحدَّد كميتها وفق تكلفة الحساب، مقاسةً بسلة معيارية من السلع. توفر هذه السلة مقياسًا مشتركًا للتكلفة، ولا تحدد السعر الذي سيدفعه شخص لشراء وحدة في السوق. لكن الحواسيب تتطور وتكاليفها الفعلية ليست معلومة للجميع. أقر Dai بهذه الصعوبة واقترح في الملحق بديلًا بالمزاد: يتفاوض مديرو الحسابات على كمية المال الجديد، ويتنافس الراغبون في إصداره بعروض حسابية. ليس هذا جدول إصدار BTC. ومن قيمة النص أنه يسمّي المشكلة الصعبة ويحاول سلوك طريق آخر. [1]

يتجاوز الاقتراح المدفوعات. في تكليف بترجمة نص، يمكن أن يثبت التوقيع الموافقة على العقد، لكنه لا يثبت جودة النص المسلَّم. لذلك تتضمن عقود b-money ضمانات مالية وتعويضات متفقًا عليها عند الإخلال ومساعدة محكّم. وإذا لم تتفق الأطراف حتى بمساعدته، تقدم حججها ويتخذ كل مشارك يدير الحسابات قراره الخاص. يوضح ذلك صعوبة نقل النزاعات البشرية إلى نظام رقمي. أما Bitcoin Script، وهي لغة شروط إنفاق مخرج معاملة، فتقيّم شروطًا تقنية محددة بدقة. لا تستطيع وحدها الحكم على جودة الترجمة الموعودة. [1]

أدرج Satoshi Nakamoto اقتراح b-money لعام ⁦1998⁩ بوصفه المرجع ⁦1⁩ في ورقة Bitcoin البيضاء التي تشرح تصميمه. يتيح ذلك تتبع صلة فكرية محددة: كان المال الرقمي من دون مدير مشترك موضوع بحث قبل Bitcoin. لكن الاستشهاد لا يعني تبنّي جميع الآليات المقترحة. تختلف الحسابات والإصدار وتسوية النزاعات في b-money عما في Bitcoin. ولا يكشف المرجع أيضًا من كان وراء اسم Satoshi Nakamoto. لفهم التاريخ، تفيد مقارنة النصوص الموثقة أكثر من استنتاج هوية المؤلف من استشهاد. [2]

تستمر قصة ⁦Crypto++⁩ من خلال الإصلاحات والاختبارات وعمل مطورين آخرين. يسجل تاريخ المشروع أن Wei Dai سلّم الإدارة اليومية إلى المجتمع في يونيو ⁦2015⁩. بالنسبة إلى المستخدم، لا يهم المؤلف الأصلي وحده، بل النسخة المحددة والاستخدام الصحيح للدوال أيضًا. قد تقدم المكتبة أدوات للتوقيع أو التشفير، لكنها لا تحل وحدها التخزين الآمن للمفاتيح أو التصميم الكامل للمحفظة. على مطوري التطبيقات قراءة الوثائق ومتابعة الإصلاحات والتحقق من استخدامهم الخاص. تقدير مساهمة المؤلف وفحص البرمجيات الحالية أمران متكاملان. [3]