Каковы наилучшие методы, позволяющие пользователям регистрироваться и входить в систему для децентрализованного приложения?

Из того, что я исследовал, кажется, что все методы, позволяющие пользователю зарегистрироваться и войти в приложение Ethereum, очень громоздки для пользователя. Каковы наилучшие методы разрешения регистрации и входа в систему, которые соответствуют следующим критериям:

  1. Способ регистрации и входа в систему не должен быть громоздким; то есть: простые, как обычные методы имени пользователя/пароля или facebook и google oauth.

  2. Метод регистрации не должен взимать с пользователя никаких эфириумов (газа) — получение чьих-то денег только за регистрацию оттолкнет большинство людей.

  3. Метод регистрации и входа в систему не должен заставлять пользователя прыгать через обручи, такие как:
    а) ввод электронной почты
    б) загрузка мобильного приложения
    в) ввод адреса кошелька
    г) ожидание подтверждения аутентификации
    д) повторный ввод кода на экране регистрации, и т.п.

  4. Дополнительное программное обеспечение, такое как MetaMask или Mist, не требуется. (Может быть, это невозможно?)

Цель состоит в том, чтобы устранить как можно больше препятствий для привлечения пользователей к децентрализованному приложению.

Ответы (4)

Насколько я знаю, всегда легко и удобно использовать механизм ключей PGP для аутентификации пользователей в DAPP, созданных с использованием Ethereum. Можно использовать адрес учетной записи в качестве имени пользователя и позволить пользователю подписать некоторые данные своим закрытым ключом для проверки. Эта статья может помочь вам в этом процессе.

Чтобы облегчить пользователям задачу, вы можете разрешить пользователям хранить свой закрытый ключ на стороне клиента (например, встроить его в приложение, которое они используют после регистрации и т. д. — не забудьте уведомить пользователя о сохранении закрытого ключа, если в любом случае приложение удален)

ОБНОВЛЕНИЕ . Как обсуждалось в комментариях ниже, если вы хотите использовать традиционную систему учетных записей пользователей, используйте традиционную таблицу пользователей с именами пользователей, связанными с адресом учетной записи, и для подключения к сети ethereum используйте web3.js (см. этот вопрос ) - Однако это снова происходит для доверенного стороннего механизма.

Может быть, Ethereum слишком незрел для того, что мне нужно. Необходимость просить обычного обычного человека, не являющегося разработчиком, установить расширения Chrome просто не сработает. Для меня это самая большая проблема, стоящая перед Ethereum и другими технологиями блокчейна — преобразование человека, который привык к обычному Интернету, в децентрализованный интернет с блокчейном, где его профиль больше не является именем пользователя/паролем, а токеном хеш-строки. адрес.
Да, Ethereum действительно крут для нас, разработчиков. В противном случае вся эта технология кажется слишком непрактичной для обычного среднего пользователя Facebook.
почему бы не использовать обычное сопоставление имени пользователя типа учетной записи с адресами учетной записи и паролем для проверки закрытого ключа, например. Возможно, вам придется выполнить сопоставление на стороне сервера. Но проблема в том, что это может выглядеть как наличие доверенной третьей стороны, для которой не предназначена концепция блокчейна.
Хорошо. Допустим, я использую узел на стороне сервера, например, как бы вы 1) связывались с сетью ethereum 2) связывали профиль пользователя с адресом кошелька ethereum? Вы бы просто попросили об этом после того, как они войдут в систему?
для # 2 ведите таблицу пользователей и сохраняйте адрес кошелька вместе с их именем пользователя в вашем бэкэнде.
хорошо, я думаю, что это может сработать. Можете ли вы обновить свой ответ тем, что мы обнаружили?
Теперь мой вопрос: «Какой механизм вы используете для проверки адреса кошелька, который пользователь дает вам в пользовательском интерфейсе?» Вы, очевидно, не можете доверять этому.
даже если он указывает неправильный адрес кошелька, он должен предоставить парольную фразу (связанную с его ключами), чтобы разблокировать учетную запись, если разблокировка учетной записи возвращается с ошибкой. Это можно использовать для проверки
Вы можете полагаться на существующие механизмы аутентификации и генерировать ключи в облаке для пользователя. Затем подпишите офлайн-транзакции. Я создал небольшую библиотеку, которая может подписывать транзакции с помощью Azure Key Vault. Пользователи могут проходить аутентификацию с помощью любого поддерживаемого OAuth, а их ключи управляются в облаке. Просто идея. npmjs.com/package/ethereumjs-tx-keyvault
@TomislavMarkovski отличный материал. будет очень полезно :)

Что касается № 4, это определенно возможно, но вам придется сделать выбор между полностью централизованным и децентрализованным подходом.

MetaMask децентрализован (конечные пользователи владеют закрытыми ключами), но расширение Chrome потребует от пользователей преодоления большего количества препятствий, чтобы начать работу.

Есть немного более централизованные решения, такие как Fortmatic , которые позволяют конечным пользователям напрямую взаимодействовать с dapps в любом браузере, не требуя загрузки расширения Chrome.

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

Вы можете использовать адрес Ethereum в качестве уникального идентификатора для учетной записи пользователя. Затем вы можете потребовать от держателя закрытого ключа, который сопоставляется с этим адресом, подписать сообщение, которое вы затем можете проверить.

Можно проверить, было ли сообщение подписано определенным закрытым ключом , не зная секретного ключа .

Я написал сообщение в блоге о подписании сообщения некоторое время назад.

Проблема с этим подходом заключается в простоте и приемлемости для сообщества. Ранее я создал протокол входа в систему, который работал, как описано выше. Проблема в том, что для этого требуется либо подписать сообщение, независимое от вашего dapp (сложное, барьер для входа), либо пользователь, предоставляющий свой закрытый ключ в той или иной форме (необработанный, ключевой файл, мнемоника и т. д.) для вашей службы, чтобы вы могли предоставить сообщение подписание.

Когда я сделал это, «сообщество» разозлилось, потому что это было угрозой безопасности (будь я мошенником).

TL;ДР; Это можно сделать, но все будут стонать о безопасности/децентрализации.

Я знаю, что это слишком старая ветка, но, поскольку я столкнулся с той же проблемой, я хотел бы ответить на нее.

Концепция цифровой подписи, которую использует блокчейн, является очень известной технологией, но, к сожалению, она не используется обычными людьми (например, пользователями Facebook). Представьте себе мобильное приложение для проверки подлинности, которое имеет следующие функции:

Составные части:

  • Приложение для проверки подлинности
  • Децентрализованный сервер
  • Аутсервер

Регистрация:

  • Пользователь переходит на страницу регистрации Dapp и сканирует QR-код со строкой вызова (сгенерированной на AuthServer).
  • Криптографическая пара ключей генерируется с использованием того же протокола, что и блокчейн.
  • Пользователь подписывает вызов, используя закрытый ключ, и отправляет на DappServer следующие данные: открытый ключ, данные пользователя, цифровую подпись (DS).
  • DappServer хранит информацию о пользователях и перенаправляет DS и открытый ключ на AuthServer.
  • Пользователь зарегистрирован

Авторизоваться:

  • Пользователь сканирует QR-код со страницы входа -> подписывает сообщение (вызов) и отправляет открытый ключ DS на DappServer.
  • DappServer проверяет, существует ли пользователь, а затем перенаправляет запрос проверки digitalSig на AuthServer.
  • AuthServer проверяет DS и отправляет ответ DappSErver на основе этого решения — пользователь вошел в систему.

Подписание сделки:

  • Транзакция формируется в Dapp и отображается как QR
  • Пользователь генерирует новую пару ключей (эта пара ключей может быть сгенерирована с использованием того же алгоритма, который использовался для генерации loginKeyPair)
  • Пользователь сканирует QR-код и подписывает транзакцию
  • Пользователь отправляет подписанный tx на DappServer, который затем отправляет в сеть.

Примечание:

  • Здесь, как вы можете видеть, все доверие находится на AuthServer, но можно представить AuthServer как смарт-контракт только с одним методом, bool verifyDigitalSig(digitalSig, publikey)который является методом получения.
  • Мы решили, что пользователю не нужно ничего платить только за вход в систему.
  • Это login-firstподход в отличие от wallet-first.

Посмотрите, поможет ли это.

Каковы наилучшие методы, позволяющие пользователям регистрироваться и входить в систему для децентрализованного приложения?
СпросиСетьПолитика конфиденциальности1y, 0v