#baby $BABY @BabylonLabs_io

durchwühlte heute erneut die Sicherheitsdokumente von TBV – diesmal nicht die Vault-Verträge, sondern den Teil darunter, wie der Bitcoin-Status überhaupt erst gegenüber Ethereum nachgewiesen wird.

herausgestellt hat sich: Es sind Light-Client-Beweise, konkret ZK-SNARKs, plus eine separate Schicht unabhängiger Indexer – die gemeinsam dafür sorgen, dass kein einzelner Knoten darauf vertraut werden muss, dass der Bitcoin-On-Chain-Status als „echt“ auf der Ethereum-Seite gilt. ehrlich gesagt ein richtig schickes Setup.

aber dann bin ich an einer Zeile im Abschnitt „Risiko“ hängen geblieben: dem Risiko der Bitcoin-Reorg-Timing. direkt neben dem Risiko der Korrektheit des Ethereum-Light-Clients. zwei getrennte Positionen, nicht eine.

ich habe eine Minute gebraucht, um zu verstehen, warum das zwei Probleme sind und nicht eins. der ZK-Beweis kann mathematisch perfekt sein und trotzdem etwas beweisen, das nach ein paar Blöcken nicht mehr stimmt, falls Bitcoin reorgs. und separat muss der Light Client auf der Ethereum-Seite diesen Beweis auch korrekt interpretieren – ein zweiter Punkt, an dem Dinge schiefgehen können, der nichts mit der Korrektheit der Kryptografie zu tun hat.

„trustless“ heißt hier also nicht „null Risiko“. es heißt, dass sich das Risiko von „Vertrauen in eine Person“ hin zu „Vertrauen darauf, dass zwei unabhängige Systeme sich im exakt richtigen Moment miteinander einig sind“ verschoben hat. anderes Problem – nicht automatisch ein kleineres.

Der Kaffee ist kalt, ich lese diesen Abschnitt trotzdem noch einmal durch. die Doku sagt nicht, wie tief eine Reorg tatsächlich gehen müsste, um hier relevant zu werden, oder ob ein Bestätigungs-Puffer eingebaut ist, bevor ein Beweis akzeptiert wird. hat das irgendjemand tatsächlich ausgerechnet, oder wird einfach angenommen, dass Bitcoin-Reorgs so tief grundsätzlich nicht passieren?

$ON $BROCCOLIF3B

Hat dich das verändert, wie du über „trustless“ nachdenkst?