Wann ist es sinnvoll, Node Server für eine Anwendung mit Smart Contracts zu verwenden?

Ich denke, dass die Antwort von @JohnAllen für mich keinen Sinn ergibt. Die üblichste Praxis besteht gerade darin, die Front-End-UI einer DApp als NodeJS-Anwendung zu implementieren, die die Web3-JavaScript-Bibliothek verwendet, um mit einem Ethereum-Knoten zu kommunizieren, der lokal ausgeführt wird, dh auf demselben Server wie die NodeJS-Anwendung.

Hier betreibt der NodeJS-Server selbst nicht den Ethereum-Knoten. (Achten Sie darauf, hier zwischen den beiden Verwendungen des Begriffs „Knoten“ zu unterscheiden.) Sowohl der Ethereum-Knoten (der Geth, Parity, Pyethapp oder jede andere Ethereum-Client-Software sein könnte) als auch die NodeJS-Anwendung laufen auf demselben Computer. Der Ethereum-Knoten ist ein Client der Ethereum-Blockchain, mit der er synchronisiert wird. Die NodeJS-Anwendung, die mit einem lokal laufenden Ethereum-Knoten kommuniziert, reduziert tatsächlich die Zentralisierung, da verschiedene Anwendungen keinem bestimmten entfernten Ethereum-Knoten vertrauen müssen. Außerdem werden Konten immer auf einem lokalen Knoten erstellt, da die generierten privaten Schlüssel auf dem lokalen Computer verbleiben sollten. Die Befehle zum Erstellen und Verwalten von Konten befinden sich in derweb3.eth.personalSchnittstelle, die standardmäßig nur über IPC (Inter-Process Communication) aktiviert ist, dh nur auf einem lokalen Ethereum-Knoten ausgeführt werden kann.

ZUSÄTZLICH: Wenn die Front-End-Schnittstelle einer DApp von einer NodeJS-Anwendung bedient wird, die auf einem bestimmten Server ausgeführt wird, führt dies zu einer gewissen Zentralisierung. Solange die DApp jedoch den Zustand ihres Modells (unter Verwendung von „Modell“ im Sinne von MVC) beibehalten kann, selbst wenn der NodeJS-Server ausfällt, und wenn jemand anderes die NodeJS-Anwendung hosten könnte, wird so die „Ansicht“ von MVC wiederhergestellt und Bereitstellung des Zugriffs auf das Backend (auf der Blockchain bereitgestellter Vertragscode), dann wird der Nachteil der Zentralisierung minimiert. Mein Punkt ist also, dass Zentralisierung/Dezentralisierung keine Schwarz-Weiß-Klassifizierung ist. Jede Anwendung liegt irgendwo auf einem Spektrum. Eine DApp könnteseine Benutzeroberfläche auch dezentralisiert bedienen lassen, z. B. habe ich gehört, dass Swarm & IPFS dafür vorgeschlagen wurden, aber ich weiß nicht mehr Details darüber, wie das gemacht werden würde. Es hängt alles vom Einzelfall ab und davon, wie viel Dezentralisierung wirklich benötigt wird.

Das macht meistens keinen Sinn für mich, hier ist der Grund:

wo der Blockchain-Knoten auf dem Server laufen würde

Die Definition von a blockchain nodeist einer von vielen Tausend Ethereum-Knoten, die die Blockchain-Daten speichern und häufig auf Anfragen zu diesen Daten antworten.

Wenn Sie also eine Architektur mit Ethereum nodeeinem Node.jsServer und einem Client haben – was würde der Node.js-Server tun?

Wird normalerweise Node.jsverwendet, um auf serverseitige Anforderungen zu antworten, Logik auszuführen und eine zentralisierte Datenbank abzufragen; aber mit Dapps fragen die Blockchain und web3(das ist eine Server- oder Client-Bibliothek) die Blockchain-Daten ab und ein Ethereum-Knoten antwortet mit den angeforderten Daten, die dann an den Client zurückgegeben werden.

Sie erwähnen das Speichern von Daten Node.jsin einem Kommentar. Eine weitere Option ist die zentrale Speicherung der Daten oder IPFS. Sie können einen einfachen Hash oder CID (Content Identifier) ​​on-chain speichern und die Daten, auf die der Hash verweist, in einer zentralisierten Datenbank speichern, die on-chain gespeicherten Hashes abfragen (deren Inhalt im Hash kodiert ist) und Ihre Daten abfragen per Hash, führen Sie dieselbe Hash-Funktion für die abgefragten Daten aus, um zu überprüfen, ob sie identisch sind, und geben Sie diese Daten dann an Ihren Client zurück.

In einer dezentralisierten Welt ist es sehr sinnvoll, Blockchain-Knoten an allen möglichen Orten zu haben. Manchmal hat Ihr Kunde Zugriff darauf, manchmal nicht. Hoffentlich werden sie das immer öfter tun, aber während wir auf leichtere Clients und skalierbarere Netzwerke warten, ist es sehr sinnvoll, Zeiten in Betracht zu ziehen, in denen Sie vielleicht auch einen Blockchain-Client auf einem Server ausführen möchten.

Clientseitige Blockchain-Clients machen wirklich nur Sinn, wenn der Benutzer ein Mensch mit einem Webbrowser ist. Bei jeder Machine-to-Machine-Transaktion wäre ein NodeJS-Prozess sinnvoller.

Auch wenn Web3 sehr praktisch ist, weil die API möglicherweise bereits im Browser des Benutzers vorhanden ist, ist es weit entfernt von einer optimalen Lookup-API. Sie können einen serverseitigen Knoten nur ausführen, um für Ihre App relevante Informationen zu indizieren, damit Sie sie den Benutzern schneller bereitstellen können.

Was das Signieren betrifft, denke ich definitiv, dass es sicherer ist, Schlüssel in den Händen des Benutzers zu lassen, aber es ist nicht unangemessen zu erwarten, dass einige Dienste im Namen der Benutzer von einem serverseitigen Prozess signieren.

Ein Blockchain-Client ist nur eine Software, die einem anderen Kontext den Zugriff auf die Blockchain ermöglicht. Es gibt nichts daran, was es in den einen oder anderen Kontext zwingt, und wenn das dezentrale Web wirklich abhebt und Skalierbarkeit und Leistung liefert, wird die schwieriger zu beantwortende Frage meiner Meinung nach lauten: „In welchem ​​Kontext würden Sie jemals KEINEN Blockchain-Client wollen in?"

Ich habe mich gefragt, ob ich an Alternativen denken könnte, die die Zuverlässigkeitsfunktionen usw. der Blockchain weiterhin nutzen könnten, aber in einem Client-Server-Framework laufen.

Sie können hybride Webanwendungen erstellen, die Python/Node/was auch immer als zentralen Back-End-Server für einige Aufgaben verwenden und die Blockchain für andere Aufgaben nutzen.

Ein zu stark vereinfachtes Beispiel für hybride Dapps wäre eine Dapp zur Verpfändung eines ERC20-Tokens im Austausch gegen ETH. Nun wollen Kreditgeber und Kreditnehmer über Zinsen und Laufzeit des Darlehens verhandeln. Der Kreditnehmer möchte auch wissen, ob jemand bereit ist, ihm bessere Zinsen anzubieten. Dieser Entdeckungsprozess kann über einen zentralisierten Dienst erfolgen, ohne dass ETH für jede Nachricht für Gas ausgegeben werden muss. An dieser Stelle könnte es zu einer gewissen Zensur kommen, wenn Ihnen Kreditgeber mit niedrigeren Zinsen aus irgendeinem Grund nicht angezeigt werden, Sie aber kein Risiko eingegangen sind und sich trotzdem aus dem Prozess zurückziehen können.

Sobald die Verhandlungen abgeschlossen sind, können sowohl der Kreditgeber als auch der Kreditnehmer einfach auf eine Schaltfläche auf der Webseite klicken und einen intelligenten Vertrag auf der Blockchain erstellen, der Informationen über alle Bedingungen der Hypothek enthält und sich entsprechend verhalten wird. An diesem Punkt müssen Sie nicht darauf vertrauen, dass die zentralisierte Website oder der Kreditgeber Ihre Sicherheiten sicher verwahrt, da sie in einem Vertrag eingeschlossen wären.

Sie opfern also in einem Schritt die Vertrauenslosigkeit für Geschwindigkeit und Kosten und nutzen die Vertrauenslosigkeit in einem anderen Schritt für die Sicherheit.

Sicher. Stellen Sie sich beispielsweise vor, Sie haben einen E-Commerce-Shop (z. B. den Verkauf von Smartphones), der in node.js geschrieben ist. Sie möchten es mit der Blockchain verbinden, um zB Zahlungen zu kontrollieren. Kunden zahlen also über Metamask oder Mist an Ihre Adresse und Ihr Shop-Backend wird mit dem Ethereum-Knoten (der sich möglicherweise auf demselben Server befindet) verbunden, um zu überprüfen, ob die Zahlung erfolgt ist, und die Bestellung fortzusetzen.

In diesem Anwendungsfall ist ein Server mit Ethereum-Knoten keine Möglichkeit, die App zu zentralisieren, sondern nur eine Möglichkeit, auf intelligente Verträge/Konten durch das Computersystem zuzugreifen, nicht durch den Menschen selbst.