TensorCash hereta sense canvis la interfície pub/sub ZMQ de Bitcoin Core. El publicador es vincula a una adreça (per defecte, tcp://127.0.0.1:28332); els subscriptors s'hi connecten i se subscriuen a prefixos de tema. Cada notificació és un missatge multipart de tres trames, i a continuació es detalla l'estructura del cos de cada tema.
5 temes · origen: inherit
Aquesta pàgina tracta el pub/sub heretat de Bitcoin Core. El canal de validació entre node i verificador és un flux ZMQ PUSH/PULL separat, les càrregues del qual fan servir els Esquemes FlatBuffer: proof.fbs, validation.fbs i blockheader.fbs.
Sobre de trames
Publisher binds; subscribers connect and SUBSCRIBE to topic prefixes. Topic strings are matched as byte prefixes — SUBSCRIBE "hash" receives both hashblock and hashtx.
Trama
Camp
Tipus
Descripció
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.
Temes
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.
Trama
Camp
Tipus
Descripció
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).
Trama
Camp
Tipus
Descripció
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.
Trama
Camp
Tipus
Descripció
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.
Trama
Camp
Tipus
Descripció
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.