Ich habe diese Frage auf Bitcointalk gestellt, aber bisher keine Antwort erhalten. Da Lior vorgeschlagen hat, Stackexchange zum Hauptaustauschmedium für Ardour zu machen, frage ich hier.
Wie ich in den FAQ gelesen habe , besteht der Hauptnachteil von Lightweight Contracts darin, dass sie nicht völlig vertrauenswürdig sind, da Sie nicht garantieren können, dass der „Vertragseigentümer“ den Vertrag wirklich ausführt.
Wenn der Vertrag also beispielsweise ein "Austauschvertrag" ist, der Ihnen einen Token für ARDR geben soll (z. B. dieser IGNIS/ARDR-Austausch ), dann erhalten Sie die Token nicht, wenn der Vertragsinhaber den Vertrag nicht ausführt ( und der Vertragsinhaber könnte Ihre ARDR stehlen).
Sie können den Vertrag selbst ausführen, aber AFAIK können Sie nicht erreichen, dass der "Vertragseigentümer" die Austauschtransaktion unterzeichnet, ohne sie selbst auszuführen - Sie können nur validieren, dass der Vertrag das tut, was er laut Quellcode tun sollte. (Korrigiert mich, wenn ich hier falsch liege.)
Aber vielleicht könntest du folgendes tun:
Sie führen den Vertrag zunächst selbst aus und berechnen die „erwartete Transaktion“, die sich daraus ergeben soll, basierend auf den Eingaben Ihrer geplanten Transaktion (in diesem Fall die Transaktion, die Sie mit Token aus Ihrem ARDR belohnt).
Sie erteilen nun eine stufenweise Transaktion („Bedingte Transaktion“) mit der Bedingung der „erwarteten Transaktion“ – im Tauschfall, dass Sie den errechneten Token-Betrag vom Vertragskonto erhalten.
Wenn der Vertrag nicht läuft oder Ihnen nicht den erwarteten Token-Betrag gibt, läuft die Transaktion irgendwann in der Zukunft ab.
Auf diese Weise kann der Vertragsinhaber die resultierenden Münzen nur dann ausgeben, wenn der Vertragsinhaber den Vertrag ausführt. So sind Sie sicher vor "selektiven Betrügern", die Verträge einmal und dann nie wieder ausführen.
Auch der Vertragsinhaber ist auf der sicheren Seite: Der Vertrag sollte so konstruiert werden können, dass zunächst geprüft werden kann, ob er wirklich in der Lage ist, die gewünschte Transaktion herbeizuführen. Wenn nicht, dann gibt er die "erwartete Transaktion" einfach nicht aus. Es passiert also nichts (nur, dass wir eine nutzlose stufenweise Transaktion auf der Blockchain aufgezeichnet haben, aber ich denke, das ist ein kleines Problem, und es schafft den Anreiz, den Vertrag nur mit möglichen Bedingungen auszulösen).
Ist dieses Szenario möglich? Ich habe es in den Diskussionen über Lightweight-Verträge nicht gelesen. Wenn nicht, wäre es meiner Meinung nach eine nette Ergänzung, da dann Lighweight Contracts genauso vertrauenslos (oder fast so vertrauenslos) wären wie Ethereum Smart Contracts (oder sogar noch mehr, da Ethereum-Kontrakten das Benzin ausgehen kann).
AFAIK würde eine neue Art von Phased Transaction benötigen - eine ähnliche, die eine verknüpfte Transaktion erfordert, aber mit der Fähigkeit, nicht den vollständigen Transaktions-Hash (der in dieser Situation nicht berechnet werden kann) anzufordern, sondern die "unsignierte" Transaktion oder die Menge eines zu erhaltenden Tokens/Coins.
Prost, d5000
Eine Idee zur Lösung funktioniert so:
Der Absender reicht die Vertragsauslösetransaktion stufenweise mit einem Reveal-Secret-Genehmigungsmodell ein, das auf dem Hash eines von ihm generierten Secrets basiert.
Der durch diese Auslösetransaktion aktivierte Vertrag übermittelt die Antworttransaktion(en) mit einem zusammengesetzten Genehmigungsmodell, das aus demselben Hash des von der Auslösetransaktion verwendeten Geheimnisses und dem vollständigen Hash der Auslösetransaktion besteht.
Als nächstes passiert Folgendes:
Wenn der Absender die Auslösetransaktion genehmigt, kann er auch die Vertragstransaktion genehmigen, da er sich auf dasselbe Geheimnis verlässt.
Wenn der Absender die Trigger-Transaktion nicht genehmigt, verfallen sowohl die Trigger-Transaktion als auch die durch den Vertrag übermittelte Transaktion.
Wenn der Absender versucht, die Vertragstransaktion zu genehmigen, aber seine eigene Transaktion nicht zu genehmigen, wird die Vertragstransaktion nicht genehmigt, da sie sich auch auf den vollständigen Hash der Trigger-Transaktion stützt, der in der Blockchain nicht genehmigt ist.
Um dies zu implementieren, benötigen wir mindestens zwei Änderungen am bestehenden Design: 1. Lösen Sie einen Vertrag durch eine noch nicht genehmigte gestaffelte Transaktion aus, die derzeit nicht unterstützt wird. 2. Verbessern Sie das Genehmigungsmodell für den vollständigen Hash nach Transaktion, sodass es die Option hat, nur genehmigt zu werden, wenn der vollständige Hash eine schrittweise genehmigte Transaktion darstellt und nicht nur eine Transaktion, die wie jetzt in der Blockchain gespeichert ist.
d5000