Ich habe gestern die TBV-Whitepaper wieder durchgearbeitet und bin im Abschnitt zu peg-in eine Weile hängen geblieben. Alle sagen immer: „BTC in einen Taproot Vault sperren und fertig“, aber im Whitepaper gibt es tatsächlich vor dem echten Einstieg in den Vault noch einen Zwischestatus namens „Pre-PegIn HTLC output“. Diese Stelle wird kaum zerlegt. $BABY
Laut der Dokumentation im Whitepaper wird bei der Auslösung der ersten Bitcoin-Transaktion der BTC nicht direkt in den endgültigen Vault-P2TR-Output geschoben, sondern erst in einen Pre-PegIn-Output, der einen Hashlock sowie einen Timelock-Refund besitzt. Zu diesem Zeitpunkt liegt der BTC bereits on-chain, aber der Vault ist noch nicht „aktiv“. Er muss auf zwei Dinge warten: erstens, dass auf der Bitcoin-Seite genügend Bestätigungen zusammenkommen, und zweitens, dass du auf der Ethereum-Seite das Hashlock-Preimage (den geheimen Wert, den nur du kennst) offenlegst. Sobald das Preimage bekannt ist, wird der letzte Schritt mit den erforderlichen Witness-Daten getriggert und der BTC in den echten Vault-Output weitergeschoben; wenn diese Offline-Koordination (Vault Provider, Keeper bauen zusammen den Transaktionsgraphen) hakt oder du deine Entscheidung änderst und das Preimage nicht offenlegst, sorgt der Timelock-Refund-Pfad im Pre-PegIn dafür, dass du die Coins einseitig zurückholen kannst. @BabylonLabs_io
Anfangs dachte ich, das sei nur ein technisches Backup. Dann ist mir klar geworden: Es verwandelt das „Cross-Chain-Aktivieren“ in einen atomaren Schalter. Die Registrierungs-Events auf Ethereum und die Asset-Sperrung auf Bitcoin werden über eine SHA-256-Preimage-Offenlegung miteinander gekoppelt; wenn eine Seite nicht fertig wird, bleibt das Asset nicht im Protokoll feststecken. Das ist etwas ganz anderes als bei traditionellen Bridges, wo man erst die Mainchain sperrt und dann die geminten, angekoppelten Tokens prägt – der BTC verlässt dabei von Anfang bis Ende nie die UTXO-Sammlung.
Noch härter ist das Manöver der „Transaktionsgraph-Pre-Signierung“. Das Whitepaper sagt, dass beim Vault-Create bereits alle erlaubten Ausgabepfade für spätere legitime Verwendungen – Redemption, Liquidation, Challenge-Response usw. – komplett als Pre-Sign-Transaktionen gebaut und signiert werden. Nach dem Erstellen kann keine Seite mehr eine neue Route erfinden. Die Bitcoin-Nodes, die danach etwas tun müssen, ist lediglich „Skripte und Signaturen verifizieren“, nicht „Aave oder eine PoS-Chain-Logik verstehen“. Externen Zustand in aus Bitcoin verständliche Ausgabebedingungen zu übersetzen, verschiebt das Vertrauen weg vom Custodian hin zur Berechnung selbst – das war der Satz, den ich vor dem Zerpflücken der Details nicht wirklich „gegessen“ hatte. #baby
Laut der Dokumentation im Whitepaper wird bei der Auslösung der ersten Bitcoin-Transaktion der BTC nicht direkt in den endgültigen Vault-P2TR-Output geschoben, sondern erst in einen Pre-PegIn-Output, der einen Hashlock sowie einen Timelock-Refund besitzt. Zu diesem Zeitpunkt liegt der BTC bereits on-chain, aber der Vault ist noch nicht „aktiv“. Er muss auf zwei Dinge warten: erstens, dass auf der Bitcoin-Seite genügend Bestätigungen zusammenkommen, und zweitens, dass du auf der Ethereum-Seite das Hashlock-Preimage (den geheimen Wert, den nur du kennst) offenlegst. Sobald das Preimage bekannt ist, wird der letzte Schritt mit den erforderlichen Witness-Daten getriggert und der BTC in den echten Vault-Output weitergeschoben; wenn diese Offline-Koordination (Vault Provider, Keeper bauen zusammen den Transaktionsgraphen) hakt oder du deine Entscheidung änderst und das Preimage nicht offenlegst, sorgt der Timelock-Refund-Pfad im Pre-PegIn dafür, dass du die Coins einseitig zurückholen kannst. @BabylonLabs_io
Anfangs dachte ich, das sei nur ein technisches Backup. Dann ist mir klar geworden: Es verwandelt das „Cross-Chain-Aktivieren“ in einen atomaren Schalter. Die Registrierungs-Events auf Ethereum und die Asset-Sperrung auf Bitcoin werden über eine SHA-256-Preimage-Offenlegung miteinander gekoppelt; wenn eine Seite nicht fertig wird, bleibt das Asset nicht im Protokoll feststecken. Das ist etwas ganz anderes als bei traditionellen Bridges, wo man erst die Mainchain sperrt und dann die geminten, angekoppelten Tokens prägt – der BTC verlässt dabei von Anfang bis Ende nie die UTXO-Sammlung.
Noch härter ist das Manöver der „Transaktionsgraph-Pre-Signierung“. Das Whitepaper sagt, dass beim Vault-Create bereits alle erlaubten Ausgabepfade für spätere legitime Verwendungen – Redemption, Liquidation, Challenge-Response usw. – komplett als Pre-Sign-Transaktionen gebaut und signiert werden. Nach dem Erstellen kann keine Seite mehr eine neue Route erfinden. Die Bitcoin-Nodes, die danach etwas tun müssen, ist lediglich „Skripte und Signaturen verifizieren“, nicht „Aave oder eine PoS-Chain-Logik verstehen“. Externen Zustand in aus Bitcoin verständliche Ausgabebedingungen zu übersetzen, verschiebt das Vertrauen weg vom Custodian hin zur Berechnung selbst – das war der Satz, den ich vor dem Zerpflücken der Details nicht wirklich „gegessen“ hatte. #baby