ترتیب کے مسائل کا حل

اس سیکشن میں 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 کے استعمال پر منحصر ہے۔ اگر یہ ایک بنیادی ڈیمو ہے اور آپ کو ہم مرتبہ ڈیٹا کو محفوظ رکھنے کی ضرورت نہیں ہے تو ، Kagami کے ساتھ مماثل لوکل نیٹ یا Docker Compose بنڈل کو دوبارہ بنائیں:

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) کے طور پر کوڈ کیا گیا ہے۔ اور public_key اور private_key دونوں مثالوں میں سٹرنگ کی لغت پر from_hex کال کریں۔

یہ فرض کرنا بھی فطری ہے کہ سٹرنگ لٹریل پر PrivateKey::try_from_str کال کرنے سے صرف صحیح کلید مل جائے گی۔ لہذا اگر آپ کو کلیدی میں بٹس کی تعداد غلط ہو جاتی ہے ، مثال کے طور پر 32 بائٹ بمقابلہ 64 ، تو یہ ایک غلطی کا پیغام پیدا کرے گا۔

یہ دونوں مفروضے غلط ہیں. بدقسمتی سے، غلطی کے پیغامات اس خاص قسم کی ناکامی کو ٹھیک کرنے میں مدد نہیں کرتے ہیں.

درست کرنے کا طریقہ: hex_literal استعمال کریں۔ اس سے حروف کی ایک بدصورت سٹرنگ کو ظاہر ہے کہ چھ اعشاریہ نمبروں کی ایک اچھی چھوٹی سی میز میں تبدیل کردیا جائے گا۔

WARNING

یہاں تک کہ try_from_str لاگو کرنے کی تصدیق نہیں کر سکتے ہیں اگر ایک دیئے گئے سٹرنگ ایک درست ہے PrivateKey اور آپ کو متنبہ اگر یہ نہیں ہے تو.

یہ کچھ واضح غلطیوں کو پکڑ لے گا، مثال کے طور پر اگر سٹرنگ میں ایک غلط علامت موجود ہے. تاہم، چونکہ ہم بہت سے کلیدی فارمیٹس کی حمایت کرنے کا ارادہ رکھتے ہیں، اس کے علاوہ زیادہ کچھ نہیں کر سکتے ہیں. یہ یہ نہیں بتا سکتا کہ آیا کلید دیئے گئے اکاؤنٹ کے لئے صحیح نجی کلید ہے یا نہیں، جب تک آپ ہدایات پیش نہیں کرتے ہیں.

اس طرح کی خفیہ غلطیوں سے بچا جاسکتا ہے، مثال کے طور پر، براہ راست سٹرنگ literal سے deserialising، یا جہاں یہ احساس ہوتا ہے وہاں ایک تازہ کلید جوڑی پیدا کر کے.