Ich habe früher auf der TBV-Seite von Babylon „vertrauenslose Verifikation“ gelesen, als würde das bedeuten, dass die gesamte Kette des Vertrauens entfernt wurde – nicht nur ein einzelnes Glied darin.
Dann habe ich tatsächlich nachgeprüft, was der Beweis abdeckt.
Drei Bausteine machen es möglich: On-Chain-Verträge, Light-Client-Beweise, die auf ZK-SNARKs laufen, und unabhängige Indexer – alles miteinander verknüpft, sodass Konsens und UTXO-Zustand von Bitcoin von irgendwoher anders überprüft werden können, ohne dass irgendjemand darauf vertrauen muss, dass ein bestimmter Verwahrer dafür bürgt.
Hmm.
Denn der SNARK beweist etwas, das enger gefasst ist als die Werbeaussage vermuten lässt. Er bestätigt, dass eine behauptete Bitcoin-Zustandsänderung zu den Regeln passt, die im Circuit hinterlegt sind – derselbe Circuit, der auch die eigene Konsenslogik von Bitcoin kodiert, Rechenprüfung für Rechenprüfung. Dabei werden zwei Dinge angenommen, ohne sie zu beweisen: dass der Header und die Transaktionsdaten, die in den Circuit eingespeist werden, von Anfang an korrekt waren, und dass der Circuit selbst im ersten Schritt korrekt gebaut wurde.
Ich habe die Seite geschlossen und beide Annahmen bis zu dem Punkt zurückverfolgt, an dem sie tatsächlich „leben“.
Die erste Aufgabe ist die des Indexers – ein separates, austauschbares Element, das neben dem Beweissystem sitzt. Die zweite liegt bei der Person bzw. dem Team, das den Circuit gebaut und geprüft hat – eine einmalige Vertrauensfrage statt einer fortlaufenden.
Ich sage nicht, dass das Design dadurch schwach wird. Jedes ZK-Light-Client-Schema, das auf externe Chain-Daten gebaut ist, hat irgendwo solche Nahtstellen. Babylon benennt sie nur, statt sie in die Werbeaussage einzufalten.
Wenn der SNARK die Zustandsänderung perfekt verifiziert, aber eine der beiden Annahmen falsch war: Hat dann der „vertrauenslose“ Teil tatsächlich gehalten – oder nur der Teil, der ohnehin nie wirklich vertrauenslos war?
#baby
$BABY
@BabylonLabs_io
$BABY
#baby
Dann habe ich tatsächlich nachgeprüft, was der Beweis abdeckt.
Drei Bausteine machen es möglich: On-Chain-Verträge, Light-Client-Beweise, die auf ZK-SNARKs laufen, und unabhängige Indexer – alles miteinander verknüpft, sodass Konsens und UTXO-Zustand von Bitcoin von irgendwoher anders überprüft werden können, ohne dass irgendjemand darauf vertrauen muss, dass ein bestimmter Verwahrer dafür bürgt.
Hmm.
Denn der SNARK beweist etwas, das enger gefasst ist als die Werbeaussage vermuten lässt. Er bestätigt, dass eine behauptete Bitcoin-Zustandsänderung zu den Regeln passt, die im Circuit hinterlegt sind – derselbe Circuit, der auch die eigene Konsenslogik von Bitcoin kodiert, Rechenprüfung für Rechenprüfung. Dabei werden zwei Dinge angenommen, ohne sie zu beweisen: dass der Header und die Transaktionsdaten, die in den Circuit eingespeist werden, von Anfang an korrekt waren, und dass der Circuit selbst im ersten Schritt korrekt gebaut wurde.
Ich habe die Seite geschlossen und beide Annahmen bis zu dem Punkt zurückverfolgt, an dem sie tatsächlich „leben“.
Die erste Aufgabe ist die des Indexers – ein separates, austauschbares Element, das neben dem Beweissystem sitzt. Die zweite liegt bei der Person bzw. dem Team, das den Circuit gebaut und geprüft hat – eine einmalige Vertrauensfrage statt einer fortlaufenden.
Ich sage nicht, dass das Design dadurch schwach wird. Jedes ZK-Light-Client-Schema, das auf externe Chain-Daten gebaut ist, hat irgendwo solche Nahtstellen. Babylon benennt sie nur, statt sie in die Werbeaussage einzufalten.
Wenn der SNARK die Zustandsänderung perfekt verifiziert, aber eine der beiden Annahmen falsch war: Hat dann der „vertrauenslose“ Teil tatsächlich gehalten – oder nur der Teil, der ohnehin nie wirklich vertrauenslos war?
#baby
$BABY
@BabylonLabs_io
$BABY
#baby