Verifizierte Geschichte, die fehlenden Block-Hashes – PISA Research

Free Bitcoins: FreeBitcoin | BonusBitcoin

Coins Kaufen: Bitcoin.deAnycoinDirektCoinbaseCoinMama (mit Kreditkarte)Paxfull

Handelsplätze / Börsen: Bitcoin.de | KuCoinBinanceBitMexBitpandaeToro

Lending / Zinsen erhalten: Celsius NetworkCoinlend (Bot)

Cloud Mining: HashflareGenesis MiningIQ Mining


tl; dr. Unser Ziel ist es, die Eintrittsbarriere für Projekte, die sich in PISA integrieren möchten, zu minimieren (oder zu beseitigen). Ein fehlendes Puzzleteil ist ein Mechanismus im EVM, mit dem historische Protokolle für einen bestimmten Smart-Vertrag überprüft werden können. Wir haben ein Beispiel dafür, wie die Überprüfung historischer Ereignisse mithilfe von Solidity funktionieren könnte. Um jedoch die Implementierung aufwändiger und komplizierter Protokolle zu vermeiden, benötigen wir eine einfache Erweiterung des vorhandenen BLOCKHASH-Opcodes.

Bei PISA Research bauen wir ein verantwortlich Wachturm für Layer-2-Skalierungslösungen (und generell jeden intelligenten Vertrag über Ethereum). Ich hebe hervor verantwortlich denn das ist es, was PISA unter den Wachtürmen einzigartig macht. Kunden, die PISA beauftragen, können sich sicher sein, dass der Auftrag abgeschlossen wird, oder sie werden erstattet.

Bei PISA handelt es sich im Kern um ein einfaches Protokoll, bei dem der Wachturm eine Transaktion im Namen des Kunden an einen Zielvertrag sendet, wenn einige Kriterien der Kette erfüllt sind. Wird die Transaktion bis zum Ablauf der Frist nicht in der Blockchain angenommen, ist der Kunde zum Empfang verpflichtet Vergütung auf vertrauenslose Weise.

Wie? Der Kunde hat Beweise dafür, dass er uns engagiert hat, und die Blockchain sollte Beweise dafür enthalten, dass wir unsere Arbeit nicht erledigt haben. Der Kunde kann einfach den Nachweis erbringen, dass er uns eingestellt hat, und der PISA-Vertrag sollte Nachweise aus den Zielverträgen abrufen, um festzustellen, ob der Wachturm seine Arbeit getan hat.

Aber wie erhält der PISA-Vertrag Beweise aus den Zielverträgen? Es gibt heute keine verlässliche Möglichkeit, dies zu tun. Deshalb haben wir das DataRegistry entwickelt, das die Daten für die spätere Verwendung vorübergehend speichert. Es hat eine sehr einfache Oberfläche, die es ideal zum Speichern von Beweisen macht, aber um es zu integrieren, müssen die Zielverträge ihren Quellcode modifizieren.

Können wir Beweise in der Kette erstellen, ohne alle bestehenden Smart-Verträge zu ändern und ohne dass eine Datenregistrierung erforderlich ist?

Na ja, die Protokolle! Intelligente Verträge können Ereignisse über ihren Status oder jeden Status, auf den sie Zugriff haben, ausgeben. Diese Ereignisse werden als Anmeldungen aufgezeichnet Transaktionsbelege und der Blockheader liefert eine Verpflichtung für alle Transaktionsbelege für den angegebenen Block. Sobald ein Ereignis ausgegeben wurde, kann es nicht mehr geändert werden. Historische Protokolle sind also technisch bereits Teil der Kette und daher scheint dies die perfekte Datenstruktur für unseren Evidence-Use-Case in PISA zu sein.

Ein Foto einiger historischer Protokolle

Das Problem ist, dass Smart Contracts von Haus aus keinen Zugriff auf Transaktionsbelege innerhalb des EVM haben. Daher können wir Ereignisse nicht als Beweismittel verwenden.

Dies ist jedoch nicht schwer zu lösen. Wir können den Nachweis erbringen, dass sich eine Transaktionsquittung in einem Block befindet, indem wir einen Kopfzeilen – und einen Merkelnachweis für die Aufnahme in den Block liefern receiptsRoot. Hier ist ein Projekt, das zeigt, wie dies funktionieren könnte.

Allerdings ist das echt grundlegendes problem, ist, dass dem EVM der Zugriff auf die meisten historischen Block-Hashes fehlt. Wir benötigen Block-Hashes in der EVM, damit wir überprüfen können, ob sich der Beleg nicht nur in einem gültigen Block befindet, sondern auch in der aktuellen Kette. Das EVM bietet jedoch nur Zugriff auf die 256 Die letzten Block-Hashes, dh die in der letzten Stunde erstellten Hashes. Daher funktioniert die Lösung für PISA nur dann wirklich, wenn von dem Benutzer erwartet wird, dass er stündlich online zurückkehrt, um nach On-Chain-Beweisen zu suchen und sie an die Blockchain zu senden.

Was! Sie können nur die letzten 256 Block-Hashes erhalten?!?!?

Es gibt 3 + 1-Optionen zum Lösen des Block-Hash-Problems

  1. Speichern Sie regelmäßig den aktuellen Block-Hash in einem Vertrag. Wir können einfach Transaktionen einreichen, um den aktuellen Block-Hash in einem intelligenten Vertrag aufzuzeichnen und historische Checkpoints für Block-Hashes zu erstellen. Auf diese Weise könnten wir eine Kette von Block-Headern bereitstellen, und der Vertrag könnte überprüfen, ob sich jeder Block-Header in der Block-Kette befindet (d. H. Rückwärts arbeiten, abhängig von der Hash-Kette). Etwa 300 Header können innerhalb der Blockgasgrenze von 8.000.000 überprüft werden, sodass die Überprüfung einmal alle ~ 250 Blöcke erfolgen müsste.
  2. Führen Sie ein Bi-Section-Protokoll Wenn eine Partei einen Block-Hash nicht als gültig akzeptiert. Zu diesem Zweck legten beide Parteien einen Anteil fest und führten dann ein Protokoll zur Halbierung der Kette durch, um zu einem Block zu gelangen, auf den sie sich einig waren. Dieses Protokoll hat möglicherweise niedrigere laufende Kosten, ist jedoch interaktiv und kann nicht für andere Herausforderungen verwendet werden, da es nur für die an der Doppelsektion beteiligten Parteien relevant ist
  3. Bilden Sie einen zkSnark-Beweis der Hash-Kette, um einen vergangenen Block zu beweisen, ist Teil der aktuellen Kette. Anders als das Bi-Section-Protokoll ist es nicht interaktiv, aber wir müssten einen Snark implementieren, der nicht trivial ist.
  4. +1 beste Option. Rüste das EVM auf zur Unterstützung der Suche nach älteren Block-Hashes!

Ein vielversprechender Vorschlag, EIP-1218, schlägt vor, frühere Blöcke bis zur Entstehung mit exponentiell abnehmenden Lücken zur Gegenwart zu speichern. Da die EIP vorschlägt, die Block-Hashes in dem Zustand zu speichern, ist es immer noch möglich, den Blockhash eines Blocks zu beweisen, jedoch müsste ein Prüfer eine Reihe von Merkle-Beweisen des früheren Zustands liefern.

Während dieses EIP sicherlich das Prüfen beliebiger Blöcke ermöglichen würde, ist es für einen Vertragsentwickler nicht trivial, dies umzusetzen (und es richtig zu machen). Außerdem ist der Zugriff auf einen Archivknoten erforderlich, um die erforderlichen Zustandsnachweise abzurufen.

Eine einfachere Lösung für unseren Anwendungsfall wäre, den vorhandenen BLOCKHASH-Opcode auf eine viel größere Anzahl von Blöcken zu erweitern, beispielsweise auf die letzten 200.000 (~ 1 Monat), was erheblich mehr Anwendungsfälle für eine einfache Überprüfung historischer Ereignisse eröffnen könnte .

Für PISA ist dies aus zwei Hauptgründen eine Verbesserung des DataRegistry-Ansatzes:

  1. Es ist weitaus billiger, Beweise zu erstellen. Obwohl die Überprüfung der Einbeziehung eines Ereignisses mit der oben genannten Methode etwa 135.000 Euro kostet, ist das Schreiben eines Ereignisses billig (ab 750 Euro für ein Ereignis mit einem Thema und von dort aus). Die Überprüfung eines Ereignisses sollte nur in schlimmeren Fällen durchgeführt werden, in denen PISA seine Aufgabe nicht erfüllt hat. In diesem Fall kann der Gaszahler entschädigt werden. Hier ist ein Link zu einem POC, den ich erstellt habe, um die Gaskosten zu messen.
  2. Automatische Integration mit den meisten intelligenten Verträgen in Ethereum. Jetzt besteht eine gute Chance, dass ein Vertrag überhaupt nicht geändert werden muss, um in PISA integriert zu werden. Jeder Vertrag, der Ereignisse verwendet, um Zustandsänderungen an externe Beobachter zu signalisieren, könnte einfach in PISA integriert werden.

PISA funktioniert bereitskönnen wir mit Verträgen über das DataRegistry integrieren. Dies beinhaltet jedoch die Zusammenarbeit zwischen Projekten, die Umschichtung intelligenter Verträge und möglicherweise einen gewissen Anstieg der Gaskosten. Aber mit überprüfte Geschichte PISA kann jedes neue oder bestehende Projekt nahtlos unterstützen.

Es könnten jedoch weitere Anwendungsfälle auftreten. Verifizierte Geschichte erweitert die Sicht eines Vertrages vom aktuellen Stand auf den ganze Geschichte von Transaktionen, Ereignissen und Zustand. Grundsätzlich alles, was von einer externen Partei über die Kette beobachtet werden kann.

Momentan fehlt jedoch der einfache Zugriff auf historische Block-Hashes in der EVM. Das eine zwischen PISA und nahtlosen Integrationen.

Free Bitcoins: FreeBitcoin | BonusBitcoin

Coins Kaufen: Bitcoin.deAnycoinDirektCoinbaseCoinMama (mit Kreditkarte)Paxfull

Handelsplätze / Börsen: Bitcoin.de | KuCoinBinanceBitMexBitpandaeToro

Lending / Zinsen erhalten: Celsius NetworkCoinlend (Bot)

Cloud Mining: HashflareGenesis MiningIQ Mining

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close