Мы планируем сделать некоторые функции смарт-контрактов доступными для внешних пользователей, но только если они будут проходить через наш веб-сайт. (В конце концов, они будут доступны через обычные вызовы контрактов непосредственно в блокчейне). Таким образом, рабочий процесс выглядит следующим образом -> Пользователь регистрируется на нашем веб-сайте — предоставляет некоторую информацию, которую мы можем проверить по внешним источникам — после проверки мы вызываем соответствующую функциональность смарт-контракта из бэкэнда.
Хотя я могу использовать web3.js для вызова с моего веб-сайта на блокчейн, как именно мой аккаунт/кошелек будет защищен самим веб-сайтом? Например, если наш веб-сайт размещен на aws, должны ли мы хранить секретный ключ в нашей базе данных и использовать его для подписи наших вызовов в цепочке блоков? Или единственный вариант использовать туман/метамаску с локально защищенного компьютера для вызова ограниченных внешних функций по контракту?
Если кто-то сделал что-то подобное, было бы здорово, если бы вы могли поделиться списком инструментов, которые вы использовали для защиты, и списком инструментов, которые вы использовали для доступа к цепочке блоков.
Любые мысли о том, как организации, состоящие из нескольких человек, могут эффективно и безопасно обрабатывать доступ к смарт-контрактам, также приветствуются.
Это зависит от модели доверия, с которой вы работаете.
Обычно в основе приложений Ethereum лежит мысль о том, что пользователю не нужно доверять людям, разработавшим контракт, и они полностью контролируют свои собственные данные. В этой модели обычно нет доверенного кода на стороне сервера и нет привилегированной стороны, имеющей традиционные учетные данные имени пользователя и пароля. Вот почему у нас есть такие вещи, как MetaMask, которые дают пользователю контроль над своими учетными данными и просят их одобрить запросы, которые, по мнению приложения, должны быть сделаны с ними. Обычно это приложения только на стороне клиента, где пользователь использует ваш статический код html/js, а код на стороне сервера отсутствует.
Если ваши пользователи должны доверять вам хранение их имени пользователя и пароля, вы можете сохранить один ключ на своем сервере и использовать его для всех своих пользователей. Вместо использования MetaMask ваши пользователи могут взаимодействовать с вашим серверным приложением, и это приложение отправляет запросы в блокчейн, отправляя запросы с вашего сервера на интерфейс JSON-RPC вашего узла. Контракты будут разработаны так, чтобы полагаться на (доверенного) вызывающего абонента для предоставления идентификатора пользователя, вошедшего на ваш сервер, в качестве параметра. Хотя технически это легко настроить, часто это означает, что вы можете захотеть использовать обычную базу данных вместо блокчейна, поскольку ваши пользователи уже должны вам доверять, и вы или тот, кто взламывает ваш сервер, будете отвечать за их безопасность. активы и данные. Обычная база данных проще, дешевле и эффективнее.
Если модель такова, что пользователи могут взаимодействовать с блокчейном напрямую, но вы также позволяете им использовать ваш веб-сайт для удобства, то вы можете разработать контракты, ожидающие, что у каждого пользователя будет свой собственный ключ, и сохранить ключ пользователя на сервере. Очевидный способ сделать это — сохранить множество разных учетных записей на вашем узле Ethereum.
Исмаэль
Сенджу