منصة R-chain blockchain: العمارة العامة والتطور

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











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





بناءً على هذه المشاريع البحثية ،





كانت نتيجة هذا العمل المطول ، كما يقول الجيش ، "قبول التوريد" من IT Raiffeisenbank لمنصة R-Chain اللامركزية العادية. يتم تقديمه الآن كعنصر من عناصر خدمة العملاء لمجموعات الشركات ذات الأحجام المختلفة.



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

المحتوى

• ميزات أنظمة الشركات وبين الشركات
• بنية النظام الأساسي العامة
  
  
  • هندسة مكونات البرمجيات
  • عملية تجارية وقفة واحدة
  • فوائد استخدام عملية تجارية شاملة
  • مساوئ استخدام عملية تجارية عامة
  • مراقبة الشبكة المضيفة
• تطور استخدام المكونات الفنية المختلفة
• خبرة في البحث وتشغيل منصات الشركات وتطويرها

ميزات أنظمة الشركات وبين الشركات

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

• يجب أن يكون للمنصة مشغل - كيان قانوني مسؤول أمام المشاركين عن أدائه. الخيار - كل رجل لنفسه ، سيتم تحديد كل شيء بإجماع المشاركين ، وما إلى ذلك ، نموذجي لمنصات blockchain العامة ، لن يعمل هنا.
• , . , - - 15 — , .
• « » , . , , , « » , .
• , , . , — .
• «» . , - — , , . , , — , .

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

بنية النظام الأساسي العامة

هندسة مكونات البرمجيات

تمت كتابة التطبيقات التي استخدمناها في مشاريعنا البحثية في 2016-2017 على أساس التكامل المباشر لواجهات الحوار مع المكونات "التقنية" للمنصة الموزعة - geth and swarm. ولكن ، بعد تحليل احتمالات وعواقب هذا النهج ، توصلنا إلى استنتاج مفاده أنه من الضروري تقديم طبقة أخرى بين الواجهة الخلفية للأعمال والمكونات "التقنية" - محول كائنات أعمال موحدة. تنتمي هذه التقنية إلى أنماط قياسية إلى حد ما لبناء هندسة البرمجيات ، والتي ، مع ذلك ، لا تقلل من فعاليتها. ونتيجة لذلك ، بدأت بنية برمجيات عقدة نظامنا الأساسي تبدو كما يلي:







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

عملية تجارية وقفة واحدة

بطبيعة الحال ، نشأ السؤال ، ما هي الخصائص التي يجب أن تُمنح مع عملية تجارية عالمية بحيث تضمن ، من ناحية ، أقصى استخدام لمزايا منصات blockchain ، ومن ناحية أخرى ، أقصى قدر من المرونة والوظائف للاستخدام في تطبيق الأعمال. كان الشرط الإضافي هو القدرة على تنفيذ الخصائص المحددة على معظم منصات DLT الشائعة ، والتي تختلف وظائفها اختلافًا كبيرًا في بعض الجوانب (Ethereum / Quorum / Masterchain ، Hyperledger Fabric ، Corda ، EOS ، Waves). بناءً على تجربة مشاريعنا ومشاريع الآخرين ، توصلنا إلى الاستنتاجات التالية.



يجب أن تتمتع العملية التجارية الشاملة بالسمات التالية:

• معلمات العملية (نوع العملية ، الحالة ، سمات السياق للعملية)
• قائمة دور المشاركين في العملية
• قائمة الوثائق الإلكترونية المتعلقة بالعملية
• عملية خريطة الانتقال

في الوقت نفسه ، يجب أن توفر المنصة ، على مستوى مكون blockchain ، الشروط التالية لنشر العملية في الشبكة:

• اكتمال وسلامة المعلومات
• سرية المستندات الإلكترونية خارج دائرة المشاركين في العملية
• السيطرة على متابعة عملية خريطة الانتقال
• تخزين تاريخ التغييرات في حالات العملية

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



دعنا نتناول بعض السمات والشروط المدرجة - ماذا وكيف ولماذا.



عوامل المعالجة- مفتوحة بشكل مشروط ، حيث يتم إرسالها مباشرة من خلال عقد ذكي. بالنسبة لبعض منصات blockchain ، فهي عامة بشكل أساسي (Ethereum / Masterchain) ، بالنسبة للآخرين يمكن إغلاقها بالوسائل القياسية لضمان خصوصية البيانات (Quorum - العقود الذكية الخاصة ، Hyperledger Fabric - القنوات والبيانات الخاصة). من المحتمل أن أهم معلمات "جوهر" العملية في تنفيذنا هو "نوع العملية" ، نظرًا لأنها لا تحمل عبئًا دلاليًا فحسب ، بل تحمل أيضًا حملًا وظيفيًا - اعتمادًا على "نوع العملية" ، يختار محول DLT نموذج عقد ذكيًا تكون هذه العملية فيه عرفنى بنفسك. لماذا هذا مطلوب؟ من الواضح أن هناك أنواعًا لا حصر لها من المعاملات ونفس العمليات التجارية المتنوعة التي تضمن تنفيذها.في عدد كبير نسبيًا من الحالات ، تختلف العمليات التجارية بشكل أساسي فقط في الخريطة الانتقالية (من وجهة نظر النظام الأساسي) ويمكن تنفيذها بعقد ذكي واحد يدعم خريطة انتقال عشوائية (المزيد حول ذلك أدناه). لكن اللحظات الفريدة من نوعها يمكن ربطها بعملية تجارية محددة:

• (, )
• (, )
• (, )

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



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



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



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



إن تاريخ تغيير حالة العملية عبارة عن سلسلة من "الإطارات" ، كل منها يتوافق مع عملية واحدة لتغيير حالة العملية. في تنفيذنا ، نقوم بتخزين البيانات التالية لكل "إطار" من التاريخ:

• الحالة
• ملحوظة
• معرّف البادئ في معاملة تغيير الحالة

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



ضمان الأهمية القانونية- قضية مهمة للغاية ، لاحظناها في قسم "ميزات أنظمة الشركات وبين الشركات". لقد انطلقنا في البداية من مفهوم أنه لا ينبغي توفير الأهمية القانونية عن طريق منصة blockchain ، ولكن من خلال استخدام PKI خارجي يتمتع بدعم تنظيمي أو مستوى مناسب من الثقة بين المشاركين في النظام الأساسي. بشكل تقريبي ، يجب توقيع مستند إلكتروني يوفر أساسًا قانونيًا لإجراءاتك (مستند الدفع ، العقد ، الطلب ، إلخ) والمرفق بالعملية على أساس PKI "كوشير" (في روسيا - GOST ، في مكان ما بالخارج ، على سبيل المثال ، SSL أو PGP / GPG). سيتحقق تطبيق خط الأعمال من التوقيع "الخارجي" ويتخذ الإجراء المناسب. أم لا ، حسب النتيجة. سيقول شخص ماأن هذا ليس "إنجيليًا" و "نحتاج إلى إقناع المحامين بالأهمية القانونية لمعاملات blockchain." لقد مررنا بالعديد من الخطوات في هذه الرحلة وكانت النتيجة هي نفسها دائمًا. ومع ذلك ، في حالة روسياتفتح شهادة Masterchain فرصًا معينة في هذا الصدد - كما يقولون ، "صيد سعيد!"

فوائد استخدام عملية تجارية شاملة

ماذا قدم لنا هذا النهج في النهاية؟

• توسيع دائرة المطورين المحتملين لتطبيقات الأعمال اللامركزية. «» - - , - «» , . . -, Corda, «» Ethereum, Quorum. , - «» - .
• «» . , , , , , - . , «» «» ( ), «- » . , « , ...», . «» -, «» . , «» -, . , - , . , , , , , , «» insufficient funds for gas * price + value gas required exceeds allowance or always failing transaction.
• «» -. - - , -. -, , 75-95% . , , « , » . , :
  
  
  
  >>> - DFS, , , «» -. Ethereum, «» . - (TON!), . , . … , , .
  
  
  
  >>> - . , Ethereum — , , , , , — .
• . . . , , , , , , . , , , , — .
• . , , « , ». , . — -. , - ( ) — - .

-

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

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

الجواب بسيط بما يكفي إذا:

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

حسنًا ، إذن - آلة حاسبة خاصة ... بمعنى Hyperledger Fabric أو Corda مع خياطة على كود Cheyncode وغيرها من "الحفر بالإزميل في الحجر". إذا لم يكن كذلك ، فكر بنفسك ...

مراقبة الشبكة المضيفة

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



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



بناءً على ما سبق ، منذ بداية تطوير منصتنا ، تم تضمين نظام مراقبة استباقي فيه. دعونا نصف مبدأ عملها:

• في أساس blockchain للمنصة ، يتم إنشاء عقد ذكي خاص مسؤول عن جمع وتوزيع بيانات المراقبة (للإيجاز ، سنشير إلى هذا العقد الذكي باسم SCM)
• , (), « », , . , - .
• - « », — .
• DFS- « », .
• , DFS .
• , , :
  
  >
  
  > «» -
  
  > «» DFS
  
  > - ( Ethereum- )
  
  > «»
  
  > «» — , «»
  
  > «»
  
  > «»
  
  > مسار التدقيق من تطبيقات الأعمال

عند قيمة معينة أو مجموعة من القيم الخاصة بمؤشرات المراقبة ، تقوم Mirror تلقائيًا بإيقاف معالجة قوائم انتظار العمليات الخاصة بها ، وتحجب ظهور النتائج المحتملة غير المرغوب فيها ، على سبيل المثال:

• في حالة وجود تأخر خطير في تسمية التحكم لقناة blockchain ، والتي يتم تفسيرها على أنها عقدة تتسرب من شبكة blockchain أو تعطل كامل لعملها
• في حالة وجود تأخر خطير في تسمية التحكم لقناة DFS ، والتي يتم تفسيرها على أنها عقدة تتسرب من شبكة DFS أو تعطل كامل لعملها
• في حالة وجود أخطاء في قائمة انتظار العمليات ، يتم حظر جميع العمليات اللاحقة المرتبطة بكائن الأعمال هذا (عملية الأعمال الشاملة)

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



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

• - DFS-
• - DFS-
• -
• «»
• «»

تُظهر الصورة أدناه مثالاً على شاشة بسيطة لإحدى شبكات الاختبار الخاصة بنا:







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



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



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



لأن أحد تفسيرات قانون مورفي يقول: "الخطأ يكمن عادة في موقف لا يشك فيه أحد".

تطور استخدام المكونات الفنية المختلفة

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



الأول كان مشروع إصدار ضمان دولي ، حيث كان شركاؤنا زملاء من بيلاروسيا - مارس - ديسمبر 2018.



بدأنا بتكوين Ethereum - Ethereum Swarm - Crypto-Pro (DLT-DFS-cryptography) ، والذي أثبت نفسه جيدًا في المشاريع البحثية. بدلاً من استخدام شبكة PoA للاختبار العام Ethereum Rinkeby ، تم رفع الشبكة الخاصة لـ Ethereum PoA والشبكة الخاصة Ethereum Swarm. في البداية ، لم تظهر أي مشاكل تقنية ، لكن واجهنا مشكلة "تشفير" - رفض أحد المشاركين البيلاروسيين رفضًا قاطعًا استخدام أدوات التشفير التي قدمناها ، مشيرًا إلى القانون المحلي بشأن إدارة المستندات الإلكترونية. في ذلك الوقت ، لم يكن من الممكن إيجاد حل عالي الجودة "في الوقت الحالي" ، ولكن كان هناك فهم ثابت للدور الصعب والمهم للتشفير في نجاح المشاريع الدولية.



في عملية تشغيل معاملات التحكم بالفعل على البنية التحتية للشبكة الحقيقية (قام كل مشارك بنشر عقدة على موارده) ، تم تحديد حالات الفشل في عمل Ethereum Swarm - كانت خسائر الملفات عند مستوى 20٪. تم اقتراح أن الخسارة ناتجة عن مشاكل في عميل Swarm عند إرسال ملفات متعددة بالتوازي. بشكل عام ، تم تأكيد هذا الافتراض: تجريبيًا ، تمكنا من إيجاد توقف مؤقت بين إرسال الملفات الفردية إلى Swarm في 5 ثوانٍ. أثناء الانتقال إلى تكوين شبكة قتالية تمامًا ، والذي ، نظرًا لخصائص تجزئة الشبكة المطبقة في البنية التحتية لـ Raiffeisenbank ، تطلب إنشاء عقدة عبور Swarm ، ظهرت مشكلة حرجة - سمح Ethereum Swarm بفقدان ما يصل إلى 30 ٪ من الملفات عند العمل من خلال عقدة عبور.مكّن الهيكل "الطبقي" ونظام المراقبة الجيد من تنفيذ الإصدار الفعلي للضمان بنجاح في وضع "الضخ اليدوي للغاز" ، ولكن تم تحديد مصير Ethereum Swarm. يجب أن أقول إن القدرة المعلنة لـ Ethereum Swarm على العمل في طبولوجيا بدون اتصال مباشر بين المرسل والمستقبل كانت أحد الأسباب الرئيسية لاختيارها كأساس تقني لـ DFS ، وقد أدى عدم قدرتها على العمل بشكل موثوق في هذا الوضع إلى خلق الكثير من المشاكل.وخلق عدم قدرته على العمل بشكل موثوق في هذا الوضع الكثير من المشاكل.وخلق عدم قدرته على العمل بشكل موثوق في هذا الوضع الكثير من المشاكل.



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



كان المشروع التالي هو إنشاء شبكة داخل المجموعة لمجموعة شركات Ascona Group - سبتمبر 2018 - الوقت الحالي.



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

• عند إرفاق ملف بعقد ذكي لعملية تجارية معينة ، يتم إنشاء حدث DeliveryFile الذي يحتوي على ارتباط إلى الملف
• DeliveryFile IPFS. IPFS , , . .
• , , , «» ,

وهكذا ، بدأ مشروع Ascona في تكوين Ethereum - IPFS - Crypto-Pro.



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



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



تبين أن الحل هو Quorum - عمليا شقيق Ethereum. كان عدد التحسينات في "المرآة" ضئيلاً ، ولا يتطلب تطبيق الأعمال ، بالطبع ، أي تحسينات على الإطلاق.



في الوقت الحالي ، جلب الانتقال إلى النصاب مزايا فقط:

• توافق الطوافة المستخدمة يزيل الشوكات
• يقلل عدم وجود كتل فارغة من حجم السلسلة

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



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



كنتيجة لكل هذا التطور الدراماتيكي ، وصلنا إلى تكوين Quorum - IPFS - Crypto-PRO ، والذي نستخدمه الآن في السوق المحلية الروسية.



ربما يسأل شخص ما سؤالًا منطقيًا: "حسنًا ، لم تسمع عن النصاب من قبل ، أم ماذا؟"... لقد سمعنا عن Quorum و Hyperledger Fabric و EOS. حتى أن مؤلف هذا المقال حضر ورشة عمل كوردا الأولى باللغة الروسية في خريف عام 2017. ربما ، من أجل إجابة ذكية على مثل هذه الأسئلة تحديدًا ، اخترع هيجل ديالكتيك. كان لدى الفريق الصغير الذي بدأ البحث في عام 2016 خبرة جيدة في تطوير التطبيقات التفاعلية لنظام التشغيل Windows ، وكان لدى Ethereum العامة (الاختبار الأول مفهوم) أدنى حد دخول من منصات blockchain. ونظرًا لأننا كنا مهتمين بإجراء بحث على وجه التحديد حول موضوع blockchain ، وليس في العبث بمختلف عمال الإرساء ، وبدون ذلك يكون من غير الواقعي إطلاق Quorum أو Hyperledger Fabric "للبالغين" (وليس على جميع منصات Windows الافتراضية) ، فإن الاختيار كان واضحا. حيث بدأت نتائج البحث في جذب انتباه وحدات أعمال البنك وشركائه ،أصبح من الممكن توسيع الفريق ، وتعهد الأحذية إلى صانعي الأحذية ، والفطائر في الكعك ، والحصول على خوادم Linux ، وما إلى ذلك. وبطبيعة الحال ، لم يتجاهل أحد الحلول المطورة طالما احتفظت بإمكانياتها التنموية. الجدل والتطور.

خبرة في البحث وتشغيل منصات الشركات وتطويرها

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



ما هي أهم الاستنتاجات التي يمكن استخلاصها من كل هذه التجربة؟



1. هناك مجموعة متنوعة معينة من منصات blockchain ، والتي تختلف اختلافًا كبيرًا في صفاتها "الاستهلاكية":

• "عتبة الدخول" وسهولة نشر الشبكة
• عرض النطاق
• وظائف العقود الذكية
• خيارات إغلاق المعلومات
• وقت التطوير والتكلفة

لذلك ، أعتقد أنه من المستحيل القول إن أيًا من المنصات ستصبح مهيمنة تمامًا. لكل منها دائرة خاصة بها من المستخدمين والمهام المحتملين ، حيث يكون استخدامها أكثر منطقية وفعالية من حيث التكلفة. ينطبق هذا على Ethereum و Quorum و Hyperledger Fabric و Corda. هنا ، كما هو الحال مع لغات البرمجة - فقط Vasya و Petya ، اللذان يعرف كل منهما لغة واحدة ، سيتجادلان لدرجة الغباء حول أيهما أفضل - "الإيجابيات" أو "العلجوم". وسيتحدث سيميون بتروفيتش وألبرت إيفانوفيتش ، اللذان يعرفان العشرات منهم ، بسلام - عندما تكون "الإيجابيات" أفضل ، ومتى - "العلجوم".



2. على الرغم من حقيقة أن بعض منصات DLT (على سبيل المثال ، Hyperledger Fabric و Corda) توفر القدرة على نقل عناصر البيانات الكبيرة - في الواقع ، الملفات ، على الأرجح ، أساس blockchain مع آليات العقد الذكية ووظيفة نقل الملفات ستبقى منفصلة. هذا يرجع إلى النقاط التالية:

• , DLT-. . Hyperledger Fabric Corda 2M « », , IPFS 100M. - - pdf (, ), 50M — , .
• - , ( + ), , .
• , , S3. , , « », , DFS. .
• , , -, «» .

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



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



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