Почему туман блокирует импорт учетных записей, когда нода geth уже запущена?

Я столкнулся с этой проблемой . Причина описана в той ветке, но не объяснена.

Если я запускаю mistи позволяю ему запускать свой собственный узел, то Accounts>Importпункт меню доступен.

Если я запускаю gethсебя, а затем запускаю mist --rpc /home/me/.ethereum/geth.ipc, пункт меню становится серым.

введите описание изображения здесь

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

Ответы (1)

Причины безопасности. Когда вы удаляете файл, а не privKey, будет происходить передача файла через rpc. Несмотря на то, что это очень низкий риск, риск все же есть. Кроме того, функция импорта geth (например, импорт учетной записи geth ./key.prv) работает с закрытыми ключами, но не с json. туман хочет, чтобы вы перетаскивали файлы json.

Изменить: более точно:

«Чистый» geth не имеет функции импорта файлов кошелька json. Он может импортировать только закрытые ключи (см. https://github.com/ethereum/go-ethereum/wiki/Managing-your-accounts#import-private-key ).

Функция Mist «Импорт учетных записей» принимает файлы кошелька в формате json. Но они не могут быть переданы через удаленные вызовы процедур (RPC) в geth, потому что у geth нет процедур для их обработки (он может импортировать только закрытые ключи, а не файлы кошелька json).

Вы выполняете rpc (mist --rpc), поэтому он не может работать и отображается серым цветом.

Если вы запускаете Mist без RPC-подключения к другому экземпляру geth — таким образом, просто запускаете Mist без какой-либо командной строки — тогда Mist и узел работают в одном контексте. Это означает, что графический интерфейс Mist может передать файл json в ключевую папку узла (например, ~/.ethereum/keystore). Но RPC не позволяет этого (например, из соображений безопасности), потому что с RPC Mist и geth не работают в одном контексте.

И, очевидно, нет пункта меню Mist для «импорта закрытых ключей». Многие (ориентированные на конечного пользователя) браузеры Ethereum не имеют функции «импорт закрытого ключа», потому что это может нести угрозу безопасности.

Я не понимаю, почему туману нужно отправлять кошелек или ключи через RPC. Если у тумана есть все секреты, то почему он не может сам создать и подписать передачу и отправить ее через RPC на гет, не отправляя гету никаких секретов?
Насколько мне известно, Mist разработан не так, как MyEtherWallet. Если вы запустите Mist и Geth на одном компьютере, они будут совместно использовать папку хранилища ключей. Например: у меня Geth работает на моем VPS уже пару недель. Сегодня я установил Mist и запустил его с помощью RPC для работающего экземпляра Geth. Я видел тот же кошелек/адреса, которые я однажды настроил в Geth (без Mist) пару недель назад.
Я не понимаю, какое отношение общий доступ к папке хранилища ключей имеет к отправке секретов через RPC.
Если вы запускаете Geth отдельно и подключаете Mist через RPC к работающему сеансу Geth, то сеанс Geth (на время выполнения) является «владельцем» папки хранилища ключей. Таким образом, все процедуры, связанные с этим, обрабатываются экземпляром Geth, например: есть команда geth «geth account new»… и Mist предлагает пункт меню «Новая учетная запись»… все в порядке. Но: НЕТ команды Geth "get import json wallet" или около того. Таким образом, эта функция Mist недоступна. (...продолжение следует в следующем комментарии из-за ограничения по количеству символов...)
Почему у Geth нет функции импорта json через RPC? Ну в теории все возможно. Можно, конечно, развивать. Самый простой способ — получить json-файл через RPC и поместить его в папку хранилища ключей. Именно так я импортирую учетные записи Ethereum в работающий экземпляр Geth: просто вручную копирую файлы в папку хранилища ключей. Но: это плохой дизайн: иметь функцию RPC, которая напрямую записывает файлы (из RPC) на жесткий диск. Это несет в себе угрозу безопасности. Таким образом, сейчас Geth спроектирован так, что нет возможности напрямую импортировать json через RPC.