RFC 56 - Secure Message Delivery


Discussion topic for RFC 56.


Very cool and I’m still absorbing the detail and will do so for quite a while I feel. Here’s some of my intial impressions

The title

Secure Message Delivery

I feel that for an RFC about ‚Äėmessage delivery‚Äô there‚Äôs essentially no info about routes or hops (ie the ‚Äėdelivery‚Äô). I don‚Äôt really know how messages traverse the network. That info probably belongs in the unpublished ‚Äúreliable message delivery‚ÄĚ rfc; maybe the purpose of this rfc would be clearer using a title of ‚ÄėMessage Delivery Security‚Äô. It‚Äôs bikeshedding for sure but I was expecting to read about ‚Äėmessage delivery‚Äô when really it‚Äôs only about ‚Äėsecurity‚Äô of that.

‚ÄúSecure Message Delivery‚ÄĚ + ‚ÄúReliable Message Delivery‚ÄĚ is (to my mind) a weaker pair of descriptions than ‚ÄúMessage Delivery Security‚ÄĚ and ‚ÄúMessage Delivery Reliability‚Ä̂Ķ it‚Äôs just my initial impression and I can definitely get used to the current naming.


I feel the summary describes the purpose (ie why) but does not summarise the basic operation or idea of the scheme (ie what). Some plain simple description of the mechanism would be handy. As in, what happens?

eg Sections use a common aggregate keypair (comprised of subkeypairs from all elders) to identify the section to other sections. As the section membership changes so too does the aggregate keypair, which is shared and updated for all other sections. The aggregate keypair can then be used to easily verify the integrity of messages between sections and prevent malicious messaging.

We assume sections prove themselves via the use of a BLS public key.

For those who haven‚Äôt heard of this (myself included), it‚Äôs Boneh‚ÄďLynn‚ÄďShacham. The ‚ÄėProperties‚Äô section of the wiki page is relevant - Simple Threshold Signatures, Signature Aggregation.

Does anyone know of any particularly good sources for reading more about this algorithm?

A simple enhancement would be to include section health in an SectionProofBlock, this would take the form of a 32 bit integer to represent the age of the section Elders and an 8 bit integer to represent the number of nodes in a section.

This is very cool. I like the direction it’s going.

Is it right to assume ‚Äėbigger numbers‚Äô means ‚Äėmore healthy‚Äô or is it more like ‚Äėcloser to this target‚Äô means ‚Äėmore healthy‚Äô?

struct SectionProofBlock {
 key: BLS::PublicKey,
 sig: BLS::Signature

Have to say I really hate the use of block. I don’t hate on many things but I hate this. It’s a link (or change, or event). Not a block. There are probably many words that can be used but block seems wrong. If the struct encapsulated a whole bunch of links then sure call it a block (well, I think snapshot would be even better than block in that case) but this data object is simply not a block in any way shape or form. In my very strong opinion.

type SectionProofChain = Vec<SectionProofBlock>
type SectionProofChain = Vec<SectionProofLink>

The first one is a blockchain the second is just a chain. And… SAFE is not a blockchain!!!


I found this post that seems pretty good. It mentions that the drawback of BLS is that verification is burdensome.


is an OK start,
https://eprint.iacr.org/2018/068.pdf (shnorr)
https://www.cc.gatech.edu/~aboldyre/papers/bold.pdf (gap diffie hellman scheme)
https://eprint.iacr.org/2018/483.pdf (bls scheme for smaller blockchains, but closely related to our case)
The threshold_crypto crate we will use does in fact use the gap diffie hellman method for threshold.

That does read better IMO. Yes the reliable delivery RFC will make this much more understandable, I pushed for this to be published with the reliable one coming on its heels. We actually did a pre-rfc for reliability before the pre-rfc for section validation (this one).

We can have a lot there, so health (how many nodes, average age of elders etc.), farmed safecoin, held safecoin etc. I suspect we will see some pretty neat things there that perhaps even allows seciton recovery from any takeover etc.

:smiley: :smiley: yip that is true, I am not as opposed ot block but yea it is a bit like info that is my peeve to your block peeve. They are both bad at communicating what the thing is.


I don’t know if you are talking about this specific use of the term here or its generalized use by Maidsafe in data chain or PARSEC.

Initially I tried to argue for a better term because I also think it is too vague (for example see here).

But now this is OK with me because in traditional blockchain based networks the same vague term is used to refer to a precise specific object (a set of validated transactions in their case). So, this term is commonly used in the field to refer to the basic component of the ledger of the network (the datachain in our case).