كيفية اكتشاف ذكاء بيانات PlatoBlockchain نصف المخبوز. البحث العمودي. عاي.

كيفية اكتشاف بلوكشين نصف مخبوز

عندما لا تخدم السلاسل والكتل أي غرض مفيد

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

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

بالنسبة للشركات التي ترغب في استكشاف وفهم تقنية جديدة ، فإن وفرة الاختيار هي شيء جيد بشكل عام. ومع ذلك ، في حالة blockchains ، التي لا تزال محددة بشكل فضفاض وغير مفهومة بشكل جيد ، تأتي هذه الوفرة مع جانب سلبي كبير: العديد من منصات "blockchain" المتاحة لا تعالج في الواقع المشكلة الأساسية التي يقصد حلها. وما هي هذه المشكلة؟ اسمحوا لي أن أقتبس باختصار تعريف الفيديو بقلم ريتشارد جندال براون ، CTO of R3، كليا:

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

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

كيفية اكتشاف ذكاء بيانات PlatoBlockchain نصف المخبوز. البحث العمودي. عاي.
سلسلة أخرى من الكتل لا تساعد في مشاركة قاعدة البيانات - مصدر.

الحد الأدنى من blockchain قابلة للحياة

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

فيما يلي ست طرق حاسمة يمكن أن يفشل فيها هذا النظام مستخدميه:

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

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

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

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

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

بلوكشين مدقق واحد

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

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

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

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

blockchain الدولة المشتركة

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

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

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

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

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

بلوكشين سحابة واحدة

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

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

حل اللغز

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

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

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

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

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

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

يرجى نشر أي تعليقات على LinkedIn.

المصدر: https://www.multichain.com/blog/2016/12/spot-half-baked-blockchain/

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

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