ورقة بيتكوين البيضاء: نظام نقدي من نظير إلى نظير

PANews ملاحظة المحرر: في 31 أكتوبر 2008، قام ساتوشي ناكاموتو بنشر “ورقة بيتكوين البيضاء”، واليوم يصادف الذكرى السابعة عشرة لهذا الحدث. فيما يلي ترجمة لي شياو لاي لمحتوى الورقة البيضاء، لإعادة استذكار الكلاسيكيات.

الملخص: نظام نقدي إلكتروني بنسخة نقية من نقطة إلى نقطة، يسمح بالدفع عبر الإنترنت مباشرة من طرف إلى آخر دون الحاجة إلى المرور عبر مؤسسة مالية. التوقيعات الرقمية توفر جزءًا من الحل، ولكن إذا كان لا يزال هناك حاجة لطرف ثالث موثوق لمنع الإنفاق المزدوج، فإن الميزة الرئيسية للدفع الإلكتروني تصبح ملغاة. نقترح حلاً يستخدم شبكة من نقطة إلى نقطة لحل مشكلة الإنفاق المزدوج. ستقوم الشبكة من نقطة إلى نقطة بوضع طابع زمني لكل تداول، وذلك عن طريق إدخال بيانات التجزئة للتداول في سلسلة إثبات العمل المستمرة والمعتمدة على التجزئة، مما يشكل سجلًا لا يمكن تغييره إلا بإعادة العمل بالكامل. السلسلة الأطول تُستخدم لإثبات الأحداث وشروطها، وأيضًا لإثبات أنها جاءت من أكبر تجمع قوة التجزئة CPU. طالما أن غالبية قوة التجزئة CPU تحت سيطرة العقد الصالحة — أي أنها لا تتعاون مع العقد التي تحاول مهاجمة الشبكة — فإن العقد الصالحة ستنشئ السلسلة الأطول وتتفوق في السرعة على المهاجمين. الشبكة نفسها تحتاج إلى هيكلية دنيا. يتم نشر المعلومات بأقصى جهد، والعقد يمكنها الانضمام أو المغادرة بحرية؛ ولكن عند الانضمام يجب دائمًا قبول سلسلة إثبات العمل الأطول كدليل على كل ما حدث أثناء عدم مشاركتهم.

1. المقدمة (Introduction)

تعتمد التجارة عبر الإنترنت تقريبًا بالكامل على المؤسسات المالية كأطراف ثالثة موثوقة لمعالجة المدفوعات الإلكترونية. على الرغم من أن هذا النظام جيد لمعظم التداولات، إلا أنه لا يزال يعاني من عيوب متأصلة في النموذج القائم على الثقة. لا يمكن أن تكون التداولات غير قابلة للعكس تمامًا، لأن المؤسسات المالية لا تستطيع تجنب التحكيم في النزاعات. يزيد التحكيم من تكلفة التداول، ويحد من حجم التداولات الصغيرة الممكنة، ويمنع العديد من المدفوعات الصغيرة. بالإضافة إلى ذلك، هناك تكلفة أكبر: النظام لا يمكنه تقديم مدفوعات غير قابلة للعكس مقابل خدمات غير قابلة للعكس. إمكانية العكس تخلق الحاجة إلى الثقة في كل مكان. يجب على التجار الحذر من عملائهم، ويطلبون منهم تقديم معلومات أكثر مما هو ضروري في حالة وجود الثقة. يُعتبر جزء من الاحتيال أمرًا لا مفر منه. يمكن تجنب هذه التكاليف وعدم اليقين في الدفع عند استخدام النقد المادي مباشرة بين الأشخاص؛ لكن لا يوجد آلية تسمح بالدفع عبر قناة اتصال عندما لا يكون أحد الطرفين موثوقًا.

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

2. التداولات (Transactions)

نعرّف العملة الإلكترونية كسلسلة من التوقيعات الرقمية. عندما ينقل مالك العملة إلى شخص آخر، يضيف في نهاية سلسلة التوقيعات الرقمية توقيعًا رقميًا يتضمن: تجزئة التداول السابق، والمفتاح العام للمالك الجديد. يمكن للمستلم التحقق من سلسلة التوقيعات الرقمية للتحقق من الملكية.

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

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

3. خادم الطابع الزمني (Timestamp Server)

يبدأ الحل بخادم طابع زمني. يعمل خادم الطابع الزمني كالتالي: يضع طابعًا زمنيًا على تجزئة مجموعة من السجلات (كتلة)، ثم يبث التجزئة كما تفعل الصحيفة، أو كما في منشور في مجموعة أخبار (Usenet)[2-5]. من الواضح أن الطابع الزمني يثبت أن البيانات كانت موجودة قبل ذلك الوقت، وإلا لما أمكن توليد تلك التجزئة. كل طابع زمني يتضمن التجزئة للطابع الزمني السابق، مما يشكل سلسلة؛ كل طابع زمني جديد يُضاف بعد الطابع السابق.

4. إثبات العمل (Proof-of-Work)

لإنشاء خادم طابع زمني موزع من نقطة إلى نقطة، نستخدم نظام إثبات العمل مشابهًا لـ “هاش كاش” الخاص بآدم باك، وليس الصحف أو منشورات المجموعات الإخبارية. إثبات العمل يعني البحث عن قيمة تحقق شرطًا معينًا: بعد استخراج تجزئتها — مثل استخدام SHA-256 — يجب أن تبدأ التجزئة بعدد معين من الأصفار. كلما زاد عدد الأصفار المطلوبة، زاد العمل المطلوب بشكل أُسّي، بينما يمكن التحقق من العمل بسهولة بحساب تجزئة واحدة.

في شبكة الطابع الزمني لدينا، نحقق إثبات العمل عن طريق إضافة nonce عشوائي إلى الكتلة حتى يتم العثور على قيمة تحقق الشرط: أن تبدأ تجزئة الكتلة بعدد محدد من الأصفار. بمجرد أن تحقق نتيجة قوة التجزئة CPU إثبات العمل، لا يمكن تغيير الكتلة إلا بإعادة كل العمل السابق. مع إضافة كتل جديدة باستمرار، يصبح تغيير الكتلة الحالية يعني إعادة كل العمل في الكتل التالية.

إثبات العمل يحل أيضًا مشكلة تحديد من يقرر الأغلبية. إذا كانت “الأغلبية” تُحدد على أساس “عنوان IP لكل صوت”، يمكن لأي شخص لديه العديد من عناوين IP أن يُعتبر الأغلبية. إثبات العمل في جوهره هو “CPU لكل صوت”. الأغلبية تُحدد بالسلسلة الأطول، لأنها السلسلة التي بُذل فيها أكبر قدر من العمل. إذا كانت أغلبية قوة التجزئة CPU تحت سيطرة العقد الصالحة، تنمو السلسلة الصالحة بسرعة أكبر من السلاسل المنافسة. لتغيير كتلة موجودة، يجب على المهاجم إعادة إثبات العمل لتلك الكتلة وكل الكتل التالية، ثم اللحاق وتجاوز عمل العقد الصالحة. لاحقًا سنوضح لماذا تقل احتمالية نجاح المهاجم بشكل أُسّي مع زيادة عدد الكتل.

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

5. الشبكة (Network)

خطوات تشغيل الشبكة كالتالي:

1. تُبث جميع التداولات الجديدة إلى جميع العقد؛
2. كل عقدة تجمع التداولات الجديدة في كتلة؛
3. تبدأ كل عقدة في البحث عن إثبات عمل للكتلة؛
4. عند العثور على إثبات العمل، تُبث الكتلة إلى جميع العقد؛
5. تقبل العقد الأخرى الكتلة فقط إذا كانت جميع التداولات فيها صالحة ولم تُنفق مرتين؛
6. تعبر العقد عن قبولها للكتلة بإدراج تجزئة الكتلة المقبولة كالتجزئة السابقة في الكتلة الجديدة التي تنشئها.

تعتبر العقد دائمًا أن السلسلة الأطول هي الصحيحة، وتستمر في إضافة بيانات جديدة إليها. إذا بثت عقدتان في نفس الوقت نسختين مختلفتين من “الكتلة التالية”، قد تستقبل بعض العقد واحدة أولًا، وأخرى تستقبل الثانية أولًا. في هذه الحالة، تستمر العقد في العمل على الكتلة التي استلمتها أولًا، لكنها تحتفظ بالفرع الآخر في حال أصبح هو السلسلة الأطول. عندما يتم العثور على إثبات العمل التالي ويصبح أحد الفروع أطول، يتم حل الانقسام المؤقت، وتتحول العقد التي كانت تعمل على الفرع الآخر إلى السلسلة الأطول.

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

6. المكافآت (Incentive)

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

يمكن أن تأتي المكافآت أيضًا من رسوم التداول. إذا كانت قيمة مخرجات التداول أقل من قيمة المدخلات، يكون الفرق هو رسوم التداول؛ وتُستخدم هذه الرسوم لمكافأة العقد التي تضم التداول في الكتلة. بمجرد دخول عدد محدد من العملات إلى التداول، ستعتمد المكافآت بالكامل على رسوم التداول، ولن يكون هناك تضخم.

قد تشجع آلية المكافآت العقد على البقاء صادقة. إذا تمكن مهاجم جشع من جمع قوة تجزئة CPU أكثر من جميع العقد الصالحة، عليه أن يختار: هل يستخدم هذه القوة لخداع الآخرين باسترجاع الأموال التي أنفقها؟ أم يستخدمها لتوليد عملات جديدة؟ يجب أن يجد أن اتباع القواعد أكثر ربحية، حيث يحصل على عملات أكثر من الجميع، وهذا أفضل من تدمير النظام وجعل ثروته بلا قيمة.

7. استعادة مساحة القرص (Reclaiming Disk Space)

إذا حدث تداول لعملة قبل عدد كافٍ من الكتل، يمكن حذف سجل التداولات السابقة لتلك العملة — لتوفير مساحة القرص. لتحقيق ذلك دون الإضرار بتجزئة الكتلة، يتم تضمين تجزئة سجل التداولات في شجرة Merkle[7،2،5]، ويُدرج فقط الجذر في تجزئة الكتلة. يمكن ضغط الكتل القديمة عن طريق قطع الفروع، ولا حاجة لحفظ التجزئات الداخلية.

رأس كتلة بدون أي سجل تداولات يبلغ حوالي 80 بايت. إذا تم إنتاج كتلة كل عشر دقائق، 80 بايت × 6 × 24 × 365 = 4.2 ميجابايت سنويًا. حتى عام 2008، معظم أجهزة الكمبيوتر المتوفرة بها 2 جيجابايت من الذاكرة، ووفقًا لقانون مور، تزداد 1.2 جيجابايت سنويًا، حتى لو كان يجب حفظ رؤوس الكتل في الذاكرة فلن يكون ذلك مشكلة.

8. التحقق المبسط من الدفع (Simplified Payment Verification)

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

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

9. دمج وتقسيم القيمة (Combining and Splitting Value)

رغم أنه يمكن معالجة العملات واحدة تلو الأخرى، إلا أن تخصيص سجل منفصل لكل سنت أمر غير عملي. للسماح بتقسيم ودمج القيمة، يحتوي سجل التداولات على عدة مدخلات ومخرجات. عادةً، إما مدخل واحد من تداول سابق كبير، أو عدة مدخلات من تداولات صغيرة مجمعة؛ وفي الغالب مخرجين: واحد للدفع (للمستلم)، وإذا لزم الأمر، آخر لإرجاع الباقي (للمرسل).

من الجدير بالذكر أن “التشعب” هنا ليس مشكلة — أي أن تداول واحد يعتمد على عدة تداولات، وهذه التداولات تعتمد على المزيد. لا حاجة أبدًا لاستخراج نسخة مستقلة كاملة من سجل أي تداول.

10. الخصوصية (Privacy)

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

11. الحسابات (Calculations)

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

المنافسة بين السلسلة الصالحة والمهاجم يمكن وصفها بمشي عشوائي ثنائي الحدين. الحدث الناجح هو إضافة كتلة جديدة للسلسلة الصالحة، مما يزيد تفوقها بمقدار 1؛ والحدث الفاشل هو إضافة كتلة جديدة لسلسلة المهاجم، مما يقلل تفوق السلسلة الصالحة بمقدار 1.

احتمالية أن يلحق المهاجم بعد التأخر تشبه مشكلة إفلاس المقامر. افترض أن مقامر لديه رقائق غير محدودة، يبدأ بخسارة، ويسمح له بالمراهنة بلا حدود، بهدف تعويض الخسارة. يمكننا حساب احتمالية تعويضه للخسارة، أي احتمالية أن يلحق المهاجم بالسلسلة الصالحة[8]، كما يلي:

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

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

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

ينتظر المستلم حتى يتم تضمين التداول في كتلة، ويُضاف كتلة أخرى بعدها. لا يعرف مدى تقدم المهاجم، لكن يمكنه افتراض أن الكتل الصالحة تُنتج بمتوسط وقت محدد؛ تقدم المهاجم المحتمل يتبع توزيع بواسون، وتوقعه هو:

لحساب احتمالية أن يلحق المهاجم، نضرب كثافة بواسون لكل تقدم للمهاجم في احتمالية أن يلحق من تلك النقطة:

لتجنب جمع سلسلة لا نهائية من كثافة التوزيع…

تحويل إلى برنامج بلغة C…

من النتائج الجزئية، نرى أن الاحتمالية تنخفض بشكل أُسّي مع زيادة Z:

إذا كان P أقل من 0.1%…

12. الخاتمة (Conclusion)

قدمنا نظام تداول إلكتروني لا يعتمد على الثقة؛ يبدأ بإطار عمل عملة يستخدم التوقيعات الرقمية، ويوفر تحكمًا قويًا في الملكية، لكنه لا يمنع الإنفاق المزدوج. لحل هذه المشكلة، قدمنا شبكة من نقطة إلى نقطة تستخدم آلية إثبات العمل لتسجيل سجل تداولات علني، طالما أن العقد الصالحة تسيطر على أغلبية قوة التجزئة CPU، لا يمكن للمهاجمين تغيير النظام من ناحية قوة التجزئة فقط. قوة الشبكة تكمن في بساطتها غير الهيكلية. يمكن للعقد العمل في وقت واحد مع تنسيق قليل. لا تحتاج حتى إلى التعرف على بعضها، لأن مسار الرسائل لا يعتمد على نقطة نهاية محددة؛ فقط يجب نشر الرسائل بأقصى جهد. العقد يمكنها الانضمام أو المغادرة بحرية، وعند إعادة الانضمام، يكفي قبول سلسلة إثبات العمل كدليل على كل ما حدث أثناء غيابها. تصوت العقد بقوة التجزئة CPU، من خلال إضافة كتل صالحة جديدة للسلسلة ورفض الكتل غير الصالحة، لتحديد قبول التداولات الصالحة. يمكن فرض أي قواعد أو مكافآت ضرورية من خلال آلية الإجماع هذه.