关于Corda NODE_NOTARY_COMMIT_LOG表记录逻辑及唯一性判定的技术咨询

Great question! Let’s break down how this table works, why you’re seeing duplicate TRANSACTION_ID entries, and how uniqueness is actually enforced here.

What is NODE_NOTARY_COMMIT_LOG used for? #

This table is a core component of Corda’s notary node infrastructure, designed to track two critical pieces of information:

• Records of transactions that have been successfully notarized and committed to the ledger.
• Details of how those committed transactions’ outputs are later consumed by subsequent transactions.

It’s essentially the notary’s source of truth for preventing double-spends and verifying the validity of incoming transaction requests.

Why duplicate TRANSACTION_ID entries exist #

The confusion comes from misinterpreting what TRANSACTION_ID represents here: it refers to the original notarized transaction whose outputs are being consumed, not the consuming transaction itself.

Let’s use a concrete example to explain your observation:
Suppose you have a transaction T1 that produces two outputs (Output 0 and Output 1). Later, another transaction T2 consumes both of these outputs as its own inputs (Input 0 and Input 1). In this case, the NODE_NOTARY_COMMIT_LOG will create two separate records:

• Record 1: TRANSACTION_ID=T1, CONSUMING_TRANSACTION_ID=T2, CONSUMING_INPUT_INDEX=0, OUTPUT_INDEX=1
• Record 2: TRANSACTION_ID=T1, CONSUMING_TRANSACTION_ID=T2, CONSUMING_INPUT_INDEX=1, OUTPUT_INDEX=0

The inverse relationship between CONSUMING_INPUT_INDEX and OUTPUT_INDEX is just a reflection of how the consuming transaction maps inputs to the original outputs—there’s no requirement for input order to match output order, so Corda tracks this mapping explicitly.

How uniqueness is determined in this table #

Uniqueness isn’t enforced by the TRANSACTION_ID field alone. Instead, the table uses a composite primary key made up of three fields together:

• TRANSACTION_ID: The ID of the original notarized transaction
• CONSUMING_TRANSACTION_ID: The ID of the transaction consuming the original’s outputs
• CONSUMING_INPUT_INDEX: The index of the input in the consuming transaction that references the original output

This combination guarantees no duplicate records: a single input in a consuming transaction can never reference multiple outputs from the same original transaction, so each trio of values is unique.

Quick recap #

Those "duplicate" TRANSACTION_ID entries aren’t errors—they’re intentional records tracking individual output consumption events for the same original transaction. The composite key ensures each entry represents a unique consumption event, which is critical for the notary to accurately verify transaction validity and prevent double-spends.

内容的提问来源于stack exchange，提问作者bartman250