Boros: Tx submission for intense workloads by TxPipe

[GENERAL] Name and surname of main applicant

Santiago Carmuega

[GENERAL] Are you delivering this project as an individual or as an entity (whether formally incorporated or not)

Entity (Incorporated)

[GENERAL] Please specify how many months you expect your project to last (from 2-12 months)

5

[GENERAL] Please indicate if your proposal has been auto-translated into English from another language

No

[GENERAL] Summarize your solution to the problem (200-character limit including spaces)

We will build a generic backend component that serves as a smart, massive mempool. It can be used by dApps directly out-of-the-box as a resilient and performant mechanism for tx submission.

[GENERAL] Does your project have any dependencies on other organizations, technical or otherwise?

No

[GENERAL] If YES, please describe what the dependency is and why you believe it is essential for your project’s delivery. If NO, please write “No dependencies.”

No dependencies.

[GENERAL] Will your project’s output/s be fully open source?

Yes

[GENERAL] Please provide here more information on the open source status of your project outputs

The project will be licensed using Apache 2.0 and will welcome external contributions.

[SOLUTION] Please describe your proposed solution

Submitting an isolated Cardano Tx is simple enough. Submitting a constant stream of transaction with a high-level of a assurance and performance is quite complex. We want to build a generic backend component that can be used by dApps that have intense submission workloads.

We're building a new infrastructure component called Boros, that can be used by dApp teams as a smart, massive pipeline for transaction submission. It will include the following features:

Resilience

• Persistent queues: Boros uses persistent message queues through pluggable backend technologies such as Kafka, Redis and Postgres; allowing dApps to fire-and-forget transaction without the risk of data loss.
• Tx Monitoring: an automated procedure will monitor submission, confirmation and rollbacks of transactions, updating in real-time the status of each.
• Retry Mechanism: Boros includes an automatic retry mechanism using configurable policies to handle confirmation timeouts or rollbacked transaction.

Throughput

• Peer Fanout: an outbound connection manager will connect to multiple peers simultaneously using node-to-node protocols to propagate transactions as efficient as possible.
• Configurable Topology: a static topology can be provided via configuration for scenarios where outbound relays are known in advance.
• Dynamic Topology: a dynamic topology can be constructed automatically using on-chain relay data from pool certificates or via p2p networking using the peer sharing mini-protocol.

Smart submission

• TX-Chaining: chaining is a mechanism to drastically improve throughput that involves careful management during the submission phase. Boros will be detect chained txs and maintain the required "session affinity" against the upstream peer.
• Priority Queues: Boros will have support for different priority queues with configurable policies, allowing high-priority txs to jump ahead of lower priority ones.
• Server-side Signatures: for dApps that require it, Boros will support server-side tx signatures by integrating battle tested key managers such as Hashicorp Vault.

Developer Experience

• Lightweight Process: Boros will be a very lightweight process with little resource footprint.
• No Dependencies: Boros will connect directly to peers using node-to-node miniprotocols. No Cardano node will be required to run Boros.
• Friendly API: Boros will support different API mechanism to queue transactions via three different alternative protocols: HTTP, WebSockets and gRPC.
• Notification WebHooks: Boros will have the option to configure webhooks to receive notifications for status change from the submission pipeline. Devs will be able to subscribe to events such as: Tx submitted, Tx confirmed, Tx rolled-back, Tx retry).

Observability

• Prometheus metrics: Boros will ship with Prometheus metrics, allowing operators to measure throughput, performance, health, peer status and more. We'll also include default Grafana dashboards that can be used out-of-the-box or customized.
• Management API: Boros provides an API that can be used to execute special management operation such as queue configuration, tx monitoring, tx removal, tx prioritization, etc.
• Detailed Logging: Boros outputs structured logs detailing the the different state transitions of txs in the queue, along with other relevant processing events. This logs can be used for debugging but also for future traceability of activities.

[IMPACT] Please define the positive impact your project will have on the wider Cardano community

The process of transaction submission is a generic concern shared by almost all Cardano dApps. By providing a reusable infrastructure component that solves the problem in a generic way, we allow dApps to offload this complexity and focus on core concerns for their particular use-case.

[CAPABILITY & FEASIBILITY] What is your capability to deliver your project with high levels of trust and accountability? How do you intend to validate if your approach is feasible?

TxPipe is an active member of the Cardano ecosystem

TxPipe has been developing open-source tools for the Cardano ecosystem for over 2 years and we're not going anywhere. Evidence of our commitment can be found by evaluating the continuous activity of our public code repositories.

Experience developing in the Cardano ecosystem

TxPipe has helped developed several dApps for the Cardano ecosystem. This experience allows us to evaluate the feasibility of the project and its potential benefit from a developer's perspective.

Successful Catalyst proposals

We have successfully completed several Catalyst proposals. This may serve as evidence that our team has the required capabilities to fulfill these type of projects.

Development process will be public and open-source

Both the output and the development process will be public and open-source. This approach provides an easy way for the Catalyst team and the Cardano community to evaluate the progress at each step of the process.

[PROJECT MILESTONES] What are the key milestones you need to achieve in order to complete your project successfully?

Scaffolding

Milestone outputs

• Publicly available source-code containing the project scaffold
• A stub of the fanout mechanism that includes the relevant API interface
• A stub of the monitoring mechanism that includes the relevant API interface
• A stub of the smart-submission mechanism that includes the relevant API interface

Acceptance criteria

• The interface for the fanout mechanism matches the feature requirements
• The interface for the monitoring mechanism matches the feature requirements
• The interface for the smart-submission mechanism matches the feature requirements

Evidence of milestone completion

• Source-code available in the Github repository

Fanout Mechanism

Milestone outputs

• publicly available source-code for the tx fanout mechanism
• documentation on how to configure the fanout mechanism
• report with benchmarks and integration test results

Acceptance criteria

• the fanout mechanism propagates transactions to peers successfully
• the fanout mechanism connect to multiple peers simultaneously using node-to-node protocols
• a static topology can be provided via configuration and it's honored by the fanout mechanism.
• a dynamic topology can be constructed automatically using on-chain relay data from pool certificates
• a dynamic topology can be constructed via p2p networking using the peer sharing mini-protocol.

Evidence of milestone completion

• Source-code available in the Github repository
• Documentation published at custom website
• Reports included as part of the Github repository

Persistence, Monitoring and Retry logic

Milestone outputs

• publicly available source-code for the persistence mechanism
• publicly available source-code for the monitoring mechanism
• publicly available source-code for the retry mechanism
• documentation on how to configure the new features
• report with benchmarks and integration test results

Acceptance criteria

• tx requests are successfully persisted in message queues for each of the available backends (Kafka, Redis, Postgres)
• transactions are lifecycle is monitored by the system and the status for each item is queryable in real-time.
• transactions which timeout or are rolled-back get retried according to the configured policy.

Evidence of milestone completion

• Source-code available in the Github repository
• Documentation published at custom website
• Reports included as part of the Github repository

Smart Submission Features

Milestone outputs

• publicly available source-code for the tx-chaining logic
• publicly available source-code for the priority queue logic
• publicly available source-code for the server-side signature mechanism
• documentation on how to configure the new features
• report with benchmarks and integration test results

Acceptance criteria

• the submission process maintains affinity of chained txs to the same upstream peer.
• different priority queues can be configured and the system prioritizes submission accordingly.
• flagged transactions are automatically signed by the system using a Hashicorp Vault service.

Evidence of milestone completion

• Source-code available in the Github repository
• Documentation published at custom website
• Reports included as part of the Github repository

Final report

Milestone outputs

• publicly available source-code of the complete system
• a video showcasing the final output of the project
• a final report describing the project process and outcome

Acceptance criteria

• the final system can be used as a backend for bulk transaction submission.
• the final video complies with Catalyst requirements.
• the final report complies with Catalyst requirements.

Evidence of milestone completion

• Source-code available in the Github repository
• Documentation published at custom website
• Final video uploaded to Google drive
• Final report uploaded to Google drive

[RESOURCES] Who is in the project team and what are their roles?

• Santiago Carmuega - TxPipe : Rust Developer /Tech Lead - Github
• Federico Weill - TxPipe : Project Manager - Linkedin
• Alejandro Avagnina - TxPipe : Site Reliability Engineer - Github
• Clark Alesna - TxPipe: Rust and Aiken Developer - Github
• Paulo Bressan - TxPipe: Rust Developer- Github
• Felipe Gonzalez - TxPipe: Rust Developer - Github

[BUDGET & COSTS] Please provide a cost breakdown of the proposed work and resources

FTE = Full-time equivalent

Total budget = ₳ 198,750

Software development

• Rust developer: 2 FTE x 4 months = ₳ 180,000
• Technical Writer: 1/2 FTE x 2.5 months = ₳ 9,375

Project Management

• Project Manager: 1/4 FTE x 5 months = ₳ 9375

[VALUE FOR MONEY] How does the cost of the project represent value for money for the Cardano ecosystem?

The bulk of the budget falls under the software development category. TxPipe has extensive experience in the field, allowing it to provide good value for money. The hourly rates are defined using fair market prices. The estimation for the level of effort takes into account all of the optimizations that our team is capable of providing after years of experience developing software solutions in the Cardano ecosystem.