Transactions Monitoring on Ethereum

When a transaction is made on a Blockchain, the network must validate it before recognizing it as legitimate. Determining the appropriate number of validations needed to ensure the immutability of a transaction can be challenging, as this may vary from one Blockchain to another. Leveraging this information in the context of application development presents technical challenges that we will detail here.

Contexte

A blockchain is composed of a sequence of x blocks, numbered over the range [0;+inf[

Each of these blocks contains y transactions, numbered over the range [0;+inf[

Each of these transactions contains z logs, numbered over the range [0;+inf[

A block is emitted every n seconds and contains y number of transactions. Each of these transactions corresponds to an interaction on the EVM Blockchain. In essence, a transaction is a reflection of a state change. Smart contracts communicate with external systems through events ; as soon as an event is emitted, it is stored in the transaction. Therefore, a transaction comprises z number of events (also referred to as logs).

-- Bloc (x)
   -- Transaction (y)
      -- Log (z)

the unique transaction identifier on the canonical chain is : x,y
the unique log identifier on the canonical chain is : x,y,z

Chain Reorganization

A chain reorganization occurs when two blocks are published simultaneously. Reorganizations of 1 to 15 blocks often happen due to network latency and/or poor synchronization of validators. This increases transaction delays and can lead to the cancellation of some transactions. This poses a significant issue, as waiting for too many confirmations would result in poor user experience, but conversely, considering a block secure too soon could lead to user fund loss.

For various reasons, it happens that some blocks are invalidated afterwards. The main chain splits into two (fork), and the two blocks numbered x coexist in parallel. General consensus must then decide which of these two blocks will be retained to continue the chained list. This is how the canonical chain is defined. The most effective way to ensure the validity of a block (in terms of its persistence) is to count the number of blocks existing in front of it (number of confirmations). Depending on the Blockchain and consensus mechanisms used, this value can change. For example, on BSC (Binance Smart Chain), 5 blocks of confirmations seem sufficiently robust, while on Polygon, 15 blocks are necessary.

Thus, in the case of a fork, there will be two blocks responding to the key: x,y,z — one from the canonical chain and one from the secondary chain.

The blockhash is the SHA256 hash of all the information stored in the block ; in case of a fork, the two blocks with the same number x will have different blockhash.

The txid is the SHA256 hash of all the information stored in the transaction. It is likely that after a fork, the two blocks with the same number x will not contain the same transactions. However, if some transactions are present in both blocks, they would have the same txid.

Data Capture and Update Strategy

Identifying duplicate transactions due to chain reorganization, as well as managing the latency time between the transaction’s publication and its validation by the network, are critical aspects to consider, especially in the context of application development.

Managing Pending Transactions

Handling transactions on the Blockchain is a challenge for applications seeking to balance responsiveness and reliability. Initially, it is vital to mark these transactions as “pending.” Only after reaching the required threshold of confirmations can they be reclassified as “confirmed” and deemed reliable.

In cases where a rapid response from the application is necessary, it’s feasible to begin processing pending transactions. However, these processes must be designed to be reversible or conditional, considering the potential risk of these transactions being canceled. It is crucial to develop strategies that allow for the cancellation or modification of actions taken based on transactions that might later be annulled.

Managing Duplicate Transactions (Reorgs)

Continuous monitoring is essential for tracking transactions that have been processed, allowing for a quick response in the event of a chain reorganization. It’s possible to monitor each transaction from its appearance in the initial block, by associating each transaction with its block identifier (blockhash) and transaction identifier (txid). In the case of a chain reorganization, the system can identify a change in the blockhash for a specific block number, thus signaling the possibility of a duplicated transaction.

If such a duplicate transaction is identified, it’s essential to determine which version of the transaction belongs to the main chain, or canonical chain. Any transaction that is not part of the canonical chain should be considered invalid and excluded from the application’s processing.

Conclusion

By adopting a strategic approach that balances responsiveness and security, and employing suitable tracking and validation tools, developers can build robust applications that fully leverage the unique advantages of blockchain technology.