TensorCash dziedziczy interfejs ZMQ pub/sub z Bitcoin Core bez zmian. Wydawca nasłuchuje (domyślnie na tcp://127.0.0.1:28332); subskrybenci łączą się i subskrybują prefiksy tematów. Każde powiadomienie to trzyramkowa wiadomość multipart, a układ treści dla każdego tematu znajdziesz poniżej.
Tematy: 5 · pochodzenie: inherit
Ta strona opisuje mechanizm pub/sub odziedziczony po Bitcoin Core. Kanał walidacji między węzłem a weryfikatorem to osobny strumień ZMQ PUSH/PULL, którego ładunki opisują Schematy FlatBuffer: proof.fbs, validation.fbs i blockheader.fbs.
Koperta ramek
Publisher binds; subscribers connect and SUBSCRIBE to topic prefixes. Topic strings are matched as byte prefixes — SUBSCRIBE "hash" receives both hashblock and hashtx.
Ramka
Pole
Typ
Opis
0
topic
utf-8 string
One of the topic names below.
1
body
per-topic
Defined by the topic. See frames[1] per topic.
2
sequence_counter
uint32 little-endian
Monotonically increasing per-topic counter. Subscribers detect dropped messages by checking for gaps. Resets on bcore restart.
Tematy
hashblock
-zmqpubhashblock=<address>
Best-block-tip changed (new block connected to the active chain).
A block is connected to the main chain. Fires once per UpdatedBlockTip callback.
Ramka
Pole
Typ
Opis
1
block_hash
32 bytes, little-endian (display-reversed)
The connecting block's hash. Note Bitcoin Core's display convention reverses byte order — the wire bytes are little-endian; tooling that prints hex usually reverses them for display.
Transaction entered the mempool or was confirmed in a block.
Fires for every TransactionAddedToMempool and BlockConnected event; may emit duplicates for the same hash if a tx is re-broadcast or re-mined after a reorg.
Same trigger as hashblock — but the body is the full block, not just its hash. Heavier; only enable if a subscriber actually needs full block bytes (e.g. an indexer that does not have its own bcore peer).
Ramka
Pole
Typ
Opis
1
block_serialized
variable-length bytes
The block, serialized using Bitcoin Core's standard block serialization (CBlock::Serialize). Includes the header, tx count (var_int), and all transactions in order.
Same trigger as hashtx — body is the full serialized transaction (CTransaction::Serialize). Subscribers can fully decode without round-tripping to JSON-RPC.
Ramka
Pole
Typ
Opis
1
tx_serialized
variable-length bytes
The transaction, serialized with Bitcoin Core's standard transaction serialization. Witness data included when present.
Block-connect, block-disconnect, mempool-accept, and mempool-remove events. The body's event byte tells subscribers which type. Useful for indexers that need a single ordered event stream rather than the separate hashblock/hashtx topics.
Ramka
Pole
Typ
Opis
1
hash + event_byte (+ optional mempool_seq)
32-byte hash || 1-byte event || optional 8-byte LE mempool_sequence
Body layout depends on the event: • 'C' (block connect) — hash || 'C' • 'D' (block disconnect) — hash || 'D' • 'A' (mempool accept) — hash || 'A' || mempool_sequence (uint64 LE) • 'R' (mempool remove) — hash || 'R' || mempool_sequence (uint64 LE) The 32-byte hash is little-endian on the wire (same convention as the hash topics). mempool_sequence is a separate per-mempool counter — distinct from the topic-level sequence_counter in frame 2.