Babylons Herausforderer-Regeln: Fehlertoleranz oder operative Perfektion?
Ich glaube, das schwierigste Problem in Krypto ist nicht zu beweisen, dass eine Regel existiert; es ist nachzuweisen, dass ein ehrlicher Teilnehmer unter unvollkommenen Bedingungen überleben kann, während er sie befolgt.
Darum verdient das Herausforderer-Design von @BabylonLabs_io eine genauere Betrachtung. In DeFi und bei Onchain-Automatisierung hängt die Abwicklung oft von Offchain-Software ab, die Ereignisse beobachtet, Bedingungen auswertet und innerhalb eines festen Zeitfensters reagiert. Ein böswilliger Betreiber kann diese Aufgaben absichtlich ignorieren, aber ein ehrlicher Herausforderer kann ebenfalls eine Antwort verpassen, etwa wegen eines Client-Absturzes, eines Netzwerkausfalls, eines beschädigten Zustands oder einer fehlgeschlagenen Benachrichtigung. Aus Sicht des Protokolls können beide Ausfälle identisch aussehen.
Babylon adressiert das breitere Abwicklungsproblem, indem es vor der Freigabe von Mitteln vordefinierte Richtlinienprüfungen anwendet und anschließend Onchain-Bestätigungen nutzt, damit der akzeptierte Zustand sichtbar und durchsetzbar wird. Ein Auszahlungs- oder Liquidationsanspruch muss vordefinierten Bedingungen entsprechen, während Herausforderer ungültige Ansprüche anfechten und den Anspruchsteller dazu zwingen können, kryptografische Beweise vorzulegen. Das ist eine sinnvolle Verbesserung gegenüber Systemen, die auf Verwahrern, intransparenten Betreibern oder sozialem Eingreifen setzen.
Doch die tiefere Abwägung ist der Entzug versus Widerstandsfähigkeit. Babylons Regeln können eine Partei disqualifizieren, die eine Herausforderung verliert, wodurch sich wiederholte Störungen reduzieren und teure Herausforderungs-Infrastruktur amortisiert. Das verbessert die Effizienz. Aber wenn eine verpasste Antwort, die durch kaputte Software verursacht wurde, einen ehrlichen Herausforderer dauerhaft aus dem System entfernt, belohnt das System nicht nur Ehrlichkeit; es belohnt operative Perfektion.
Meine Ansicht ist, dass eine starke Fehlertoleranz nachweisbare Täuschung aggressiv bestrafen sollte, gleichzeitig aber einen eng definierten Rückweg in das System für wiederherstellbare operative Ausfälle bieten sollte. Andernfalls könnte eine sauberere Teilnahme mit dem Preis geringerer Redundanz einhergehen.
Für $BABY und das breitere #baby -Ökosystem ist die Frage einfach: Soll die Systemsicherheit jede Nichterfüllung der Antwort als Beleg für Unehrlichkeit behandeln, oder sollte sie böswilliges Verhalten von ehrlichem technischem Versagen unterscheiden?