SAFE network upgrades

Development
1

So Bitcoin Core is being challenged by Bitcoin XT (see @dallyshalla s thread [here][1])

The question that is rapidly becoming relevant for the SAFE network is: how do we manage upgrades in the SAFE network? I’m interested in hearing what ideas you guys come up with. I’ll only share some considerations

  1. the SAFE network is autonomous, and can host its own binaries (old versions, as well as new proposed updates)
  2. Bitcoin has a global state in the blockchain and can count votes, setting deadlines as “if 75% of nodes by jan 16 have adopted Bitcoin XT, then Bitcoin XT forks by breaking with Bitcoin Core”, effectively forcing the minority out of business.
  3. The SAFE network does not have a global state, but it has atomically mutable StructuredData objects, that have (for a low number < ~ 100) a majority vote on mutation.
  4. obviously it is in the interest of any upgrade to be backwards compatible (a couple of versions); otherwise it would never be adopted; but what are strategies for the network to not fork, tear in higher dimensional connection space, form internal regions that absorb or reject information, … but rather smoothly sails into the future ? - oh yes, local behaviour (SAFE) is far richer than global behaviour (Bitcoin)

enjoy :slight_smile:
[1]: Bitcoin fork divides Bitcoin community

16 Likes
2

Great topic!

I think the main issue for SAFE is that it can’t afford a major fork because then neither the original nor the forked network has the capacity to store all of the network’s data. This, the fact that close groups operate with a 28/32 quorum, and the fact that nodes in a close group disconnect from dissenters may be a problematic combination if there’s a competition regarding an upgrade.

Perhaps we need a system where nodes in a close group can “agree to disagree” with nodes that make different decisions based on a known and legitimate alternative ruleset, and then not disconnect with each other but instead make a majority decision on which ruleset is followed.

So, using Bitcoin version terms, if SAFE XT would be released, SAFE Core could also push a small update with the only change being that it acknowledges SAFE XT’s ruleset as a legitimate, but competitive update. Then XT and Core are not at war, but in a “friendly” competition.

8 Likes
3

I’m assuming you need at least 17/32 nodes for approval in that situation?

1 Like
4

would it not be better to have a bigger majority and stick to the quorum-defined majority rules for a group?

1 Like
5

If SAFE XT had to achieve 28/32 nodes for approval, that is not “friendly” competition, it is a hostile takeover. They might as well start a new network unless they believe 87% of the farming community supports the change.

At least with 17/32 or a 51% they can propose a change and let the farmers decide.

Either way, it can get messy because what happens in some areas where 17/32 is approved and others are not? This could mean some transactions for SAFE XT don’t go through.

3 Likes
6

Maybe it is worthwhile reducing the problem first. How would we implement (global) voting. Assume (and we can) that we do want to reach a global consensus. How would the SAFE network best go about tallying, what would we tally, how, who would/should get to vote?

2 Likes
7

You’re making me work hard today, haha!

I’ll think on it and get back to you.

2 Likes
8

so … most important first - i don’t really have a solution here :smiley:
i’ll just leave some thoughts …

for a global voting system you need some kind of voting box …
…there are only 2 options as i see it … either there is some box where every client PUTs its vote in … or every single node needs to contact every other node inside the network and then would have its own counting done …

the second option is not really an option in my opinion simply because you don’t want to contact everybody all over the world … that would be kind of crazy to contact 8942304508 nodes …

the first option would mean you’d have to leave a note somewhere inside the safe network … and when you logout you need to delete this note … but e.g. if you are disconnected suddenly it would still remain there … so it had to be a self-destructing note which has to be refreshed from time to time … and because there is no central authority which is able to count and release just some numbers you’d have to read 8942304508 notes and i don’t really see a difference in the result compared to option 2 …

option 3 would be to go with a monte-carlo estimation (ok monte-carlo might be the wrong term here … but in my mind it is connected to it somewhere…) … contacting random chosen 777 nodes and using this as a estimation for the network status

1 Like
9

As far as SAFE upgrades are concerned, I think global voting is impractical.

We don’t vote to “start” the SAFE Network. Why would we need one to “upgrade”?

Technically, people already vote/agree the minute they installed a client and run a vault. If they no longer agree, they uninstall and go somewhere else. That’s as simple as it gets.

I’m perfectly fine with MaidSafe and or its successors auto-updating my Client/Vault. This is especially useful if they find a vulnerability and need to patch quickly.

I realize MaidSafe doesn’t want to be in “charge” of SAFE and that is okay.

Here’s a decentralized solution for them to consider.

SAFE Pods Multi-Signature Vote Required for Upgrade

1st Signature (SAFE Pod Troon)
2nd Signature (SAFE Pod Montreal)
3rd Signature (SAFE Pod San Francisco)
4th Signature (SAFE Pod Syndey)
5th Signature (SAFE Pod London)

If majority signatures 51% approve, the auto-update takes effect.
Of course they can adjust the details of how it gets implemented, but you get the idea now.

I prefer this way because the SAFE developers are more informed about an update/upgrade and can determine if it should be denied. This becomes more decentralized as more Pods join. That covers all your questions.

2 Likes
10

Couldn’t all users just be given the opportunity to vote if they wished somehow?

Am I fundamentally mis-understanding something , I mean why do only the farmers decide? :smiley:

11

The problem here is that it costs no to minimal amount of safecoin to generate many clients, so there is no way I know of to have clients vote at this level.

On the other hands, vaults (or vault owners) have a certain amount of data they are serving the network to the network, so it is a realtime “proof of stake” SAFE variation. After all its the vaults who are the concerned party here

3 Likes
12

Ah, I get you on the first point. The other point was why are farmers the only “concerned party” are users not supporting the Network too I mean? In an ideal world (without tech issues) should users have a say, or more likely have I missed a different point as to why just farmers decide?

1 Like
13

Yes, in an ideal world we (SAFE Network) would count every “individual” but it’s not technically doable right now.

1 Like
14

Got you…phew… :smiley:
Technological problems can be overcome…ideological ones were more my concern…lol

15

I guess the closest technical solution is that we actively (and fanatically) try to make every safe user a farmer, making every device a safe vault

6 Likes
16

I really don’t like this idea. Then we’re back at the bitcoin developer problem that’s going on right now. Assuming the patch is backward compatible, I would prefer “here’s the new client/vault/thing, run it if you want” and if 51%+ run it, that’s the new standard.

Obviously that doesn’t work with “hard fork” aka non-backwards compatible patches, that would need something else. Something that could be done ASAP in case of security issues. I don’t have a suggestion for that one yet. Working on it.

3 Likes
17

From what I have gathered reading about this topic a couple of times is the discussion is still theryetical. If that is the case I really liked the idea’s discussed on this thread:

Continuing the discussion from How to go about controversial changes once the community takes over?:

What interested me the most was mimicking how human DNA is “upgraded.”

18

And we have to consider the case where someone who has say 10,000 SAFEcoins in their client/vault and for some reason cannot use the system for a year or so with that client/vault. (Medical, work abroad or whatever)

What happens when they connect back up and their client is 5 versions behind and no longer compatible.

There is going to have to be some upgrade path for old clients/vaults. At no time can we totally cut off old versions, even if it is simply being able to securely recognise the old version and provide an upgrade that will carry over the coins, datamaps and settings.

2 Likes
19

The network needs to be self testing, self policing and self bounty-ing.

One ought to be able to fork the client, tweak it, and run it… The network ought to send it bad requests as good and my client ought only be trusted if it responds as it should.

Eliyahu M. Goldratt : Theory of Constraints: Five focusing steps:

  1. Identify the system’s constraint(s).
  2. Decide how to exploit the system’s constraint(s).
  3. Subordinate everything else to the above decision(s).
  4. Elevate the system’s constraint(s).
    5)Warning! If in the previous steps a constraint has been broken, go back to step 1, but do not allow inertia to cause a system’s constraint.

Something will always be holding the system back -be it lack of storage, lack of bandwidth, latency etc. If we could use automated testing to follow the process quoted above (Or something very simular), adjusting bounties for circumventing or elevating the constraints, the system would have good incentive to continue to be intelligently self-optimizing.

2 Likes
20

Wow. I’ve been waiting for this discussion, not because I have any solution but because it seemed inevitable.

From looking over the thread, it seems that there are some parameters that have not been defined.

Most notably, who or what gets to “decide” whether or not an update is accepted. To establish that I think we have to back off and look at who or what can actually hold the “lever of change”.

This roll certainly can’t be in the hands of the End User, as far as I can figure, meaning “the person who uses the network via a Client to access data and communications.”

So then we step back to think about the owner of the resources being donated to the network, the Farmer. The problem here is that, generally, Farmers are just people who have computers. No technical discrimination or even ability to really view what the software running on their machine is, much less the ability to judge what’s going on.

David Irvine has stated in a number of interviews about setting up a sacrificial vault to run a new version in parallel and only be accepted if it performed better than the existing one. So we’re finally discussing the nitty-gritty of what that actually means. This is THE nut to crack if we’re talking about a truly autonomous network. (You mean David doesn’t already have this point solved? Scary thought, actually.)

This all boils down to “What is the mechanism, the switch, that allows vaults to change behavior without being rejected by other vaults?” If a Vault can change behavior without being rejected, then a change in function could propagate through the network.

Is that switch controlled by the logic at the Vault level? Or is it controlled by a cryptographic key applied from an external source? The argument branches depending on the answer to these two questions. So, @BenMS, which is it?

5 Likes