Am frühen Donnerstagmorgen kauerte ich neben den Gärtanks der Craft-Beer-Werkstatt und half einem Kumpel bei einer Cross-Border-Abrechnung dabei, für @NewtonProtocol eine „konforme Geldkassette“ aufzusetzen. In den Dokumenten stand „out of the box“, aber schon um eine einzelne Rego-Kombination aus „Whitelist + Limit“ zum Laufen zu bringen, hat mich eine ganze Nacht gekostet.
Rego ist eigentlich für Unternehmens-IT gedacht, um Cloud-Ressourcenrichtlinien zu schreiben: deklarativ, standardmäßig deny und dann jede allow-Zeile einzeln. #Newt hat es aufs Chain gehoben als Autorisierungs-Kern—mit der Begründung, es sei besser zu schreiben als Solidity und flexibler. Aber welche Kosten verursacht diese Flexibilität? Ich habe versucht, eine Regel zu schreiben, die gleichzeitig Identität, Limit, Risiko des Gegenparts und den Preis der Sicherheiten bewertet: vier Bedingungen, ineinander verschachtelt—und das Modul ist sofort zu einem Spinnennetz aus gegenseitigen Imports aufgebläht. Ändere ein Limit, und du musst drei Ebenen im Import-Chain hochscrollen. Ich habe meine eigenen Regeln selbst nicht einmal vollständig durchgerechnet. Wenn ich einen Bug entdecke: Wende ich mich an den Operator? An den Strategieautor? Oder an das Newton-Team, das nur Versprechen verkauft?
Und dann dieses „sekundenschnell“-Märchen. Man verpackt die Absicht in eine Aufgabe, wirft sie an die Operatoren, die bei EigenLayer restake machen. Jede:r läuft Rego, erzeugt Beweise, macht BLS-Aggregationssignaturen, und am Ende wird alles zurück on-chain übermittelt. Klingt sexy—aber wenn man die Doku durchliest, findet man keine Stresstest-Daten. Je komplexer die Strategie, desto länger braucht ein einzelner Operator für die Bewertung; je mehr Operatoren, desto unberechenbarer wird die Verzögerung beim Synchronisieren der Signaturen. Sind „sekundenschnell“-Angaben im Dokument für Experimente im Labor gedacht, oder ist das in realen komplexen Strategien der Normalfall?
Der Streit- bzw. Dispute-Window macht mir besonders zu schaffen. Wenn ein Operator falsch liegt, musst du erst abwarten, bis die Challenge-Periode vorbei ist und jemand einen Fraud-Proof einreicht, um wieder zu korrigieren. Ist das nicht „zuerst ausführen, später bereinigen“? Dein Geld wird vorher schon transferiert, und die Gelder hängen dann in der Schwebe. Nennt man das Risikokontrolle? Oder soll der Nutzer als bezahlter Freiwilliger einspringen?
Und Datenschutz—auch da wird’s skurril. $NEWT preist TEE + ZK als Schutz für Privatsphäre. Aber in der Strategie kommen Identitätsprüfung, Risikoscoring und KYC-Status allesamt von externen Drittanbieter-APIs. Je flexibler die Strategie, desto weniger kann der Normalmensch sie prüfen—und am Ende musst du doch wieder demjenigen vertrauen, der dir die Bewertung gibt. Privatsphäre schützt dann in Wahrheit gar nichts: Der Vertrauensanker wird nur vom On-chain in eine Off-chain Blackbox verschoben.
Ich schließe mein Handy. Die Niedertemperatur im Gärtank lässt meine Finger kribbeln. Schon wieder jemand, der Komplexität in eine einfache Story packt—nur dass auf dem Papier eine Goldfolie mit den TEE- und ZKP-Logos prangt. $BTC $ETH
Rego ist eigentlich für Unternehmens-IT gedacht, um Cloud-Ressourcenrichtlinien zu schreiben: deklarativ, standardmäßig deny und dann jede allow-Zeile einzeln. #Newt hat es aufs Chain gehoben als Autorisierungs-Kern—mit der Begründung, es sei besser zu schreiben als Solidity und flexibler. Aber welche Kosten verursacht diese Flexibilität? Ich habe versucht, eine Regel zu schreiben, die gleichzeitig Identität, Limit, Risiko des Gegenparts und den Preis der Sicherheiten bewertet: vier Bedingungen, ineinander verschachtelt—und das Modul ist sofort zu einem Spinnennetz aus gegenseitigen Imports aufgebläht. Ändere ein Limit, und du musst drei Ebenen im Import-Chain hochscrollen. Ich habe meine eigenen Regeln selbst nicht einmal vollständig durchgerechnet. Wenn ich einen Bug entdecke: Wende ich mich an den Operator? An den Strategieautor? Oder an das Newton-Team, das nur Versprechen verkauft?
Und dann dieses „sekundenschnell“-Märchen. Man verpackt die Absicht in eine Aufgabe, wirft sie an die Operatoren, die bei EigenLayer restake machen. Jede:r läuft Rego, erzeugt Beweise, macht BLS-Aggregationssignaturen, und am Ende wird alles zurück on-chain übermittelt. Klingt sexy—aber wenn man die Doku durchliest, findet man keine Stresstest-Daten. Je komplexer die Strategie, desto länger braucht ein einzelner Operator für die Bewertung; je mehr Operatoren, desto unberechenbarer wird die Verzögerung beim Synchronisieren der Signaturen. Sind „sekundenschnell“-Angaben im Dokument für Experimente im Labor gedacht, oder ist das in realen komplexen Strategien der Normalfall?
Der Streit- bzw. Dispute-Window macht mir besonders zu schaffen. Wenn ein Operator falsch liegt, musst du erst abwarten, bis die Challenge-Periode vorbei ist und jemand einen Fraud-Proof einreicht, um wieder zu korrigieren. Ist das nicht „zuerst ausführen, später bereinigen“? Dein Geld wird vorher schon transferiert, und die Gelder hängen dann in der Schwebe. Nennt man das Risikokontrolle? Oder soll der Nutzer als bezahlter Freiwilliger einspringen?
Und Datenschutz—auch da wird’s skurril. $NEWT preist TEE + ZK als Schutz für Privatsphäre. Aber in der Strategie kommen Identitätsprüfung, Risikoscoring und KYC-Status allesamt von externen Drittanbieter-APIs. Je flexibler die Strategie, desto weniger kann der Normalmensch sie prüfen—und am Ende musst du doch wieder demjenigen vertrauen, der dir die Bewertung gibt. Privatsphäre schützt dann in Wahrheit gar nichts: Der Vertrauensanker wird nur vom On-chain in eine Off-chain Blackbox verschoben.
Ich schließe mein Handy. Die Niedertemperatur im Gärtank lässt meine Finger kribbeln. Schon wieder jemand, der Komplexität in eine einfache Story packt—nur dass auf dem Papier eine Goldfolie mit den TEE- und ZKP-Logos prangt. $BTC $ETH