👨🏻‍🔧 🐜 🍐 تسجيل العجلات الموزعة: تجربة مع Hyperledger Fabric ⛹🏿 🌄 ☀️

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

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

المشكلة: لم يتم قياس blockchains حتى الآن

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

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

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

يعمل Mainnet Ethereum الآن بمعدل 30 نقطة في الثانية تقريبًا. وبسبب هذا بالفعل ، من الصعب تصورها على أنها أي blockchain مناسبة لاحتياجات الشركات. ومن بين الحلول permissioned، ومن المعروف المعايير، والتي تبين 2000 TPS ( النصاب القانوني ) أو 3000 TPS ( Hyperledger النسيج ، ونشر أصغر قليلا، ولكن عليك أن تنظر في الأمر أن المؤشر أجريت على المحرك الإجماع القديم). كانت هناك محاولة لمراجعة النسيج بشكل جذري ، والتي لم تعط أسوأ النتائج ، 20000 نقطة في الثانية ، ولكن حتى الآن هذا هو مجرد بحث أكاديمي في انتظار تنفيذه المستقر. من غير المحتمل أن تتعامل شركة يمكنها الحفاظ على قسم من مطوري blockchain مع هذه المؤشرات. لكن المشكلة ليست في الإنتاجية فقط ، ولكن لا يزال هناك كمون.

وقت الإستجابة

يعتمد التأخير من لحظة بدء المعاملة حتى الموافقة النهائية عليها من قبل النظام ليس فقط على سرعة الرسالة التي تمر عبر جميع مراحل التحقق والطلب ، ولكن أيضًا على معلمات تكوين الكتلة. حتى إذا سمحت لنا سلسلة الكتل لدينا بالالتزام بسرعة 1،000،000 tps ، لكن الأمر يستغرق 10 دقائق لتشكيل كتلة 488 MB ، فهل سيكون الأمر أسهل بالنسبة لنا؟

دعونا نلقي نظرة فاحصة على دورة حياة المعاملات في نسيج Hyperledger لفهم ما يقضيه الوقت وكيف يرتبط بمعلمات تشكيل الكتلة.

مأخوذ من هنا : hyperledger-fabric.readthedocs.io/en/release-1.4/arch-deep-dive.html#swimlane

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

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

تجنب انتظار الانتهاء من الحظر ولا تفقد القدرة على تتبع حالة المعاملة

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

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

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

تتمثل الخطوة التالية في جعل تفاعل العميل مع النظام غير متزامن بحيث لا ينتظر 15 أو 30 أو 10،000،000 ثانية ، والذي سنقوم بتعيينه على BatchTimeout. ولكن في نفس الوقت ، تحتاج إلى توفير الفرصة للتأكد من أن التغييرات التي بدأتها المعاملة مكتوبة / غير مكتوبة إلى blockchain.
يمكنك استخدام قاعدة بيانات لتخزين حالة المعاملة. الخيار الأسهل هو CouchDB بسبب سهولة الاستخدام: تحتوي قاعدة البيانات على واجهة مستخدم جاهزة ، وواجهة برمجة تطبيقات REST ، ويمكنك بسهولة تكوين النسخ المتماثل والمشاركة لها. يمكنك إنشاء مجموعة منفصلة فقط في نفس نسخة CouchDB التي يستخدمها Fabric لتخزين حالته العالمية. نحن بحاجة لتخزين وثائق من هذا النوع.

{
 Status string //  : "pending", "done", "failed"
 TxID: string // ID 
 Error: string // optional,   
}

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

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

لقد اخترنا BoltDB لتخزين حالات المعاملات ، لأننا بحاجة إلى حفظ الذاكرة ولا نريد قضاء الوقت في التفاعل مع الشبكة باستخدام خادم قاعدة بيانات مستقل ، خاصة عندما يحدث هذا التفاعل باستخدام بروتوكول النص العادي. بالمناسبة ، أنت تستخدم CouchDB لتنفيذ المخطط الموضح أعلاه أو لمجرد تخزين الحالة العالمية ، في أي حال ، من المنطقي تحسين طريقة تخزين البيانات في CouchDB. بشكل افتراضي ، في CouchDB ، حجم عقد b-tree هو 1279 بايت ، وهو أصغر بكثير من حجم القطاع على القرص ، مما يعني أن قراءة الشجرة وإعادة موازنتها ستتطلب وصولًا فعليًا أكبر إلى القرص. الحجم الأمثل يتوافق مع معيار التنسيق المتقدم وهو 4 كيلو بايت. للتحسين ، نحتاج إلى تعيين المعلمة btree_chunk_size على 4096في ملف تكوين CouchDB. بالنسبة لـ BoltDB ، هذا التدخل اليدوي غير مطلوب .

الضغط العكسي: استراتيجية عازلة

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

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

إسقاط : يمكننا الادعاء بأنه لا يمكننا معالجة أكثر من X من المعاملات في T ثوانٍ. تتم إعادة تعيين جميع الطلبات التي تتجاوز هذا الحد. إنها بسيطة جدًا ، ولكن بعد ذلك يمكنك نسيان تجربة المستخدم.

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

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

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

أدوات أخرى

لم يقل شيء هنا عن السلاسل ، لأنه ، كقاعدة عامة ، لا يوجد شيء لتحسينه. يجب أن يكون Chaincode بسيطًا وآمنًا قدر الإمكان - هذا كل ما هو مطلوب منه. تساعدنا كتابة Cheynkod ببساطة وأمان في تأطير SSKit بشكل كبير من S7 Techlab والمحلل الثابت Revive ^ CC .

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

استنتاج

هذا النهج يجعل من السهل استبدال Hyperledger Fabric بـ Quorum ، وشبكات Ethereum الخاصة الأخرى (PoA أو حتى PoW) ، وتقليل عرض النطاق الترددي الحقيقي بشكل كبير ، ولكن في نفس الوقت الحفاظ على UX العادي (لكل من المستخدمين في المتصفح والأنظمة المتكاملة). عند استبدال النسيج بـ Ethereum في المخطط ، ستحتاج فقط إلى تغيير منطق خدمة / ديكور إعادة المحاولة من معالجة تعارضات MVCC إلى الزيادة غير الذرية وإعادة الإرسال. سمح التخزين المؤقت للحالات وتخزينها بفصل وقت الاستجابة من وقت تكوين الكتلة. الآن يمكنك إضافة الآلاف من عقد الترتيب ولا تخشى أن يتم تشكيل الكتل في كثير من الأحيان وتحميل خدمة الطلب.

بشكل عام ، هذا كل ما أردت مشاركته. سأكون سعيدًا إذا كان هذا يساعد شخصًا في عمله.