[shared-objects] Client - Consensus Interface

[asonnino]

What is the best way to allow clients to communicate with consensus?

The story so far

Right now clients communicate with the core by sending transactions and certificates (forgetting non-safety critical sync messages).

What has to change

Clients still send transactions to the core. But to support shared objects, clients now have two options when sending their certificates: (i) either they send it to the core for normal processing, or (ii) they first send it to consensus and then send it to the core for normal processing. Option (i) is selected when there are no shared-objects involved in the transaction, and option (ii) is required when the transaction contains a shared object.

[asonnino]

Proposal 1

We currently have a (useless) wrapper around certificate messages called ConfirmationTransaction. We add a second possible wrapper around certificates called TransactionToSequence. The AuthorityServer forwards ConfirmationTransaction messages to the core (as it is done today) and TransactionToSequence messages to consensus. Upon aggregating a certificate over a transaction containing a shared object, the client performs the following actions:

1. Wrap the certificate into TransactionToSequence and send it to (hopefully not too many) authorities
2. Wait for consensus and detect when the certificate is sequenced. This means the client needs to run a light client of the consensus protocol we select.
3. Wrap the certificate into ConfirmationTransaction and send it to the authorities.4.

Advantages:

• We keep the authority design relatively simple

Drawbacks:

• Bad clients may submit the 'TransactionToSequence` to all authorities (thus dividing the throughput of consensus by the committee size)
• Higher latency since we have more round trips
• More complex client design.

Proposal 2

We add a new component sitting between the current AuthorityServer and AuthorityState that parses the certificate.

• If the certificate does not contain any shared object, it simply forwards the certificate to the core.
• If the certificate contains a shared object, it decides whether to drop the message or send it to consensus (filtering). If it decided to send the certificate to consensus, it then waits until it is sequence (thus running some sort of light client), and finally forwards the certificate to the core

Advantages:

• Lower latency with respect to option 1
• Simpler client

Drawbacks:

• Without smart filtering all authorities submit the certificate to consensus (thus dividing the throughput of consensus by the committee size) even if the client is honest.
• Unclear how to design the filtering mechanism (but honest authorities know there are 2f+1 honest authorities out there)
• Higher complexity for the authorities (although in a separate component)

[asonnino]

@gdanezis @sblackshear

[gdanezis]

The common challenge is to avoid all authorities submitting the same transaction, leading to a O(N) overhead right?

[asonnino]

Yes exactly

[LefKok]

11pm idea so might scrap it when I am not sleepy:

Use checkpoints as "tiny epochs" each of which has a random seed (biasable but this is a liveness issue so uninteresting to attack). Use VRF(certificate|seed) to tell you which (constant c=3?) authorities are responsible for transmission during this tiny epoch.

If you think this is too complex just H(cert,tiny_epoch_number).

[asonnino]

I was thinking the same but with C=f+1 to be sure, but C constant is not a bad idea 

[LefKok]

C=f+1 doesn't really reduce the load but guarantees transmission. Given that this is a liveness-only issue and most of the time no node will act as malicious and crashes should be a minority, hence I would do c=2.