Verlauf dieser Epoche
Jeder Punkt ist eine echte Messung an einem Node. Der Zustand des Schwarms lässt sich nicht nachträglich rekonstruieren — was nicht gemessen wurde, fehlt.
Akzeptierte Lösungen
Node-Status
Welcher Peer gerade abgefragt wurde, seine Latenz und wie viele Nachbarn antworten.
Verbindungsaufbau…
IP-Adresse
–
Latenz
–
TCP-Roundtrip zum Node
Node-Version
–
Peers
–
Peer-Verbindungen
Die Aufgabe
Gegen diese Parameter rechnet der Schwarm — dieselben für alle Nodes weltweit.
Eingangs-Trits
–
Sequenzlänge
–h
Kontextfenster
–h
Bew. Fenster
–
Schwelle (max. Fehler)
–
Freie ANN-Slots
–
Daten-Hash (byteweise Verifikation)
–
–
Zielverteilung — rein binär (0/1, kein „weiß nicht")
Ziel 0: –
Ziel 1: –
Unbekannt (Ziel): –
„Weiß nicht" (Trit 2) ist interner Netzwerkzustand, aber niemals Zielwert — Abweichung zählt schlicht als Fehler.
Revenue-Verteilung (näherungsweise bis Epochenende)
Direkt vom Node: drei Score-Dimensionen über alle 676 Computor-Slots. Mid-Epoch-Werte sind laut Core-Dokumentation näherungsweise — erst am Epochenende exakt.
Slots gesamt
–
TX nonzero
–
/ 676
Oracle nonzero
–
/ 676
Doge nonzero
–
/ 676
Top-10-Anteil
–
sehr gleichmäßig wenn < 5%
IPC
–
Verteilung der Slot-Summen (tx + oracle + doge) über alle 676 Slots
Jeder Balken repräsentiert einen Slot, sortiert nach Gesamtscore. Gleichmäßige Verteilung deutet auf gute Dezentralisierung hin.
Was diese Seite zeigt: direkt gemessene Fakten über die Mining-Maschinerie — Schwarmaktivität, Node-Zustand, Task-Profil, Revenue-Verteilung. Alles kommt live von einem Qubic-Node, nichts ist geschätzt oder erfunden.