Supplementary to CIP 45 - Hardware Deterrence

Hi everyone,

I am the author of CIP-45 which attempts to solve the Cardano decentralization issue. It had just been reviewed and was found to suffer from pool splitting, i.e., it encourages entities to create multiple pools. This weakness is not unique to CIP-45. In fact, the more popular CIP-50 suffers from the same.

It dawned on me that any attempt to solve decentralization will have pool splitting to contend with. In my opinion, the pool splitting problem arises from the fact that Cardano requires only an IP address for pool registration. Why is that a problem? We’ll, a single node can create an unlimited number of IP addresses (hence unlimited number of pools) without incurring any penalty at all (read here). To me, this is the weakest link towards decentralization.

A potential solution to this problem is to require that 1 IP address is associated to only 1 MAC address. This will not completely prevent pool splitting because an operator can use virtual machines, but it will severely limit the pool splitting behavior. A sample calculation I made for a PC with:

  • 64 cores (highest count to date)
  • 256 GB RAM (8 slots, 32 GB per slot)
  • 100% CPU core allocation
  • 100% memory allocation

can accommodate 20 of 12 GB (pool RAM requirement) virtual machines only which I calculated using this website. The question is if it is practical to increase RAM requirement, say 24, 32, 64, or maybe even 128? How would you do it? What are the technical challenges/disadvantages?

Under CIP-45 at ~3000 total number of pools, an entity with 2.8B ADA would need to set up 282 pools if the entity wants to keep all 2.8B delegation. At 10,000 total number of pools, the same entity needs to set up 800+ pools, otherwise, those delegations will move elsewhere. 800+ pools or even 282 pools can be very expensive especially if the RAM requirement is 128 GB.

The good thing about RAM is that it has very low energy usage. So, it is a viable hardware deterrent. Any thoughts you may want to share? Thanks!

You might want to read:

Convincing the community (or the powers that be) that we should switch to (or at least amend with) a consensus method that is wasting resources again (although not quite such a harmful resource as energy) does not seem very promising to me.

We want to and we are doing proof of stake, here. Stake should be the deciding factor and the art will be to find a way that it does not really matter if people are running one or 50 pools.

My impression was that CIP 50 wanted to achieve exactly that, even allowing what are now multi pools to consolidate into larger single pools again by making pledge more relevant. So, I am a little surprised that you say that pool splitting is a problem for CIP 50. Do you have the argument for that?

1 Like

I’m sorry I am not knowledgeable enough of CIP-50. It was mentioned to me by one of the CIP editors that CIP-50 is dealing with the same problem. Thanks for the link!

To be precise, I said that CIP 50 is “dealing with that problem” in that it’s intended to address the problem… rather than being afflicted by it. :sunglasses:

I see. That is more precise now :sunglasses: Given that it is very challenging to impose a hardware deterrence, I think CIP-45 is moot and academic. But I left a comment for you in my CIP document.

1 Like

BTW, it was KtorZ.

Referring forum users to the general discussion back here (which is in turn linked to the original version of the presented CIP and should be linked to any future iterations of this idea):