Разработка полного стека приложений Ethereum

Я начинающий разработчик Solidity и пытаюсь разработать приложение для голосования на Эфириуме.

Требования к заявке -

1) Должна быть регистрационная форма кандидата и избирателя.

2) Избиратель должен иметь возможность войти в систему, используя какой-либо механизм аутентификации, такой как имя пользователя, пароль.

3) Каждый избиратель должен иметь возможность проголосовать только один раз.

4) Результат голосования должен быть виден всем

Вещи, которые я пробовал -

Я разработал смарт-контракт для голосования в кандидатах и ​​избирателях structтипа, в котором хранятся соответствующие атрибуты кандидата и избирателя.

Данные кандидатов и избирателей хранятся в массиве структур. Функции прописаны в смарт-контракте для голосования, чтобы получить количество голосов. избирателей и кандидатов, вставить избирателя и кандидата и т. д.

Проблемы, с которыми я сталкиваюсь -

1) Как мне аутентифицировать избирателя и кандидата?

2) Должен ли я создать новую учетную запись с помощью personal.newAccount()команды для каждого кандидата и избирателя?

3) Может ли один аккаунт иметь несколько адресов? чтобы я мог создать несколько адресов для разных избирателей и кандидатов?

4) В соответствии с ответом на этот вопрос message.sender() должен использоваться для аутентификации пользователя. Я не могу понять, как у каждого пользователя будут разные адреса? Это адрес учетной записи, которую мы можем создать с помощью personal.newAccount()команды?

5) Поскольку эфириум — это цепочка блоков без разрешений, как реализовать/имитировать аутентификацию и авторизацию, с помощью которых можно контролировать, кто может участвовать в частной сети цепочек блоков?

Ответы (1)

Недавно я создал небольшой проект, не связанный с голосованием, который может ответить на некоторые ваши вопросы. Проверьте папку «html» в zip-файле.

https://github.com/matheswarwan/capestoneEthILP/blob/master/Capestone_17%20April.zip

В вашем случае каждый проект — это отдельная учетная запись, верно? Поправьте меня, если я ошибаюсь. Но я не могу понять, как выполняется аутентификация для утверждающего озера и утверждающего леса? Вторая вещь, которую я заметил и которая является потенциальной проблемой, заключается в том, что вы используете адреса учетной записи и их соответствующие закрытые ключи для аутентификации, которые очень трудно запомнить по сравнению с username+password . Есть ли у нас другое решение?
Имя пользователя и пароль DApp — это что-то автономное от сети eth (т. е. специфичное для dapp) и не связанное с сетью ethereum. Это что-то вроде, скажем, у вас есть учетная запись в zebpay, у вас будет имя пользователя + пароль (+ мобильный телефон + аутентификатор) для входа в zebpay. Как только вы войдете в систему, как часть данных вашего профиля, zebpay надежно сохранит список номеров учетных записей ethereum (0x123.. + пароль + информация о закрытом ключе и т. д.), который вы можете продолжить и использовать или добавить еще несколько учетных записей, если вы хотеть.
Чтобы ответить на конкретные вопросы - в моем случае использования структура Land не будет иметь отдельных учетных записей. Он идентифицируется идентификатором типа bytes32. Аутентификация для озера/леса не установлена, т. е. любой, у кого есть действующий адрес + газ, может их одобрить (это исправим). Я использую адрес + пароль (который отделен от закрытого ключа — используйте web3.personal.newAccount («пароль»), чтобы установить pwd) — который пользователь может запомнить.
Как часть списка утверждающих, я создал функцию в контракте, как здесь , а затем проверяю, как это `функция isValidLakeApprover (адрес _lakeApprover) возвращает (bool) { return lakeApprover [_lakeApprover]; }`
Разработка полного стека приложений Ethereum
СпросиСетьПолитика конфиденциальности1y, 0v