Jimmy 1st

Granny Smith Apple, 100% original
Regelmäßiger Trader
4.9 Jahre
66 Following
1.0K+ Follower
826 Like gegeben
Beiträge
·
--
#sxt Immer wenn ein Projekt seine Geschwindigkeit in einer einzigen Zahl zusammenfasst, frage ich gern, was diese Zahl auslässt. Space and Time stellt überprüfbare Daten für DeFi bereit, und als Beleg wird am häufigsten angeführt, dass die Zero-Knowledge-Beweise in weniger als einer Sekunde eintreffen. Bevor ich das akzeptiere, möchte ich genau wissen, was die Uhr misst. Denken wir an einen Flug, der fünfundfünfzig Minuten dauert. Niemand nennt die ganze Reise fünfundfünfzig Minuten, denn Reisende zählen die Zeit vom Verlassen des Hauses bis zum Verlassen der Ankunftshalle. Bei Space and Time ist die Proof-Generierung in Proof of SQL der Flug. Davor muss die Abfrage anhand festgeschriebener Daten ausgeführt werden. Danach muss der Beweis geprüft werden und das Ergebnis über die SXT Chain einen Smart Contract erreichen. Diese Schritte sind die Fahrt zum Flughafen, die Sicherheitskontrolle und die Warteschlange für das Taxi. Das ist in DeFi wichtiger als anderswo. Eine Liquidation oder ein Rebalancing reagiert auf einen Markt, der sich mit jedem Block verändert. Eine verspätete Antwort von Space and Time ist also in Wirklichkeit eine Antwort auf eine ältere Frage. Ein schneller Flug hilft nur, wenn auch der Rest der Reise kurz ist. Außerdem stellt sich die Frage, welche Reise gemessen wurde. Eine einfache Abfrage und eine Aggregation über Monate an Handelsdaten sind zwei völlig unterschiedliche Reisen, und Risikomodelle benötigen normalerweise die zweite Art. Wenn eine Geschwindigkeitsangabe für Space and Time ohne Angabe des Abfragetyps und der Datengröße erscheint, kann ich nicht erkennen, welche Reise sie beschreibt. Meine Einschätzung ist also einfach: Die Aussage ist für den Flug zutreffend und sagt nichts über die Gesamtdauer von Tür zu Tür aus. Als Benchmark funktioniert sie. Als Versprechen an DeFi-Entwickler braucht sie mehr. Vertrauen würde ich einer Ende-zu-Ende-Angabe von Space and Time, die den Zeitraum von der Anfrage bis zu einem Ergebnis misst, das ein Contract verwenden kann – für eine konkret benannte Abfrage auf einem konkret benannten Datensatz. Auch die Aktivität auf der SXT Chain kann zeigen, wie lange kostenpflichtige Abfragen tatsächlich dauern. Bis dahin lese ich die Zahl als reine Flugzeit. $SXT @SpaceandTimeDB \u003c\u003e
#sxt Immer wenn ein Projekt seine Geschwindigkeit in einer einzigen Zahl zusammenfasst, frage ich gern, was diese Zahl auslässt. Space and Time stellt überprüfbare Daten für DeFi bereit, und als Beleg wird am häufigsten angeführt, dass die Zero-Knowledge-Beweise in weniger als einer Sekunde eintreffen. Bevor ich das akzeptiere, möchte ich genau wissen, was die Uhr misst.

Denken wir an einen Flug, der fünfundfünfzig Minuten dauert. Niemand nennt die ganze Reise fünfundfünfzig Minuten, denn Reisende zählen die Zeit vom Verlassen des Hauses bis zum Verlassen der Ankunftshalle. Bei Space and Time ist die Proof-Generierung in Proof of SQL der Flug. Davor muss die Abfrage anhand festgeschriebener Daten ausgeführt werden. Danach muss der Beweis geprüft werden und das Ergebnis über die SXT Chain einen Smart Contract erreichen. Diese Schritte sind die Fahrt zum Flughafen, die Sicherheitskontrolle und die Warteschlange für das Taxi.

Das ist in DeFi wichtiger als anderswo. Eine Liquidation oder ein Rebalancing reagiert auf einen Markt, der sich mit jedem Block verändert. Eine verspätete Antwort von Space and Time ist also in Wirklichkeit eine Antwort auf eine ältere Frage. Ein schneller Flug hilft nur, wenn auch der Rest der Reise kurz ist.

Außerdem stellt sich die Frage, welche Reise gemessen wurde. Eine einfache Abfrage und eine Aggregation über Monate an Handelsdaten sind zwei völlig unterschiedliche Reisen, und Risikomodelle benötigen normalerweise die zweite Art. Wenn eine Geschwindigkeitsangabe für Space and Time ohne Angabe des Abfragetyps und der Datengröße erscheint, kann ich nicht erkennen, welche Reise sie beschreibt.

Meine Einschätzung ist also einfach: Die Aussage ist für den Flug zutreffend und sagt nichts über die Gesamtdauer von Tür zu Tür aus. Als Benchmark funktioniert sie. Als Versprechen an DeFi-Entwickler braucht sie mehr.

Vertrauen würde ich einer Ende-zu-Ende-Angabe von Space and Time, die den Zeitraum von der Anfrage bis zu einem Ergebnis misst, das ein Contract verwenden kann – für eine konkret benannte Abfrage auf einem konkret benannten Datensatz. Auch die Aktivität auf der SXT Chain kann zeigen, wie lange kostenpflichtige Abfragen tatsächlich dauern. Bis dahin lese ich die Zahl als reine Flugzeit.
$SXT @SpaceandTime \u003c\u003e
BILIUS-2,15%
Übersetzung ansehen
BILIUS-2,15%
Übersetzung ansehen
Übersetzung ansehen
Übersetzung ansehen
Übersetzung ansehen
·
--
Als ich zum ersten Mal las, wie Kite Identität strukturiert, ertappte ich mich bei der Frage: „Warum dieser ganze Aufwand, nur um etwas zu bezahlen?“ Die Autorität ist auf drei Ebenen verteilt. Der Nutzer hält den Root-Schlüssel, der Agent erhält delegierte Autorität, und jede Sitzung läuft mit einem temporären Schlüssel. Die einfachste Einrichtung für Agentenzahlungen lässt all das weg: Man gibt dem Agenten eine Wallet und lässt ihn damit bezahlen. Wenn Autonomie das Ziel ist, scheint ein Design mit weniger Ebenen naheliegend. Gemessen an den Fähigkeiten ist es das auch. Aber ich glaube nicht, dass Kite um Fähigkeiten konkurriert. Worauf es den Preis ansetzt, ist der Schadensradius. Das Urteilsvermögen eines Agenten ist das Einzige, wofür niemand garantieren kann. Modelle driften ab, Prompts werden manipuliert, ein Tool liefert etwas Merkwürdiges zurück und der Agent handelt danach. Die Fähigkeiten verbessern sich ständig, und trotzdem treten weiterhin Fehler auf. Für einen Agenten, der Geld verwaltet, ist also nicht entscheidend, wie viel er tun kann. Entscheidend ist, wie viel Schaden er an seinem schlimmsten Tag anrichten kann. So betrachtet erfüllt die Autoritätskette eine andere Aufgabe. Der Agent kommt nie mit dem Root-Schlüssel in Berührung. Eine Sitzung verfügt nie über die volle Autorität des Agenten. Das Design hält einen Sicherheitsvorfall auf der Ebene, auf der er aufgetreten ist, und Passport setzt zusätzlich Ausgabenlimits durch. Der schlimmste Fall ist dann keine Überraschung mehr, sondern eine Zahl, die jemand festgelegt hat. Deshalb verstehe ich Kite als eine Möglichkeit, Fehler zu begrenzen, statt sie zu verhindern. Es gibt allerdings einen Haken, und genau darüber grüble ich immer wieder. Ein kleiner Schadensradius schützt nur vor dem, was die Limits verbieten. Wird ein Agent dazu gebracht, sein Budget zu überschreiten, und bezahlt er bei einem Händler, bei dem er bezahlen darf, besteht er jede Prüfung. Der Schlüssel blieb sicher. Das Geld ist trotzdem weg. Der Radius ist also eine Einstellung, keine Garantie, und solche Einstellungen werden großzügiger, wenn Menschen es bequem haben wollen. Entscheidend wäre für mich, wie streng Kites Voreinstellungen sind und wie viele Nutzer sie lockern. Wenn die meisten das tun, schützen die drei Ebenen die Schlüssel. Wenn die meisten es nicht tun, schützen sie das Geld. Was werden Kites Nutzer am Ende haben? #KiteBBW $KITE 😇
Als ich zum ersten Mal las, wie Kite Identität strukturiert, ertappte ich mich bei der Frage: „Warum dieser ganze Aufwand, nur um etwas zu bezahlen?“

Die Autorität ist auf drei Ebenen verteilt. Der Nutzer hält den Root-Schlüssel, der Agent erhält delegierte Autorität, und jede Sitzung läuft mit einem temporären Schlüssel. Die einfachste Einrichtung für Agentenzahlungen lässt all das weg: Man gibt dem Agenten eine Wallet und lässt ihn damit bezahlen. Wenn Autonomie das Ziel ist, scheint ein Design mit weniger Ebenen naheliegend. Gemessen an den Fähigkeiten ist es das auch.

Aber ich glaube nicht, dass Kite um Fähigkeiten konkurriert. Worauf es den Preis ansetzt, ist der Schadensradius.

Das Urteilsvermögen eines Agenten ist das Einzige, wofür niemand garantieren kann. Modelle driften ab, Prompts werden manipuliert, ein Tool liefert etwas Merkwürdiges zurück und der Agent handelt danach. Die Fähigkeiten verbessern sich ständig, und trotzdem treten weiterhin Fehler auf. Für einen Agenten, der Geld verwaltet, ist also nicht entscheidend, wie viel er tun kann. Entscheidend ist, wie viel Schaden er an seinem schlimmsten Tag anrichten kann.

So betrachtet erfüllt die Autoritätskette eine andere Aufgabe. Der Agent kommt nie mit dem Root-Schlüssel in Berührung. Eine Sitzung verfügt nie über die volle Autorität des Agenten. Das Design hält einen Sicherheitsvorfall auf der Ebene, auf der er aufgetreten ist, und Passport setzt zusätzlich Ausgabenlimits durch. Der schlimmste Fall ist dann keine Überraschung mehr, sondern eine Zahl, die jemand festgelegt hat.

Deshalb verstehe ich Kite als eine Möglichkeit, Fehler zu begrenzen, statt sie zu verhindern.
Es gibt allerdings einen Haken, und genau darüber grüble ich immer wieder. Ein kleiner Schadensradius schützt nur vor dem, was die Limits verbieten. Wird ein Agent dazu gebracht, sein Budget zu überschreiten, und bezahlt er bei einem Händler, bei dem er bezahlen darf, besteht er jede Prüfung. Der Schlüssel blieb sicher. Das Geld ist trotzdem weg.

Der Radius ist also eine Einstellung, keine Garantie, und solche Einstellungen werden großzügiger, wenn Menschen es bequem haben wollen. Entscheidend wäre für mich, wie streng Kites Voreinstellungen sind und wie viele Nutzer sie lockern.

Wenn die meisten das tun, schützen die drei Ebenen die Schlüssel. Wenn die meisten es nicht tun, schützen sie das Geld. Was werden Kites Nutzer am Ende haben?

#KiteBBW $KITE 😇
Anmelden und weiter Inhalte entdecken
Krypto-Nutzer weltweit auf Binance Square kennenlernen
⚡️ Bleib in Sachen Krypto stets am Puls.
💬 Die weltgrößte Kryptobörse vertraut darauf.
👍 Erhalte verlässliche Einblicke von verifizierten Creators.
E-Mail-Adresse/Telefonnummer
Sitemap
Cookie-Präferenzen
Nutzungsbedingungen der Plattform