Ethereum-Full-Stack-Anwendungsentwicklung

Ich bin Anfänger im Solidity-Entwickler und versuche, eine Abstimmungsanwendung für Ethereum zu entwickeln

Bewerbungsvoraussetzungen sind -

1) Es sollte ein Registrierungsformular für Kandidaten und Wähler geben

2) Der Wähler sollte sich mit einem Authentifizierungsmechanismus wie Benutzername und Passwort anmelden können

3) Jeder Wähler soll nur einmal wählen können

4) Das Abstimmungsergebnis sollte für alle sichtbar sein

Dinge, die ich ausprobiert habe -

Ich habe einen intelligenten Vertrag für die Abstimmung in Kandidaten- und Wählertyp entwickelt, structin dem die jeweiligen Attribute von Kandidat und Wähler gespeichert sind.

Daten von Kandidaten und Wählern werden in einer Reihe von Strukturen gespeichert. Funktionen sind in Smart Contracts geschrieben, um abzustimmen, um die Anzahl der Nr. zu erhalten. von Wählern und Kandidaten, zum Einfügen eines Wählers und Kandidaten usw.

Probleme, mit denen ich konfrontiert bin -

1) Wie soll ich Wähler und Kandidat authentifizieren?

2) Soll ich mit personal.newAccount()dem Befehl für jeden Kandidaten und Wähler ein neues Konto erstellen?

3) Kann ein Konto mehrere Adressen haben? damit ich mehrere Adressen für verschiedene Wähler und Kandidaten erstellen kann?

4) Gemäß der Beantwortung dieser Frage message.sender() wird zur Authentifizierung des Benutzers verwendet. Ich kann nicht verstehen, dass jeder Benutzer unterschiedliche Adressen haben wird? Ist es die Adresse des Kontos, das wir mit dem Befehl erstellen können personal.newAccount()?

5) Da Ethereum eine genehmigungslose Blockchain ist, wie kann man Authentifizierung und Autorisierung implementieren/simulieren, mit deren Hilfe man kontrollieren kann, wer an einem privaten Blockchain-Netzwerk teilnehmen kann?

Antworten (1)

Ich habe vor Kurzem ein kleines Projekt erstellt, das nichts mit Abstimmungen zu tun hat und vielleicht einige Ihrer Fragen beantwortet. Überprüfen Sie den Ordner „html“ in der Zip-Datei.

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

In Ihrem Anwendungsfall ist jedes Projekt ein separates Konto, oder? Korrigiere mich, wenn ich falsch liege. Aber ich kann nicht erfahren, wie die Authentifizierung für den Lake-Genehmiger und den Gesamtstruktur-Genehmiger erfolgt? Die zweite Sache, die ich beobachtet habe und die ein potenzielles Problem darstellt, ist, dass Sie, da Sie Kontoadressen und ihre jeweiligen privaten Schlüssel zur Authentifizierung verwenden, diese im Vergleich zu username+password sehr schwer zu merken sind. Haben wir eine andere Lösung?
Der Benutzername und das Passwort der DApp sind etwas, das vom Eth-Netzwerk offline ist (dh spezifisch für DApp) und nichts mit dem Ethereum-Netzwerk zu tun hat. Es ist so etwas wie, sagen wir, Sie haben ein Konto bei zebpay, Sie haben einen Benutzernamen + Passwort (+ Handy + Authentifikator), um sich bei zebpay anzumelden. Sobald Sie sich angemeldet haben, wird zebpay als Teil Ihrer Profildaten sicher eine Liste von Ethereum-Kontonummern (0x123.. + Passwort + Informationen zum privaten Schlüssel usw.) führen, die Sie verwenden oder weitere Konten hinzufügen können, wenn Sie möchten möchte.
Um spezifische Fragen zu beantworten - in meinem Anwendungsfall wird die Landstruktur keine separaten Konten haben. Es wird durch eine ID vom Typ bytes32 identifiziert. Die Authentifizierung für See/Wald ist nicht eingestellt, dh jeder mit gültiger Adresse + Gas kann sie genehmigen (wird dies beheben). Ich verwende Adresse + Passwort (das vom privaten Schlüssel getrennt ist - verwenden Sie web3.personal.newAccount ("password"), um pwd festzulegen) - an das sich der Benutzer erinnern kann.
Als Teil der Genehmigerliste habe ich eine Funktion im Vertrag wie hier erstellt und überprüfe dann wie folgt: Funktion isValidLakeApprover(Adresse _lakeApprover) gibt zurück (bool){ return lakeApprover[_lakeApprover]; }`