completed
Batch tx generator for cardano-cli
Current Project Status
Complete
Amount
Received
$18,000
Amount
Requested
$18,000
Percentage
Received
100.00%
Solution

Develop an open source tool for cardano-cli which generates batched transactions that can send multiple native assets to multiple addresses.

Problem

Transactions for sending assets to many addresses will incur cumulative transaction fee unless batched together into one transaction.

Addresses Challenge
Feasibility
Auditability

Team

1 member

Batch tx generator for cardano-cli

Develop a batched transaction generator that generates signed transactions which can be directly submitted to the Cardano blockchain even when there are multiple assets and recipient addresses involved.

Batching transactions is a pertinent use case as it has a direct impact on transaction fees that are paid. At present teams devise their own approaches to batch transactions when using the cardano-cli. This project will create a well designed open source repository that can be used by teams for batching transactions easily by just configuration of properties.

We implemented a batched transaction (manually prepared) in testnet to observe the reduction in transaction fee. To test, we sent a native token to 150 different receive addresses in one transaction. The total transaction fees turned out to be just ~ 0.73 ADA whereas if the transactions were not batched, the total cost would have been 150 x ~0.17 = ~ 25.5 ADA.

Here is the test transaction on cardanoscan: <https://testnet.cardanoscan.io/transaction/af31b5852987d350a089684e6ccc9189c8a86b0014a88d3de296803bf988aa41>

A reduction in fees by 35 times as seen in the above example is why we think it is worth the effort to develop this into an open source solution.

Projects which employ batching of transactions today in their dApps and projects use their own approaches. There is a lack of scalable solutions which dApp developers can use out of the box. We will develop an open source repository with the code for this solution, a working example on testnet and video walkthrough for using the solution.

How the components of this solution will work:

  • The transaction generator (haskell component) will receive data from the data source integration service about receiving addresses as well as the native assets and their amounts that need to be transferred.
  • The generator will read the configuration properties and generate commands that perform a create a batched transaction, signs and submits it to the Cardano blockchain. The configuration among other parameters will include the signing keys for the address/wallet being used with the CLI.
  • Shell scripts will be used to orchestrate the various steps that need to occur sequentially.

A schematic diagram of the components can be found here.

Benefits of this open source solution

  • Teams do not have to invest time and effort in developing batching mechanisms when using cardano-cli.
  • Reduction in cost when transferring native assets to multiple addresses.
  • Configurability of data source will allow this code base to cater to various project teams and scenarios.
  • Automated approach to building batched transactions. It is possible to manually create batched transactions using the cardano-cli’s transaction build command. But the manual approach is not scalable and this provides a programmable way for creating batched txs.
  • Demonstration of this solution will highlight the advantage that Cardano EUTXO model has over other blockchains in terms of fees. Cardano's low tx fees is widely quoted. This solution of batching will allow development teams to readily harness it.

Use cases:

  • NFT drops : NFT drops require native assets to be sent to multiple addresses as part of the drop.
  • Token sales by companies : During various stages tokens purchased have to be distributed to multiple recipients.
  • Token faucets: Faucets depending on cardano-cli can make use of the repository.

Design considerations:

  1. The generator will be coded in Haskell to take advantage of Haskell’s type safety and immutability. These are significant as the accuracy of the correctness of the generated transaction depends on the accuracy of the generator code.
  2. The datasource integration module will be developed as a micro service decoupled from the tx generator itself. Adapter design pattern will be used for interfacing data sources in a plug and play model.
  3. Batch size that can be accommodated into a transaction (which is capped at 16KB today) depends on the type of asset that is being sent. So the batch size (besides other properties) should be a parameter that teams that use this solution can configure.

Configurability

  • The generator will be configuration driven so that users of the repository can set properties like maximum and minimum batch size, policy ids for exclusion and inclusion etc.
  • The datasource integration being designed as a micro service will allow modifications independent of the generator component. Additional data sources can be added in as plug and play.

Future scope:

Pipelining mechanisms for this system so that it can be interfaced into live applications through APIs. This is part of future scope as interfacing with application pipelines rather than using as a standalone repository requires extensive work.

As described in the challenge details, the OSDE challenge aims to promote open source projects, open-source frameworks, and accessible knowledge. This project aligns with the guiding questions by ensuring benefits for future teams from this work, by sharing our knowledge and work through an open source repository. This proposal is for developing a common tool.

This open source solution aligns with all the key metrics of this challenge by

  • adding to the number and the quality of Cardano Open Source projects
  • Increase the number of contributors by way of our team's contribution.
  • adding one more open source tool for the community to use.

Health challenges like Covid can reduce availability of human resources and delay our delivery timeline.

As described in the detailed solution, we have conducted tests for batching a cardano-cli based transaction and have observed the benefits of fee reduction. That test involved manual steps, used text based input and had less configurability. However with the concept proven, we are confident that we can package it into a configurable generator with a supporting service to integrate with data sources. The roadmap for implementing is below:

Roadmap

Month 1

  • System design and review for transaction generator and services for datasource
  • Prototype generator using Haskell
  • Prototype service or data source integration with a simple data source

Month 2

  • Extend data sourcing services to support various data sources in a plug and play model.
  • Integrate generator with data service
  • Add documentation
  • Add video walkthrough
  • Publish as open source repository with documentation

Extensibility

  • As explained above, the generator will be configuration driven. In future new configuration parameters can be added by corresponding extension of the code.
  • Service oriented architecture will support extension of supported data sources.

Budget

The costs incurred in this project are development costs.

  • 1 Tech architect for system design and review for 1 month ($5000 x 1) = $5000
  • 1 Haskell developer for 2 months ($4000 x 2) = $8000
  • 1 Backend developer part time for 2 months for data source integration service ($2500 x 2) = $5000

Total = $18000

We are a team of experienced Software Engineers/Plutus Pioneers/Gimbalabs PBL member/an ambassador in the Cardano ecosystem. Our team has delivered a in Fund 6, funded proposals in Fund 7. We have been building in Cardano for close to a year and have developed various open source repositories for Plutus/Cardano which can be found in our Github repo added in this proposal.

Notable development projects on Cardano that our team has been part of are:

  • Adatar.me ( <https://adatar.me/> ) funded through Catalyst in Fund 6
  • Unsigs NFT marketplace ( https://unsigs-frontend.vercel.app/ ) through Gimbalabs project based learning initiative.

Reshma Mohan

  • Professional Software Engineer
  • Plutus Pioneer (1st cohort)
  • Prism Pioneer (currently undergoing)
  • Bachelor of Technology degree in Electrical and Electronics Engineering
  • Ambassador to ‘Genius Yield’.
  • Proposer of multiple funded proposals in Fund 7.

LinkedIn: https://www.linkedin.com/in/reshmhn/

Twitter: https://twitter.com/reshmhn

Ganesh

  • Professional Software Engineer for over 8 years
  • Plutus & Prism Pioneer (1st cohorts)
  • Gimbalabs PPBL Team Member
  • Bachelor of Technology degree in Electronics Engineering
  • Has lead development of large scale applications
  • Experience in the financial services industry

Github: <https://github.com/gannith>

The components of this solution have been listed out in the previous sections. The development has been split into different milestones to be achieved over a period of two months as indicated in the roadmap.

The progress and development can be measured by tracking the milestone and tangibly verified since we are building an open source repository.

The following are our success metrics

Open source repository completely developed in 2 months.

In 1 month:

At least one team using the repository for batching transactions on testnet.

In 3 months:

At least one team using the repository for batching transactions on mainnet.

In 6 months:

Mutiple teams useing the repository for batching transactions on mainnet.

Other teams extending repository further or collaborating for enhancements.

KPIs

  • Number of projects using the codebase
  • Number of forks for the Github repository
  • Number of pull requests for the Github repository

This is a new proposal.

close

Playlist

  • EP2: epoch_length

    Authored by: Darlington Kofa

    3m 24s
    Darlington Kofa
  • EP1: 'd' parameter

    Authored by: Darlington Kofa

    4m 3s
    Darlington Kofa
  • EP3: key_deposit

    Authored by: Darlington Kofa

    3m 48s
    Darlington Kofa
  • EP4: epoch_no

    Authored by: Darlington Kofa

    2m 16s
    Darlington Kofa
  • EP5: max_block_size

    Authored by: Darlington Kofa

    3m 14s
    Darlington Kofa
  • EP6: pool_deposit

    Authored by: Darlington Kofa

    3m 19s
    Darlington Kofa
  • EP7: max_tx_size

    Authored by: Darlington Kofa

    4m 59s
    Darlington Kofa
0:00
/
~0:00