Ստեղծման խնդիրների լուծում

Այս բաժինը առաջարկում է խնդիրների լուծման խորհուրդներ Iroha 3 կոնֆիգուրացիայի համար: Համոզվեք, որ դուք նախ ստուգել եք բանալիները, քանի որ դա ամենատարածված խնդրի աղբյուրն է Iroha:

Եթե ձեր խնդիրն այստեղ չի նկարագրվել, կապվեք մեզ հետ Telegram միջոցով:

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 բայթներ vs 64, դա կհանգեցնի սխալ հաղորդագրության:

Այս երկու ենթադրությունները սխալ են: Ցավոք, սխալների հաղորդագրությունները չեն օգնում լուծել այս հատուկ տեսակի ձախողումները:

Ինչպես շտկել. օգտագործեք hex_literal։ Դա նաեւ կվերածի աքաղաղ տառերի շարքը գեղեցիկ փոքր աղյուսակում, որը ակնհայտորեն վեց դեկամալ թվերով է:

WARNING

Նույնիսկ try_from_str իրականացումը չի կարող ստուգել, թե արդյոք տրված շղթան է վավերական PrivateKey եւ նախազգուշացնել ձեզ, եթե այն չէ.

Այն կբացահայտի որոշ ակնհայտ սխալներ, օրինակ, եթե շղթան պարունակում է անվավեր խորհրդանիշ: Այնուամենայնիվ, քանի որ մենք նպատակ ունենք աջակցել բազմաթիվ բանալիր ձեւաչափերին, այն շատ բան չի կարող անել: Այն չի կարող ասել, թե արդյոք բանալին ճիշտ մասնավոր բանալիր է տվյալ հաշիվի համար, քանի դեռ դուք չեք ներկայացրել հրահանգ:

Այս տեսակի մանր սխալները կարելի է խուսափել, օրինակ, ուղղակիորեն դեզերիալացնելով շղթայական բառերից կամ նոր բանալիների զույգը ստեղծելով այն վայրերում, որտեղ դա իմաստ ունի: