Ich habe gestern die ein paar Abschnitte aus dem Whitepaper zu „automatischem Slashing“ im Vergleich zu Casper/Tendermint wieder hervorgeholt. Damals wirkte der Vergleich zwischen „automatisch“ und „Community-Konsens“ sehr klar: Einmal wird es automatisch ausgeführt, einmal braucht es eine komplexe Koordination—und damit war sofort klar, wer gewinnt. Aber diesmal habe ich genauer auf das Wort „automatisch“ geschaut, und je länger ich es ansehe, desto mehr habe ich den Eindruck, dass dahinter eine Bedingung steckt, die ich noch nicht vollständig durchdrungen habe.
Ich habe den Ausführungsweg für das Slashing noch einmal neu gezeichnet. Im Whitepaper, Abschnitt 9.2, steht: Bei Etherereums PoS ist für Slashing bei Sicherheitsverstößen ein Community-Konsens erforderlich, weil mehr als 1/3 böswilliger Validatoren die Slashing-Belege auf der Kette prüfen können. Dadurch muss ein Off-Chain-Koordinationsprozess durchlaufen werden, um die Chain neu zu starten. Beim Bitcoin-Staking liegt das eingesetzte Kapital hingegen auf der Bitcoin-Kette (aufgrund von $BABY ), sodass bei einem Verstoß „sofort ein automatisches Slashing“ erfolgt. Die eigentliche Frage ist jedoch: Wer ist dafür verantwortlich, die Slashing-Transaktion in die Bitcoin-Kette einzureichen? Wenn ein(e) Monitor/Überwacher eine einzelne Einheit oder eine begrenzte Menge an Akteuren ist—was passiert dann, wenn sie/er angegriffen wird oder offline geht? Und wenn das Bitcoin-Netzwerk gerade ausgelastet ist und die Slashing-Transaktion für ein paar Stunden im mempool hängt: Gilt dieses „automatisch“ dann immer noch?
Später habe ich in meinen Notizen formuliert: Das „automatische Slashing“ beim Bitcoin-Staking verlagert im Kern den Engpass der Lebendigkeit von „Koordination auf der gleichen Kette über den PoS-Chain-Konsens“ hin zu „Kombination aus Cross-Chain-Ausführungsverzögerung + Zuverlässigkeit des/der Überwachers + Reaktionsfähigkeit des Bitcoin-Netzwerks“. Der Community-Konsens in Ethereum (#baby ) ist zwar langsam und schmerzhaft, aber er ist protokollimmanent—selbst wenn mehr als 1/3 der Validatoren Schaden anrichten, gibt es für die Community immer einen Weg zu einer endgültigen Entscheidung. Beim Bitcoin-Staking ist es zwar schnell, aber sein „automatisch“ braucht externe Rahmenbedingungen: Der/die Überwacher muss online und ehrlich sein, das Bitcoin-Netzwerk darf nicht überlastet sein, und die Slashing-Transaktion muss rechtzeitig bestätigt werden.
Natürlich heißt das keineswegs, dass die Ethereum-Lösung besser ist. Ein Community-Konsens entspricht in extremen Fällen fast einem Kettenstillstand, während die Cross-Chain-Verzögerung bei Bitcoin in den meisten Fällen akzeptabel ist. Aber die Zweiteilung „automatisch“ vs. „manuell“ vereinfacht das Ganze tatsächlich zu stark. Genauer wäre vielleicht: „wirksam unter den Bedingungen eines funktionierenden Cross-Chain-Automatik-Trigger-Mechanismus in Kombination mit einem funktionierenden Überwacher und einer funktionsfähigen Bitcoin-Netzwerkfunktion“. Diese Bedingung ist nicht zwingend tödlich, aber als Forscher halte ich es für notwendig, diese Grenze klar zu benennen. @BabylonLabs_io
Ich habe den Ausführungsweg für das Slashing noch einmal neu gezeichnet. Im Whitepaper, Abschnitt 9.2, steht: Bei Etherereums PoS ist für Slashing bei Sicherheitsverstößen ein Community-Konsens erforderlich, weil mehr als 1/3 böswilliger Validatoren die Slashing-Belege auf der Kette prüfen können. Dadurch muss ein Off-Chain-Koordinationsprozess durchlaufen werden, um die Chain neu zu starten. Beim Bitcoin-Staking liegt das eingesetzte Kapital hingegen auf der Bitcoin-Kette (aufgrund von $BABY ), sodass bei einem Verstoß „sofort ein automatisches Slashing“ erfolgt. Die eigentliche Frage ist jedoch: Wer ist dafür verantwortlich, die Slashing-Transaktion in die Bitcoin-Kette einzureichen? Wenn ein(e) Monitor/Überwacher eine einzelne Einheit oder eine begrenzte Menge an Akteuren ist—was passiert dann, wenn sie/er angegriffen wird oder offline geht? Und wenn das Bitcoin-Netzwerk gerade ausgelastet ist und die Slashing-Transaktion für ein paar Stunden im mempool hängt: Gilt dieses „automatisch“ dann immer noch?
Später habe ich in meinen Notizen formuliert: Das „automatische Slashing“ beim Bitcoin-Staking verlagert im Kern den Engpass der Lebendigkeit von „Koordination auf der gleichen Kette über den PoS-Chain-Konsens“ hin zu „Kombination aus Cross-Chain-Ausführungsverzögerung + Zuverlässigkeit des/der Überwachers + Reaktionsfähigkeit des Bitcoin-Netzwerks“. Der Community-Konsens in Ethereum (#baby ) ist zwar langsam und schmerzhaft, aber er ist protokollimmanent—selbst wenn mehr als 1/3 der Validatoren Schaden anrichten, gibt es für die Community immer einen Weg zu einer endgültigen Entscheidung. Beim Bitcoin-Staking ist es zwar schnell, aber sein „automatisch“ braucht externe Rahmenbedingungen: Der/die Überwacher muss online und ehrlich sein, das Bitcoin-Netzwerk darf nicht überlastet sein, und die Slashing-Transaktion muss rechtzeitig bestätigt werden.
Natürlich heißt das keineswegs, dass die Ethereum-Lösung besser ist. Ein Community-Konsens entspricht in extremen Fällen fast einem Kettenstillstand, während die Cross-Chain-Verzögerung bei Bitcoin in den meisten Fällen akzeptabel ist. Aber die Zweiteilung „automatisch“ vs. „manuell“ vereinfacht das Ganze tatsächlich zu stark. Genauer wäre vielleicht: „wirksam unter den Bedingungen eines funktionierenden Cross-Chain-Automatik-Trigger-Mechanismus in Kombination mit einem funktionierenden Überwacher und einer funktionsfähigen Bitcoin-Netzwerkfunktion“. Diese Bedingung ist nicht zwingend tödlich, aber als Forscher halte ich es für notwendig, diese Grenze klar zu benennen. @BabylonLabs_io