Байгууллагын асуудлыг шийдвэрлэх

Энэ хэсэг нь Iroha 3 тохируулалтын. Та түлхэгийг шалгасан Нэгдүгээрт, энэ нь хамгийн түгээмэл тулгамдсан асуудал Iroha.

Хэрэв танд тохиолдож буй асуудал энд тодорхойлдоггүй бол Telegram -ээр бидэнтэй холбоо бариарай.

Docker Compose тоног төхөөрөмж дээр цаг хугацааны сүүлдсэн генез

Iroha-ийн Docker Compose хувилбарыг ашиглахдаа 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 хүчин төгөлдөр эсэхийг баталгаажуулж чадахгүй бөгөөд үгүй бол сэрэмжлүүлж болно.

Энэ нь зарим ил тод алдааг олж авах болно, жишээ нь, акор нь хүчингүй тэмдэгтэй бол. Гэсэн хэдий ч, бид олон үндсэн хэлбэрүүдийг дэмжих зорилготой тул энэ нь бусад зүйлсийг хийх боломжгүй. Хэрэв та тушаалыг хүргэхгүй бол энэ нь тухайн дансны хувийн түлхүүр нь зөв эсэхийг хэлж чадахгүй.

Энэ төрлийн хялбар алдааг салах боломжтой юм. Жишээлбэл, жижиг бичлэгээс шууд дэзерализ хийх эсвэл утга учиртай газруудад шинэхэн түлхүүр хувилбарыг үүсгэхэд.