Typische Architektur einer DApp mit einem Browser-Client

Ich versuche, die typische Architektur einer Dapp mit Browser-Clients zu verstehen. Ist das folgende Verständnis korrekt?

[Webbrowser (Endbenutzer)] <==> [Server (Webanwendung/Javascript <==> web3 <==> Ethereum-Client wie Geth)] <==> [Ethereum Netzwerk (Soliditätscode)]

Hey, im Grunde hast du Recht. Können Sie mir helfen zu verstehen, was Sie mit dem Ethereum-Client meinen?
Hallo Borinho, Ethereum-Client wie Geth, Eth, Pyethapp usw., der mit Smart Contracts im Ethereum-Netzwerk kommunizieren kann.

Antworten (2)

Ich bin mir nicht sicher, ob Sie eher den Datenfluss als die tatsächliche Systemarchitektur beschreiben, aber wenn Sie es sind, ist es nicht ganz richtig.

Übersicht der dezentralen Anwendungen:

Alex Van de Sande hat einen großartigen Artikel über das Erstellen von serverlosen Anwendungen geschrieben und darin die Unterscheidung zwischen einem zentralisierten Build und einem dezentralisierten Build gegenübergestellt.

https://blog.ethereum.org/2016/07/12/build-server-less-applications-mist/

Traditionelle zentralisierte StrukturGeben Sie hier die Bildbeschreibung ein

Dezentrale Struktur der neuen GenerationGeben Sie hier die Bildbeschreibung ein

Der Artikel spricht viel über Mist, aber das war, als Mist wirklich der einzige war, der in der Stadt gezeigt wurde. Jetzt haben wir Parity und sogar MetaMask, die Benutzern den Zugriff auf web3.js und eine Verbindung zu einer Ethereum-Wallet ermöglichen, und vor allem die Möglichkeit, die Ethereum-Wallet zu verwenden, um Transaktionen auf der Ethereum-Blockchain/dem Netzwerk zu signieren.

Betrachtet man Ihr Beispiel:

[Webbrowser (Endbenutzer)] <==> [Server (Webanwendung/Javascript <==> web3 <==> Ethereum-Client)] <==> [Ethereum Netzwerk (Soliditätscode)]

Der Ethereum-Client befindet sich normalerweise nicht auf der Serverseite, es gibt Ausnahmen wie die Verwendung von etwas wie MetaMask, aber in diesem Fall würden Sie MetaMasks auf der Serverseite und nicht Ihre eigene verwenden. Der Ethereum-Client wäre Teil des Webbrowsers. Außerdem kommuniziert der Client mit dem Ethereum-Netzwerk, nicht Ihr Server. Ihre Struktur / Beziehung müsste also in zwei Teile aufgeteilt werden und eher so aussehen:

Herunterladen von HTML und JS:

[Webbrowser (Endbenutzer <==> Ethereum-Client) ] <==> [Server (Webanwendung/JavaJcript <==> web3) ]

Interaktion mit der Blockchain:

[Webbrowser (Endbenutzer <==> Ethereum-Client) ] <==> [Ethereum-Netzwerk (Soliditätscode) ]

Oben ist eine gute Antwort. Nur damit es nicht so aussieht, als wären serverseitige Knoten schrecklich ungewöhnlich (nodejs, Python usw.), würde ich hier auf eine ähnliche Frage hinweisen: ethereum.stackexchange.com/questions/11624/…
Eigentlich meinte ich mit Ethereum-Client geth/eth/pyethapp. Endbenutzer sind die breite Öffentlichkeit, die einfach www.xyz.com in den Browser eingeben, um auf die App (dapp) zuzugreifen. Wir können nicht erwarten, dass sie das gesamte Geth auf ihrem Laptop installiert haben! Es muss eine Webanwendung auf einem Server mit serverseitigem Javascript (node.js), web3 und geth vorhanden sein, um der Webanwendung zu helfen, sich mit dem Ethereum-Netzwerk zu verbinden.
Aus Interesse, wie verwalten Ihre Benutzer ihre Ethereum-Schlüssel?
Hallo Samyoul - ich bin noch nicht bis dahin gegangen. Ich versuche nur zu verstehen, wie ein Smart Contract / Dapp einen Webclient haben kann. Wenn ich beispielsweise etherscan.io besuche , kommuniziert es mit dem Ethereum-Netzwerk (mit intelligenten Verträgen), um die angezeigten Daten anzuzeigen. Wie macht es das? Verbindet sich das js in meinem lokalen Browser direkt mit dem Etheruem-Netzwerk? Ich glaube nicht. Was ich verstehe ist, dass auf das Ethereum-Netzwerk nur über Komponenten wie web3 (oder ähnliches) und geth (oder ähnliches) zugegriffen werden kann und ich keine davon auf meinem Laptop habe. Wo sind diese also? Irgendwo dazwischen?
Es hängt von Ihrem Anwendungsfall ab. Möchten Sie, dass Ihre Benutzer mit Verträgen interagieren? In diesem Fall benötigen die Benutzer eine sichere Methode zum Signieren ihrer Transaktionen. Ein rein serverseitiger Ethereum-Client bedeutet, dass Benutzer dies nicht tun können, es sei denn, Sie bauen einen zusätzlichen Dienst auf, der genau wie MetaMask funktioniert.
Exakt. Das ist der Anwendungsfall, den ich meine. Benutzer sollten in der Lage sein, mit den Smart Contracts auf der Blockchain zu interagieren. (Ja, die Transaktionssignierung kann über einen Dienst erfolgen). Der Punkt, den ich bestätigen möchte, ist, dass jede "Komponente", die versucht, mit dem Ethereum-Netzwerk zu interagieren, ein Web3 (oder ähnliches) + Geth (oder ähnliches) benötigt. Und diese „Komponente“ kann alles sein – Desktop-Anwendung (wie Wallets) oder Server-Code einer Webanwendung (wie Web-Wallets und etherscan.io und Browser Solidity). Ich hoffe mein Verständnis geht in die richtige Richtung.

@Ashish - Ihre Hypothese ist richtig, aber unvollständig. Während dies ein üblicher Weg ist, ist es keineswegs der übliche Weg ; Es gibt mehrere akzeptable Muster, die vom vorgesehenen Anwendungsfall abhängen.

Dieser Artikel gibt einen Überblick über die aktuell beliebtesten Ethereum-Architekturmuster und bietet einen Anwendungsfall für jedes: https://blog.zeppelin.solutions/designing-the-architecture-for-your-ethereum-application-9cec086f8317 .

Typische Architektur einer DApp mit einem Browser-Client
AntwortenHierDatenschutz-Bestimmungen1y, 0v