Durchgehend einige großartige Anstrengungen – und dann von Platz 750 in die Top 100 zu kommen, war keine leichte Aufgabe. Es war ein Bekenntnis und Konsequenz in Richtung qualitativ hochwertiger Inhalte. Als ich damals auf Platz 750 war, war mein Kopf festgefahren, und ich habe einige falsche Eingaben in $BANK & $SKYAI gemacht, aber danach hat sich mein Kopf komplett in Richtung @BabylonLabs_io umgestellt.
Ich habe heute über Babylons Staking-Backend gelesen und bin dabei auf etwas gestoßen, womit ich ehrlich gesagt nicht gerechnet hatte.
Wie viel von dem, was wie On-Chain-Zustand aussieht, läuft tatsächlich zuerst durch Off-Chain-Infrastruktur, bevor du es jemals zu sehen bekommst.
Der Staking-Indexer – ein spezieller Dienst in Babylons Backend-Suite – synchronisiert Delegationsereignisse, Status der Finality Provider und globale Staking-Parameter aus sowohl Bitcoin als auch Babylon Genesis in seine eigene Datenbank. Das Frontend und der Staking-API-Dienst lesen beide aus diesem Indexer, nicht direkt aus irgendeiner der beiden Chains. Das hatte ich ehrlich gesagt nicht so auf dem Schirm, bis ich gesehen habe, wie es dort dargestellt ist.
Mein erster Eindruck war: Okay, das ist einfach eine Caching-Schicht für Geschwindigkeit. Praktisch, aber nicht tragend.
Nicht ganz. Wenn der Indexer beim Syncen hinterherhinkt, beginnt das, was ein Nutzer über sein eigenes Staking sieht, von dem abzuweichen, was tatsächlich on-chain wahr ist – ganz egal, dass sich auf keiner der beiden Chains etwas bewegt hat.
Das lässt mich trotzdem ein wenig zweifeln, wie leicht man das übersehen kann.
Die Chains bleiben die ganze Zeit korrekt. Es ist diese Übersetzungsschicht in der Mitte, die still und leise driften kann.
Ich weiß nicht, wie viele Indexer-Instanzen gerade parallel laufen, oder wie zentralisiert dieses Stück heute tatsächlich ist. Das wird in den allgemeinen Architektur-Dokumenten nicht aufgeschlüsselt, und ich werde auch nicht so tun, als hätte ich eine Zahl, die ich nicht habe.
Das erste Mal, dass ein Staker einen falschen Status sieht, weil der Indexer verzögert war – nicht weil sich sein Staking tatsächlich geändert hat –, verschiebt das dann, wie Menschen darüber nachdenken, was „on-chain“ im Alltag wirklich bedeutet?
Wem solltest du die Daten mehr vertrauen?
@BabylonLabs_io #baby $BABY
Ich habe heute über Babylons Staking-Backend gelesen und bin dabei auf etwas gestoßen, womit ich ehrlich gesagt nicht gerechnet hatte.
Wie viel von dem, was wie On-Chain-Zustand aussieht, läuft tatsächlich zuerst durch Off-Chain-Infrastruktur, bevor du es jemals zu sehen bekommst.
Der Staking-Indexer – ein spezieller Dienst in Babylons Backend-Suite – synchronisiert Delegationsereignisse, Status der Finality Provider und globale Staking-Parameter aus sowohl Bitcoin als auch Babylon Genesis in seine eigene Datenbank. Das Frontend und der Staking-API-Dienst lesen beide aus diesem Indexer, nicht direkt aus irgendeiner der beiden Chains. Das hatte ich ehrlich gesagt nicht so auf dem Schirm, bis ich gesehen habe, wie es dort dargestellt ist.
Mein erster Eindruck war: Okay, das ist einfach eine Caching-Schicht für Geschwindigkeit. Praktisch, aber nicht tragend.
Nicht ganz. Wenn der Indexer beim Syncen hinterherhinkt, beginnt das, was ein Nutzer über sein eigenes Staking sieht, von dem abzuweichen, was tatsächlich on-chain wahr ist – ganz egal, dass sich auf keiner der beiden Chains etwas bewegt hat.
Das lässt mich trotzdem ein wenig zweifeln, wie leicht man das übersehen kann.
Die Chains bleiben die ganze Zeit korrekt. Es ist diese Übersetzungsschicht in der Mitte, die still und leise driften kann.
Ich weiß nicht, wie viele Indexer-Instanzen gerade parallel laufen, oder wie zentralisiert dieses Stück heute tatsächlich ist. Das wird in den allgemeinen Architektur-Dokumenten nicht aufgeschlüsselt, und ich werde auch nicht so tun, als hätte ich eine Zahl, die ich nicht habe.
Das erste Mal, dass ein Staker einen falschen Status sieht, weil der Indexer verzögert war – nicht weil sich sein Staking tatsächlich geändert hat –, verschiebt das dann, wie Menschen darüber nachdenken, was „on-chain“ im Alltag wirklich bedeutet?
Wem solltest du die Daten mehr vertrauen?
@BabylonLabs_io #baby $BABY
Direct chain query
50%
Indexer/dashboard
25%
Both, equally
25%
Depends on timing
0%
4 Stimmen • Abstimmung beendet