Mein Verständnis ist, dass die typische Architektur für eine Ethereum-App darin besteht, einen intelligenten Vertrag zu haben, der als Backend für ein zentralisiertes, zustandsloses Frontend fungiert, das auf einem einzelnen Server läuft.
Ist das nicht ein ziemlich eklatantes Sicherheitsrisiko? Wenn die Front-End-App gekapert wird, können alle Aktionen des Benutzers fehlgeleitet werden, was der Angreifer will (dh anstatt Ether an einen nützlichen Smart Contract zu senden, wird er an die Brieftasche des Angreifers gesendet).
Gibt es eine Möglichkeit, eine Front-End-App dezentral zu hosten?
Dies stellt in der Tat ein eklatantes Sicherheitsrisiko dar. Theoretisch zeigt der Benutzer vor dem Senden eine Vorschau seiner Transaktion in MetaMask usw. an, sodass er dem dapp nicht vertrauen muss, aber in der Praxis sind die Daten, die Sie in der Vorschau anzeigen, eine kryptische Vertragsadresse und ein unergründlicher Haufen hexadezimaler Daten und der Kontext für diese Daten - z. B. welches Kätzchen welche ID hat - stammt von der dapp, sodass ein betrügerisches Front-End Benutzer leicht dazu verleiten könnte, andere Transaktionen als die beabsichtigten zu senden.
Das Problem lässt sich wahrscheinlich lösen, indem inhaltsadressierte Daten von IPFS oder Swarm bereitgestellt werden, die von einer Browsererweiterung bereitgestellt werden, und ein Namensvertrag verwendet wird, der einen Bereitstellungsprozess erzwingt – z Benutzer für einen bestimmten Anwendungsnamen. Diese Systeme sind jedoch schwierig zu entwerfen, und es gibt noch keine praktische Lösung, die von DApp-Entwicklern einfach bereitgestellt werden kann.
Typischerweise besteht der Zweck eines Front-Ends für eine Ethereum-DApp darin, eine „hübsche“ Methode zum Aufrufen von Funktionen bereitzustellen, die sich auf dem hochgeladenen Smart Contract befinden. Natürlich könnte der Hacker die Adresse des Smart Contracts ändern, mit dem der Benutzer interagiert (aber der Benutzer kann immer sehen, wohin seine Transaktionen gehen). Sie können ein dezentrales Frontend mit IPFS https://ipfs.io hosten
Das Tolle an der Verwendung eines dezentralen Backends und der Verwendung von Tools wie EtherScan ist, dass wir immer relativ einfach sehen können, wohin unser Ether geht und an wen.
Wenn das Frontend zufällig überfallen wurde und der Hacker die Vertragsadresse geändert hat, kann der Benutzer sehen, dass seine Transaktionen nicht an die Adresse gehen, die es sein sollte (denken Sie daran, wie Sie die Adresse Ihres Freundes kennen, jemand sein Telefon gestohlen hat und Ihnen eine Nachricht sendet, dass Sie zu einer anderen Adresse kommen sollen, um Sie auszurauben, werden Sie vorsichtig sein, zu dieser Adresse zu gehen, da Sie noch nie zuvor dorthin gegangen sind und es keinen Grund dafür gibt). Sie können auch die Anzahl der Transaktionen anzeigen, die der Vertrag hatte (nur nützlich, wenn er kürzlich geklaut wurde). Ich denke, das ist ein etwas kleineres Problem und kann durch die Verwendung von IPFS gelöst werden (es kann jedoch langsam sein).
Um einen Überblick darüber zu geben, was der Hacker tun müsste, um Ether böswillig von Benutzern zu bekommen, hätten sie es auch getan;
Ja, das ist richtig, weshalb Sie Ihre Dapps auf IPFS+IPNS hosten können (nachdem Sie mit so etwas wie Webpack erstellt haben).
Die gleiche Logik gilt für Orakel, sie sind zentralisierte Fehlerquellen.
Jazzloch
Jazzloch
Edmund Edgar