RFC: Relay Nodes

Here’s the link to RFC 0044: Relay Nodes.

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.

Detailed Design
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.


Weird the link did not work for me This one does though


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.


haha @dirvine you are maybe worse than me (but definitely more qualified xD ) :smiley: always full of new ideas and not enough time to take care of them all

though i think you should probably sleep enough as well this sounds to me like a brilliant angle that is absolutely worth discussing and should be tested in the field! =)
(said the incompetent one)

ps: i have a feeling i chose the right project as being my favorite =)


The RFC “Relay Node” reminds me of the “ZERO vault” discussed awhile back.

I have a question about the Safecoin reward incentive for relay nodes. Do all relay nodes along the XOR path get paid from the Client Node PUT?

(Client Node) ~> (Relay Node) ~> (Relay Node) ~> (Relay Node) ~> (Managed Node)

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)

Level 2: Managed Node = Storage Vault (stores data)

Level 3: Archive Node = Archive Vault (stores old data long term).


This anchor probably explains it a bit better.

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.


Does this mean users will have to pay SafeCoin to join a group and begin farming?

Hope it doesn’t, because that’s almost a chicken and egg problem :chicken: :hatching_chick:

There is no Safecoin cost to join a group.

Joining Token

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.

(Client Node) <~> (Relay Node) <~> (SAFE Network).

So when a client spends Safecoin to PUT data, the relay node is rewarded in some small way. It took me a while to understand what is a relay node and how they differ from a managed node.


No I’m not talking about your idea, I’m talking about the RFC in the OP:

Does this RFC 48 mean you’ll have to pay to join a group and start farming?

Yes, to make sure one can’t start 2000 Vaults to target a group.


The “cost” referred in the OP is “time”… as in… it takes time for a user’s vault to obtain the rank of (managed node). This is a full node that is able to store data chunks for the Network.

1 Like

Hmm, quite night and day answers there, who is right?

If you’re asking, will it cost Safecoin to join, the answer is no.

If you’re asking, will it cost Resources to join, the answer is yes.


Oh OK, thank you :slight_smile:

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


Yes, but until now, we didn’t have any detail laying out how we are going to rank vaults and their respective responsibilities. RFC 48 gives us more clarity.


thank you very much for bearing with me along the way :slight_smile:


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.

Group Attack
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?

Relay Node
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