Following on from @mav 's post Researching network updates and governance I figured it was a good point to clarify some features/design statements in Safe. We have an in-house discourse and slack, where we discuss many topics. Even there I see the confusion over the use of terminology or indeed on occasion extremely slow adoption of using an agreed naming. Sometimes we uncover old use of terms, and that confuses if you try and review code. These days that’s all much better, but still exists in areas. This post is to try and clarify once and for all a basic network feature, Authority. It is pretty central to the whole network IMO and does make decisions more transparent, such as should a section sign again a message some other section signed etc.
I am looking to cement this into easy to understand chunks. This post is to get folk thinking and allow these design elements to become cemented in our minds to be very specific, and the use of these authorities carries costs and benefits. So the design choice to re-sign messages etc. is helped by a clear understanding of these authorities. All comments improvement welcome. Is some nice Sunday afternoon thinking maybe?
Authority
Authority to do something may be implicit in the network, such as section elders add/remove nodes from that section. Or it may be explicit, such as data types that have an owner and only that owner can update (with BLS the owner could be a group of clients, etc.).
In terms of the network, a message or operation requires the authority to carry it out. However, there is purely authority. We do not have source authority or destination authority on messages, for instance. A message has the authority or does not. It can be sent from anywhere as many times as we wish.
, i.e. Authority is a thing a message possesses, it is not a network location (This is much misunderstood)
For us, Authority is confirmed by the use of a digital signature. So think Signature is your proof you claim to have authority, like presenting a driving license or passport with your picture on it. “Hey, this is me I claim to have authority to do drive/travel etc.”.
Implicit Authority
We can break this down further:
NetworkAuthority
Some section on the network, current or past has signed this message.
Any other section can pick this message up and perhaps alter network data using this authority.
i.e. imagine a wallet in section A pays a wallet in section B, the elders of A can say yip, we debited wallet A and signed the credit Wallet B. Of course, Elders in B can sign again to make the Authority Section Authority, perhaps because the section chain is local to that section and therefor easier to confirm.
OR a section signs a nodes approval to join another section. The receiving section says, hey cool, this node has age X and we will accept him as we know his age is valid. We will make him change his name though to meet our requirements, but cool, we have NetworkAuthority and will accept him based on that and provide SectionAuthority to accept him.
Note: NetworkAuthority may not be local, so the SectionChain that holds the key that signed this may not be local. Therefore this requires a query to another section to get their SectionChain or at least part of it.
SectionAuthority
The Elders of this section have signed an operation only valid in this section (like add/remove nodes etc.) As above when they add a node provided by another section (apart form infants this is the only way to add nodes to a section) they take NetworkAuthority as the nodes passport to join, then provide SecitonAuthority to accept the node.
For removes SectionAuthority is gathered and if the node restarts, we sign to give the relocation (as above) NetworkAuthority.
AT2 and similar mechanisms such as DSB gather SectionAuthority by asking each Elder to sign an operation. When the client or initiator gets agreement (consensus) then the message has authority, the client can send this to each Elder to perform some operation (assuming the business logic is satisfied, such as this is the next data change as seen from the index in the operation being monotonically increasing (i.e. this is operation 4 and you can see the last one I did was operation 3 so we are good).
Note: SectionAuthority is local, we can confirm locally any authority (key) without getting proof from other sections. Even if the message is from (edit - thanks @JPL) a different prefix, as long as the prefix is an ancestor of the current one then we have that key locally (maybe in network data and not actually on our hard disk, but that’s Ok).
NodeAuthority
The node signs a message that comes from him. As nodes have no authority to do anything on the wider network then the NodeAuthority has no meaning in practice outwith the current section. Internal to the section it may vote on matters if it is an elder or give data as an Adult etc.
This is interesting to dive down into. Do we care a node sends or does not send a message onwards? Is it worth the hassle of finding that out (proving a negative is not a simple thing).
Explicit Authority
An Elder has the ability to send a vote and does do by sending a BLS signature share (this means a valid sig that can be combined with majority other sigs to create a section signature). The section knows the agreed Elders and these Elders have Authority to vote on section matters. i.e. they create SectionAuthority as the votes reach consensus (agreement of the majority of valid Elders).
A client may change a piece of data he owns. The data will hold a key that states the authority required to mutate this data. This is explicit to the data, but the network may hold the implicit authority to change the data as well. This in crdt terms makes the network (NetworkAuth or SectionAuth) also a valid Actor, alongside the client and all the clients devices etc. (I am always keen to remove this ability of the network to be an Actor and make the network as dumb as possible, also more secure, by extension).
Business Logic
Authority to do something does not make it possible to do it. So authority to drive a car does not mean you can do so on the water. So here your license is your authority, but the business logic is when you can logically use that authority.
For us, business logic is done by enforcing updates to data from a particular pattern and that pattern is defined in the data (i.e. append-only, sequence and so on).
