Hey all. Many of you know me from my activity here a year ago, when we were architecting our project Intercoin. At that time I had many discussions with the team and supporters of SAFE Network, and I hope the project has a big launch soon! How close are we?
At the end of the day, where SAFE seems to be about storing information in the network, Intercoin is more about how things change. So we need validators. In a chess game some referees to sign whether moves are valid. In a token we may want M of N latest “owners” sign a transaction. These things are called InterActions and they are taken in certain states of InterActivities.
I would love for our projects to be InterOperable (pardon the pun) and indeed SAFE network can add something to its protocol that strictly adds interoperability with MANY projects like ours without any loss in any security or features. That’s what I would like to describe now. I would like for the protocol to be open enough that maybe in the future Intercoin notaries can join the SAFE Network as vaults without LOSING capabilities. (Kind of like the website IndieWeb warns against a web monoculture, and how DID spec took over for identity interoperability lately.)
The MAIN thing I would like to ask the SAFE team to add is the ability to add and remove validators, and have some simple rules about adding/removing validators.
The content of the document stored in SAFE can be mutable and evolve and change. But as far as I understand, there is no mechanism to reject certain changes. Dat has this problem also. As far as I know it is impossible to “bolt it on from the inside”, because vaults will happily accept gibberish changes and go into eg a chess variation that is illegal. And the correct variation will now have to be built upon a wrong history which it repudiates. You may be able to tunnel some additional consensus mechanism through the inside but it’s wasteful, and unnecessary.
Validators can be added by simply adding their public keys. They can be encrypted on the level of the section or whatever mechanism checks for there to be no forks, and stores which hash / revision is the head. Or not encrypted.
The public keys are arbitrary, they can be part of public-private key pairs generated by some clients or bots for the express purpose of validating one or more transactions. The section and vaults don’t care. What they do care about is that they REJECT ANY CHANGE TO A MUTABLE DOCUMENT THAT HAS NOT BEEN SIGNED BY AT LEAST M OF N VALIDATORS.
In this way we can build lots of consensus algorithms and applications on top of SAFENetwork or make it interoperable with nodes from other projects that do cryptocurrency, like Intercoin, or perhaps some decentralized githubs of the world.
There has to be some protocol that is general enough to be interoperable with various M of N governance rules within a document. Maybe adding a new validator requires M1 of N validators, but removing one requires M2 of N validators. Maybe you can do it in bulk, which may be good for when a safecoin or some other document or token changes from being controlled by one corporation to another corporation. Maybe the list of validator public keys can be stored in other referenced documents, but that can be overkill.
The point is that the section must REJECT any updates that aren’t signed by at least M of N validators. If the section wants to additionally detect corruption in itself (eg when a consensus led to accepting illegal chess moves in the past) any vault can check this. Maybe it can’t do anything about this once a consensus has been established. But an honest vault will refuse to participate in such a consensus, and as long as a majority of the SAFE network section vaults aren’t compromised that should be enough.
PS: We could have gone further — if the vault detects that members of a section are colluding and accepting invalid transactions, it can maybe gossip this to others and kick them out of the section. And if MAJORITY the nodes in the section are compromised and continue not caring, they it can gossip to others and get them to migrate away from that section. I brought up this part before as Watchers, but it was rejected because there is no mechanism to migrate documents to another “healthy” section. In any case such migration could easily be done by the actual end-users of the document if they can somehow signal each other despite the section being totally compromised. That part can be done without changing SAFE Network. But the feature to reject updates that aren’t signed by M of N validators cannot be emulated by doing something else.