Skip to content

Conversation

Chengxuan
Copy link
Contributor

@Chengxuan Chengxuan commented Sep 10, 2025

Exposing a method to allow confirmation map building using the in-memory canonical chain in the connector for efficient confirmation calculation of any given tx hash.

The new approach is similar to the existing confirmation manager, but with the following differences:

  1. No need to build a confirmation queue outside the block listener; the in-memory canonical chain in the block listener is reused for confirmation checking
  2. Supports confirmation requests that have different lengths

Additionally, there is a significant design difference when it comes to confirming a transaction that is inside a block no longer in the in-memory chain: the existing confirmation manager prioritizes confirmation details over confirmation latency and resource usage, whereas the new ReconcileConfirmationsForTransaction follows an instant confirmation approach.

More details in the firefly-evmconnect PR: hyperledger/firefly-evmconnect#174

A new confirmation map struct is introduced to capture all the potential confirmation queues (due to forking) of a single transaction hash. The confirmation map struct needs to be stored and passed back to the ReconcileConfirmationsForTransaction by the consumer in order to persist confirmation queues that are no longer on the latest canonical chain.

Signed-off-by: Chengxuan Xing <chengxuan.xing@kaleido.io>
@Chengxuan Chengxuan requested a review from a team as a code owner September 10, 2025 12:32
Signed-off-by: Chengxuan Xing <chengxuan.xing@kaleido.io>
@Chengxuan Chengxuan force-pushed the expose-reconcile-confirmation-map branch from 7bc7bb8 to 07127ff Compare September 10, 2025 15:33
Signed-off-by: Chengxuan Xing <chengxuan.xing@kaleido.io>
Signed-off-by: Chengxuan Xing <chengxuan.xing@kaleido.io>
@Chengxuan Chengxuan changed the title adding a new function for reconciling confirmations map adding a new function for reconciling confirmations map in the connector interface Sep 11, 2025
Signed-off-by: Chengxuan Xing <chengxuan.xing@kaleido.io>
Copy link
Contributor

@EnriqueL8 EnriqueL8 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few thoughts

// the key of the map is the hash of the first block (tx block) that contains the transaction hash
// the value of the map is an array of blocks, the first block is the tx block
// the rest of the blocks are blocks inside the range of the target confirmation count
// gap is allowed between the tx block and the second block
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this allowed?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldn't this just be an implementation detail from the connector?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could argue it's a connector implementation details. Will remove that from the comment

Signed-off-by: Chengxuan Xing <chengxuan.xing@kaleido.io>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants