Wir haben dieses Anwendungsszenario und versuchen zu sehen, ob Ethereum oder Blockchain im Allgemeinen eine gute Lösung dafür ist.
Die Grundidee ist, dass der Benutzer eine kleine Menge privater sensibler Daten kontrolliert (z. B. individuelle Profiländerungshistorie, Transaktionshistorie). Der Benutzer kann steuern, wer Zugriff auf diese Daten hat. Wenn Benutzer A den Zugriff für einen anderen Benutzer B aktiviert, kann B den gesamten Transaktionsverlauf einsehen. Offensichtlich sollten andere Benutzer ohne Zugriff die Daten von A nicht sehen.
Wir denken darüber nach, die verschlüsselten Daten der Benutzer in der öffentlichen Blockchain zu speichern. Ethereum ist eine der Optionen, die wir in Betracht ziehen. Die Vorteile dabei sind:
Dezentral oder null Ausfallzeit
Jeder Benutzer mit Zugriff sieht den unveränderlichen Transaktionspfad (gut für Auditzwecke)
Fragen :
Offensichtlich können wir den Inhalt nicht mit dem eigenen privaten Schlüssel des Benutzers verschlüsseln, sonst müsste der Benutzer, wenn er Daten teilen möchte, den privaten Schlüssel preisgeben, um den Inhalt zu entschlüsseln.
Daher sollte jede Einheit privater Daten einen eindeutigen Verschlüsselungsschlüssel haben. Und wir müssen den Verschlüsselungsschlüssel ändern und den Inhalt jedes Mal neu verschlüsseln, wenn der Benutzer den Zugriff einer anderen Person widerruft.
Das führt also zu einer weiteren Frage:
Sollten wir sie in einer privaten Datenbank speichern? Eine allgemeinere Frage ist, da die Blockchain die Verfolgung des Eigentums in einem öffentlichen gemeinsamen Ledger erreicht, kann sie eine rollenbasierte Zugriffskontrolle vollständig mit allem (außer den privaten Schlüsseln des Benutzers) auch in der öffentlichen Kette implementieren?
AKTUALISIERUNG
Danke für die Antwort von Rob Hitchens. Ich habe den Blogbeitrag von Vitalik gelesen und festgestellt, dass es schwierig ist, verschleiertes Computing on Chain zu implementieren. Daher ist es unmöglich, alles in der öffentlichen Kette zu speichern und gleichzeitig die Privatsphäre der Benutzer zu wahren.
Das erfordert, dass wir eine Art privaten Speicher benötigen, um die Privatsphäre zu verwirklichen. Eine Idee ist, die öffentliche Kette nur zum Aufbewahren von Berechtigungsaufzeichnungen zu verwenden. zB erklären wir
mapping (address => bool) permissions;
Und kann nur senderdie Berechtigung eines beliebigen Kontos auf "true" oder "false" setzen. Unser privater Authentifizierungsserver respektiert diese (in der öffentlichen Kette gespeicherte) Berechtigungszuordnung und erlaubt nur einem authentifizierten Benutzer (dh dem Benutzer, der den privaten Schlüssel zu einem autorisierten Konto besitzt) auf den Inhaltsverschlüsselungsschlüssel zuzugreifen.
Wenn wir das obige Design verwenden, um sich selbst zu authentifizieren, muss der Kontoinhaber den privaten Schlüssel verwenden, um eine Signatur zu berechnen, und der Authentifizierungsserver muss dies überprüfen. Das scheint der Art und Weise zu ähneln, wie die Identität bei Ethereum-Transaktionen überprüft wird.
Wird der obige Ansatz funktionieren? oder noch wichtiger, gibt es ein besseres Design?
Stimmen Sie mit Sanchit über die Verwendung von Modifikatoren zur Steuerung des Zugriffs auf Funktionen überein.
Die Beispielimplementierung ist jedoch irreführend. Ich würde das für eine Neugestaltung markieren.
Ein paar Dinge zu beachten.
In Bezug auf die Datenspeicherung sollten Sie vielleicht eine Off-Chain-Serialisierung mit Verschlüsselung in Betracht ziehen. Dies, um die Gesamtspeicherkosten zu reduzieren, ohne die verteilte Natur der App zu beeinträchtigen.
Aus Datenschutzgründen sind Sie sich bewusst, dass Informationen in Ethereum für alle Parteien sichtbar sind. Erwägen Sie die Verwendung einer Mehrparteienverschlüsselung mit einem Smart Contract, um das „Geheimnis“ an mehrere autorisierte Parteien zu verteilen.
Für die Skalierbarkeit muss der Modifikator von @ Sanchit die unbegrenzte forSchleife eliminieren. Einfach gesagt, for(i=0;i<n;i++) ist ein Anti-Pattern . Ab einem bestimmten nZeitpunkt überschreiten die Ausführungskosten das BlockgasLimit, was bedeutet, dass es in jedem Fall fehlschlägt. Mit anderen Worten, eine Implementierung auf diese Weise garantiert, dass eine erfolgreiche Anwendung schließlich fehlschlägt, möglicherweise auf eine Weise, die nicht repariert werden kann.
Was gezeigt wird, ist in einer serverzentrierten Welt vollkommen logisch. In Ethereum benötigen alle Funktionen in jeder Größenordnung (ungefähr) feste Gaskosten. Eine Lösung ist das Refactoring mit 1-Step-Lookups unter Verwendung von mapping.
Ich erwähne dies nur, weil dieser Fehler in vielen Verträgen vorkommt und ich hoffe, dass die Antwort (ich stimme im Allgemeinen zu) die Programmierer nicht dazu bringt, diese Art von Fehler zu replizieren.
Ich hoffe es hilft.
Mithilfe von Modifikatoren können Sie die Zugriffskontrolle auf Ihre Smart-Contract-Funktionen implementieren. Angenommen, Sie möchten nicht, dass eine Funktion von jedem aufgerufen wird, der Ihren Vertrag verwendet. In diesem Fall können Sie einen Modifikator erstellen und die Verwendung der Funktion einschränken. Auf ähnliche Weise können Sie je nach Fall mehrere Modifikatoren für verschiedene Rollen haben.
Ein Beispielmodifikator, den ich in einem meiner Projekte verwende - "Only Member"
modifier onlyMember {
var index = DataStore(memberStore).getAddressIndex('account', msg.sender);
var state = DataStore(memberStore).getIntValue(index, 'state');
if (index != 0 && state == 0) {
_;
} else {
Status(100);
}
}
//modifier usage
function getMyBooks() constant onlyMember returns (string bookString, uint8 count) {
return getBooks(true);
}
Hoffe das hilft.
Benutzer10375
Benutzer10375
Sanchit
Rob Hitchens
Benutzer10375
Rob Hitchens