Предположим, я создаю новый контракт с:
web3.eth.contract(abi).new({ data: code }, (err, contract) => { ... })
Внутри обратного вызова я могу получить contract.addressновый контракт. Затем я могу успешно вызвать этот контракт.
Я просто пытаюсь понять, каким должен быть правильный способ хранения этого адреса? Я склоняюсь к тому, чтобы хранить его в БД, которую моя система будет загружать при запуске.
Или есть лучший способ? Думаю, я ожидал чего-то похожего на DNS, где я мог бы дать своему контракту уникальное имя и версию, и он сопоставлялся бы с адресом. Разве этого не существует? Разумно ли вводить адрес в БД на этапе миграции?
В идеале вы будете взаимодействовать с контрактом на протяжении всей подачи заявки. Вы можете сохранить его в database, locally or even hardcodeадресе.
Если вы храните в БД, вы можете легко справиться с будущими миграциями и обновить свой контракт, когда захотите.
Если развертывание контракта является динамическим, вы можете подключить развертывание к обещанию и сохранить адрес, когда оно вернется. И сделайте глобальную переменную всех развернутых контрактов.
Возможно, вы захотите изучить iurimatias/embark-framework
Параметры файла базы данных или файла конфигурации, предложенные другими ответами, звучат нормально: даже если бы существовал реестр в стиле DNS, DApps изначально пришлось бы жестко закодировать его адрес.
Ваш вопрос своевременен, и ENS, служба имен Ethereum, только что была развернута в тестовой сети (Ropsten).
См. вики ENS для быстрого старта и других подробностей. Вот введение:
ENS — это служба имен Ethereum, распределенная, расширяемая система имен, основанная на блокчейне Ethereum.
ENS можно использовать для разрешения широкого круга ресурсов. Первоначальный стандарт для ENS определяет разрешение для адресов Ethereum, но система является расширяемой по своему дизайну, что позволяет в будущем разрешать больше типов ресурсов без необходимости обновления основных компонентов ENS.
ENS развернут в тестовой сети Ropsten по адресу 0x112234455c3a32fd11230c42e7bccd4a84e02010.
Первоначальное обсуждение здесь .
Если вы находитесь в узле, вы можете сохранить его в базе данных, такой как postgres, или даже создать файл для резервного копирования пользователем.
Если вы находитесь в браузере, у вас есть множество вариантов, от файлов cookie до localStorage и indexedDB.
Вы даже можете позволить пользователям вводить свои собственные адреса контрактов, чтобы восстановить уже развернутый контракт с известным байт-кодом и ABI.