إنهاء مناقشة Bitcoin مقابل blockchain

عقدة المصدر: 1849174

هل هناك أي قيمة في blockchain بدون عملة مشفرة؟

الجدل مستمر منذ فترة ، لكن الشهر الماضي شهد ارتفاعا خطيرا. السؤال المطروح هو:

هل هناك أي قيمة في blockchain بدون عملة مشفرة؟ وهل يمكن تسمية "دفاتر الأستاذ المشتركة التي لا تحمل رمزا" بلوكشين على الإطلاق؟

لذا قرأت مقالة بايليشاهد فيديو تيم، وقراءة هذا منشور ناسداك، اتبعت ريتشارد كل كلمة، وحتى كان لي نقاش جيد (انظر التعليقات) مع Chris DeRose من مؤسسة Counterparty. الكثير من الهواء الساخن.

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

كان blockchain بيتكوين اقتصاديًا و ابتكار علوم الكمبيوتر.

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

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

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

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

نموذج معاملات البيتكوين

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

تحتوي Bitcoin على مجموعة من القواعد الإضافية التي يتم فرضها من قبل كل عقدة في الشبكة:

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

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

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

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

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

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

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

إذا كان إنشاء كتلة أمرًا صعبًا ومكلفًا ، فلماذا يزعج أي شخص ذلك؟ الجواب في مكافأة الكتلة. يتحكم المُعدِّن الناجح للكتلة في معاملة العملة الأساسية التي تمنحهم 25 بيتكوين (ينخفض ​​هذا المبلغ إلى النصف كل أربع سنوات). يمكنهم بيع عملات البيتكوين هذه في السوق المفتوحة مقابل 7,000 دولار (بسعر اليوم) ، وسداد فاتورة الكهرباء ، ونأمل أن يحصلوا على بعض الأرباح. يجمع عمال المناجم أيضًا القليل من الرسوم المرتبطة بالمعاملات ، على الرغم من أن هذه الرسوم تلعب دورًا ثانويًا في الوقت الحالي.

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

التحكم في تعدد القنوات

في غضون ذلك ، أريد أن أتحدث عن شيء قد يبدو غير مرتبط تمامًا.

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

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

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

ولكن ماذا يحدث إذا بدأت العمليتان في نفس الوقت؟ في هذه الحالة ، سيقرأ كل منهم رصيد حسابك ويرى أنه كافٍ للمتابعة. عند اكتمال دفع الرهن العقاري ، سيتم حساب رصيدك الجديد بمبلغ 150 دولارًا أمريكيًا وسيتم كتابته في قاعدة البيانات. عند اكتمال سحب ماكينة الصراف الآلي ، سيتم كتابة رصيدك الجديد بقيمة 500 دولار بالمثل. ستلغي إحدى عمليات الكتابة هذه العملية الأخرى ، واعتمادًا على حظك ، ستحصل على مكافأة 750 دولارًا أو 400 دولارًا من مصرفك. لا شك أنك سوف تتعلم قريبا لتوقيت زيارات الصراف الآلي ليوم الرهن.

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

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

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

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

من الأهمية بمكان لأغراضنا هنا ، يمنع MVCC التضارب بين عمليات الكتابة. على وجه التحديد:

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

دق أجراس أي؟ هناك قطعة خلفية أخرى نحتاج إلى مناقشتها.

النسخ المتماثل لقاعدة البيانات المتعددة الرئيسية

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

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

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

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

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

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

يبدو هذا بسيطًا من الناحية النظرية ، ولكن النسخ المتماثل متعدد الأغراض يطرح مشكلة جديدة لأن الصراعات يمكن أن تنشأ. ماذا لو قامت نسختان من قاعدة البيانات بتحديث نفس الصف في نفس الوقت ، ثم حاولت تبادل هذه التحديثات مع بعضها البعض؟ ستلاحظ قاعدتا البيانات حدوث تحديث متضارب ، ويجب تطبيق بعض الإستراتيجية المتفق عليها لحل هذه التعارضات. وهنا تحصل الأشياء معقدة جدا - راجع المستندات الخاصة بـ MySQL, ملقم SQL or Oracle لبعض الأمثلة على استراتيجيات حل النزاعات. (أنا أتجاهل النسخ المتزامن متعدد الأغراض المتزامن أو ما يسمى بـ "حريصة") ، حيث يجب أن تلتزم جميع النسخ المتماثلة بعملية كتابة قبل أن تتم ، لأن ذلك يتحول كل نسخة من قاعدة البيانات إلى عنق الزجاجة.)

إذن ، هذا هو المكان الذي تقودنا إليه كل هذه الخلفية:

ألن يكون من الجيد لو تمكنا من توزيع التحكم في التزامن متعدد النسخ لمنع التعارضات التي تحدث في النسخ المتماثل متعدد المفاتيح؟

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

blockchains كما وزعت MVCC

دعونا نسخ بضع جمل كتبتها بالخط العريض أعلاه:

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

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

هذه الجمل متطابقة باستثناء المصطلحات الجريئة. إذن هذا ما سأطالب به:

يوفر blockchain MVCC الموزع (مع بعض أجراس وصفارات إضافية).

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

تنفق معاملة البيتكوين واحدًا أو أكثر من هذه المخرجات وتنتج نتيجةً واحدةً أو أكثر من المخرجات الجديدة. هذا يشبه تمامًا معاملة قاعدة البيانات التي تحذف إصدارًا واحدًا أو أكثر من الصفوف ، وتنشئ صفًا جديدًا أو أكثر كنتيجة (تذكر أنه في MVCC لا يوجد شيء مثل تعديل صف في مكانه) تضمن blockchain البيتكوين أنه لا يمكن إنفاق ناتج واحد بأكثر من معاملة واحدة. هذا يعادل ضمان عدم إمكانية حذف إصدار صف واحد بأكثر من معاملة قاعدة بيانات واحدة.

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

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

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

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

Blockchains وراء MVCC

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

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

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

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

فأين هو الرمز المميز؟

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

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

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

الخاتمه

آمل أن أكون قد أثبتت أن blockchains بدون الرموز لديها بعض التطبيقات المفيدة ، حتى لو كانت مختلفة تمامًا عن blockchain للبيتكوين. ومع ذلك يبقى سؤال واحد:

هل هذه أنظمة دفتر الأستاذ المشترك المسموح بها والخالية من رمز مميز تستحق حقًا اسم "blockchain"؟

الجواب المختصر: من يهتم؟ نادرا ما يجادل حول معنى الكلمات ، لأن هناك لا إجابة صحيحة.

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

هل هذه الدفاتر المشتركة متشابهة بما يكفي لعملة البيتكوين تستحق اسم "blockchain"؟

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

شكرا لقرائتك.

اطلع على تابعني على تويتر هنا. أنظر أيضا: التسليم مقابل الدفع على blockchain.

فيما يلي بضع قطع أخرى تستحق القراءة حول هذا الموضوع بيوتر بياسيكي و حفر كامبل.

الطابع الزمني:

اكثر من متعدد السلاسل