RFC 57: Safecoin Revised

Development RFCs
58

This post was a lot longer but I found a lot of stuff answered itself as I wrote it. At the risk of stating the obvious, this is a very detailed and nuanced rfc!

From Unresolved questions:

“we currently require payment for the creation of a new CoinBalance instance, whereas here the vault would need to create one without being able to pay for its creation.”

Some options

  • Elders pay for it. Elders already have both higher income and higher costs. It’s a tiny amount of extra work/cost to pay for a new wallet for the new vault as part of the overall burden of a new vault joining. Could be baked in that if the new vault CoinBalance already exists then the elders credit it for being a well prepared citizen.

  • Have the ‘from’ field be the aggregate section bls key which is accepted even though it has no balance. The check for valid creation becomes a two-stage test a) ‘from’ is able to pay or b) ‘from’ is a section.

  • Have elders act as an escrow, and when the new vault has earned enough to pay for CoinBalance creation the elders create it. This may involve having an actual CoinBalance for the aggregate section bls key. In this way Elders act as a ‘farming pool’ for very young vaults, aggregating funds like a bitcoin mining pool. But the purpose of the pool is not to reduce variation in rewards, more to ensure a correct sequence of operations in the vault setup phase.

I think the second option is simplest. Would be interested to hear more ideas.

In the Safecoin Transfer section, how is uuid for a CoinTransfer.Credit.transaction_id determined?

In the Account creation section, it seems most of text belongs in an Account Structure’ RFC. These details seem to have no impact on safecoin or farming. I think some mention of this data structure is useful to add context to CoinBalance but the details don’t seem to belong here. Probably the first two sentences of this section is all that’s needed, and also “any updates are free of charge.”

A minor point for sure, but the document is pretty large and any way to reduce cognitive burden is a win.

A question to ponder about the StoreCost algorithm…

Should the network measure “full vaults” or “spare space” and what’s the difference?

On one hand, full vaults is really what needs be avoided, but on the other hand spare space is the metric with the best resolution for allowing it to be avoided. Full Vault is post-problem, Spare Space is pre-problem.

Another question…

Should StoreCost for a network of 10 sections with 1 full vault each be the same or different to a network of 10,000 sections with 1 full vault each?

On one hand the portion of full vaults is the same for both networks, but on the other hand the larger network has a thousand times more spare space than the smaller one.

With overall 2 × UploadCost reward, it could be that vaults would want to upload data to their section to get more rewards. If every vault did this it might pay for itself but it becomes a prisoners dilemma problem. Just touching this to see if it tickles anyone.

Could be a maximum reward scenario when one vault is not full and all others are (maybe only briefly? maybe all only 1 chunk over-capacity?). This would mean nearly 2 safecoin per PUT with 2× reward totalling nearly 4 safecoin reward per PUT to be divided into the section. Not sure how achievable or dangerous this scenario is but again wanted to touch on it to see if prods anyone.

“reward will be divided as follows”

single_node_age = if no associated CoinBalance::owner { 0 }
                  else if flagged as full { node's age/2 }
                  else { node's age }

I think an extra line might be good here to account for the additional workload of elders that adults don’t have (especially important for tie-breakers among adults for eldership):

single_node_age = if no associated CoinBalance::owner { 0 }
                  else if flagged as full { node's age/2 }
                  else if elder { node's age + 1 }
                  else { node's age }

I’m interested in the Full Vault details…

Are chunks always attempted to be stored in full vaults to give them a chance to become recognised as unfull? Or does a full vault get automatically bypassed and the chunk redirected to the next nearest nonfull vault?

Will there be an option for a full vault to ask for relocated chunks to be returned to them, eg an Unrelocate request?

Is there some time after which the full vault is killed? Or can full vaults live on the network forever? Or until their next relocation?

Can the list of relocated chunks keep growing forever or is there some limit to how many chunks can be relocated?

Has the disallow rule been replaced by number of full vaults?

Seems to be covered in Future enhancements section:

“accepting a node to a section will revolve around 100 nodes capable of storing data, full nodes will not be counted as part of the section recommended size of 100”

and

“Each section will aim to maintain a minimum ratio of 50% good nodes”

So… full nodes don’t count toward the 100 target, but they do count toward the 50% good.

Does this psuedocode seem right?

allow new vault?
    less than 100 good -> yes
    more than 50% full -> yes
    else -> no

“accepting a node to a section will revolve around 100 nodes capable of storing data, full nodes will not be counted as part of the section recommended size of 100”

“Each section will aim to maintain a minimum ratio of 50% good nodes”

This gives some expected ranges of section size.

100 good nodes is the target. At least 50% good nodes means target between 0 and 100 full nodes.

200 good nodes is roughly when a split will happen, which means between 0 and 200 full nodes in a big section.

So the likely biggest section would be 400 nodes (200 good, 200 full).

Some StoreCost calculations

G    F    N    SC
100    0  100  0.0100
100  100  200  0.5100
200    0  200  0.0050
200  200  400  0.5050

StoreCost will almost always be roughly between 0.005 - 0.5 safecoin per PUT.

Does this summary sound right? Am I missing some details?

13 Likes