pa
Ich habe darüber nachgedacht, warum Smart Contracts noch immer Schwierigkeiten damit haben, Entscheidungen auf Grundlage historischer Blockchain-Aktivitäten zu treffen.
Nehmen wir ein Kreditprotokoll. Zwei Wallets können exakt denselben aktuellen Kontostand haben, aber ihre Verläufe könnten völlig unterschiedlich sein. Die eine könnte seit Jahren verantwortungsbewusst Kredite aufnehmen und zurückzahlen, während die andere erst gestern erstellt wurde.
Der Vertrag kann ihren aktuellen Zustand sehen. Aber wie bewertet er alles, was zuvor geschehen ist?
Da begann ich, mir @SpaceandTime genauer anzusehen.
Was meine Aufmerksamkeit erregte, war nicht einfach die Tatsache, dass es Proof of SQL verwendet. Es war die Art und Weise, wie ein Smart Contract tatsächlich ein Ergebnis erhält, ohne die Datenbankberechnung selbst durchführen zu müssen.
Hier gibt es einen wichtigen Unterschied.
Ein Smart Contract wird nicht plötzlich zu einer Datenbank. Er sendet einen vorkompilierten SQL-Abfrageplan zusammen mit einer Zahlung und einem Callback-Ziel an den QueryRouter von Space and Time.
Die Abfrage wird anhand von Tabellen auf der SXT Chain verarbeitet. Das System erstellt zusammen mit dem Ergebnis einen Proof of SQL, und der Beweis wird on-chain verifiziert, bevor das Ergebnis an den anfragenden Vertrag zurückgegeben wird.
Der Callback ist jedoch ein weiterer interessanter Aspekt.
Der empfangende Vertrag muss überprüfen, ob die Antwort vom autorisierten Router-Executor stammt, und dann die zurückgegebenen Daten dekodieren, bevor er sie verwendet.
Mit anderen Worten: Daten zu empfangen und sicher mit ihnen zu handeln, sind zwei verschiedene Schritte.
Das verändert meine Vorstellung von der Architektur. Die aufwendige Berechnung findet außerhalb des anfragenden Vertrags statt, während die kryptografische Verifizierung es dem Vertrag ermöglicht, sich auf das zurückgegebene Ergebnis zu verlassen, ohne den gesamten Datensatz selbst verarbeiten zu müssen. Space and Time +1
Moment, da ist noch eine weitere Ebene, die ich nicht übersehen möchte.
Ein gültiger Beweis bedeutet nicht automatisch, dass die ursprünglichen Informationen wahr waren.
Wenn bei der Datenübernahme falsche Informationen in eine Datenbank gelangen, wird der ursprüngliche Fehler nicht auf magische Weise korrigiert, nur weil bewiesen wird, dass eine SQL-Berechnung korrekt anhand dieser festgeschriebenen Daten durchgeführt wurde. Datenintegrität und Datengenauigkeit hängen zusammen, sind aber nicht dasselbe. Beweis .
@SpaceandTime #sxt $SXT
Ich habe darüber nachgedacht, warum Smart Contracts noch immer Schwierigkeiten damit haben, Entscheidungen auf Grundlage historischer Blockchain-Aktivitäten zu treffen.
Nehmen wir ein Kreditprotokoll. Zwei Wallets können exakt denselben aktuellen Kontostand haben, aber ihre Verläufe könnten völlig unterschiedlich sein. Die eine könnte seit Jahren verantwortungsbewusst Kredite aufnehmen und zurückzahlen, während die andere erst gestern erstellt wurde.
Der Vertrag kann ihren aktuellen Zustand sehen. Aber wie bewertet er alles, was zuvor geschehen ist?
Da begann ich, mir @SpaceandTime genauer anzusehen.
Was meine Aufmerksamkeit erregte, war nicht einfach die Tatsache, dass es Proof of SQL verwendet. Es war die Art und Weise, wie ein Smart Contract tatsächlich ein Ergebnis erhält, ohne die Datenbankberechnung selbst durchführen zu müssen.
Hier gibt es einen wichtigen Unterschied.
Ein Smart Contract wird nicht plötzlich zu einer Datenbank. Er sendet einen vorkompilierten SQL-Abfrageplan zusammen mit einer Zahlung und einem Callback-Ziel an den QueryRouter von Space and Time.
Die Abfrage wird anhand von Tabellen auf der SXT Chain verarbeitet. Das System erstellt zusammen mit dem Ergebnis einen Proof of SQL, und der Beweis wird on-chain verifiziert, bevor das Ergebnis an den anfragenden Vertrag zurückgegeben wird.
Der Callback ist jedoch ein weiterer interessanter Aspekt.
Der empfangende Vertrag muss überprüfen, ob die Antwort vom autorisierten Router-Executor stammt, und dann die zurückgegebenen Daten dekodieren, bevor er sie verwendet.
Mit anderen Worten: Daten zu empfangen und sicher mit ihnen zu handeln, sind zwei verschiedene Schritte.
Das verändert meine Vorstellung von der Architektur. Die aufwendige Berechnung findet außerhalb des anfragenden Vertrags statt, während die kryptografische Verifizierung es dem Vertrag ermöglicht, sich auf das zurückgegebene Ergebnis zu verlassen, ohne den gesamten Datensatz selbst verarbeiten zu müssen. Space and Time +1
Moment, da ist noch eine weitere Ebene, die ich nicht übersehen möchte.
Ein gültiger Beweis bedeutet nicht automatisch, dass die ursprünglichen Informationen wahr waren.
Wenn bei der Datenübernahme falsche Informationen in eine Datenbank gelangen, wird der ursprüngliche Fehler nicht auf magische Weise korrigiert, nur weil bewiesen wird, dass eine SQL-Berechnung korrekt anhand dieser festgeschriebenen Daten durchgeführt wurde. Datenintegrität und Datengenauigkeit hängen zusammen, sind aber nicht dasselbe. Beweis .
@SpaceandTime #sxt $SXT
