Leios miniprotocols for transaction processors?

[SupernaviX]

I'm curious what Leios miniprotocols will look like for software which processes transactions. I'm specifically thinking about tools like Kupo which index all onchain transactions; today they use chainsync+blockfetch to collect blocks, and assume that the cbor body of a block contains a complete set of unique+valid transactions for that block.

In Leios, EBs and IBs (which contain transactions) are gossiped between nodes and then included on-chain by reference. I think that there are some implications to this which make transaction processing harder:

• After a consumer uses blockfetch to grab a base protocol block, it also needs the EB which that block references, any EBs which that EB references recursively, and the IBs from each EB. There's essentially a tree structure DAG of resources required.
• A single base protocol block can indirectly reference the same transaction multiple times, or (if I understand correctly) two conflicting transactions. So not all transactions referenced by a block should actually be considered "on" chain.
• Stake pools gossip new IBs and EBs through the network as they get produced, and use FFD to prioritize fetching newer IBs. But for a transaction processor (or any node which wants older data from a producer), it's not clear to me what the network activity would look like. In particular, using FFD for IB bodies seems like the wrong behavior for a node trying to process "every transaction in order"; it'll prioritize fetching newly-created IBs (which may never even reach the chain) over an old on-chain IB which it needs to process next.

What will it look like to implement Kupo on top of Leios? Will transaction processing tooling, new relay nodes catching up with history, and block producers at the tip of the chain all use the same set of miniprotocols for IBs/EBs?

[Quantumplation]

The hypothesis is that the existing miniprotocols and provide a "view" of the chain that matches what currently happens: i.e. chainsync would return "blocks", with a list of applicable transactions, and the tooling built on top wouldn't need to change. Then, new miniprotocols, such as rb-sync, eb-sync, and ib-sync could expose the "real" details if someone wanted access to them.

That being said, I think this is a tall order, and might be a lot harder than it sounds in practice.

[SupernaviX]

I'm sure a "stream of groups of transactions + rollback events" would be great for kupo and friends.

But if catching up to the head of the chain requires complete IBs/EBs/RBs, then chainsync alone isn't enough, and that "TX stream" protocol isn't either. Would we need additional mini protocols for fetching on-chain IBs/EBs to support that?

[Quantumplation]

(this is effectively what TxPipe have been designing and implementing for dolos: https://utxorpc.org/; in my dreams, this is eventually adopted as a standard, instead of custom binary protocols that everyone has to reverse engineer and reimplement lol)

[dcoutts]

The low level node-to-client protocol was never intended to be something everone had to implement. It was intended just for middleware that translates into more friendly APIs and protocols for different use cases & languages. The problem was that writing that middleware was left as an exercise to the reader. Sigh.

[dcoutts]

That being said, I think this is a tall order, and might be a lot harder than it sounds in practice.

Doesn't sound that hard, and totally worth it so that all other middleware doesn't have to do it.

[Quantumplation]

@dcoutts you'd definitely know better than I, and I think it'd definitely be worth it! As someone who will be on the receiving end I'm just prone to a bit of pessimism 😅

[Saizan]

Do tools like Kupo assume they can trust the node they are getting data from or do they perform some amount of validation?

In the first case it doesn't seem necessary for them to have direct access to EBs and IBs, just the already-serialized list of Txs should actually be enough?

[Quantumplation]

Generally, indexers use the N2C protocols, and implicitly trust the data they're receiving beyond things like serialization invariants; There is value to a dApp developer or an indexer to being able to access the EBs and IBs, so it's not a question of that being "enough", but whether an "already serialized list of Txs" is possible to provide in a backwards compatible way.

Right now the chainsync protocols expose the raw bytes of the block; meaning, they won't include an already serialized list of Txs, they'll include the raw bytes of the block. My understanding is that, in Leios, that would be (something like) the block header, followed by a list of praos transactions, followed by an EB block (or reference) and evidence that it's met the voting threshold.

so we'd either need to make a "synthetic" block that is just a list of the already-serialized transactions that make it to the ledger, or create a new miniprotocol.

My guess is that we'd go with the latter, and that would require at least minimal updates to indexers to switch to this new miniprotocol. and those "minimal updates" tend to snowball downstream 😅 hence my lack of optimism about the impact to the dApp ecosystem.

[Saizan]

Indeed, indexers in general will still want access to the actual representation of the chain for beyond what's enough to reconstruct the ledger state. ChainSync is already polymorphic so that the node-to-client version provides block bodies and not just headers (like in the node-to-node version), seems like it would be amenable to be instantiated to provide the referenced EBs and IBs as well.

For clients that only care about the ledger-state (and its history) it seems like you could repurpose the node-to-node Tx-submission mini-protocol (currently used to diffuse txs in mempool) as a node-to-client instead. In the node-to-client instance it would produce the Txs from the blockchain rather than the mempool. I believe the exact protocol is being revised at the moment though.

The point about changes still stands, but if we can go with the above it should give something more concrete to evaluate impact.

[rkuhn]

One issue with changing the existing protocol to include all information implied by a Leios RB is that the whole point of the exercise is to dramatically increase the amount of data this entails. The protocols are all built around a notion of back pressure for resource control, which means that making the response messages larger breaks the resource assumptions made by older peers.

I still think that the safest option is to devise a new (mini)protocol for this purpose and perhaps include explicit resource commitments instead of counting messages so that we can later grow the protocol when needed.

[SupernaviX]

Another issue with repurposing tx-submission is that it has no way to report that a TX should be removed, so it couldn't handle rollbacks.

[dcoutts]

For clarity, we're talking here about the node to client protocol, not the node to node protocol (which will of course need to change for Leios).

My expectation is that it's totally possible and practical and a good idea to have a mode of the node to client protocol that emulates simple blocks of transactions. This would be a much easier target for most clients that just care about the ledger content and do not themselves need to validate the blocks or to know about block structures. This would be 99% of clients, including indexers. And it'd make the transition to Leios much easier.

As an extension, some special clients might want to know the full gory details of the Leios block structure and so want protocols appropriate for that (probably similar to the node to node case).