Ist eine DAPP wirklich dezentralisiert? Wenn ja, was genau ist dezentralisiert? [abgeschlossen]

Dies ist eine Art theoretische Frage in Bezug auf Ethereum DAPPs, die ich in letzter Zeit zu lernen versucht habe (und von der ich zugeben muss, dass ich immer noch kläglich unwissend bin).

Grundsätzlich (mit meinem begrenzten Wissen) würde ich ein DAPP so beschreiben: Ein DAPP ist eine Sammlung von Smart Contracts (die über öffentliche APIs miteinander interagieren - jeder Vertrag hat einen).

Jeder Smart Contract ist ein dezentralisiertes Programm, das auf der Blockchain läuft. Mit anderen Worten, wenn ein Anruf an den Vertrag geht, führt jeder Knoten im Ethereum-Netzwerk den Vertragscode aus und aktualisiert seinen Status. Dies bedeutet im Wesentlichen, dass der Status des Programms (seine Daten, dh wie viel Ether es hat, seine Mitglieder oder was auch immer ...) nicht an einem einzigen Ort gespeichert wird und nicht einer zentralen Instanz unterliegt, die ihn nach Belieben ändert.

Da eine Anwendung die Summe ihrer Teile ist und in einem DAPPS-Fall die Teile Verträge sind, bedeutet dies, dass die DAPP ebenfalls dezentralisiert ist (dh keiner zentralen Autorität unterliegt).

Nachdem ich jedoch ein wenig mit der Implementierung versucht hatte, stieß ich schnell auf einige Probleme, die im Wesentlichen darauf hinauslaufen: Wenn ich einige Smart Contracts im Netzwerk bereitgestellt habe, stellt sich die Frage (insbesondere angesichts des jüngsten DAO-Hacks, bei dem mehrere andere Personen als der eigentliche Hacker, der sich möglicher Probleme bewusst war), wie kann ich Verträge aktualisieren (für Fehlerbehebungen oder Verbesserungen)?

Um etwas genauer zu sein, scheint es mir, dass es grundsätzlich zwei verschiedene Klassen von Verträgen gibt:

1. Vertrags-Singletons, das wären Bibliotheken oder Fabriken.
2. Verträge, die von Fabriken produziert wurden.

Ein Beispiel wäre eine Terminbörse, bei der (in einem sehr vereinfachten Fall, ich weiß) die Börse die Singleton-Fabrik wäre und Terminkontrakte vom Typ 2 produzieren würde.

Abgesehen davon stellt sich die Frage: Wie aktualisiert diese Terminbörse ihre Software auf eine neue, nicht abwärtskompatible Version, da zu jeder Zeit verschiedene Futures-Kontrakte im Umlauf sind, die erwarten, dass der Futures-Börsenkontrakt-Singleton eine bestimmte API hat (das entspricht der Vorgängerversion). In einem anderen Fall, wenn eine kritische Sicherheitslücke in den generierten Futures-Kontrakten entdeckt wird, wie fügt diese Börse einen Patch für alle bereits bestehenden Futures-Kontrakte (vom Typ 2) ein?

Nach dem Lesen (und vielem Nachdenken - immer noch ohne ein sehr klares detailliertes Bild davon, wie dies getan werden könnte) scheint dies kompliziert zu werden. Eines ist jedoch klar, um dies auf sichere Weise zu tun (ohne einige Community-Abstimmungen, die kritische Zeit verschwenden könnten), muss die Börse ein Vertragsschema entwickeln (unter Verwendung eines Vertragsnamenregisters usw.), in dem sie die Fähigkeit, die APIs und den Status aller Verträge zu ändern, die sie erstellt hat (der Vertragsstatus muss möglicherweise geändert werden, um einen Fehler im Vertrag zu verbessern oder zu beheben, ist dies vermeidbar, nicht sicher?). Dies könnte durch die Einführung einer Bibliothek mit einer sich ständig weiterentwickelnden Upgrade-Funktion geschehen, die Verträge oder ähnliches aktualisiert (ich weiß nicht - ich habe nicht genug Erfahrung mit Ethereum, um dies klar zu durchdenken).

Dies führt jedoch zu meiner Frage: Wenn die Börse (oder im Allgemeinen das Entwicklungsteam eines DAPP) alle Verträge unter ihrer zentralen Kontrolle halten muss (damit sie ihre Funktionalität oder ihren Zustand ändern können), was genau ist dann dezentralisiert? Wenn dieses Entwicklungsteam jemals gehackt würde (dh seine Privatadresse gestohlen oder so), wäre das System genauso anfällig wie eine normale Webanwendung? Was genau ist also in der DAPP dezentralisiert, außer der eigentlichen Ausführung (dh der Ausführung auf mehreren Knoten), was nur ein technischer Unterschied ist (nicht anders als die Ausführung eines herkömmlichen Webservers in AWS wirklich ...)

Vielen Dank im Voraus, ich freue mich darauf, stark korrigiert zu werden =).

Bearbeiten: Ich denke, man könnte argumentieren, dass sich die Zustände von Verträgen niemals ändern könnten (was meiner Meinung nach dem Einfrieren des Datenmodells einer Anwendung oder zumindest Teilen davon entspricht). Selbst wenn dies erreicht würde, würden die tatsächlichen Methoden aller Verträge zentralisiert, was den Zustand der Verträge ändert ...

Edit2: Vielleicht könnte man immer einem Muster folgen, bei dem alle Verträge vom Typ 2 (dh generierte Verträge) nicht unter der Kontrolle von irgendjemandem wären (für Patches, Fixes usw.). In diesem Fall sollte der Vertrag niemals etwas über die API eines anderen Vertrags annehmen (weil sich das jederzeit ändern kann). Ich bin mir jedoch nicht sicher, was man gegen Sicherheitslücken im Vertrag selbst tun könnte ...