Front-running and transaction censorship via selective deafness are problems with both random notary selection and political voting. The solution I proposed for randomly selected notaries
in this post
https://bitsharestalk.org/index.php?topic=3895.msg49007#msg49007 involves generating txsets. In this post, I will develop a similar alternative protocol to fit better with a
political voting design. This protocol implements the following restrictions on notaries:
(1) Avoid giving a notary exclusive power to decide which transactions will be included ("transaction censorship"),
(2) Avoid giving a notary the ability to include non-public transactions ("private placement"),
(3) Forbid a notary from inserting a transaction at the last moment ("front-running").
The new protocol is a simple variation of my previously proposed txset protocol. Rather than have randomly chosen nodes propose txsets, have notaries propose
txsets. Additionally, since notaries are more reliable than randomly chosen ordinary nodes, use a commitment protocol instead of a simple broadcast, so blind
to the transactions that are included.
The "primary notary" is the notary that is supposed to produce the next block.
First, we choose a set of notaries that participate in choosing the transactions for the next block. Call this set the "proposer set." If the members of
the proposer set collude with each other, they will be able to perform transaction censorship, private placement and front-running. A larger set will
increase security by increasing the amount of collusion necessary for a successful attack, but also has a cost of increased blockchain storage. I will
discuss how to reduce the size of the proposer set in a future post, but an easy and secure way to choose the proposer set is the maximal choice: Simply
put every notary except the primary notary in the proposer set.
The size of the proposer set is TXSET_QUORUM for consistency with my previous posts. Each proposer signs and broadcasts a txset commitment hash, which
is simply the Merkle root hash of a nonce (chosen randomly locally) and the list of hashes of transactions the proposer believes ought to be included
in the block. However, proposers do not immediately broadcast the transaction list used to create the txset commitment hash! After receiving the
txset commitment hash, the notary issues a block commitment. The block commitment is a signed hash of all the txset commitment hashes for the txsets
that will be included in the block. Once a proposer receives a block commitment from the primary notary, it broadcasts ("reveals") the txset contents
and nonce corresponding to its previous commitment. The block can be validated when all proposers' block commitments are revealed. Finally,
the primary notary signs the block one last time, which finalizes it.
I've left out descriptions of the timeouts necessary to deal with offline notaries in the above protocol. But basically, whenever one or more of the notaries
doesn't respond and appears to be offline, the algorithm should replace the offline node(s) by the next available node(s) and restart from the top.
Timeout implementation considerations are the rationale behind the finalization step. Finalization is really a barrier to avoid a race condition
where all proposers reveal, but the timeout expires before the reveals reach the primary notary (perhaps one or more of the proposers is slow). The
protocol restarts with a new proposer set that doesn't include the slow members of the previous proposer set. All the reveals from the original proposer
set might reach some nodes, which would be able to put together a complete block; meanwhile the notaries have started working on a different block,
and that information might not have gotten very far. The nodes that have received all the reveals can assemble them into a complete block, but it
won't be able to proceed without the finalization signature. This is a "fork", but a very limited one: The wrong branch will never grow beyond
a single block; clients understand that the block is not yet immutable, the transactions therein still pending.