Network design criteria - part 1 - Authority

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 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:


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.


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).


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).


And that’s why the recent investment into the clean-up and simplification of the code makes me so happy. Thanks again!


Thanks for the clarifications @dirvine. Not sure I quite understand this.

“Even if the message is formed a different prefix” - should this be “Even if the message is from a different prefix”?


Sorry to necro-bump this thread, but does anybody know if there was ever a part 2 for this thread, discussing more authority-related info or other network design criteria? I took the info in this post to rough draft a wiki article and I wanted to flesh it out beyond paraphrasing the info in this post. Or I could take it to populate other new wiki pages.


I am not sure, there is way too much in way too many places (so thanks for wiki and @JPL primer also).

I can give some more info.

Above we define Authority. It’s kinda like defining an entity and we recognise the entity via its signature.

SectionAuthority and NetworkAuthority are a new kind of entity! These represent a decentralised Actor. Sounds weird, well in CRDT etc. we consider Actors do stuff to data. So stick with it.

Many years folk consider the group consensus set as the oldest X nodes, but this is very wrong and misleading!

You see we need to look at the eldest nodes (now eldest connectable nodes) to define an Elder. We say an Elder is one of the oldest reachable nodes, but that is not fully true, it is true at a certain point in time (time in Safe is logical time). So at some clock tick and we represent those clock ticks with the SectionChain.

What’s a SectionChain

The first node on the network starts the chain. It creates a keypair (BLS) and put’s the public key there. That’s our genesis key.

Then another node joins and a new key is arranged via a DKG (Decentralised Key Generation) protocol. This means the 2 nodes agree on a common public key. They each have a key share, nobody has the secret key of the agreed key (Section key). (BLS beauty incoming).

Each node has a key share, a secret and a public key. If we add both keys together they == the Section key (cool), but even cooler, if both sign and we add the sigs (aggregate, it’s not really added, but …) then the signature looks like it was signed by the SectionKey. So we have decentralised key pairs.

Ok on we go!

So the 2nd node plus the first one create the new SectiionKey, this is signed by the previous SectionKey (in this specific case signed by the first node only). So we form a chain where a new SEctionKey is agreed and signed by the last one. On that goes, forever.

What’s an Elder again?

So an elder now is one of the oldest reachable nodes in relation to a specific SectionKey. i.e. without a SectionKey hint, it’s not an elder and it’s only that Elder during the time that key is valid (before more churn).

Ok churn?

When the Elder group changes a new SectionKey is created via DKG, the previous Elders sign this with their older key share. We are good. so the previous elders at key ABC are elders again at key ABC+1 (ot whatever it is called).

So the critical thing, easily missed is a node who is and Elders at ABC is not the same Elder at the next key ABC+1, but it is the same node. It’s just not the same Elder.

I hope that makes sense, it is non-obvious but very important.


Fair enough, the info is a bit disparate still, but I figured it was worth checking. In any case, what you just wrote is plenty to go on, so thanks for putting this together! I’ve been adding to the wiki in the little pockets of free time during my day, etc. so I’ll start folding this info in soon :grin: