Допустим, я хочу создать приложение, которое не является полностью децентрализованным, на самом деле оно обслуживает API-интерфейсы Restful для внешнего интерфейса и использует частную цепочку блоков Эфириума в серверной части для обработки конфиденциальных данных и управления разрешениями пользователей. Я создаю для каждого пользователя при регистрации в моем бэкенде учетную запись ethereum, используя его пароль. Бэкэнд работает под управлением NodeJS Express и подключен к экземпляру web3. Всякий раз, когда пользователь хочет совершить действие, он должен ввести свой пароль, затем я использую этот пароль, чтобы разблокировать его учетную запись и отправить транзакцию (или это может быть звонок по контракту).
Имеет ли смысл выступать в качестве промежуточного программного обеспечения между пользователем и приватным блокчейном? Я имею в виду, что с точки зрения дизайна Эфириума это обычная практика? Как пользователь должен знать об этой практике, если он не видит ничего, связанного с блокчейном, потому что вся работа выполняется за кулисами? Как пользователь может быть уверен в моей системе, что его пароль не будет раскрыт?
Рекомендуется ли в таком случае использовать несколько узлов для этого частного блокчейна? Какую пользу он приносит с собой? Только ли высокая доступность и устранение центральной точки отказа?
Прежде чем я попытаюсь ответить на ваши вопросы: есть определенные преимущества использования блокчейна и эфириума в частности. Эти преимущества:
эти преимущества необходимы вам для реализации платформы на основе эфириума. Помимо этого, эфириум быстро станет помехой и слабым местом в вашей системе.
Ваши вопросы :
1) Во многих текущих и большинстве будущих крупных проектов узлы Ethereum в любом случае не будут видны пользователю. То, что укрепит доверие между платформой (системой) и пользователем, будет обещанием прозрачности и надежности. Хорошей практикой является явное сообщение пользователям, что вы управляете их учетными записями от их имени, и даете им возможность отказаться от этого и самостоятельно управлять своими учетными записями Ethereum и транзакциями, при этом пользуясь услугами вашей платформы.
2) Несколько узлов в случае частной сети не нужны. Вам может понадобиться использовать много узлов, если логика вашей системы требует фактического разделения решений между этими узлами. Что-то вроде узла для каждой страны или узла для каждой партии. Наличие большого количества узлов также может снизить нагрузку на ваше оборудование и повысить производительность и отказоустойчивость вашей системы.
Я реализовал частную цепочку блоков с бэкэнд-системой в nodejs, которая справляется с некоторыми препятствиями, но оставила цепочку блоков, выполняющую работу лучше всего: предоставление доверия. Итак, в основном я реализовал решение, которое работает противоположно тому, что вы описали здесь.
В моей архитектуре закрытый ключ пользователя находится на клиенте, а данные пользователя регистрируются на сервере mongodb вместе с учетной записью пользователя в эфириуме. Всякий раз, когда запрашивается транзакция, клиент создает ее в блокчейне с использованием закрытого ключа пользователя (в мобильном приложении хранится в области хранения, в веб-приложении им управляет MetaMask) и, в случае успеха, регистрирует транзакцию в базу данных со ссылкой на хэш транзакции.
Таким образом, правда хранится в блокчейне, никто не может украсть пароли, а в базе данных у вас есть данные, которые слишком дорого хранить в блокчейне.
ОВАДВЛ
ДоттореМ