بحث بتكوين مترجم

الورقة الأصليه

الورقة المترجمة

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

ساتوشي ناكاموتو

[email protected]

www.bitcoin.org

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

1.مقدمة

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

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

2.المعاملات

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

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

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

3. خادم الطابع الزمني

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


4. إثبات العمل

لتنفيذ خادم طابع زمني موزع على أساس نظير إلى نظير ، سنحتاج إلى استخدام نظام إثبات العمل مشابه لـ Adam Back’s Hashcash [6] ، بدلاً من منشورات الصحف أو Usenet. يتضمن إثبات العمل مسحًا ضوئيًا لقيمة عند تجزئتها ، مثل SHA-256 ، تبدأ التجزئة بعدد من البتات الصفرية. متوسط ​​العمل المطلوب أسي في عدد البتات الصفرية المطلوبة ويمكن التحقق منه عن طريق تنفيذ تجزئة واحدة.

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

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

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

5.شبكة الاتصال

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

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

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

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

6.حافز

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

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

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

7.استعادة مساحة القرص

بمجرد دفن آخر معاملة في عملة معدنية تحت كتل كافية ، يمكن التخلص من المعاملات المستنفدة قبل ذلك لتوفير مساحة على القرص. لتسهيل ذلك دون كسر تجزئة الكتلة ، يتم تجزئة المعاملات في Merkle Tree [7][2][5],] ، مع تضمين الجذر فقط في تجزئة الكتلة. يمكن بعد ذلك ضغط الكتل القديمة عن طريق قطع فروع الشجرة. لا يلزم تخزين التجزئات الداخلية.

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

8.التحقق من الدفع المبسط

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

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

  1. الجمع بين القيمة وتقسيمها

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

وتجدر الإشارة إلى أن fan -out ، حيث تعتمد المعاملة على العديد من المعاملات ، وتعتمد تلك المعاملات على العديد من المعاملات الأخرى ، ليست مشكلة هنا. ليست هناك حاجة مطلقًا لاستخراج نسخة كاملة من سجل المعاملة.5

10. الخصوصية

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

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

11. الحسابات

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

يمكن وصف السباق بين السلسلة الصادقة وسلسلة المهاجمين بأنه مسيرة عشوائية ذات الحدين. حدث النجاح هو السلسلة الصادقة التي يتم تمديدها بواسطة كتلة واحدة ، مما يؤدي إلى زيادة تقدمها بمقدار +1 ، وحدث الفشل هو تمديد سلسلة المهاجم بمقدار كتلة واحدة ، مما يقلل الفجوة بمقدار -1.

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

p = احتمال أن تجد العقدة الصادقة الكتلة التالية

q = احتمال أن يجد المهاجم الكتلة التالية

qz = احتمالية أن يتمكن المهاجم من اللحاق بـ z كتلة من الخلف


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

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

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

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

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

إعادة الترتيب لتجنب جمع الذيل اللانهائي للتوزيع …

جاري التحويل إلى كود 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

 الخلاصة

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

مراجع

  1. W. Dai, “b-money,” http://www.weidai.com/bmoney.txt, 1998.
  1. H. Massias, X.S. Avila, and J.-J. Quisquater, “Design of a secure timestamping service with minimal trust requirements,” In 20th Symposium on Information Theory in the Benelux, May 1999.
  1. S. Haber, W.S. Stornetta, “How to time-stamp a digital document,” In Journal of Cryptology, vol 3, no 2, pages 99-111, 1991.
  1. D. Bayer, S. Haber, W.S. Stornetta, “Improving the efficiency and reliability of digital time-stamping,” In Sequences II: Methods in Communication, Security and Computer Science, pages 329-334, 1993.
  1. S. Haber, W.S. Stornetta, “Secure names for bit-strings,” In Proceedings of the 4th ACM Conference on Computer and Communications Security, pages 28-35, April 1997.
  1. A. Back, “Hashcash – a denial of service counter-measure,” http://www.hashcash.org/papers/hashcash.pdf, 2002.
  1. R.C. Merkle, “Protocols for public key cryptosystems,” In Proc. 1980 Symposium on Security and Privacy, IEEE Computer Society, pages 122-133, April 1980.
  1. W. Feller, “An introduction to probability theory and its applications,” 1957.

إضافة تعليق