إصلاح مشاكل الإعدادات

يقدم هذا القسم نصائح لحل المشاكل لتكوين Iroha 3. تأكد من أنك قمت بتحقق من المفاتيح أولاً ، لأنها هي المصدر الأكثر شيوعا للمشكلات في Iroha.

إذا لم يتم وصف المشكلة التي تواجهها هنا، اتصل بنا عن طريق التليغرام .

الجينيزة القديمة على تشكيل Docker Compose

عندما تستخدم إصدار Docker Compose من Iroha ، قد تواجه مشكلة فشل أحد حاويات الزملاء مع خطأ Failed to deserialize raw genesis block. هذا يعني عادةً أن عملية الزملاء والموقع والتشكيل الذي تم إنشاؤه تم إنتاجه بواسطة مراجعات أو ملفات تعريف مختلفة Iroha.

تحقق من الفشل باستخدام هذه الخطوات:

1. استخدم docker ps للتحقق من الحاويات الحالية. اعتمادا على الملف الذي تم إنشاؤه، سترى عادةً حاويات hyperledger/iroha:dev. يحتوي الملف الافتراضي Docker Compose على أربعة حاويات نظيرة، على الرغم من أن docker-compose.yml قد تختلف.

2. تحقق من السجلات و ابحث عن الخطأ Failed to deserialize raw genesis block. إذا قمت بتشغيل Iroha الخاص بك في وضع ديمون مع docker compose up -d ، استخدم أمر docker compose logs .

طريقة حل هذه المسألة تعتمد على استخدام Iroha. إذا كان هذا هو التجربة الأساسية ولا تحتاج إلى الحفاظ على البيانات من الزملاء، وإعادة تشكيل شبكة محلية متطابقة أو Docker Compose حزمة مع Kagami:

cargo run --bin kagami -- localnet --build-line iroha3 --peers 4 --out-dir ./localnet
cargo run --bin kagami -- docker --peers 4 --config-dir ./localnet --image hyperledger/iroha:dev --out-file ./docker-compose.yml

ثم إزالة حالة الحاوية القديمة وإعادة تشغيلها من الملفات التي تم تجديدها genesis.signed.nrt ، والملفات ذات الصلة config.toml، و client.toml.

إذا كنت بحاجة إلى استعادة بيانات مثال Iroha، قم بما يلي:

1. ربط الزميل الثاني Iroha الذي سيتم نسخ البيانات من الزميل الأول (فاشل).
2. انتظر حتى يزامن الزميل الجديد البيانات مع الزميل الأول.
3. اترك الزملاء الجدد نشطين
4. قم بتحديث ملفات التكوين والتكييف للقرّ الأول فقط كجزء من الهجرة المنسقة.

INFO

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

تنسيق المفاتيح الخاصة والعامة متعددة الأهداف

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

إذا لم تكن قد عملت مع المتعدد من قبل، فمن الطبيعي أن نفترض أن الجانب الأيمن ليس هوكسادسيمال تمثيل البايتات الرئيسية (رمزين لكل بايت) ، ولكن بدلاً من ذلك البايتات المشفورة على أنها ASCII (أو UTF-8) والاتصال from_hex على الخط حرفي في كلتا public_key و private_key -إثبات .

ومن الطبيعي أيضًا أن نفترض أن الاتصال PrivateKey::try_from_str على حرفية السلسلة سيؤدي إلى المفتاح الصحيح فقط. لذلك إذا حصلت على عدد البيتات في المفتاح بشكل خاطئ ، مثل 32 بايت مقابل 64 ، فسوف يثير رسالة خطأ.

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

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

WARNING

حتى تنفيذ try_from_str لا يمكن التحقق من إذا كانت سلسلة معينة صحيحة PrivateKey وتحذيرك إذا لم يكن.

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

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