<p>Let me try to answer your questions, although it's very dependent on the actual use case on what structure for off-chain processing of these &quot;tens of thousands transactions per second&quot; would make sense.</p>
<blockquote>
<p>For hydra-pay on the main chain, is the limitation of how many
transactions you can handle per second for your users dependent on how
many Hydra nodes you are running or what? What kind of infrastructure would &gt; be needed for this? From my understanding, one solution for this use case is &gt; opening up a Hydra head for every user during the time they are transacting.</p>
</blockquote>
<p><a href="https://github.com/obsidiansystems/hydra-pay" rel="nofollow noreferrer">hydra-pay</a> is a tool that makes pairwise payment channels based on Hydra Heads easy to create and use. As you are bringing it up, I assume you have a use case where users want to process their transactions with a single other party, e.g. another user or your service.</p>
<p>Infrastructure: In such a pairwise setting, you would have two <code>hydra-node</code>s running, one for each participant. For highest security, users would have their own <code>hydra-node</code> running on their end, e.g. wrapped up in a client-side application. When using <code>hydra-pay</code> though, nodes are run in a &quot;hosted&quot; way. That is, secrets would stay on the client-side (not yet, future feature), while the actual operation would stay with the service operator of <code>hydra-pay</code>.</p>
<p>Scalability: Now the capability of how many transactions can be processed depends on the performance of the machines running the <code>hydra-node</code>s, their bandwidth, the latency between them <strong>and</strong> also of your users' machines which at the very least need to sign transactions - unless you are keeping the keys of your users (which would make the use-case custodial).</p>
<blockquote>
<p>For a Cardano sidechain, what are the limitations for how many transactions &gt; you can settle per second? Is it just based on the consensus algorithm?</p>
</blockquote>
<p>For the mainchain, for a sidechain, for a Hydra Head.. for any decentralized network the limit on scalabality is a consequence of how decentralized (number of nodes, their latency &amp; bandwidth, minimum system requirements) and how secure a network is (redundant communication, consensus algorithms, cryptographic complexity). It is also important how big and complex the transactions you care about are. All of these influence how long it takes a transaction to be processed &amp; finalized by the network and in consequence how many transactions you can settle per second.</p>

CC BY-SA 4.0
2023-01-17T19:21:17.923Z
Thank you for the prompt response Sebastian, this has greatly improved my understanding. I have a few follow up questions. 

Could you please give further detail about 'For highest security, users would have their own hydra-node running on their end, e.g. wrapped up in a client-side application' ?

Also, for the current implementation of hydra and hydra-pay, is it possible to run it as an L2 for a Cardano sidechain?
Myles
CC BY-SA 4.0
2023-01-17T19:30:50.080Z
And could you please describe the secrets that will stay on the client-side? I assume that the 'actual operations' that would stay with the service operator (server-side) you're referring to are Hydra Head operations like Initializing the head, Committing transactions in the head, Closing the head, etc. Does this sound correct?
Myles
CC BY-SA 4.0
2023-01-20T22:12:57.203Z
The answer to all of these questions is: yes. You seem to have understood the protocol quite well already! The secrets which ideally stay on the client side are: 1) the payment credential for spending the UTxOs on the L2, and 2) the hydra signing key used to sign snapshots of the L2 UTxOs. The latter is not possible to keep outside of the hydra-node as of today, but we plan on supporting client side signing of snapshots eventually.
Sebastian Nagel
CC BY-SA 4.0
2023-01-17T08:08:32.777Z
2023-01-17T08:08:32.777Z
Sebastian Nagel
<p>I have an idea for a dapp that needs to settle tens of thousands of transactions per second and there's a grey area in my knowledge when it comes to understanding the limitations of hydra-pay on the main chain and Cardano sidechains</p>
<p>For hydra-pay on the main chain, is the limitation of how many transactions you can handle per second for your users dependent on how many Hydra nodes you are running or what? What kind of infrastructure would be needed for this? From my understanding, one solution for this use case is opening up a Hydra head for every user during the time they are transacting.</p>
<p>For a Cardano sidechain, what are the limitations for how many transactions you can settle per second? Is it just based on the consensus algorithm?</p>

<hydra><sidechains>
Speed of Hydra on the main chain vs a Cardano sidechain
# Speed of Hydra on the main chain vs a Cardano sidechain

(Asked by: username_0 on 2023-01-17)

I have an idea for a dapp that needs to settle tens of thousands of transactions per second and there's a grey area in my knowledge when it comes to understanding the limitations of hydra-pay on the main chain and Cardano sidechains

For hydra-pay on the main chain, is the limitation of how many transactions you can handle per second for your users dependent on how many Hydra nodes you are running or what? What kind of infrastructure would be needed for this? From my understanding, one solution for this use case is opening up a Hydra head for every user during the time they are transacting.

For a Cardano sidechain, what are the limitations for how many transactions you can settle per second? Is it just based on the consensus algorithm?

**Tags:** hydra, sidechains

---

## 1 answers

### Answer by username_1 on 2023-01-17. Score: 3

Let me try to answer your questions, although it's very dependent on the actual use case on what structure for off-chain processing of these "tens of thousands transactions per second" would make sense.

> For hydra-pay on the main chain, is the limitation of how many
> transactions you can handle per second for your users dependent on how
> many Hydra nodes you are running or what? What kind of infrastructure would > be needed for this? From my understanding, one solution for this use case is > opening up a Hydra head for every user during the time they are transacting.

[hydra-pay](https://github.com/obsidiansystems/hydra-pay) is a tool that makes pairwise payment channels based on Hydra Heads easy to create and use. As you are bringing it up, I assume you have a use case where users want to process their transactions with a single other party, e.g. another user or your service.

Infrastructure: In such a pairwise setting, you would have two `hydra-node`s running, one for each participant. For highest security, users would have their own `hydra-node` running on their end, e.g. wrapped up in a client-side application. When using `hydra-pay` though, nodes are run in a "hosted" way. That is, secrets would stay on the client-side (not yet, future feature), while the actual operation would stay with the service operator of `hydra-pay`.

Scalability: Now the capability of how many transactions can be processed depends on the performance of the machines running the `hydra-node`s, their bandwidth, the latency between them **and** also of your users' machines which at the very least need to sign transactions - unless you are keeping the keys of your users (which would make the use-case custodial).

> For a Cardano sidechain, what are the limitations for how many transactions > you can settle per second? Is it just based on the consensus algorithm?

For the mainchain, for a sidechain, for a Hydra Head.. for any decentralized network the limit on scalabality is a consequence of how decentralized (number of nodes, their latency & bandwidth, minimum system requirements) and how secure a network is (redundant communication, consensus algorithms, cryptographic complexity). It is also important how big and complex the transactions you care about are. All of these influence how long it takes a transaction to be processed & finalized by the network and in consequence how many transactions you can settle per second.

> **Comments:**
> **username_0**: Thank you for the prompt response Sebastian, this has greatly improved my understanding. I have a few follow up questions.   Could you please give further detail about 'For highest security, users would have their own hydra-node running on their end, e.g. wrapped up in a client-side application' ?  Also, for the current implementation of hydra and hydra-pay, is it possible to run it as an L2 for a Cardano sidechain?  
> **username_0**: And could you please describe the secrets that will stay on the client-side? I assume that the 'actual operations' that would stay with the service operator (server-side) you're referring to are Hydra Head operations like Initializing the head, Committing transactions in the head, Closing the head, etc. Does this sound correct?  
> **username_1**: The answer to all of these questions is: yes. You seem to have understood the protocol quite well already! The secrets which ideally stay on the client side are: 1) the payment credential for spending the UTxOs on the L2, and 2) the hydra signing key used to sign snapshots of the L2 UTxOs. The latter is not possible to keep outside of the hydra-node as of today, but we plan on supporting client side signing of snapshots eventually.  

---

