Yeah, I now recall discussion about how one could pay on PUT, but in a delayed manner where the elders hold back the actual payment until the next section split. I can see how this would work well if you tie it in with Get audits and penalty for Get/audit failures.
Even with pay on PUT, a pool/buffer would be important/helpful imo for maintaining adequate resources in a smooth and stable fashion.
Before it would have ensured a loose coupling between PUTprice for clients and StoreReward for nodes at small timescales and could help maximize network growth. For example, the network charges as much as clients are willing to pay for puts, and pays as little as nodes are willing to accept before leaving, to maximize the rate of network growth in terms of rate of chunks stored and nodes joining. If puts arenāt coming in fast enough for max growth the PUTprice could be reduced relative to StoreReward. Likewise, if spare storage is dwindling the store reward could be increased relative to PUTprice. It gives you two levers to pul instead of one.
The new pay on put with holdback till section split may well have made the buffer redundant as happybeing mentioned⦠maybe the extra complexity isnāt worth it⦠Iām just not entirely convinced yet based on simple control theory.
This sounds violent, haha. So a stripped down version of QUIC or just closer to QUIC in its basic form with P2P like plugins? Just curious bc qp2p was a relief compared to maintaining Crust, which was cool in its own right.
Thanks! But I guess the original question remains, which was, as the update mentioned XorName and other related things were originally in sn_routing but recently moved to qp2p2, and Iām curious what motivated this move. For example did XorName etc being in routing cause any specific trouble? Or e.g. any github issue documenting this decision?
I am not sure what you are asking. qp2p is a network (quic) layer, routing is infrastructure and sn_node/client is the network at the upper layer. When you say things moved I am not clear. What we are doing is simplifying and clarifying what layer does what, and no more.
Is there some specific thing you are worried about?
Ah yes that is misleading. What this is saying is the mapping to xorname / Socketaddr is moved qp2p but already that is becoming generic. Xorname is almost everywhere, but the mapping of this moved. Sorry for the confusion, not really clear at all there.
No worries, just moving fast. qp2p will lose the connection pool and more soon and become a very (very) thin wrapper around quinn (quic). We had some optimisations there and those are wrong in a networking lib. Sometimes you can think you can optimise network connections, but 40 years of ietf work shows you cannot. We did a wee bit and paid the price. No more though.
As an exercise to me, I was trying to locate the commit, but couldnāt. Is it much trouble for you to point out where to read about this commit regarding the mapping?
No, I donāt have time for that, as you can imagine, but if you are looking to get that involved you should really take a peek at work in progress right now in qp2p and safe_network repos and jump in to help out.
Sure, I totally understand. And yes, I will try to get to know the work in progress better, and help out when I can. And for the commit in question, I saw it after some digging, here. Indeed, the change was preparing qp2p to be generic, namely XorName would be just one specific ConnId among possibly others, later, and it seems the corresponding change in safe_network is still ongoing and not merged to main yet.
Also interesting is that few people seem use price rises in stamps to buy low and save later.
A few years ago the UK prices of first and second class stamps were increased massively. This was widely publicised well in advance, people knew that on a specified date the prices would jump dramatically yet I know of nobody but myself who bought large quantities before the rise.