Проблемы с конфигурацией

В данном разделе приведены советы по устранению неполадок 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, peer config.toml и client.toml.

Если вам нужно восстановить данные экземпляра Iroha, выполните следующее:

1. Присоедините второй Iroha, который будет копировать данные из первого (неудавшегося) партнера.
2. Подождите, пока новый партнёр синхронизирует данные с первым партнёром.
3. Оставьте новую группу активной.
4. Обновляйте файлы генезиса и конфигурации первой группы только в рамках скоординированной миграции.

INFO

Не существует общего автоматического пути переписки для замены генезиса в живой сети. рассматривайте это как скоординированную миграцию: сохранение старого состояния, создание совместимых сверстников и перенос валидаторов в новую конфигурацию только после согласования операторами плана миграции.

Мульти-хаш формат частных и публичных ключей

Если вы посмотрите на конфигурацию клиента, вы заметите, что ключи там указаны в формате multi-hash.

Если вы никогда раньше не работали с множественными хэшами, естественно предположить, что правая сторона - это не шестидесятное представление ключевых байтов (два символа на байт), а скорее байты, закодированные как ASCII (или UTF-8), и вызвать from_hex на буквальном строке как в экземпляре public_key, так и в экземплярном слоге private_key.

Также естественно предполагать, что вызов PrivateKey::try_from_str на буквальном строке дает только правильный ключ. Так что, если вы ошибаетесь в количестве битов ключа, например 32 байта против 64, то это вызовет сообщение об ошибке.

Оба этих предположения ошибочны. К сожалению, сообщения об ошибке не помогают в отстранении данного типа неудач.

Как исправить: используйте hex_literal. Это также превратит уродливую строку символов в хорошую небольшую таблицу с очевидными шестидесятными числами.

WARNING

Даже реализация try_from_str не может проверить, является ли данная строка действительной PrivateKey и предупреждает вас, если она нет.

Он обнаружит некоторые очевидные ошибки, например, если строка содержит недействительный символ. Однако, поскольку мы стремимся поддерживать многие форматы ключей, он не может сделать многого другого.

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