بيتكوين: نظام نقدي إلكتروني من نظير إلى نظير
نسخة خالصة من النقد الإلكتروني من نظير إلى نظير ستسمح بإجراء المدفوعات عبر الإنترنت مباشرة من طرف إلى آخر دون الحاجة للذهاب من خلال مؤسسة مالية. توفر التوقيعات الرقمية جزءًا من الحل، ولكن الفوائد الرئيسية تضيع إذا كانت هناك حاجة لطرف ثالث موثوق لمنع الإنفاق المزدوج. نقترح حلاً لمشكلة الإنفاق المزدوج باستخدام شبكة من نظير إلى نظير. تقوم الشبكة بتوقيت المعاملات عن طريق تجزئتها إلى سلسلة مستمرة من إثبات العمل القائم على التجزئة، مما يشكل سجلاً لا يمكن تغييره دون إعادة تنفيذ إثبات العمل. لا تعمل السلسلة الأطول فقط كدليل على تسلسل الأحداث التي تمت مشاهدتها، ولكن كدليل على أنها جاءت من أكبر تجمع لقوة معالجة وحدة المعالجة المركزية. طالما أن الأغلبية من قوة معالجة وحدة المعالجة المركزية تسيطر عليها العقد التي لا تتعاون لمهاجمة الشبكة، فإنها ستولد السلسلة الأطول وتتفوق على المهاجمين. تتطلب الشبكة نفسها هيكلًا minimal. يتم بث الرسائل على أساس أفضل جهد، ويمكن للعقد مغادرة الشبكة والعودة عند الرغبة، مع قبول أطول سلسلة من إثبات العمل كدليل على ما حدث أثناء غيابهم.
1. المقدمة يعتمد التجارة على الإنترنت تقريبًا حصريًا على المؤسسات المالية بوصفها أطرافًا ثالثة موثوقة لمعالجة المدفوعات الإلكترونية. ورغم أن النظام يعمل جيدًا بما يكفي لمعظم المعاملات، فإنه ما يزال يعاني من نقاط الضعف الجوهرية في نموذج قائم على الثقة. لا يمكن فعلًا تنفيذ معاملات غير قابلة للعكس بالكامل، لأن المؤسسات المالية لا تستطيع تجنب الوساطة عند نشوء نزاع. إن تكلفة الوساطة ترفع تكلفة المعاملة، مما يحد من الحد الأدنى العملي لحجم المعاملة ويقطع إمكانية المعاملات الصغيرة العرضية، كما توجد تكلفة أوسع تتمثل في فقد القدرة على إجراء مدفوعات غير قابلة للعكس مقابل خدمات غير قابلة للعكس. ومع إمكانية الإرجاع/العكس، تنتشر الحاجة إلى الثقة. يجب على التجار توخي الحذر من زبائنهم، والتعامل معهم للحصول على معلومات أكثر مما يحتاجون عادةً. يُقبل قدر معيّن من الاحتيال بوصفه أمرًا لا مفر منه. يمكن تجنب هذه التكاليف وعدم اليقين في المدفوعات عند إجراء التعامل شخصيًا باستخدام العملة الورقية، لكن لا توجد آلية لجعل المدفوعات عبر قناة اتصالات دون طرف موثوق. المطلوب هو نظام دفع إلكتروني قائم على البرهان التشفيري بدلًا من الثقة، يسمح لأي طرفين راغبين بإجراء المعاملة مباشرة دون الحاجة إلى طرف ثالث موثوق. المعاملات التي تكون من الناحية الحسابية غير عملية للعكس ستحمي البائعين من الاحتيال، ويمكن بسهولة تنفيذ آليات الإيداع الضماني المعتادة لحماية المشترين. في هذه الورقة، نقترح حلًا لمشكلة الإنفاق المزدوج باستخدام خادم طابع زمني موزع من نظير-إلى-نظير لتوليد برهان حسابي على الترتيب الزمني للمعاملات. يكون النظام آمنًا طالما أن العقد الصادقة مجتمعة تسيطر على قوة CPU أكبر من أي مجموعة متعاونة من عقد المهاجمين.
2. التحقق من المعاملات نعرّف العملة الإلكترونية على أنها سلسلة من التواقيع الرقمية. ينقل كل مالك العملة إلى المالك التالي عبر توقيع رقمي لتجزئة المعاملة السابقة ومفتاح المالك العام التالي، ثم إضافة ذلك إلى نهاية العملة. يمكن للمستفيد التحقق من التواقيع للتحقق من سلسلة ملكية العملة. تحقق المعاملة مفتاح المالك 1 العام تجزئة توقيع المالك 0 توقيع المالك 1 المفتاح الخاص للمالك 1 تجزئة مفتاح المالك 2 العام توقيع المالك 1 المفتاح الخاص للمالك 2 تجزئة مفتاح المالك 3 العام توقيع المالك 2 المفتاح الخاص للمالك 3 إن المشكلة، بالطبع، هي أن المستفيد لا يستطيع التحقق من أن أحد المالكين لم ينفق العملة مرتين. حل شائع هو إدخال جهة مركزية موثوقة، أو دار سكّ، تتحقق من كل معاملة لمنع الإنفاق المزدوج. بعد كل معاملة، يجب إعادة العملة إلى دار السك لإصدار عملة جديدة، ولا تُثق إلا العملات الصادرة مباشرة من دار السك بأنها لم تُنفق مرتين. تكمن المشكلة في أن هذا الحل يجعل مصير نظام المال كله يعتمد على الشركة التي تدير دار السك، إذ يجب أن تمر كل معاملة عبرها، تمامًا مثل البنك. نحتاج طريقةً تجعل المستفيد يعرف أن المالكين السابقين لم يوقّعوا أي معاملات أقدم. لأغراضنا، فإن أقدم معاملة هي التي تُحتسب، لذا لا يهمنا محاولات الإنفاق المزدوج اللاحقة. الطريقة الوحيدة لتأكيد غياب معاملة هي أن يكون المرء على علم بجميع المعاملات. في نموذج دار السك، كانت دار السك على علم بجميع المعاملات وقررت أيّها وصل أولًا. ولتحقيق ذلك دون طرف موثوق، يجب الإعلان عن المعاملات علنًا [1]، ونحتاج إلى نظام يتفق فيه المشاركون على سجل واحد لتحديد ترتيب استلام تلك المعاملات. يحتاج المستفيد إلى إثبات أنه في وقت كل معاملة، وافقت أغلبية العقد على أنها كانت أول معاملة تم استلامها.
3. خادم الطابع الزمني يبدأ الحل الذي نقترحه بخادم طابع زمني. يعمل خادم الطابع الزمني عن طريق أخذ تجزئة (هاش) لمجموعة من العناصر المطلوب وضع طابع زمني لها، ونشر هذه التجزئة على نطاق واسع، مثلًا في صحيفة أو منشور على Usenet [2-5]. يثبت الطابع الزمني أن البيانات كان يجب أن تكون موجودة في ذلك الوقت، بالطبع، لكي تدخل ضمن التجزئة. يتضمن كل طابع زمني الطابع الزمني السابق في تجزئته، مما يشكل سلسلة؛ إذ إن كل طابع زمني إضافي يعزز ما سبقه. تجزئة تجزئة كتلة عنصر عنصر ... عنصر عنصر ...
4. برهان-العمل لتنفيذ خادم طابع زمني موزع على أساس نظير-إلى-نظير، نحتاج إلى استخدام نظام برهان-عمل مشابه لنظام Adam Back Hashcash [6]، بدلًا من منشورات الصحف أو Usenet. يتضمن برهان-العمل البحث عن قيمة، عندما تُجزّأ (مثلًا باستخدام SHA-256)، يبدأ الهاش بعدد من بتات الصفر. إن متوسط العمل المطلوب يتزايد بشكل أسي مع عدد بتات الصفر المطلوبة، ويمكن التحقق منه عبر تنفيذ عملية تجزئة واحدة. بالنسبة لشبكة الطوابع الزمنية، نُطبّق برهان-العمل عبر زيادة قيمة nonce داخل الكتلة حتى نجد قيمة تجعل تجزئة الكتلة تبدأ ببتات الصفر المطلوبة. بمجرد أن تُصرف جُهود الـ CPU لجعلها تحقق برهان-العمل، لا يمكن تغيير الكتلة دون إعادة تنفيذ العمل. ومع قيام الكتل اللاحقة بالربط بعدها، فإن تغيير الكتلة سيتضمن إعادة تنفيذ جميع الكتل التي تأتي بعدها. كتلة التجزئة السابقة Tx كتلة nonce Tx ... التجزئة السابقة nonce Tx Tx ... كما أن برهان-العمل يحل أيضًا مشكلة تحديد التمثيل في قرارات الأغلبية. إذا كانت الأغلبية مبنية على «عنوان IP واحد-تصويت واحد»، فيمكن إحباطها بواسطة أي شخص قادر على تخصيص عناوين IP كثيرة. برهان-العمل هو عمليًا «CPU واحد-تصويت واحد». تُمثَّل الأغلبية بالسلسلة الأطول، التي تحوي أكبر جهد برهان-عمل مُستثمر فيها. إذا كانت أغلبية قوة الـ CPU تحت سيطرة عقد صادقة، فإن السلسلة الصادقة ستنمو بأسرع وتسبق أي سلاسل منافسة. لتعديل كتلة سابقة، سيتعين على مهاجم إعادة تنفيذ برهان-العمل للكتلة وجميع الكتل التي بعدها، ثم اللحاق والسبق على عمل العقد الصادقة. سنبيّن لاحقًا أن احتمال أن يلحق مهاجم أبطأ يقل بشكل أسي كلما أُضيفت كتل لاحقة. لتعويض ازدياد سرعة العتاد وتفاوت الاهتمام بتشغيل العقد مع الزمن، تُحدَّد صعوبة برهان-العمل بواسطة متوسط متحرك يستهدف متوسط عدد الكتل في الساعة. إذا كانت تُنشأ بسرعة كبيرة جدًا، تزداد الصعوبة.
5. الشبكة خطوات تشغيل الشبكة هي كما يلي: 1) يتم بث معاملات جديدة إلى جميع العقد. 2) تجمع كل عقدة المعاملات الجديدة في كتلة. 3) تعمل كل عقدة على إيجاد برهان-عمل صعب لكتلتها. 4) عندما تجد عقدة ما برهان-عمل، تقوم ببث الكتلة إلى جميع العقد. 5) لا تقبل العقد الكتلة إلا إذا كانت جميع المعاملات فيها صالحة ولم تُنفق من قبل. 6) تُعبّر العقد عن قبولها للكتلة عن طريق العمل على إنشاء الكتلة التالية في السلسلة، باستخدام تجزئة الكتلة المقبولة باعتبارها التجزئة السابقة. تَعتبر العقد دائمًا أن أطول سلسلة هي الصحيحة وتواصل العمل على تمديدها. إذا بثّت عقدتان نسختين مختلفتين من الكتلة التالية في الوقت نفسه، فقد تستقبل بعض العقد أحدهما أولًا. في تلك الحالة، تعمل تلك العقد على الفرع الذي استلمته أولًا، لكنها تحفظ الفرع الآخر في حال صار أطول. يُحسم التعادل عند العثور على برهان-عمل تالٍ، بحيث يصبح أحد الفرعين أطول؛ عندها ستنتقل العقد التي كانت تعمل على الفرع الآخر إلى الفرع الأطول.
لا يلزم بالضرورة أن تصل بثّات المعاملات الجديدة إلى جميع العقد. ما دامت تصل إلى عدد كبير من العقد، فستدخل في كتلة في وقت ليس بعيدًا. كما أن بثّ الكتل يتحمل رسائل تم إسقاطها. إذا لم تستلم عقدة كتلة، فستطلبها عندما تستلم الكتلة التالية وتدرك أنها فاتتها واحدة.
6. الحافز بالاصطلاح، تكون المعاملة الأولى في كتلة معاملة خاصة تبدأ عملة جديدة يملكها منشئ الكتلة. يضيف هذا حافزًا للعقد لدعم الشبكة، ويوفر طريقة لتوزيع العملات في التداول في البداية، إذ لا توجد سلطة مركزية لإصدارها. الإضافة المستمرة لثابت مقدار من العملات الجديدة تشبه إنفاق عمال المناجم للموارد لإدخال الذهب في التداول. في حالتنا، يُصرف وقت وحدة المعالجة المركزية والكهرباء. يمكن أيضًا تمويل الحافز برسوم المعاملات. إذا كانت قيمة مخرج المعاملة أقل من قيمة مدخلها، فإن الفرق يكون رسوم معاملة تُضاف إلى قيمة الحافز للكتلة التي تحتوي تلك المعاملة. بمجرد دخول عدد محدد سلفًا من العملات إلى التداول، يمكن للحافز أن ينتقل بالكامل إلى رسوم المعاملات وأن يصبح خاليًا تمامًا من التضخم. قد يساعد الحافز أيضًا في تشجيع العقد على البقاء صادقة. إذا تمكن مهاجم جشع من تجميع قدرة CPU أكثر من جميع العقد الصادقة، فسيُضطر للاختيار بين استخدام هذه القدرة لخداع الناس عبر سرقة مدفوعاته، أو استخدامها لتوليد عملات جديدة. ومن المفترض أن يجد أنه أكثر ربحية للعب وفق القواعد، وهي قواعد تمنحه عملات جديدة أكثر من الجميع مجتمعا، بدلًا من تقويض النظام وإضعاف صحة ثروته الخاصة.
7. استعادة مساحة القرص عندما تُدفن أحدث معاملة في عملة تحت عدد كافٍ من الكتل، يمكن حذف المعاملات المصروفة قبلها لتوفير مساحة على القرص. لتسهيل ذلك دون كسر تجزئة الكتلة، تُجزّأ المعاملات داخل شجرة ميركل [7][2][5]، بحيث لا يتم إدراج سوى الجذر في تجزئة الكتلة. يمكن عندها ضغط الكتل القديمة عن طريق قطع/استئصال فروع الشجرة. لا يلزم تخزين تجزئات داخلية. كتلة كتلة رأس (تجزئة الكتلة) التجزئة السابقة قيمة nonce التجزئة الجذر Hash01 تجزئة Hash0 تجزئة Hash1 تجزئة Hash23 تجزئة Hash2 Tx0 Tx1 Tx2 تجزئة Hash3 Tx3 المعاملات المُجزّأة في شجرة ميركل كتلة كتلة رأس (تجزئة الكتلة) التجزئة السابقة قيمة nonce التجزئة الجذر Hash01 تجزئة Hash23 تجزئة Hash2 تجزئة Hash3 Tx3 بعد التقليم Tx0-2 من الكتلة رأس كتلة دون معاملات سيكون بحجم يقارب 80 بايت. إذا افترضنا أن الكتل تُنشأ كل 10 دقائق، فستكون 80 بايت * 6 * 24 * 365 = 4.2MB في السنة. وبالنظر إلى أن أنظمة الحاسوب عادةً تُباع بسعة 2GB من الذاكرة العشوائية (RAM) اعتبارًا من عام 2008، وبما تتنبأ به «قانون مور» من نمو حالي يبلغ 1.2GB في السنة، فلا ينبغي أن تكون سعة التخزين مشكلة حتى لو كانت رؤوس الكتل يجب الاحتفاظ بها في الذاكرة.
8. التحقق المبسط للدفع يمكن التحقق من المدفوعات دون تشغيل عقدة شبكة كاملة. يحتاج المستخدم فقط إلى الاحتفاظ بنسخة من رؤوس الكتل لسلسلة أطول برهان-عمل، والتي يمكنه الحصول عليها عبر الاستعلام من عقد الشبكة حتى يقتنع بأنه يملك أطول سلسلة، والحصول على فرع ميركل الذي يربط المعاملة بالكتلة التي وُضع فيها طابعها الزمني. لا يستطيع التحقق من المعاملة بنفسه، لكن بربطها بمكان داخل السلسلة، يمكنه أن يرى أن عقدة شبكة قد قبلتها، وأن الكتل المضافة بعد ذلك تؤكد أكثر أن الشبكة قبلتها. سلسلة أطول برهان-عمل رأس كتلة التجزئة السابقة قيمة nonce جذر ميركل رأس كتلة التجزئة السابقة جذر ميركل تجزئة01 تجزئة2 رأس كتلة قيمة nonce التجزئة السابقة قيمة nonce جذر ميركل تجزئة23 تجزئة الفرع الخاص بالمعاملة Tx3 جذر ميركل التجزئة Hash3 Tx3 وهكذا تكون عملية التحقق موثوقة طالما أن العقد الصادقة تسيطر على الشبكة، لكنها تكون أكثر عرضة للخداع إذا تمكن مهاجم من الاستحواذ على الشبكة. بينما تستطيع عقد الشبكة التحقق من المعاملات لأنفسها، يمكن لخطة التحقق المبسطة أن تُخدع بمعاملات مُصطنعة من مهاجم ما دام المهاجم قادرًا على مواصلة التفوق على الشبكة. إحدى الاستراتيجيات للحماية من ذلك هي قبول التنبيهات من عقد الشبكة عند اكتشافها لكتلة غير صالحة، بحيث يقوم برنامج المستخدم بتنزيل الكتلة الكاملة والمعاملات التي تم التنبيه عنها للتأكد من التناقض. ستظل الشركات التي تتلقى مدفوعات متكررة غالبًا ترغب في تشغيل عقدها الخاصة من أجل أمان أكثر استقلالية وتحقيق تحقق أسرع.
9. الجمع والتجزئة للقيمة رغم أنه يمكن التعامل مع العملات بشكل منفرد، إلا أنه سيكون غير عملي إنشاء معاملة منفصلة لكل سنت في عملية تحويل. ولإتاحة تقسيم القيمة ودمجها، تحتوي المعاملات على مدخلات ومخرجات متعددة. عادةً سيكون هناك إما مدخل واحد من معاملة سابقة أكبر، أو عدة مدخلات تجمع مبالغ أصغر، وبحد أقصى مخرجان: واحد للدفع، وواحد لإرجاع التغيير، إن وجد، إلى المرسل. معاملة In In Out ... ... تجدر الإشارة إلى أن التوسع/التفرّع (fan-out)، حيث تعتمد معاملة على عدة معاملات، وأن تعتمد تلك المعاملات على المزيد، ليس مشكلة هنا. ولا توجد أبدًا حاجة لاستخراج نسخة مستقلة كاملة لسجل تاريخ معاملة ما.
10. الخصوصية يحقق نموذج العمل المصرفي التقليدي مستوى من الخصوصية عبر تقييد الوصول إلى المعلومات على الأطراف المعنية والطرف الثالث الموثوق. تمنع ضرورة الإعلان عن جميع المعاملات علنًا إمكانية استخدام هذه الطريقة، لكن يمكن الحفاظ على الخصوصية عبر كسر تدفق المعلومات في مكان آخر: عبر إبقاء المفاتيح العامة مجهولة الهوية. يمكن للجمهور أن يرى أن شخصًا ما يرسل مبلغًا إلى شخص آخر، لكن دون معلومات تربط المعاملة بأي شخص. يشبه ذلك مستوى المعلومات التي تُنشرها البورصات، حيث تُعلن للعموم أوقات وأحجام الصفقات الفردية، «الشريط»، دون الكشف عن من كانوا أطرافًا فيها. نموذج الخصوصية التقليدي هويات مفاتيح عامة هويات نموذج الخصوصية الجديد معاملات طرف ثالث موثوق معاملات Counteparty عامة معاملات المعاملات العامة كجدار ناري إضافي، يجب استخدام زوج مفاتيح جديد لكل معاملة لمنع ربطها بمالك مشترك. لا يزال هناك قدر من الربط غير قابل للتجنب في المعاملات متعددة المدخلات، إذ إنها تكشف بالضرورة أن مدخلاتها كانت مملوكة لنفس المالك. تتمثل المخاطرة في أنه إذا تم الكشف عن مالك المفتاح، فقد يؤدي ذلك إلى كشف معاملات أخرى تخص المالك نفسه.
11. الحسابات ندرس سيناريو يحاول فيه مهاجم توليد سلسلة بديلة أسرع من السلسلة الصادقة. حتى إذا تحقق ذلك، فلن يفتح النظام على تغييرات عشوائية من قبيل خلق قيمة من لا شيء أو أخذ أموال لم تكن أصلًا للمهاجم. لن تقبل العقد معاملة غير صالحة كدفعة، ولن تقبل العقد الصادقة كتلة تحتوي عليها. لا يمكن للمهاجم إلا محاولة تغيير واحدة من معاملاته هو لاسترجاع أموال أنفقها مؤخرًا. يمكن توصيف السباق بين السلسلة الصادقة وسلسلة المهاجم كسير عشوائي ثنائي (Binomial Random Walk). حدث النجاح هو أن السلسلة الصادقة تُمدَّد بكتلة واحدة، ما يزيد تقدمها بمقدار +1، وحدث الفشل هو أن سلسلة المهاجم تُمدَّد بكتلة واحدة، ما يقلص الفارق بمقدار -1. احتمال أن يلحق مهاجم ما من عجز معيّن يشبه مشكلة «هلاك القمار» (Gambler's Ruin). لنفترض مقامرًا لديه رصيد غير محدود يبدأ عند عجز ويخوض عددًا محتملًا لا نهائيًا من المحاولات للوصول إلى التعادل. يمكننا حساب احتمال أن يصل يومًا إلى التعادل، أو أن يلحق مهاجم ما بالسلسلة الصادقة، كما يلي [8]: p = احتمال أن يجد عقدة صادقة الكتلة التالية q = احتمال أن يجد المهاجم الكتلة التالية qz = احتمال أن يتمكن المهاجم من اللحاق من z كتل خلفًا qz = { 1 إذا p≤q q/ pz إذا pq }
بافتراضنا p > q، تنخفض الاحتمالية بشكل أسي مع زيادة عدد الكتل التي يتعين على المهاجم اللحاق بها. مع عدم الحظ ضده، إذا لم يقم بانطلاقة حظ مبكرة، تصبح فرصه صغيرة جدًا لدرجة أنها تقترب من الصفر كلما ابتعد أكثر عن الركب. الآن ندرس المدة التي يحتاج فيها مستلم معاملة جديدة إلى الانتظار ليصبح على يقين كافٍ بأن المُرسل لا يستطيع تغيير المعاملة. نفترض أن المُرسل مهاجم يريد جعل المستلم يصدّق أنه دفع له لبعض الوقت، ثم يبدّلها لاحقًا ليدفع إلى نفسه بعد مرور بعض الوقت. سيتم تنبيه المستلم عند حدوث ذلك، لكن المُرسل يأمل أن يكون الوقت قد فات. يقوم المستلم بتوليد زوج مفاتيح جديد ويعطي المفتاح العام للمُرسل قبل التوقيع مباشرة. يمنع ذلك المُرسل من تجهيز سلسلة كتل مسبقًا عبر العمل عليها باستمرار حتى يحالفه الحظ كي يتقدم بما يكفي، ثم تنفيذ المعاملة عند تلك اللحظة. بمجرد إرسال المعاملة، يبدأ المُرسل غير النزيه بالعمل سرًا على سلسلة موازية تتضمن نسخة بديلة من معاملته. ينتظر المستلم حتى تُضاف المعاملة إلى كتلة ويتم ربط z كتلة بعدها. لا يعرف مقدار التقدم الدقيق الذي أحرزه المهاجم، لكن بافتراض أن الكتل الصادقة استغرقت متوسطًا زمنيًا متوقعًا لكل كتلة، فإن التقدم المحتمل للمهاجم يتبع توزيع بواسون بقيمة متوقعة: =z q p لإيجاد احتمال أن يتمكن المهاجم من اللحاق الآن أيضًا، نضرب كثافة بواسون لكل مقدار تقدم قد يكون أحرزه بالاحتمال الذي يمكنه من خلاله اللحاق من تلك النقطة: ∞ ke− ∑ k=0 k! ⋅ { q/ pz−k if k≤z 1 if kz } ترتيبًا لإزالة الحاجة إلى جمع الذيل اللانهائي للتوزيع... 1−∑ k=0 z ke− k! 1−q/ pz−k تحويلًا إلى كود C... #include <math.h> double AttackerSuccessProbability(double q, int z) { double p = 1.0 - q; double lambda = z * (q / p); double sum = 1.0; int i, k; for (k = 0; k <= z; k++) { double poisson = exp(-lambda); for (i = 1; i <= k; i++) poisson *= lambda / i; sum -= poisson * (1 - pow(q / p, z - k)); } return sum; }
بتشغيل بعض النتائج، نلاحظ أن الاحتمالية تنخفض بشكل أسي مع z. q=0.1 z=0 P=1.0000000 z=1 P=0.2045873 z=2 P=0.0509779 z=3 P=0.0131722 z=4 P=0.0034552 z=5 P=0.0009137 z=6 P=0.0002428 z=7 P=0.0000647 z=8 P=0.0000173 z=9 P=0.0000046 z=10 P=0.0000012 q=0.3 z=0 P=1.0000000 z=5 P=0.1773523 z=10 P=0.0416605 z=15 P=0.0101008 z=20 P=0.0024804 z=25 P=0.0006132 z=30 P=0.0001522 z=35 P=0.0000379 z=40 P=0.0000095 z=45 P=0.0000024 z=50 P=0.0000006 حلًا للعثور على P أقل من 0.1%... P < 0.001 q=0.10 z=5 q=0.15 z=8 q=0.20 z=11 q=0.25 z=15 q=0.30 z=24 q=0.35 z=41 q=0.40 z=89 q=0.45 z=340
12. الخلاصة لقد اقترحنا نظامًا للمعاملات الإلكترونية دون الاعتماد على الثقة. بدأنا بالإطار المعتاد للقطع النقدية المصنوعة من التواقيع الرقمية، والذي يوفر تحكمًا قويًا في الملكية، لكنه غير مكتمل دون طريقة لمنع الإنفاق المزدوج. لحل ذلك، اقترحنا شبكة نظير-إلى-نظير تستخدم برهان-العمل لتسجيل سجل عام للمعاملات يصبح بسرعة غير عملي حسابيًا بالنسبة لمهاجم لتغييره إذا كانت العقد الصادقة تتحكم بأغلبية قوة وحدة المعالجة المركزية (CPU). الشبكة قوية بفضل بساطتها غير المهيكلة. تعمل العقد كلها في الوقت نفسه تقريبًا دون تنسيق كبير. ولا تحتاج إلى أن تُعرّف، إذ لا يتم توجيه الرسائل إلى موقع بعينه ولا يلزم تسليمها إلا على أساس بذل أقصى جهد. يمكن للعقد مغادرة الشبكة والانضمام إليها متى شاءت، مع قبول سلسلة برهان-العمل باعتبارها دليلًا على ما حدث أثناء غيابها. تصوّت العقد باستخدام قوة الـ CPU لديها؛ فهي تُعبّر عن قبولها للكتل الصالحة عبر العمل على تمديدها، وترفض الكتل غير الصالحة عبر الامتناع عن العمل عليها. يمكن فرض أي قواعد وحوافز مطلوبة عبر آلية الإجماع هذه.