Als ich im TBV Rollen wie Vault Provider, Application Vault Keeper oder Universal Challenger gesehen habe, hatte ich anfangs ebenfalls Fragen: Wenn das System weiterhin so viele Operatoren benötigt, warum wird es dann überhaupt als Non-Custodial bezeichnet?
Nach weiterer Recherche glaube ich, dass es nicht darum geht, ob Menschen im System beteiligt sind, sondern darum, welche Befugnisse diese Personen tatsächlich haben.
Der Vault Provider treibt das Ein- und Auslösen voran, erstellt Nachweise und broadcastet Bitcoin-Transaktionen; der Application Vault Keeper ist an der Konfiguration auf Anwendungsebene beteiligt und kann in Integrationen mit Aave auch am Clearing und Settlement mitwirken; der Universal Challenger überwacht fortlaufend die Auslösungsnachweise und verhindert ungültige Auslösungen.
Diese Rollen können beeinflussen, ob ein Prozess rechtzeitig abläuft, aber sie können nicht einfach ad hoc einen neuen Ausgabepfad für Bitcoin erzeugen. Wohin BTC fließen darf, ist bereits bei der Vault-Erstellung in Skripten und Vorignatur-Strukturen festgelegt. Selbst wenn der Provider den Dienst einstellt, kann er die BTC der Nutzer nicht in eigene Adressen umleiten; Nutzer können die Auszahlung außerdem auch mithilfe der gespeicherten Materialien selbst vorantreiben.
Das hat mir geholfen, „trustless“ (ohne Vertrauen) neu zu verstehen: Es bedeutet nicht, dass das System überhaupt keine Operatoren braucht, sondern dass Operatoren von Kontrolleure über die Assets zu Ausführungsdiensten werden.
Ein gutes Protokoll sollte nicht davon ausgehen, dass alle Dienstanbieter stets zuverlässig und online sind, sondern standardmäßig davon ausgehen, dass ein Teil ausfällt, Fehler macht oder sogar missbraucht – und dann die schlimmsten möglichen Folgen begrenzen.
Darum schaue ich bei der Teilnehmerstruktur in TBV weniger auf die reine Anzahl der Rollen, sondern darauf, was jede Rolle tun kann und was nicht – und ob Nutzer sie ersetzen können, wenn sie ausfällt. Befugnisse haben Grenzen; das ist wichtiger als nur die Reduktion der Anzahl der Knoten. #baby $BABY @BabylonLabs_io
Nach weiterer Recherche glaube ich, dass es nicht darum geht, ob Menschen im System beteiligt sind, sondern darum, welche Befugnisse diese Personen tatsächlich haben.
Der Vault Provider treibt das Ein- und Auslösen voran, erstellt Nachweise und broadcastet Bitcoin-Transaktionen; der Application Vault Keeper ist an der Konfiguration auf Anwendungsebene beteiligt und kann in Integrationen mit Aave auch am Clearing und Settlement mitwirken; der Universal Challenger überwacht fortlaufend die Auslösungsnachweise und verhindert ungültige Auslösungen.
Diese Rollen können beeinflussen, ob ein Prozess rechtzeitig abläuft, aber sie können nicht einfach ad hoc einen neuen Ausgabepfad für Bitcoin erzeugen. Wohin BTC fließen darf, ist bereits bei der Vault-Erstellung in Skripten und Vorignatur-Strukturen festgelegt. Selbst wenn der Provider den Dienst einstellt, kann er die BTC der Nutzer nicht in eigene Adressen umleiten; Nutzer können die Auszahlung außerdem auch mithilfe der gespeicherten Materialien selbst vorantreiben.
Das hat mir geholfen, „trustless“ (ohne Vertrauen) neu zu verstehen: Es bedeutet nicht, dass das System überhaupt keine Operatoren braucht, sondern dass Operatoren von Kontrolleure über die Assets zu Ausführungsdiensten werden.
Ein gutes Protokoll sollte nicht davon ausgehen, dass alle Dienstanbieter stets zuverlässig und online sind, sondern standardmäßig davon ausgehen, dass ein Teil ausfällt, Fehler macht oder sogar missbraucht – und dann die schlimmsten möglichen Folgen begrenzen.
Darum schaue ich bei der Teilnehmerstruktur in TBV weniger auf die reine Anzahl der Rollen, sondern darauf, was jede Rolle tun kann und was nicht – und ob Nutzer sie ersetzen können, wenn sie ausfällt. Befugnisse haben Grenzen; das ist wichtiger als nur die Reduktion der Anzahl der Knoten. #baby $BABY @BabylonLabs_io
