Например, веб-сайт, который даст возможность зарегистрировать учетную запись ethereum. Пользователь нажмет кнопку регистрации, и сервер, который, я полагаю, работает круглосуточно и без выходных, создаст учетную запись через web3.eth.personal.newAccount. Затем сервер отправляет открытый и закрытый ключ для этой учетной записи пользователю.
Теперь на веб-сайте также есть возможность разрешить пользователям развертывать смарт-контракт. Я предполагаю, что для этого они отправят свой открытый ключ/закрытый ключ, и сервер будет использовать его для развертывания контракта из учетной записи пользователя после его разблокировки.
Но у этой учетной записи будет 0 эфиров, поскольку пользователь не использует ее для майнинга, потому что у них даже нет узла ethereum. Другое решение может заключаться в том, что у сервера есть одна учетная запись, которая содержит эфир, так как сервер занимается майнингом. Затем сервер развертывает все контракты из этой учетной записи от имени других пользователей, но каким-то образом объявляет их владельцами контракта.
Может ли кто-нибудь пояснить, какой подход используется для реализации такого веб-сайта?
Скорее всего, рабочий процесс, который вы упомянули, не оптимален для целей безопасности.
Важно:
Ни один пользователь не должен доверять службе, которая генерирует ключи на своем централизованном сервере.
К счастью, вы можете включить библиотеку web3 в веб-браузер, чтобы ваши пользователи могли генерировать и хранить там ключи. Еще раз ПРИМЕЧАНИЕ. Существует несколько передовых методов и процедур для безопасного выполнения этой операции.
Как вы упомянули, у этого Ethereum accountне будет средств для публикации транзакций (или смарт-контрактов в сети Ethereum). Перевод средств на эту новую учетную запись является отдельным потоком и потребует от пользователя получения ETH откуда-то (ваша служба может предоставить небольшое количество ETH для учетной записи при ее создании).
Ваш второй сценарий предложения «бесплатной услуги публикации смарт-контрактов» возможен, но создает новые проблемы: предотвращение использования пользователями вашего сервиса и обеспечение того, чтобы все развернутые контракты были созданы вашими пользователями, а не только ключ, который ownableвы публикуете в блокчейне. с.
Возможный поток:
В идеале в целях безопасности вы должны создать или поддерживать пользовательский кошелек либо clientв виде приложения, либо в браузере, что позволит пользователям управлять ключами.
Во-вторых, пользователи должны получить свои собственные ETH (иначе люди попытаются воспользоваться вашим бесплатным сервисом ETH).
В-третьих, после того, как ваши пользователи получат ключи и ETH, ваше клиентское программное обеспечение сможет генерировать и подписывать код смарт-контракта для пользователей.
Наконец, после того, как контракты подписаны (ключами пользователей, с доступными средствами), ваш сервис может опубликовать их в сети Ethereum (например).