This RFC will propose a method to enforce a joining “cost” for new or restarting vaults to join the network. This is a mechanism to prevent mass joining quickly and therefor will introduce a cost of such an attack that is proportional to the network “effort” over time.
SAFE has already taken advantage of securing groups and group consensus. It also, with disjoint groups, secures hops which prevents nodes masquarading as network identities. It still though has a weakness in a possible attack where an attacker can easily restart many nodes constantly to target a network location. The difficulty of such an attack is not considered here, merely the opportunity of such an attack exists in some form.
The Effort of the network should allow that a proportionate amount of effort is carried out by a node wishing to join. This distinction requires a measurement of such work as well as a task that is adventageous to the network. One such tas that is currently under-rewarded is providing the access points (relays) for client nodes. This function is onerous on nodes in the netwoork, but at the same time it is critical.This is the initial observation.
A RelayNode will be paid directly from client Put actions, which is a simple mechanism that the MaidManager atributes payments to the RelayNode. This requires some additional code XXXX
This one is really new. It means getting paid for providing bandwidth instead of delivering chunks of data. It’s like: you are a relay_node for user “ABC” in the network and that Client just did a PUT so here’s some money.
Would it be accurate to say every new node start as a Relay Node with the opportunity to become a Managed Node? But if your node has a “Joining Token” then it bypasses the Relay Node initiation and goes straight into Managed Node even after reset?
I assume a Joining Token will be issued once a Relay Node gets promoted to Managed Node. I also assume vaults with a joining token do not flush their data chunks?
It looks like we will have 3 vault levels.
Level 1: Relay Node = Routing Vault (no data stored)
Nice thing is this increases security, measures nodes before join and really does so with very little code change. The beginning of what will eventually be (years from now after launch) a very granular ranking and protection mechanism.
The RFC describes a joining token which is like a certificate of completion when a (relay node) is promoted to (managed node).
After a (managed node) disconnects and tries to rejoin, it uses the joining token to say, “hey, I’ve already passed the reliable node test, here’s my proof.”
The token is then deleted / recycled by the group and the node starts as a (managed node), earning Safecoin right away. If it does not have a joining token, it must start as a (relay node) and can’t make the big bucks right away.
However, there is a reward incentive proposed for relay nodes. Relay nodes are described as “connection nodes” for clients trying to access the Network. Here’s how I see it.
I thought this was always the plan? I remember David’s analogy of how your vault is like a person, and we don’t trust it with chunks while it’s a low-rank “baby,” and only give it chunks when it grows up into a “Teenage node” or so
I changed the title to “Relay Nodes” as this is the new name for this RFC. It was called “Secure Vault Joining before”.
Here’s a summary of how this RFC works in my own words:
Connect to SAFE
There are 2 ways to connect to SAFE.
As a Client
As a Vault
As a Client you connect to several relay_nodes which serve as your proxies into the network. The relay_nodes don’t know what you communicate with the group as it’s fully encrypted. The group doesn’t know what your IP is as only the relay_nodes do.
As a Vault you don’t use any relay_nodes. You just route chunks from one Vault to the other and cache the chunks that come by. When a chunk is requested from your Vault you might make some Safecoin (Farming attempt) when the data_managers agree on you doing a good job delivering the chunk.
No here’s a problem. What if a group with big resources like a datacenter starts thousands of nodes to attack a certain address range (group) on the network? They could take over a group especially when the network is still small. How to prevent that?
This RFC covers this problem by preventing a node to become a farming Vault all at once. So now we have 3 options for nodes on the network:
Be a Client
Be a Relay Node (Vault that can’t farm yet, no signing power)
Be a full Vault (with signing power and option to Farm)
There’s also an Archive Node but this is not in the scope of this RFC.
Joining as a Vault
The idea here is you start as a Relay Node before you can become a full Vault. It means you connect Clients to a group and transfer all data back and forth without getting paid. When the Client does a PUT and a Safecoin is farmed you might go to the next level becoming a full Vault which signs messages and has the opportunity to farm Safecoin yourself by delivering chunks from your Vault.
So do we have any idea how long Joe Blogg’s vault will take before it can farm?
I’m thinking the idea was that people farm while their machine is on and turn off each day. But yet still provide storage and farm coins. If the promotion to full vault takes > 8 hours then using phones on charge, laptops, PCs on for 4-12 hours will have little incentive to try farming and even if they do will provide little to no storage ever