In this post, we provide an overview of an enhancement to Amazon Managed Blockchain (AMB) Query which enables you to retrieve data on a public blockchain prior to finalization. AMB Query is a fully managed AWS service that provides high quality blockchain data delivered with sub-second latency to applications via uniform APIs across a number of public blockchains. We begin this post by providing a brief overview of AMB Query and transaction finality, then we show a typical use case for this functionality, and finally describe how to use the new enhanced feature.

Benefits of AMB Query

With AMB Query, you can query an entire blockchain for a wide range of data, such as contract meta information, token balances, transaction details, and transaction events. High-quality data responses are returned with sub-second latency using a unified blockchain-agnostic API. This query capability provides rapid insights into the blockchain state, going back to each blockchain’s ‘genesis’ block, which can provide a significant advantage for blockchain applications that would otherwise be dependent on the availability of a full archive node for each specific blockchain you wish to support. Archive nodes require non-trivial infrastructure, compute, and storage, which can add significant cost and complexity to a blockchain application architecture. A blockchain data query capability provided as a fully managed AWS service can therefore enable significant functional and cost benefits for applications that require data from multiple blockchains.

What is “Transaction finality” in public blockchains

Blockchains rely on consensus protocols to ensure a reliable and up-to-date record of data. These protocols help achieve agreement among users about the validity of data without needing a central authority, and are designed to thwart any changes, malicious or otherwise, to data after being included in a block. Finality refers to the point at which a transaction submitted to a blockchain is widely accepted as irreversible and immutable. This differs from confirmation, which simply refers to the inclusion of a given transaction and any resulting state data in a block.

The time taken for a transaction submitted to a public blockchain to reach finality is dependent on a number of factors; such as the degree of congestion on the network, the amount of transaction fee paid, and the type of consensus mechanism used by the network, all of which impact how long a user may have to wait before the transaction can be regarded as final.

It’s important to note that public blockchains such as Bitcoin and Ethereum can’t offer complete certainty of finality due to their nature, and so the term is an indication that the transaction can be considered immutable. This degree of immutability is a result of the fact that reversal of a finalized transaction would typically require an infeasible amount of resource or a highly unusual governance action.

Practical considerations of transaction finality

The time taken for a transaction to reach finality in a public blockchain such as Bitcoin or Ethereum varies considerably. For Bitcoin, the widely accepted point at which a transaction is considered final occurs at 6 confirmations, which equates to approximately 1 hour depending on network conditions. In contrast, Ethereum reaches finality typically after 2 epochs, equating to around 64 slots each containing one block, or approximately 15 minutes. During the period between the on-chain confirmation of the transaction and its finality, the transaction status remains in a pending or non-final state. This lack of clarity in transaction status during this pending phase can pose challenges in business scenarios, especially in financial services involving value transfers. The prolonged uncertainty of whether a transaction can be regarded as final can create confusion and ambiguity for end-users.

It’s worth noting that the practical and generalized definition of finality adopted by Bitcoin and Ethereum may not be appropriate to all use cases. For use cases that need to define finality in a more esoteric way at the application level, returning both finalized and non-finalized transactions enables applications to apply a definition that is more meaningful for the application’s use case.

Typical use case of transaction finalized and non-finalized status

Consider a typical digital asset custody use case scenario. In this use case a digital asset custodian is responsible for managing assets linked to a specific wallet account on a blockchain network. When an organization initiates a transfer of assets to their chosen custodian, both parties must wait until the transaction is finalized and their wallet balances are updated accordingly before assuming the transaction is complete. Until that point, the custodian needs to regularly check the blockchain to discover new incoming transactions. As soon as a transaction is finalized on the blockchain (which might take up to 60 minutes on the Bitcoin blockchain, for example), the custodian should promptly acknowledge to the sending organization that the transfer is underway, even if the transaction has not yet finalized. Subsequently, the custodian should continue to monitor the blockchain for any updates on the status of the transaction and keep the sending organization informed until the transaction is completely finalized. This approach guarantees both transparency and security in the handling of digital asset transactions.

Using AMB Query to retrieve transaction finality status

The AMB Query APIs have now been enhanced to provide both finalized and non-finalized transaction data. The enhancements have been made to enable minimal code changes to an application using AMB Query. This provides clarity on the transaction status and enables finer grained monitoring over the transaction lifecycle, such as that required by the use case we discussed. Prior to this enhancement, only transactions that had reached finality were available.

The following table indicates how specific APIs have been enhanced.

The new functionality only affects the APIs listed in the preceeding table. Other APIs, such as those APIs retrieving token balance and contract data, are unchanged.

Using the enhanced AMB Query APIs

You can use the Amazon Managed Blockchain Query Editor via the Amazon Managed Blockchain console to access the enhanced APIs and get started with ongoing testing and experimentation.

In the following example, we call the ListTransactions API, with the Confirmation Status field set to include ‘NONFINAL”. At the time of running the query, the response for this specific query included both FINAL and NONFINAL transactions, as shown in the response list.

We can copy the transaction hash of any of the results and use the GetTransaction API to retrieve the full details of the transaction, using this transaction hash as input. In the following example, we call the GetTransaction API, passing this specific transaction hash. The response shows the full transaction detail, including the current confirmation status.

The API enhancements described in this post are also now available via the AWS SDKs.

Conclusion

In this post, we described the new enhancements launched for AMB Query, outlined a typical business use case, and demonstrated how to access the enhancements.

If you would like more information about Amazon Managed Blockchain, AMB Query, AMB Access, or wish to discuss blockchain on AWS in general, please reach out to the AWS blockchain team at blockchain-gtm@amazon.com.

About the Authors

AJ Park is a product manager on the Amazon Managed Blockchain team at AWS and is passionate about building blockchain and Web3 solutions for customers. Prior to that, AJ was innovating in the data protection and storage space for over 20 years as a software developer and a product manager.

Steven Bacci is a Principal Specialist Solution Architect within the Worldwide Specialist Blockchain/Web3 team at AWS. He works closely with the product and engineering team for Amazon Managed Blockchain, and advises global customers on business case alignment, technical architectural designs, and application engineering for blockchain and Web3 solutions. Steven’s background is in financial services and capital markets software engineering and architecture.