Need for this solution:
Every dApp on Cardano has use cases to make transactions with ADA or native assets.
Once a transaction is initiated it gets added to the mempool and from then there is a delay by which the transaction is on chain and gets added into a block accepted by the network. In such situations the dApp is waiting for an update on the transaction.
Common approaches used by dApps to get an update on transaction status are
-
Periodically query the blockchain with the transaction id to get the status.
-
Ask the end user to manually check the status of the transaction and perform some action on the dApp to initiate the query to the blockchain.
1. Both the approaches above are inefficient.
The first approach, thought it employs an automated process has the following disadvantages:
- The time for confirmation depends on various factors like network congestion and size of the transaction. By the time it's on chain a dApp might have already done multiple queries to the blockchain without any result. This is inefficient. Also, even when the tx is confirmed that dApp does not get an update till it does the next query.
- The dApp developer has to develop the component for polling the blockchain along with their dApp. This increases development and maintenance cost of the dApp.
The second approach avoids periodic query to the blockchain but it comes with the trade off of
- Bad user experience as the user needs to manually check transaction confirmation and perform actions on the dApp.
- Larger delays if the user is not able to wait till the tx is on chain. We have already seen an hour-long waiting period for ADA transactions when network congestion is at its peak. Further if the dApp performs a smart contract based transaction then waiting period can be longer due to queuing of transactions (eg: Swaps on DEXes) and larger transaction sizes (large tx may not fit into the current block).
2. Though there are different ways to query the blockchain, dApps usually use a third party service to save on integration costs and related code on the dApp side. If the dApp needs to switch to a different query service in future for considerations like performance or cost, additional development work might be needed on the dApp side.
This solution is to solve the above drawbacks.
How it works:
- DApps subscribe to this transaction monitoring service and configure properties for receiving real time push updates from the service.
- Registered dApps submit the transaction ids to the monitoring service over HTTP APIs.
- Once the tx status is updated on the blockchain the monitoring app publishes the message to the dApp that submitted the transaction.
- DApps and teams can create multiple communication channels with the monitoring service. They can choose their preferred set of querying services to be used for better resiliency.
Please see this diagramatic illustration also.
Benefits of this solution:
- Transaction monitoring as a service for dApps to use to get updates about their transaction. DApps avoid duplicated work of periodically querying the blockchain and save effort in writing their own code for it. This service will offer Webhook based communication so that the dApps can receive updates without having to initiate a query. The service reduces what can be a few weeks' work to just a few minutes for dApp dev teams. If you would like to read about webhooks, please read here: https://webhook.net/?gclid=Cj0KCQjwz7uRBhDRARIsAFqjuln4DfhVaVWM4fruSXls_mDOiZc8ZTyfNuNS29GviFE0lxlx5qS2dJEaAvAmEALw_wcB
- Aggregation and abstraction of blockchain query services (Blockfrost, Dandelion APIS from Gimbalabs etc) so that dApps can pick and choose services behind the scenes for accessing blockchain data and switch among such services without refactoring the dApp.
- Cost optimization for dApps by sharing paid services. Many blockchain query services offer paid plans when significant usage is involved. Abstracting the query will optimize cost for each dApp that requires paid plans by sharing costs across a larger pool of dApps.
- Better scalability through abstraction. New blockchain query services that may provide better cost and performance may arrive in the market and by delegating the integration mechanism to the monitoring service dApp developers can pick or switch services with just a configuration change.
We have highlighted savings through better time efficiency for tracking transactions enabled by proactive call back to the dAapp as well as better cost efficiency of dApp development by avoiding duplicated development work. There are 500+ projects being developed in Cardano today and will likely have thousands more especially once the scaling solutions are implemented. The time & cost savings that can be achieved as a whole for the ecosystem of dApp on Cardano with this solution is big.
Use cases:
Usable in all cases where a transaction is to be tracked by a dApp. In the case of marketplaces where users make purchases with ADA, the marketplace backend should ideally check that the transaction has been confirmed before issuing the purchase (NFT, native tokens or other items). DEXes can use this solution for more efficient transaction monitoring to improve their transaction pipelines. Similarly token faucets and other dApps can also make use of this service.
Design considerations:
- Best practices for large scale application platforms need to be followed in the design of this service. Modularising components will allow to compose and maintain different modules as well as integrations of third party query services.
- Horizontal scalability of throughput within dApps and across dApps will be ensured by adopting service oriented architecture. Deployment models will be akin to what’s used for micro services.
- We will choose a modern tech stack, widely adopted by the IT industry for implementation.
- For quality assurance each module will be unit tested with automated tests during the course of development. During the integration phase of modules end to end integration tests will be used for ensuring quality. Additionally, static code analysis wherever relevant will be employed.
Sustainability
- Hardware costs for a year have been factored into the budget.
- We will provide support and maintenance for the considerable future.
- If need for new functionalities is discovered funding through future Catalyst funds might be requested.
- A platform fee to sustain the running costs is expected only after a year or more after the service is launched and even then would be managed without charging dApps with small usage.
Future scope:
- Integration with new services that read data from the Cardano blockchain.
- Further cost optimization for dApps using this service by usage metric driven resource allocation for each dApp. This is useful but requires a larger effort to implement. We would like to keep such finer optimisations outside the scope for now to manage the delivery timeline.
- Enhance webhook based communication to allow dApps to define conditions in which notifications about transactions are to be sent.
The outcome of this project is to provide service to dApps for monitoring on chain status of transactions, improve time efficiency of dApp operation through proactive call backs, avoid duplicated development effort for dApps and reduce costs by pooling of resources across dApps.
We believe the outcome suits the intent of this ‘Developer Ecosystem’ challenge.
The guiding question of this challenge that this project aligns to is ‘What are enterprise dev managers looking for in order to be able to build out enterprise projects - either internal or commercial?’
The key metric of this challenge is to check whether it has made it easier for developers to build on top of Cardano? This project of ours, like many other good proposals, will do exactly that by helping achieve better productivity and costing for their dApp development on Cardano.
Health challenges like Covid can reduce availability of human resources and delay our delivery timeline.