Byzantine Reliable Broadcast (BRB) gives you the guarantee that at least 1 honest node has seen and validated a message.
A client getting message $m$ validated through BRB, with 4 nodes, you have $f = 1$ so 2 signatures is enough to guarantee at least one honest node has validated the message
This can be used to protect against inclusion attacks, i.e. If we run BRB in front of a consensus protocol, and that protocol outputs a value, we know that this value has been approved by at least 1 honest node, this prevents the attacker from being able to force an outcome that was not seen by any honest nodes.
We can try to adapt BRB for use in a staked consensus protocol:
First we need to adapt BRB to work with stake.
This is simple enough, just ensure the sum of stake signing for the value is at least $f$.
Next, note that BRB with the $> f$ stake condition is just as susceptible to the tagging attack as any other protocol, we need to increase the threshold
We can increase the threshold to $2f$, this helps quite a bit, but not fool proof. ($2f$ is the midpoint between liveness and safety)
The attacker only controls $f$ stake, he needs to aggregate at least another $f$ stake for his value to be included. This still leaks information:
e.g. repeated attempts to get enough stake signing his value can create a system of equations that can eventually be solved to reveal the stake of a validator:
$$ \begin{align} f + s_1 + s_2 + s_3 > 2f \\ f + s_2 + s_4 > 2f \\ f + s_1 + s_4 > 2f \\ \cdots \end{align} $$
If the attacker collects enough of these equations, it can start to solve the system and reveal the stakes.
We can attempt to mitigate this by adding a random variable $r$ to the stake’s we are summing:
$$ \begin{align} f + s_1 + \cdots + s_4 + r> 2f \end{align} $$
We can make $r$ a function of the full context of the stake threshold inequality so that we limit the information leaked from repeated runs i.e. include contributor validator keys, value, etc. something like:.
$$ \begin{align} r=hash_f(value||v_1||v_2||v_3),\space r\in [0,f) \end{align} $$
To make this safe, $(5)$, (6) needs to be evaluated within some sort of ZK proof to prevent the attacker from learning the value of $r$.
$$ \begin{align} f + s_1 + r_a> 2f \\ f + s_1 + s_2 + r_b > 2f \\ f + s_1 + s_2 + s_3 + r_c> 2f \\ \cdots \end{align} $$
Since $r$ changes for each invocation, adding another validator’s stake does not necessarily increase the total on the left side of the inequality.
Issues:
s + r has a mean of s + f / 2, with enough data collected, you may be able to isolate that.2f stake.