Vom Autovoter zum Blockchain Data Warehouse – ein unerwartetes Curation-Rätsel

Hello World 👋

Eigentlich wollte ich nur einen besseren Autovoter für Steem bauen.

Inzwischen ist daraus ein kleines Data Warehouse für Blockchain-Curation-Daten geworden.

Der Grund ist einfach:

Die Blockchain speichert zwar jeden Vote, aber sie beantwortet nicht automatisch die Frage, die für bessere Curation wirklich interessant ist:

Warum bringt Vote A deutlich mehr Curation als Vote B?

Das ursprüngliche Ziel

Für VoteBroker wollte ich zunächst die erwartete Curation möglichst präzise berechnen.

Dafür erfasse ich inzwischen unter anderem:

• Vote Delay
• Pending Payout zum Vote-Zeitpunkt
• Voting Power vor dem Vote
• Vote Weight
• Strategie-Kategorie
• spätere reale Curation-Auszahlung

Aus diesen Daten entsteht Schritt für Schritt eine Art Fact Table für Voting-Entscheidungen.

Das erste Rätsel

Beim Vergleich mit SteemWorld fiel auf:

Meine Berechnung lag systematisch über den angezeigten Werten von SteemWorld.

Nach mehreren Tests konnten wir einen Teil der Abweichung erklären. Ein verwendeter Faktor war zu hoch angesetzt. Nach der Korrektur lagen die Ergebnisse deutlich näher an SteemWorld.

Aber eine kleinere Differenz blieb bestehen.

Das zweite Rätsel

Also haben wir die Berechnung auf einzelne Posts heruntergebrochen.

Dabei zeigte sich etwas Interessantes:

Zwei unterschiedliche Modelle liefern unterschiedliche Ergebnisse.

Modell A: Weight Share

Dabei wird der Anteil meines Vote-Gewichts am gesamten Vote-Gewicht des Posts betrachtet.

Modell B: Rshares Share

Dabei wird der Anteil meiner rshares an den gesamten rshares des Posts betrachtet.

Beide Ansätze sind nachvollziehbar.

Aber sie führen nicht immer zum gleichen Ergebnis.

Warum ist das spannend?

Gerade bei frühen Votes scheint die Sache nicht linear zu sein.

Ein Vote kann zum Zeitpunkt der Abgabe anders wirken als später zum Zeitpunkt der Auszahlung.

@Michelangelo3 hatte mich vor einiger Zeit bereits auf genau diesen Punkt hingewiesen:

Wenn man sehr früh votet, kann der aktuelle Vote-Wert deutlich vom späteren Auszahlungswert abweichen.

Und genau deshalb ist die Funktion Simulate Payout in SteemWorld so interessant.

Die eigentliche Frage

Vielleicht ist die entscheidende Frage nicht nur:

Wie viel ist mein Vote jetzt wert?

Sondern eher:

Welche Faktoren beeinflussen die spätere reale Curation tatsächlich?

Deshalb speichere ich inzwischen nicht nur aktuelle Schätzwerte, sondern auch spätere Outcomes.

So kann man verschiedene Modelle später gegen die Realität testen:

• Weight-basierte Schätzung
• Rshares-basierte Schätzung
• SteemWorld als externe Referenz
• tatsächlich realisierte Curation

Damit wird aus einer reinen Momentaufnahme langsam ein echtes Analysemodell.

Frage an die Steem-Dev-Community

Mich würde interessieren:

• Wie nähert ihr euch der Berechnung erwarteter Curation Rewards?
• Nutzt ihr eher Weight, rshares oder eine Kombination?
• Welche Rolle spielt die Reward Curve bei euren Schätzungen?
• Gibt es Details bei der Simulation offener Payouts, die leicht übersehen werden?
• Kennt jemand gute Referenzimplementierungen neben der Steem Developer Doku und beem?

Besonders spannend wäre natürlich, wie nah man mit öffentlich verfügbaren Chain-Daten an die Logik von SteemWorlds Simulate Payout herankommt.

Ich freue mich über jede technische Einschätzung von Entwicklern, Witnesses und allen, die sich schon tiefer mit rshares, Reward Pool und Curation beschäftigt haben.

Vielleicht können wir dieses kleine Curation-Rätsel gemeinsam sauber auflösen. 🚀

#steem #dev #blockchain #curation #rshares #data #analytics #steemworld