Ich dachte früher, dass eine gute Erfahrung nur schnell genug und so intuitiv wie möglich sein muss. Wenn eine Oberfläche Nutzer dazu zwingt, zu lange zu warten, gehe ich fast automatisch davon aus, dass genau das der Bereich ist, der optimiert werden sollte.
Als ich Peg-ins selbst mit dem BTC-Signet auf Babylon ausprobierte, fühlte es sich zunächst nicht anders an. Transaktion bestätigen, warten, zwölf Blöcke. Fast zwei Stunden lang zeigte der Bildschirm nur, wie die Blockanzahl Schritt für Schritt steigt, und die Meldung, dass der Vault erst verfügbar sein wird, nachdem die Transaktion eine ausreichende Anzahl an Bestätigungen erreicht hat. Alles funktionierte korrekt, nur konnte ich nicht wirklich spüren, was „hinter den Kulissen“ gerade passiert.
Am Anfang betrachtete ich die zwölf Bestätigungen als eine Art Wartezeit. Erst später wurde mir klar, dass ich dadurch die Nutzererfahrung von dem Systemdesign entkoppelt habe. Ich musste die Beschreibung von Bitcoin Finality erneut lesen, um zu verstehen: Jeder Block ist nicht nur Zeit, die verstreicht. Jede neue Bestätigung senkt die Wahrscheinlichkeit, dass die Transaktion rückgängig gemacht wird, extrem schnell, und die Kosten, um die Kette neu zu organisieren, steigen erheblich. Genau das ist die Grundlage dafür, dass die Protokolle darüber Vertrauen darauf aufbauen können, dass das BTC tatsächlich „eingeschlossen“ wurde.
Aus meiner heutigen Perspektive liegt das Problem nicht darin, dass Bitcoin langsam ist. Es ist viel eher so, dass die Oberfläche den Nutzern kaum erklärt, worauf genau sie warten. Das Vertrauensmodell des Systems basiert auf der Finality von Bitcoin, doch was man unmittelbar sieht, ist im Grunde nur ein Fortschrittsbalken.
Ich habe es im Testnet ausprobiert, also hatte ich genug Zeit zum Beobachten. Für jemanden, der wirklich echtes Bitcoin sperrt, wird sich das vermutlich deutlich anders anfühlen. Vielleicht lautet die Frage nicht, wie sich die Wartezeit verkürzen lässt, sondern wie Nutzer die Bedeutung der Zeit erkennen, in der sie gerade warten.
#baby $BABY @BabylonLabs_io
Als ich Peg-ins selbst mit dem BTC-Signet auf Babylon ausprobierte, fühlte es sich zunächst nicht anders an. Transaktion bestätigen, warten, zwölf Blöcke. Fast zwei Stunden lang zeigte der Bildschirm nur, wie die Blockanzahl Schritt für Schritt steigt, und die Meldung, dass der Vault erst verfügbar sein wird, nachdem die Transaktion eine ausreichende Anzahl an Bestätigungen erreicht hat. Alles funktionierte korrekt, nur konnte ich nicht wirklich spüren, was „hinter den Kulissen“ gerade passiert.
Am Anfang betrachtete ich die zwölf Bestätigungen als eine Art Wartezeit. Erst später wurde mir klar, dass ich dadurch die Nutzererfahrung von dem Systemdesign entkoppelt habe. Ich musste die Beschreibung von Bitcoin Finality erneut lesen, um zu verstehen: Jeder Block ist nicht nur Zeit, die verstreicht. Jede neue Bestätigung senkt die Wahrscheinlichkeit, dass die Transaktion rückgängig gemacht wird, extrem schnell, und die Kosten, um die Kette neu zu organisieren, steigen erheblich. Genau das ist die Grundlage dafür, dass die Protokolle darüber Vertrauen darauf aufbauen können, dass das BTC tatsächlich „eingeschlossen“ wurde.
Aus meiner heutigen Perspektive liegt das Problem nicht darin, dass Bitcoin langsam ist. Es ist viel eher so, dass die Oberfläche den Nutzern kaum erklärt, worauf genau sie warten. Das Vertrauensmodell des Systems basiert auf der Finality von Bitcoin, doch was man unmittelbar sieht, ist im Grunde nur ein Fortschrittsbalken.
Ich habe es im Testnet ausprobiert, also hatte ich genug Zeit zum Beobachten. Für jemanden, der wirklich echtes Bitcoin sperrt, wird sich das vermutlich deutlich anders anfühlen. Vielleicht lautet die Frage nicht, wie sich die Wartezeit verkürzen lässt, sondern wie Nutzer die Bedeutung der Zeit erkennen, in der sie gerade warten.
#baby $BABY @BabylonLabs_io