פתרון בעיות בהסדרות

חלק זה מציע עצות פתרון בעיות עבור הגדרת 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, 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 בייטים לעומת 64, שזה יעלה מסר טעות.

שני ההנחות הללו לא נכונות. למרבה הצער, הודעות הטעות לא עוזרות לפתור סוג של כישלון מסוים זה.

איך לתקן: השתמש hex_literal. זה גם יהפוך שרשרת מכוערת של אותיות לשולחן קטן נחמד של מספרים hexadecimal ברור.

WARNING

אפילו ההפעלה try_from_str לא יכולה לאמת אם שרשרת נתונה היא תקפה PrivateKey ולהזהיר אותך אם זה לא כך.

הוא יתפוס כמה טעויות ברורות, למשל אם החוט מכיל סמל לא חוקי. עם זאת, מאחר שאנחנו שואפים לתמוך בקבוצות מפתחות רבות, זה לא יכול לעשות הרבה יותר. הוא לא יכול לדעת אם המפתח הוא גם המפתח הפרטי הנכון עבור החשבון נתון, אלא אם אתה מספק הוראה.

ניתן להימנע מהטעויות עדין מסוג זה, לדוגמה, על ידי דיזריאליזציה ישירה מ-string literals, או על ידי יצירת זוג מפתח חדש במקומות שבהם זה הגיוני.