To accumulate at destination, we can today send msg with SrcLocation::Node, but then you are responsible for the accumulation and verification yourself as currently routing doesn't know the message it supposed to be accumulated (it sees it only as a raw Bytes).
Solution
We can add something like this:
fn send_message_accumulated_at_dst(&self, dst: DstLocation, signing_key: &bls::PublicKey, content: Bytes) -> Result<()>
And routing would then sign content with the secret key share that corresponds to signing_key (if any) and send it to dst as a special message variant. The dst's routing would then validate the messages, checks their keys and accumulate the signatures and finally raise it upwards as Event::MessageReceived.
Details
There are essentially two approaches. We call them accumulation at source and accumulation at destination.
Accumulation at source works like this:
The 7 elders each create a message and sign it with their respective secret key share.
Each then sends the message to all the other elders
Once an elder receives a supermajority of such messages, it aggregates the signatures into a full section signature and sends the resulting message to the destination
The destination receives up to 7 such messages, but they are all identical as they already contain the full section signature, not just the signature share
So the destination only needs to receive one such message and action it. It can then disregard the rest.
Accumulation at destination approach:
Each elders created a message and signs it with their respective secret key share
Then each elders sends this message to the destination
When the destination receives a supermajority of such messages, it aggregates the signature shares into the full section signature and actions the message
Currently in routing we support both. To accumulate at source, all you need to do is send the message with SrcLocation::Section and routing takes care of the rest. On the destination you get it as Event::MessageReceived and the message is already verified, so you can already action it.
To accumulate at destination, send it with SrcLocation::Node, but then you are responsible for the accumulation and verification yourself as currently routing doesn't know the message it supposed to be accumulated (it sees it only as a raw Bytes). We can try to change this if desired though.
We are trying to move towards using the accumulation at destination approach where possible as it seems simpler - there is fewer messages sent and the bulk of the work is carried by the destination which seems to be in line with the overall philosophy we are going for.
Problem
To accumulate at destination, we can today send msg with
SrcLocation::Node, but then you are responsible for the accumulation and verification yourself as currently routing doesn't know the message it supposed to be accumulated (it sees it only as a rawBytes).Solution
We can add something like this:
fn send_message_accumulated_at_dst(&self, dst: DstLocation, signing_key: &bls::PublicKey, content: Bytes) -> Result<()>And routing would then sign content with the secret key share that corresponds tosigning_key(if any) and send it to dst as a special message variant. The dst's routing would then validate the messages, checks their keys and accumulate the signatures and finally raise it upwards asEvent::MessageReceived.Details
There are essentially two approaches. We call them accumulation at source and accumulation at destination.
Accumulation at source works like this:
Accumulation at destination approach:
Currently in routing we support both. To accumulate at source, all you need to do is send the message with
SrcLocation::Sectionand routing takes care of the rest. On the destination you get it asEvent::MessageReceivedand the message is already verified, so you can already action it. To accumulate at destination, send it withSrcLocation::Node, but then you are responsible for the accumulation and verification yourself as currently routing doesn't know the message it supposed to be accumulated (it sees it only as a rawBytes). We can try to change this if desired though.We are trying to move towards using the accumulation at destination approach where possible as it seems simpler - there is fewer messages sent and the bulk of the work is carried by the destination which seems to be in line with the overall philosophy we are going for.