@map84 Do you think there is a coalition of stake pools that provide privileged access to a select group of insiders? And, they achieve this by controlling who has access to add transactions to their mempools, rather than allowing external relays to add transactions as the protocol is designed to work?
OK, so now I have a couple more questions:
- Are you instead suggesting that SPOs who participate in something like the Droperatorz coalition should be more highly considered by CF for delegation?
- Does the Droperatorz coalition of pools restrict their mempools from receiving transactions from other external Cardano relays?
Yes definitely. DEXs, Aggregators, Token Distribution platforms, batchers for all sorts of things most likely use these tactics and others to speed up their platforms. As more apps compete to propagate their txās you notice more in-connections to your relays.
Hi @adatainment ! Sorry if I missed it, but what is a deadline for applications. Thank you!
1). No, Iām suggesting the CF consider SPOs who participate in private relay peering networks as doing so can provide a deep layer of resiliency to the network.
2). Stake pools participating in the Droperatorz program run a single dedicated relay (w/ dedicated mempool) in parallel with the poolās regular relay cluster. The pools themselves are not restricted from seeing outside transactions as the pool is connected to n other public relays. The Droperatorz dedicated relay simply assists with rapid propagation and achieving FIFO at network level (fatty transactions were being propagated much slower; a phenomenon unknown to IO when we showed them; since been remedied since 8.0).
yep this is the idea
To my understanding inbound connections (being connected to) are what propagates a poolās blocks, whereas outbound connections propagate transactions.
While there might be some merit to running a private node in p2p only mode, Iām not sure how a private hidden relay could be discoverable via p2p (without being *exposed to outside world) to be even able to establish the inbound connections needed to propagate blocks.
Essentially every relay running in P2P mode is already participating in private relay peering networks. They are just using the P2P mechanism to choose the ābestā peers to connect with. The automated P2P selection mechanism works much better than the previous human initiated manual programming of known peer addresses.
Relays running in P2P mode can set up outgoing connections to external relays from a private LAN address behind a firewall and these connections can then be upgraded to duplex permitting traffic both ways. For example, here are the connection stats for one of my hidden relays on a private LAN:
Connections:
duplex: 19
incoming: 2
outgoing: 50
unidirn: 32
prunable: 1
This relay has set up 50 outgoing connections and 19 of these have been upgraded to duplex. The 19 duplex connections were initially set up as outbound connections and prior to the P2P mechanism, these connections would have only been able to pull blocks. However, using the P2P mechanism these connections were upgraded to duplex so that both ends can pull blocks and submit transactions. IE: This hidden relay, running in P2P mode, is not directly discoverable from outside but it can nevertheless establish bi-directional connections.
One advantage, or disadvantage, depending on what you are seeking to achieve, is that wallets, DEXs, and other dapps are unable to submit transactions to this hidden relay directly, because they are unable to establish inbound connections to it. But if a DEX submits a transaction to one of the peer relays it has a duplex connected with, then I understand that transaction will get propagated to it.
(The two incoming connections are from my internal block producer and a private LAN backup machine.)
What if second or 3d relay is not public, it will take 2 epochs if submitted now to be visible as public ? Do we have time for that ?
There have already been many good points and concerns brought up by previous commenters, so I will just add my overall thoughts here, as well as one very important question that has not yet been answered:
When is the deadline for form submissions @adatainment ?
I want to make a serious contribution to CIP 1694 before I submit, and that involves reading all 300+ threads in the CIP, which I am close to completing.
Iām sure many would like to know when the deadline for completing the form is so that they can make sure that they donāt miss participating.
My thoughts overall:
-
An extended staking duration will definitely help out SPOs, although 1 year is a very long time. Iād say that 6 months would be the sweet spot in a delegation strategy to be effective but still give opportunity to other deserving pool operators.
-
Choosing to support multi-pool operators in the CF delegation strategy is a decision that will continue to bring contention. This is mostly because effective K is currently being undermined by the ability to run multiple pools, and is around 250 instead of 500, so a large flaw in the staking system that has still yet to be fixed. This is majorly impacted by exchanges and very large pool groups, but is a concern if the CF shows public support for the action of centralization of Cardano with the delegation of their ADA.
Here is an up to date breakdown of Effective K:
https://docs.google.com/spreadsheets/d/1HTsIpcxikIMyGFbwz_96uMHMRaC5W6lacRTMncV67cY/edit?usp=sharing
I understand that there are developer pools out there that have greatly contributed and would deserve a CF delegation, but I think this would be better implemented in a different way that would receive much less pushback:
- Run another CF pool or two, and use the staking rewards from this to fund developers on Cardano. Developers could apply for support in a similar fashion, but receive payouts from the CF directly instead from rewards generated from the pool.
There has also been a surprising amount of unprofessionalism with this latest delegation strategy post:
-
The first form was immediately closed for submissions.
-
No deadline is set yet for the current submission form.
-
Some of the replies to comments in this thread were not appropriate from someone representing the CF.
Ultimately the ADA the CF owns is theirs to do with as they choose, but as a founding entity of Cardano and a very public organization that pulls great weight with their decisions, it is important to choose wisely how to use the influence they hold for the greater good of the overall health of the Cardano ecosystem.
I do appreciate the opportunity the CF gives to Cardano SPOs, as it is a form of support that simply would not exist without their efforts - I am very grateful for this.
You know security by obscurity is bad practice right?
Also having two public relays will mitigate the risk of your pool showing as offline in wallets and blocks explorers (or even worse not showing up in them for a while). Some regularly check them and if yourāre just doing maintenance on your only relayā¦ Next check might be some hrs or even a day laterā¦
Hello Gaia. Thank you for joining the discussion.
Iām happy to clarify:
(1) The form was not immediately closed. We are using a āvanityā redirect https://cardanofoundation.org/forms/delegation to the always current form and for some reason, it didnāt update this time. This is why I added the link to the new one in the description of the āthis form is closedā-text. I mentioned this fact when I first posted the link:
(2) The new form has no deadline. Itās for new pools coming up or doing something completely new. We have made this round based on data (=existing contributions) we already have.
(3) You are right; there was one reply that was not appropriate, and I apologized for it. There is no way I should have said that, but I did because the idea that someone inputs a query, āI donāt like this post, write me an answer,ā triggered me too much.
It is not bad practice as a second layer. Obviously it is not good enough without a first layer of proper security measures, but this is not in scope here. Calling it bad practice per se seems ignorant. In fact, it is good practice to only expose as little information as needed.
I fully agree with the second part of your reply and I consider these points very relevant. If I had to choose Iād rather obscure my systems though.
I donāt say private relays donāt have their function, but them being known or not shouldnāt impact their security. Keep in mind that there will be other peers that know your node and you have no influence what they do with that information. They might even register it themselves on chain!
Imho you should only consider a private relay if youāve already got at least two public ones.
@adatainment Do you even take this seriously??? Why in heavens name did you oversaturate a pool? Do you guys even look at the chosen pools?
This make the whole thing ridiculous!
That was, unfortunately, an oversight with AOS. We are already on it.
The delegation list is now available on:
Seems there is a second oversaturated pool (just as info).
While youāre at it, take a look at BERRY too.
Thanks for flagging.
CAG has literally a ZERO pledge, and a 4% margin - why on earth would you support someone that has no SKIN in the game, as defined by the Proof of Stake gods where Stake=SKIN??? this is outrageous as is the BERRY pool delegation (oversaturated him and more importantly he doesnāt need your bootstrapping). Can you please consider breaking these massive 30M chunks into smaller amounts and delegating to a wider audience of folks building in Cardano? Iāve been a huge defender of CF on so many occasions, but this is ridiculous what is being done to starve those of us single pool operators who know what we are doing, do it proven well (greater than 700 blocks in my case and greater than 105% Lifetime Luck as reported on adapools.org). Itās ludicrous the lack of vision you have. I respect your organization, but man oh man do you make it hard to be in your corner.