Effects of Vasil Hard Fork / Hydra evolution on stake pool operators

In June there will be the Vasil Hard Fork with improvements in scalabiltiy and TA Performance. Later on there will be further improvements along with Hydra, that will lead to in the end 100.000 or more TA / s.
This will be only be possible, if the current mechanism in block calculation, where one pool of 3000 is calculating a block and the other 2999 are idle, will change.

Is there a document where this aspect is documented or can anyone answer the question, what are the consequences for stake pool operators if Hydra is implemented:

  • What is the effect on reward calculation?
  • What are the effects on minimal hardware configuration?
  • Do SPO have to install additional software besides the node software?

I too am curious if there is an effect on SPOs. Does anyone know what provisions need to be taken?

I guess you have quite some misunderstanding when it comes to Vasil and Hydra. Let’s start with Vasil:

  • Before the hard fork SPOs are required to upgrade their node software to stay compatible with the protocol.
  • Nothing else changes when it comes down to rewards.
  • After the hardfork nodes will have higher cpu usage and network usage (because of the parallel execution of block validation and diffusion). Though it should not be dramatically more. Quad-core configurations should have no problems.
  • No additional software required.

Now how about Hydra:

  • SPOs are not required to participate in Hydra heads.
  • If they decide to participate in a specific head setup - then they should communicate with the organization or group handling the processing.
  • In order to run a hydra head you’ll need specific software (from the Hydra repo).
2 Likes

Oh, it may have taken a while, but the answer pretty much gets to the heart of the question - thanks for that.
On that note, yes, that means that with Vasil, increased CPU usage occurs due to diffusion pipelining, among other things - is this distributed equally in principle, or in proportion to the number of blocks? If the former, it would mean that the rewards for small SPO are in principle even slightly less reflective of the actual contribution to the network. So that’s just as an observation - I’m not complaining!
On Hydra:

  • Hydra will need an hardfork?
  • Is this hardfork scheduled yet?
  • Is the subject of the Hydra heads to be read up somewhere?
  • Is there any selection criteria to apply for a Hydra head or can basically anyone do it?

You can think of block diffusion a bit like a snowball effect. The minted block is picked up by the relays connected directly the block producer (of the pool in question) - and from there to the relays directly connected to the the pool’s relays and from there to the relays connected to those relays. A relay has usually 10-15 relays connected (pulling blocks). Until now every relay verifies the validity of the block it pulls and afterwards it is available for other relays for further diffusion. After Vasil, blocks can be pulled even before validation. The verification is then done in parallel or after transmission. Invalid blocks will be discarded.

TLDR: Nothing changes for SPOs because the way the block producing node is still determined the same way as before. Note that with the Ouroboros consensus protocol the performance of individual nodes is irrelevant when it comes down to the decision on which one actually mints a block.

1 Like

Hydra does not need a hardfork. There’s some information about Hydra available from IOG - but I don’t have a link at hand ATM. My knowledge comes from listening to Cardano360’s and mid-month Updates on Youtube and reading some Blogs from IOG.

Basically anyone (running a full node) can use it (after it’s release on mainnet) IMO. You can think of it as a temporary side-chain which eventually merges back to L1 chain. Performance of one Hydra head is much lower than the mentioned 100kTA/s and depends pretty much on the block diffusion performance of the participating nodes.

Hydra head is just the first implementation of a L2 chain on Cardano and I’m expecting further work from the Hydra development team to increase overall transaction performance with L2 solutions.

In parallel other teams develop or are designing zk-rollup L2 technology (independent from IOG) because in their opinion zk-tech is better than side-channels.

That’s what I like about Cardano: on one hand IOG is designing and implementing visionary technology and on the other hand other teams are inspired to do something completely different and are also successful (and supported).

Milkomeda is a good example to show my point.

1 Like