Kann jeder Smart Contract gegabelt werden?

Das Verzweigen eines Systems ist, wie Sie vorschlagen, oft eine gute Möglichkeit, einem Konsenssystem eine Sicherheitsebene zu verleihen. Der Gedanke ist, dass, wenn jemand einige Ressourcen aufwendet, um das System anzugreifen und es in einen Zustand zu versetzen, den die Benutzer für falsch halten, eine neue Version dieses Systems bereitgestellt werden kann, idealerweise mit allen Ressourcen, die noch vom Angreifer gehalten werden, gelöscht oder neu zugewiesen werden Benutzer ignorieren einfach das alte System und wechseln zum neuen System.

In der Praxis kann Forking ein paar verschiedene Dinge bedeuten.

Wenn Sie Ihr eigenes Netzwerk haben, wie das Bitcoin-Netzwerk oder das Ethereum-Netzwerk, können Sie forken, indem Sie die Regeln ändern, denen einige der Knoten folgen. Dadurch wird das System in zwei unterschiedliche Netzwerke aufgeteilt, die am Block denselben Zustand teilen, bevor sie sich teilen, aber danach einen divergierenden Zustand haben.

Wenn Sie beabsichtigen, Ihren Code auf einem bestehenden Netzwerk wie Ethereum auszuführen, können Sie die Regeln dieses Netzwerks beim Forken nicht ändern, und alle Ihre Daten werden in einem einzigen, konsistenten Ledger gespeichert. Da Sie das Ledger nicht forken können, müssen Sie irgendwie eine neue Datenstruktur auf dem bestehenden Ledger erstellen.

Eine Option besteht darin, dass Sie, wenn Ihre Ressourcen alle demselben Vertrag unterliegen, einfach eine neue Version dieses Vertrags bereitstellen können, und alle werden darauf umsteigen. Dies funktioniert, wenn die Hauptsache, die der Vertrag verwaltet, ein Token ist und Sie (die Forking-Community) in der Lage sind, jeden, der an diesem Token interessiert ist, davon zu überzeugen, zu dem neuen Vertrag zu wechseln. Wenn dies ein normaler ERC20-Token ist, wird dies wahrscheinlich nicht perfekt funktionieren, da einige Verträge, die mit dem Token kommunizieren, möglicherweise nichts über den Fork wissen, was wahrscheinlich zu einem Verlust von Geldern führen wird, aber es kann für Ihre Zwecke gut genug sein. Mehr zu den praktischen Aspekten hier: https://medium.com/@edmundedgar/what-happens-when-you-try-to-fork-an-ethereum-token-863e3defcf7

Eine andere Möglichkeit besteht darin, alle Filialen in einem einzigen Vertrag zu verwalten und die Benutzer immer zu zwingen, die Filiale anzugeben. Dies ist die Strategie, die wir in dem Vertrag verwenden, den wir hier beschreiben: https://decentralize.today/get-the-facts-hard-fork-all-the-things-3ea2233da0fd

Eine dritte Option behält die Gabeln ebenfalls in einem einzigen Vertrag bei, versucht jedoch, zwischen ihnen zu entscheiden, um eine "echte" Gabel zu erstellen. Dies ist die von Augur verwendete Strategie: Wenn ein Fork ausgelöst wird, müssen Benutzer ihren Token ("REP") in den einen oder anderen Zweig migrieren, und das System behandelt schließlich den Zweig, in den die meisten REP migriert wurden, als den "wahrer" Zweig. Dies hat den Vorteil, dass eine einzige Token-Schnittstelle anderen Verträgen offengelegt wird und keine anderen Verträge mit ihrem Vertrag kommunizieren müssen, um eine Verzweigung anzugeben, da es eine „beste“ Verzweigung gibt. Der Nachteil ist, dass dieser Prozess ziemlich störend ist und daher mit einem System von Bindungen geschützt werden muss, was die Komplexität erhöht und möglicherweise nicht ausgelöst wird, wenn sich herausstellt, dass die Bindungen auf den falschen Ebenen festgelegt wurden.

Beachten Sie, dass in allen Fällen, in denen es keinen „echten“ Zweig gibt, das System wahrscheinlich nicht in der Lage ist, externe Ressourcen wie (für ein System, das auf Ethereum läuft) ETH zu verwalten. Alle diese Systeme beruhen auf einem nativen Token, das von der Community, die es verwendet, nach Belieben neu definiert werden kann.

Hier gibt es ein paar vermischte Missverständnisse. Mal sehen, ob ich sie entwirren kann. (1) Die Casper-Abschreckung ist nicht „Forking Contracts“, tatsächlich bin ich mir nicht einmal wirklich sicher, was „Forking Contracts“ bedeutet. Casper wird manchmal den Einsatz eines Validierers „kürzen“, wenn er etwas falsch macht, aber ich würde das nicht „einen Vertrag spalten“ nennen.

Wenn Sie „Forking a Contract“ sagen, klingt das so, als ob Sie an Linux denken, wo man ein Programm forken und zwei laufende Versionen des Programms haben kann. Blockchain-Forks sind nicht so, aber ich bin mir nicht sicher, ob Sie das sagen.

Auch die Worte „Orakelvertrag“ sind etwas ungewohnt. Ein „Orakel“ in der Blockchain-Welt ist, zumindest soweit ich weiß, eine Off-Chain-Software, die regelmäßig Daten in die Kette (d. h. in einen Smart Contract) schreibt, um Daten für den Smart bereitzustellen Vertrag. Ich glaube nicht, dass die meisten Leute ein Orakel als On-Chain betrachten. (Nicht, dass Sie anderen Verträgen keine Daten aus einem anderen Smart Contract zur Verfügung stellen könnten, aber im Allgemeinen glaube ich nicht, dass die Leute das meinen, wenn sie „Orakel“ sagen.)

Schließlich ist unklar, was Sie meinen: „Fork den Vertrag, wenn er angegriffen wird“. Wollen Sie damit sagen, dass der Smart Contract selbst in irgendeiner Weise reagiert, wenn jemand versucht, ihn zu hacken? Einige Leute schreiben Smart Contracts mit einem „Kill“- oder „Pause“-Schalter, aber es klingt nicht so, als würdest du das sagen.

Insgesamt ist Ihre Frage etwas verwirrend. Vielleicht kannst du es etwas präzisieren.