LocalTxMonitor

[KtorZ]

Describe your idea, in simple words.

Provide a mini-protocol for inspecting the cardano-node's mempool. In order to support this in Ogmios, the mini-protocol would need to be added in the upstream dependencies (i.e. ouroboros-network) for which there exists already some initial design idea, albeit abandoned: https://github.com/input-output-hk/ouroboros-network/blob/master/ouroboros-network/src/Ouroboros/Network/Protocol/LocalTxMonitor/Type.hs

It'll be nice to review also the mempool API provided by the consensus layer to see exactly what's available and what could be implemented in a protocol: https://github.com/input-output-hk/ouroboros-network/blob/f03523f2f49510cf881bdc986a7da977e65c106a/ouroboros-consensus/src/Ouroboros/Consensus/Mempool/API.hs

Why is it a good idea?

It's currently quite hard for clients to monitor their transaction after successful submission, either the transaction appears on the chain or ... it is in a schrödinger / unknown state. Transactions may be dropped from the mempool for various reasons, and in order to implement some efficient re-submission, a client would need to know whether it's the case or, whether a given transaction is still floating around in the mempool.

Are you willing to work on it yourself?

Yes.

[leobel]

Hi @KtorZ, This is a really nice feature, and an amazing project! Right now we're facing this tx "unknown status" after submitting it successfully. I've a question related to submitTx though, I just recently started using ogmios and notice that request to submitTx can take a long time to response back, more than 20sec. I've tried different setup such as interactionType: LognRunning and interactionType: OneTime both of which I don't find a fully description (eg. timeout). I'm trying to keep the same InteractionContext as much as possible

Are those response times normal or I'm missing something? Here is my code:

// Start: Ogmios service
 async connect(): Promise<void> {
        this.context = await createInteractionContext(
            err => {
                this.context = null;
                console.error('Connection error', err);
            },
            (code: number, reason: string) => {
                this.context = null;
                console.log(`Connection closed. Code: ${code}, Reason: ${reason}`);
            },
            { connection: { port: this.port }, interactionType: 'LongRunning' }
        );
    }

    async isConnected(): Promise<boolean> {
        return !!this.context && ((await getServerHealth({ connection: this.connection })) as any).connectionStatus == "connected";
    }
  // End: Ogmios service

  // calling submit tx
    async submit(cbor: string) {
           const isConnected = await this.ogmiosService.isConnected();
           console.log("Connected?:", isConnected)
            if (!isConnected) {
                console.log('Connecting to ws ...');
                await this.ogmiosService.connect();
            }
            await this.ogmiosService.submitTx(cbor);
     }

[KtorZ]

(side-note: this is probably not the right issue to discuss this, so if you want to continue the discussion after my answer, I'll be thankful if you can open a dedicated issue for that to continue :pray:)

The transaction submission protocol is a blocking protocol. So, if the node's local mempool is full, then submitting a transaction will block until there's room for a transaction to be inserted. This may take a while indeed but this is how back-pressure is applied from the node to clients.

One other thing I've observed over time is that, when the node is still syncing with the chain (as in, far from the tip), it dedicates most resources to that and queries from the local clients can take a lot longer.

[leobel]

Thanks you for the reply! I understand, in my case I was using a relay node, maybe since a relay is constantly processing tx I faced the delay in most tx submission.