პრობლემების აღმოფხვრა კონფიგურაციის საკითხებში

ეს განყოფილება გთავაზობთ 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 daemon რეჟიმში 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, peer 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 და გაფრთხილებთ თუ ეს არ არის.

იგი აღმოაჩენს გარკვეულ აშკარა შეცდომებს, მაგალითად, თუ სტრიკი შეიცავს არასწორ სიმბოლოს. თუმცა, ვინაიდან ჩვენ მიზნად ისახავთ მრავალი საკვანძო ფორმატის მხარდაჭერას, მას ბევრი სხვა რამ ვერ შეუძლია გააკეთოს. ის ვერ გაიგებს, არის თუ არა გასაღები სწორი კერძო გასაღები მოცემული ანგარიშისთვის, თუ თქვენ არ წარუდგენთ ინსტრუქციას.

ამგვარი ფირფიტური შეცდომები შეიძლება თავიდან იქნას აცილებული, მაგალითად, პირდაპირ დესერიალიზაციის გზით სტრიქონის ლიტერალებიდან ან ახალი საკვანძო წყვილის შექმნით იმ ადგილებში, სადაც ეს აზრი აქვს.