تاريخ بيتكوين الأكاديمي

المقالة الأصليه : https://queue.acm.org/detail.cfm?id=3136559

تم بناء مفهوم العملات المشفرة من الأفكار المنسية في الأدبيات البحثية.

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

تتحدى هذه المقالة هذا الرأي من خلال إظهار أن جميع المكونات التقنية للبيتكوين تقريبًا نشأت في الأدبيات الأكاديمية في الثمانينيات والتسعينيات (انظر الشكل 1). هذا لا يقلل من إنجازات ناكاموتو ولكن للإشارة إلى أنه وقف على أكتاف العمالقة. في الواقع ، من خلال تتبع أصول أفكار في البيتكوين ، يمكننا التركيز على قفزة ناكاموتو الحقيقية في بعد رؤيته – الطريقة المحددة والمعقدة التي يتم بها تجميع المكونات الأساسية معًا. يساعد هذا في تفسير سبب استغراق عملات البيتكوين وقتًا طويلاً حتى يتم اختراعها. قد يكتسب القراء المطلعون بالفعل على كيفية عمل البيتكوين فهمًا أعمق من هذا العرض التاريخي. (للحصول على مقدمة ، انظر Bitcoin and Cryptocurrency Technologies by Arvind Narayanan et al. 36) يعمل تاريخ Bitcoin الفكري أيضًا كدراسة حالة توضح العلاقات بين الأوساط الأكاديمية والباحثين الخارجيين والممارسين ، ويقدم دروسًا حول كيفية استفادة هذه المجموعات من أحدها. الاخر.

دفتر الحسابات

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

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

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

الطابع الزمني المرتبط

تم استعارة هيكل بيانات دفتر الحساب الخاص ببيتكوين ، مع الحد الأدنى من التعديلات ، من سلسلة من الأوراق التي كتبها ستيوارت هابر وسكوت ستورنيتا بين عامي 1990 و 1997 (كان لورقة 1991 مؤلف مشارك آخر ، ديف باير). يقول ناكاموتو في ورقته البيضاء عن البيتكوين (34) . تناول عمل هابر وستورنيتا مشكلة الطابع الزمني للوثائق – كانا يهدفان إلى بناء خدمة “كاتب عدل رقمي”. تختص ببراءات الاختراع وعقود العمل والمستندات الأخرى ، قد يرغب المرء في إثبات أن المستند قد تم إنشاؤه في وقت معين ، وليس لاحقًا. إن مفهومهم عن المستند عام جدًا ويمكن أن يكون أي نوع من البيانات. لقد ذكروا ، بشكل عابر ، المعاملات المالية كتطبيق محتمل ، لكن لم يكن ذلك محور تركيزهم.

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

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

أشجار ميركل

تستخدم Bitcoin أساسًا بنية البيانات في أوراق Haber و Stornetta لعامي 1991 و 1997 ، الموضحة في شكل مبسط في الشكل 2 (يُفترض أن ناكاموتو لم يكن على دراية بعمل Benaloh و de Mare). بالطبع ، في البيتكوين ، تحل المعاملات محل المستندات. في شجرة Merkle الخاصة بكل كتلة ، تكون العقد الطرفية عبارة عن معاملات ، وتتكون كل عقدة داخلية بشكل أساسي من مؤشرين. بنية البيانات هذه لها خاصيتان مهمتان. أولاً ، تعمل تجزئة أحدث كتلة بمثابة ملخص. سيتطلب التغيير في أي من المعاملات (العقد الطرفية) تغييرات تنتشر على طول الطريق إلى جذر الكتلة ، وجذور جميع الكتل التالية. وبالتالي ، إذا كنت تعرف أحدث تجزئة ، فيمكنك تنزيل بقية دفتر الحساب من مصدر غير موثوق به والتحقق من أنه لم يتغير. تؤسس حجة مماثلة خاصية أخرى مهمة لهيكل البيانات – أي ، يمكن لأي شخص أن يثبت لك بكفاءة أن معاملة معينة مدرجة في دفتر الحساب. سيتعين على هذا المستخدم أن يرسل لك عددًا صغيرًا فقط من العقد في كتلة تلك المعاملة (هذه هو الهدف من شجرة Merkle) ، بالإضافة إلى كمية صغيرة من المعلومات لكل كتلة تالية. القدرة على إثبات إدراج المعاملات بكفاءة أمر مرغوب فيه للغاية للأداء وقابلية التوسع.

بالمناسبة ، تم تسمية أشجار Merkle باسم Ralph Merkle ، رائد التشفير غير المتماثل الذي اقترح الفكرة في ورقته البحثية عام 1980 (33) . كان طلبه المقصود هو إنتاج ملخص لدليل عام للشهادات الرقمية. عندما يقدم لك موقع ويب ، على سبيل المثال ، شهادة ، يمكنه أيضًا تقديم دليل قصير على ظهور الشهادة في الدليل العالمي. يمكنك التحقق من الإثبات بكفاءة طالما أنك تعرف تجزئة الجذر لشجرة Merkle للشهادات الموجودة في الدليل. هذه الفكرة قديمة بمعايير التشفير ، لكن قوتها لم يتم تقديرها إلا مؤخرًا. إنه في صميم نظام شهادة الشفافية الذي تم تنفيذه مؤخرًا .(30) تقترح ورقة عام 2015 CONIKS ، والتي تطبق الفكرة على أدلة المفاتيح العامة لرسائل البريد الإلكتروني المشفرة من طرف إلى طرف. الوظائف الرئيسية التي يوفرها دفتر الحساب في Ethereum ، عملة مشفرة جديدة.

قد تكون Bitcoin هي أشهر أشكال إنشاء مثيل في العالم الحقيقي لهياكل بيانات Haber و Stornetta ، ولكنها ليست الأولى. تقدم شركتان على الأقل – Surety التي بدأت في منتصف التسعينيات و Guardtime بدءًا من عام 2007 – خدمات ختم المستندات. هناك تطور مثير للاهتمام في كلتا هاتين الخدمتين وهو فكرة ذكرها Bayer و Haber و Stornetta ، وهي نشر جذور Merkle بشكل دوري في إحدى الصحف عن طريق نشر إعلان. يوضح الشكل 3 جذر Merkle الذي نشرته Guardtime.

تسامح الخطأ البيزنطي (Byzantine fault tolerance)

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

درس مجال بحثي مختلف ، الحوسبة الموزعة المتسامحة مع الأخطاء (fault-tolerant distributed computing) ، هذه المشكلة ، حيث تمر بأسماء مختلفة ، بما في ذلك تكرار الحالة. إن حل هذه المشكلة هو الحل الذي يمكّن مجموعة من العقد من تطبيق انتقالات الحالة نفسها بنفس الترتيب – عادةً ، لا يهم الترتيب الدقيق ، فقط أن جميع العقد متسقة. بالنسبة للعملة الرقمية ، فإن الحالة المراد تكرارها هي مجموعة الأرصدة ، والمعاملات هي انتقالات الحالة. الحلول المبكرة ، بما في ذلك Paxos ، التي اقترحتها ليزلي لامبورت الحائزة على جائزة تورينج في عام 1989 ( 28،29 ) تنظر في تكرار الحالة عندما تكون قنوات الاتصال غير موثوقة وعندما تظهر أقلية من العقد بعض الأخطاء “الواقعية” ، مثل عدم الاتصال إلى الأبد أو إعادة التشغيل وإرسال الرسائل القديمة من وقت توقفه عن الاتصال بالإنترنت لأول مرة.

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

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

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

إثبات العمل

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

البدايات

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

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

هاشكاش

تم اختراع فكرة مشابهة جدًا تسمى hashcash بشكل مستقل في عام 1997 بواسطة آدم باك ، باحث ما بعد الدكتوراه في ذلك الوقت والذي كان جزءًا من مجتمع cypherpunk. كان Cypherpunks نشطاء عارضوا سلطة الحكومات والمؤسسات المركزية ، وسعى إلى إحداث تغيير اجتماعي وسياسي من خلال التشفير. كان Back موجهاً عمليًا: أصدر hashcash أولاً كبرنامج ، وبعد عامين وخمس سنوات أصدر في عام 2002 مسودة إنترنت (وثيقة معيياريه) وورقة بحثية.(4)

Hashcash أبسط بكثير من فكرة Dwork و Naor: ليس لها باب مسحور ولا سلطة مركزية ، وتستخدم وظائف التجزئة فقط بدلاً من التوقيعات الرقمية. يعتمد على مبدأ بسيط: تتصرف وظيفة التجزئة كوظيفة عشوائية لبعض الأغراض العملية ، مما يعني أن الطريقة الوحيدة للعثور على مدخلات تجزئة لمخرجات معينة هي تجربة مدخلات مختلفة حتى ينتج المرء المخرجات المرغوبة. علاوة على ذلك ، فإن الطريقة الوحيدة للعثور على إدخال يتم تجزئته في مجموعة عشوائية من المخرجات هو محاولة تجزئة المدخلات المختلفة واحدة تلو الأخرى. لذا ، إذا تحداك في العثور على مُدخل تبدأ قيمته (الثنائية) بعشرة أصفار ، فسيتعين عليك تجربة العديد من المدخلات ، وستجد أن كل مخرج لديه فرصة 1/210 للبدء بـ 10 أصفار ، مما يعني التي يجب أن تجربها بترتيب 2^10 مدخلات ، أو ما يقرب من 1000 حساب تجزئة.

كما يوحي الاسم ، في hashcash  فإن Back ينظر إلى إثبات العمل كشكل من أشكال النقد. على صفحته على الويب ، وضعه كبديل لنظام DigiCash الخاص بـ David Chaum ، والذي كان نظامًا يصدر نقودًا رقمية لا يمكن تعقبها من أحد البنوك إلى المستخدم (3) حتى أنه قدم تنازلات بشأن التصميم الفني لجعله يبدو وكأنه نقدي. في وقت لاحق ، قدم Back تعليقات تشير إلى أن البيتكوين كان امتدادًا مباشرًا للتجزئة. Hashcash ببساطة ليست نقودًا ، لأنها لا تتمتع بأي حماية ضد الإنفاق المزدوج. لا يمكن تبادل الرموز المميزة Hashcash بين الأقران.

وفي الوقت نفسه ، في المشهد الأكاديمي ، وجد الباحثون العديد من التطبيقات لإثبات العمل إلى جانب البريد العشوائي ، مثل منع هجمات رفض الخدمة (25) و ضمان سلامة تحليلات الويب (17) وتخمين كلمة المرور المقيدة عبر الإنترنت (38)  بالمناسبة ، تم صياغة مصطلح إثبات العمل فقط في عام 1999 في ورقة كتبها ماركوس جاكوبسون وآري جولز ، والتي تتضمن أيضًا مسحًا لطيفًا للأبحاث حتى تلك النقطة (24)  وتجدر الإشارة إلى أن هؤلاء الباحثين على ما يبدو لم يكونوا على دراية بالتجزئة ولكنهم بدأوا بشكل مستقل لتقريب إثبات العمل المستند إلى التجزئة ، والذي تم تقديمه في الأوراق بواسطة Eran Gabber et al و Juels and Brainard (25، 18) (العديد من المصطلحات المستخدمة في هذه الفقرة لم تصبح مصطلحات قياسية إلا بعد فترة طويلة من  نشر هذه الأوراق.)

إثبات العمل والنقد الرقمي:  كاتش 22 (catch-22)

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

تم العثور على مناهج أكثر تماسكًا للتعامل مع حلول الألغاز على أنها نقود في مقالتين سبقتا عملة البيتكوين ، تصفان أفكارًا تسمى b-money(13) و bit gold(42) على التوالي. تقدم هذه المقترحات خدمات ختم الوقت التي توقع على إنشاء المال (من خلال إثبات العمل) ، وبمجرد إنشاء الأموال ، يقومون بالتوقيع على التحويلات. ومع ذلك ، إذا حدث خلاف حول دفتر الحساب بين الخوادم أو العقد ، فلا توجد طريقة واضحة لحلها. يبدو أن السماح للأغلبية باتخاذ قرار ضمني في كتابات كلا المؤلفين ، ولكن بسبب مشكلة Sybil ، فإن هذه الآليات ليست آمنة للغاية ، ما لم يكن هناك حارس البوابة الذي يتحكم في الدخول إلى الشبكة أو تتحقق مقاومة Sybil نفسها بإثبات العمل .

ضع كل شيء معا

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

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

تتجنب Bitcoin بدقة مشكلة الإنفاق المزدوج التي تعاني منها مخططات إثبات العمل كنقد لأنها تتجنب حلول الألغاز نفسها ذات القيمة. في الواقع ، يتم فصل حلول الألغاز مرتين عن القيمة الاقتصادية: حجم العمل المطلوب لإنتاج كتلة هو معلمة عائمة (تتناسب مع قوة التعدين العالمية) ، علاوة على ذلك ، فإن عدد عملات البيتكوين الصادرة لكل كتلة غير ثابت أيضًا. تم تعيين مكافأة الكتلة (وهي الطريقة التي يتم بها سك عملات البيتكوين الجديدة) إلى النصف كل أربع سنوات (في عام 2017 ، كانت المكافأة 12.5 بيتكوين / كتلة ، أقل من 50 بيتكوين / كتلة). تشتمل Bitcoin على مخطط مكافأة إضافي – أي مرسلي المعاملات الذين يدفعون لعمال المناجم مقابل خدمة تضمين المعاملة في كتلهم. من المتوقع أن يحدد السوق رسوم المعاملات ومكافآت عمال المناجم.

عبقرية ناكاموتو ، إذن ، لم تكن أيًا من المكونات الفردية للبيتكوين ، بل الطريقة المعقدة التي تتلاءم بها معًا لبث الحياة في النظام. لم يتطرق باحثو الطوابع الزمنية والاتفاق البيزنطي إلى فكرة تحفيز العقد على الصدق ، ولا حتى عام 2005 ، لاستخدام إثبات العمل للتخلص من الهويات. على العكس من ذلك ، لم يدمج مؤلفو الهاشكاش و b-money و bit gold فكرة خوارزمية إجماع لمنع الإنفاق المزدوج. في Bitcoin ، يعد دفتر الحساب الآمن ضروريًا لمنع الإنفاق المزدوج وبالتالي ضمان أن العملة لها قيمة. العملة القيمة ضرورية لمكافأة عمال المناجم. في المقابل ، قوة التعدين ضرورية لتأمين دفتر الحساب. بدونها ، يمكن للخصم أن يجمع أكثر من 50 في المائة من قوة التعدين العالمية وبالتالي يكون قادرًا على إنشاء كتل أسرع من بقية الشبكة ، ومعاملات الإنفاق المزدوج ، وإعادة كتابة التاريخ بشكل فعال ، وتجاوز النظام. وبالتالي ، يتم تمهيد البيتكوين ، مع اعتماد دائري بين هذه المكونات الثلاثة. لم يكن التحدي الذي واجهه ناكاموتو هو التصميم فحسب ، بل كان أيضًا إقناع المجتمع الأولي من المستخدمين وعمال المناجم بالقيام بقفزة معًا نحو المجهول – عندما كانت البيتزا تكلف 10000 بيتكوين وكانت قوة تعدين الشبكة أقل من تريليون مما هي عليه اليوم.

المفاتيح العامة كهويات

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

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

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

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

تُرى فكرة المفاتيح العامة كهويات أيضًا في b-money و bit gold ، وهما مقالتان تمهيديتان لعملة البيتكوين تمت مناقشتهما سابقًا. ومع ذلك ، فإن الكثير من الأعمال التي تم بناؤها على أساس Chaum ، وكذلك أعمال Chaum الخاصة لاحقًا بشأن ecash ، ابتعدت عن هذه الفكرة. كان cypherpunks مهتمين بشدة بالاتصالات والتجارة التي تحافظ على الخصوصية ، واعتنقوا أسماء مستعارة أطلقوا عليها اسم nyms. لكن بالنسبة لهم ، لم تكن nyms مجرد هويات مشفرة (أي مفاتيح عامة) ، بل كانت عادةً عناوين بريد إلكتروني مرتبطة بالمفاتيح العامة. وبالمثل ، فإن أطروحة Ian Goldberg ، التي أصبحت أساسًا لكثير من العمل المستقبلي حول التواصل المجهول ، تعترف بفكرة Chaum ولكنها تقترح أن تكون nyms أسماء مستعارة لا تنسى مع شهادات لربطها .20 وهكذا أثبتت Bitcoin أنها أنجح تجسيد لفكرة Chaum .

بلوكشين

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

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

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

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

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

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

الدروس الختامية

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

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

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

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

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

الشريط الجانبي

شبكات مقاومة Sybil

في ورقته البحثية حول هجمات Sybil ، اقترح John Douceur أن تكون جميع العقد المشاركة في بروتوكول BFT مطلوبة لحل ألغاز التجزئة. إذا كانت العقدة تتنكر كعقد N ، فلن تتمكن من حل الألغاز N في الوقت المناسب ، وسيتم إزالة الهويات المزيفة. ومع ذلك ، لا يزال بإمكان العقدة الخبيثة الحصول على ميزة معتدلة على العقدة الصادقة التي تدعي هوية واحدة فقط. اقترحت ورقة متابعة في عام 2005 أن العقد الصادقة يجب أن تحاكي بدلاً من ذلك سلوك العقد الخبيثة وتطالب بالعديد من الهويات الافتراضية التي يمكنها تحملها من الناحية الحسابية. مع تنفيذ هذه الهويات الافتراضية لبروتوكول BFT ، يمكن استبدال الافتراض ، “في معظم الأحيان جزء صغير من العقد معيب” بافتراض “الجزء من إجمالي القدرة الحسابية التي تتحكم بها العقد المعيبة هو f على الأكثر”. وبالتالي ، لم يعد من الضروري التحقق من صحة الهوية ، ويمكن لشبكات الند للند المفتوحة تشغيل بروتوكول BFT. يستخدم Bitcoin هذه الفكرة بالضبط. لكن ناكاموتو يطرح سؤالاً آخر: ما الذي يحفز العقد على أداء إثبات عمل مكلف حسابيًا؟ تتطلب الإجابة قفزة أخرى: العملة الرقمية.

العقود الذكية

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

تطبق Bitcoin لغة برمجة مقيدة للعقود الذكية. يتم تحديد المعاملة “القياسية” (أي معاملة تنقل العملة من عنوان إلى آخر) كنص قصير بهذه اللغة. يقدم Ethereum لغة أكثر تساهلاً وقوة.

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

بلوكشاين مرخصه

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

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

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

المصادر :

. Aspnes, J., et al. 2005. Exposing computationally challenged Byzantine imposters. Yale University Department of Computer Science; http://cs.yale.edu/publications/techreports/tr1332.pdf.

2. Back, A. 1997. A partial hash collision based postage scheme; http://www.hashcash.org/papers/announce.txt.

3. Back, A. 2001. Hash cash; https://web.archive.org/web/20010614013848/http://cypherspace.org/hashcash/.

4. Back, A. 2002. Hashcash—a denial of service counter measure; http://www.hashcash.org/papers/hashcash.pdf.

5. Bayer, D., Haber, S., Stornetta, W. S. Improving the efficiency and reliability of digital time-stamping. Proceedings of Sequences 1991; https://link.springer.com/chapter/10.1007/978-1-4613-9323-8_24.

6. Benaloh, J., de Mare, M. 1991. Efficient broadcast timestamping; http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.38.9199.

7. Boyle, T. F. 1997. GLT and GLR: Component architecture for general ledgers; https://linas.org/mirrors/www.gldialtone.com/2001.07.14/GLT-GLR.htm.

8. Castro, M., Liskov, B. 1999. Practical Byzantine fault tolerance. Proceedings of the Third Symposium on Operating Systems Design and Implementation; http://pmg.csail.mit.edu/papers/osdi99.pdf.

9. Chaum, D. 1981. Untraceable electronic mail, return addresses, and digital pseudonyms. Communications of the ACM 24(2): 84-90; https://dl.acm.org/citation.cfm?id=358563.

10. Chaum, D. 1983. Blind signatures for untraceable payments. Advances in Cryptology: 199-203.

11. Chaum, D. 1985. Security without identification: transaction systems to make Big Brother obsolete. Communications of the ACM 28(10): 1030-1044; https://dl.acm.org/citation.cfm?id=4373.

12. Chaum, D., et al. 1988. Untraceable electronic cash. Advances in Cryptology: 319-327; https://dl.acm.org/citation.cfm?id=88969.

13. Dai, W. 1998; http://www.weidai.com/bmoney.txt.

14. Douceur, J. R. 2002. The Sybil attack; https://dl.acm.org/citation.cfm?id=687813.

15. Dwork, C., Naor, M. 1992. Pricing via processing or combatting junk mail; https://dl.acm.org/citation.cfm?id=705669.

16. Felten, E. 2017. Smart contracts: neither smart nor contracts? Freedom to Tinker; https://freedom-to-tinker.com/2017/02/20/smart-contracts-neither-smart-not-contracts/.

17. Franklin, M. K., Malkhi, D. 1997. Auditable metering and lightweight security; http://www.hashcash.org/papers/auditable-metering.pdf.

18. Gabber, E., et al. 1998. Curbing Junk E-Mail via Secure Classiffication. http://www.hashcash.org/papers/secure-classification.pdf.

19. Garay, J. A., et al. 2015. The bitcoin backbone protocol: analysis and applications. Advances in Cryptology: 281-310; https://eprint.iacr.org/2014/765.pdf.

20. Goldberg, I. 2000. A pseudonymous communications infrastructure for the Internet. Ph.D. dissertation, University of California Berkeley; http://moria.freehaven.net/anonbib/cache/ian-thesis.pdf.

21. Grigg, I. 2005. Triple entry accounting; http://iang.org/papers/triple_entry.html.

22. Haber, S., Stornetta, W. S. 1991. How to timestamp a digital document. Journal of Cryptology 3(2): 99-111; https://link.springer.com/chapter/10.1007/3-540-38424-3_32.

23. Haber, S., Stornetta, W. S. 1997. Secure names for bit-strings. In Proceedings of the 4^th ACM Conference on Computer and Communications Security: 28-35; http://dl.acm.org/citation.cfm?id=266430.

24. Jakobsson, M., Juels, A. 1999. Proofs of work and bread pudding protocols; http://www.hashcash.org/papers/bread-pudding.pdf.

25. Juels, A., Brainard, J. 1999. Client puzzles: a cryptographic countermeasure against connection completion attacks. Proceedings of Networks and Distributed Security Systems: 151-165; https://www.isoc.org/isoc/conferences/ndss/99/proceedings/papers/juels.pdf.

26. Just, M. 1998. Some timestamping protocol failures; http://www.isoc.org/isoc/conferences/ndss/98/just.pdf.

27. Lamport, L., et al. 1982. The Byzantine Generals Problem. ACM Transactions on Programming Languages and Systems 4(3): 382-401; https://dl.acm.org/citation.cfm?id=357176 .

28. Lamport, L. 1989. The part-time parliament. Digital Equipment Corporation; https://computerarchive.org/files/mirror/www.bitsavers.org/pdf/dec/tech_reports/SRC-RR-49.pdf.

29. Lamport, L. 2001. Paxos made simple; http://lamport.azurewebsites.net/pubs/paxos-simple.pdf.

30. Laurie, B. 2014. Certificate Transparency. acmqueue 12(8); https://queue.acm.org/detail.cfm?id=2668154.

31. Levy, K. E. C. 2017. Book-smart, not street-smart: blockchain-based smart contracts and the social workings of law. Engaging Science, Technology, and Society 3: 1-15; http://estsjournal.org/article/view/107.

32. Melara, M., et al. 2015. CONIKS: bringing key transparency to end users. Proceedings of the 24^th Usenix Security Symposium; https://www.usenix.org/system/files/conference/usenixsecurity15/sec15-paper-melara.pdf.

33. Merkle, R. C. 1980. Protocols for public key cryptosystems. IEEE Symposium on Security and Privacy; http://www.merkle.com/papers/Protocols.pdf.

34. Nakamoto, S. 2008. Bitcoin: a peer-to-peer electronic cash system; https://bitcoin.org/bitcoin.pdf.

35. Nakamoto, S. 2008. Re: Bitcoin P2P e-cash paper; http://satoshi.nakamotoinstitute.org/emails/cryptography/11/.

36. Narayanan, A., et al. 2016. Bitcoin and Cryptocurrency Technologies: A Comprehensive Introduction. Princeton University Press; http://bitcoinbook.cs.princeton.edu/.

37. Pass, R., et al. 2017. Analysis of the blockchain protocol in asynchronous networks. Annual International Conference on the Theory and Applications of Cryptographic Techniques; https://link.springer.com/chapter/10.1007/978-3-319-56614-6_22.

38. Pinkas, B., Sander, T. 2002. Securing passwords against dictionary attacks. Proceedings of the Ninth ACM Conference on Computer and Communications Security: 161-170; https://dl.acm.org/citation.cfm?id=586133.

39. Reuters. 2014. Mind your wallet: why the underworld loves bitcoin; http://www.cnbc.com/2014/03/14/mind-your-wallet-why-the-underworld-loves-bitcoin.html.

40. Sirer, E. G. 2016. Bitcoin guarantees strong, not eventual, consistency. Hacking, Distributed; http://hackingdistributed.com/2016/03/01/bitcoin-guarantees-strong-not-eventual-consistency/.

41. Szabo, N. 1994. Smart contracts; http://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/smart.contracts.html.

42. Szabo, N. 2008. Bit gold. Unenumerated; https://unenumerated.blogspot.com/2005/12/bit-gold.html.

43. Wattenhofer, R. 2016. The Science of the Blockchain. Inverted Forest Publishing.

44. Rivest, R. L., Shamir, A. 1996. PayWord and MicroMint: Two simple micropayment schemes. International Workshop on Security Protocols.