The problem
Submitting an isolated Cardano Tx is simple enough. However, submitting a constant stream of transactions with a high level of assurance and performance is a completely different ballgame.
As a dApp dev, you might relate to the following concerns:
- mempool back-pressure: I need to keep sending txs, but my node's mempool is full. What do I do?
- global distribution: Why are my txs sitting in the mempool for so long? Are my txs reaching enough block producers to ensure they get added in the next block?
- rollbacks: I just sent a bunch of txs. Are my txs making it on-chain? How many confirmations? Can I show my user a success message? Should I retry it? Is my tx still valid to retry?
- tx chaining: I want to use tx-chaining, where do I keep my queue of txs? how can I recover if the sequence gets broken?
... and the list goes on.
These are common problems shared by almost all Cardano dApps. We see the same development effort repeated over and over again by different teams in the Cardano ecosystem.
Enter Boros
We want to build an open-source, reusable infrastructure component that solves the problem in a generic way.
We want to allow dApps developers to offload the complexity of submitting transactions and focus on core concerns for their particular use-case.
We call this tool Boros, and it can be used by dApp teams as a smart, massive pipeline for transaction submission.
Feature #1: Persistent Queues
- Boros will use persistent message queues through pluggable backend technologies such as Kafka, Redis, and Postgres; allowing dApps to fire-and-forget transactions without the risk of data loss
Feature #2: Smart Delivery
- Block Monitoring: An automated procedure will monitor minted blocks, 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.
- 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, etc.
Feature #3: Broad Distribution
- 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.
Feature #4: Priority Queues
- Priority Queues: Boros will have support for different priority queues with configurable policies, allowing high-priority txs to jump ahead of lower priority ones.
Feature #5: Tx-Chaining
- TX-Chaining: chaining is a mechanism to drastically improve throughput that involves careful management during the submission phase. Boros will detect chained txs and maintain the required "session affinity" against the upstream peer.
Feature #6: Server-side Signatures
- dApps that require server-side signatures can use Boros for automatic signing of tx as part of the submit pipeline.
- Boros will be integrated with battle-tested key managers such as Hashicorp Vault.
- Private keys will never leave the key manager, Boros sends the raw tx to the key manager and gets the signed tx back.
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 mini-protocols. 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.
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.
Getting Started
Boros is still in early stages of development, we're aiming to have an initial release by Q4 2024. Watch out our Github account for release notifications:
