Mit der heutigen Infrastruktur ist das nicht möglich. Wir können uns zwei Lösungen vorstellen.

Erste Lösung: Bitcoin-Upgrades

Das Skript wird mit neuen Opcodes zunehmend leistungsfähiger. In diesem Fall müsste es meiner Meinung nach tatsächlich einen neuen UTXO-Set-Index geben (den die Knoten derzeit nicht einmal berechnen), damit das Skript alle Zahlungen an eine bestimmte Adresse / mit einem bestimmten Marker finden und darüber nachdenken kann. Sie könnten dann Leute Geld in Ausgaben mit Skripten stecken lassen, die in Pseudocode sagen:

• Wenn es nach einer bestimmten Zeit ist
• Führen Sie die UTXO-Suche durch, um alle Ausgänge zu finden, die als für Partei A gekennzeichnet sind
• Führen Sie die gleiche Suche für Partei B durch
• Analysieren und summieren Sie sie, um herauszufinden, wer gewonnen hat. Der vorhandene Befehlssatz könnte dafür gut genug sein oder auch nicht, aber die Opcodes, die vor langer Zeit durch Panik deaktiviert wurden, wieder zu aktivieren, scheint nicht unmöglich zu sein: Es braucht nur gute Unit-Tests.
• Fordern Sie dann unter Verwendung des Ergebnisses dieser Berechnung eine Unterschrift an, die von der Gewinneradresse stammt

Die Skriptarchitektur könnte dies also tun, indem eine Erweiterung und einige der deaktivierten Opcodes wieder aktiviert werden. Aber die eigentliche Frage ist - sollte es?

Der Hauptnachteil, wenn man so etwas zulässt, ist, dass die Berechnung der benötigten Datenbankindizes rechenintensiv ist und die Knoten verlangsamt, wodurch sie teurer in der Ausführung werden und die Bitcoin-Skalierung beeinträchtigt wird.

Der Vorteil ist, dass diese Konstruktion von jedem Netzwerkteilnehmer geprüft und verifiziert wird, was die beste Sicherheit ist, die Sie in Bitcoin haben können.

Für diesen speziellen Anwendungsfall würde ich wahrscheinlich das Gefühl haben, dass die Kosten die Vorteile überwiegen. Die Konstruktion ist meiner Meinung nach eher seltsam und wenig überzeugend. Es ist jedoch möglich, dass jemand einen Anwendungsfall für OP_LOOKUP_OUTPUTS findet, der tatsächlich überzeugend ist, und wir haben schon ewig darüber gesprochen, Knoten dazu zu bringen, mehr Indizes über den UTXO-Satz zu berechnen. Wenn wir das sowieso aus anderen Gründen tun, scheint es an diesem Punkt nicht so ein großer Sprung zu sein, es über Skript verfügbar zu machen, und dieses Konstrukt als "reinen" Smart Contract zu machen, würde möglich werden (sogar einfach).

Zweite Lösung: Oracle-Netzwerk

Seit Beginn von Bitcoin gab es eine Debatte über das Gleichgewicht zwischen Einfachheit und Leistungsfähigkeit bei Skripting-Verträgen. Bitcoin hat eine ziemlich restriktive Skriptsprache, teilweise weil sie sich in der Anfangszeit als unzureichend getestet und offen für Sicherheitslücken herausstellte, und die Reduzierung ungenutzter Energie eine schnelle Möglichkeit war, den Kern zu stabilisieren.

Ethereum ist das genaue Gegenteil, es verleiht Skripten enorme Leistung und Zugriff auf viele teure Funktionen, wie Datenspeicherplätze. Wie sicher es ist, wie resistent gegen DoS-Angriffe und so weiter, ist derzeit eine ungeklärte Frage, aber wir wissen aus bitterer Erfahrung mit Bitcoin, Java, Flash, HTML/JS etc, dass das Sandboxing von mobilem Code extrem schwierig ist. Sie werden ihre Arbeit für sie ausgeschnitten haben. Alle mir bekannten mobilen Code-Sandboxen haben irgendwann Löcher in sich, also hat es noch niemand geschafft , das zu tun, was Ethereum ohne wiederkehrende Exploits tun will. Aus diesem Grund ist die Bitcoin-Community mit zunehmender Macht des Skripts so konservativ.

Es wäre ideal, wenn wir irgendwie zwei Skriptsysteme erstellen könnten, ein einfaches/triviales, das die Geldbewegungen im Kernnetzwerk verwaltet, und ein leistungsfähigeres, bei dem Sicherheitsverletzungen nur die Personen betreffen, die diese Funktionen verwenden, und nicht alle.

Es gibt ein paar Möglichkeiten, wie wir dies in Bitcoin tun können.

Eine besteht darin, ein unabhängiges P2P-Netzwerk von Orakeln zu haben:

https://en.bitcoin.it/wiki/Contracts#Trust_minimization:_multiple_independent_oracles

In diesem Fall hat jedes Orakel eine Identität und die Leute zahlen eine Schwellensignatur von vorausgewählten Orakeln ein. Jedes Orakel führt das Programm unabhängig aus und signiert dann mit seinem privaten Schlüssel, wenn das Programm erfolgreich ist.

Das Problem hier ist, dass Sie nicht viel Agilität haben. Orakel können nicht so kommen und gehen wie Bergleute.

Eine andere besteht darin, eine Seitenkette zu verwenden, wenn eine solche Technologie verfügbar wird. In diesem Fall enthält die Seitenkette keine Münzen und ein zweiseitiges Pegging ist nicht erforderlich. Vielmehr behaupten die "Transaktionen" der Seitenkette nur, dass ein Programm ausgeführt und erfüllt wurde. Orakel "minen" dann die Seitenkette und beweisen damit, dass eine Hashpower-Mehrheit das Skript ausgeführt und die erwartete Ausgabe erhalten hat.

Eine letzte Möglichkeit ist die Verwendung von SNARKs, wenn eine solche Technologie verfügbar wird.

Der Reiz dieser Art von Sandboxing besteht darin, dass, wenn beispielsweise ein Sandbox-Escape-Exploit in der dominanten Oracle-Implementierung gefunden wird, dies dazu führen würde, dass orakelgesperrte Ausgaben stehlbar werden, aber keine anderen Bitcoin-Ausgaben, sodass das Risiko begrenzt ist.

Das Ethereum-Design hingegen bindet die Dinge enger zusammen. Ein Exploit in der Ethereum Contracts Engine könnte dazu führen, dass das gesamte System zusammenbricht.

Es gibt keine Möglichkeit in der Bitcoin-Skriptsprache, auf Blockchain-bezogene Daten zuzugreifen, die weder in der Transaktion noch im Ausgabeskript enthalten sind, das die Transaktion auszugeben versucht. Dies bedeutet im Grunde, dass Sie den gesamten Adresssaldo im Skript nicht berechnen und vergleichen können.

Sie benötigen einen Drittvermittler, der beurteilen kann, welche Partei mehr Bitcoins auf ihrem Konto hat.