[draft] MIP-103: Baker Confirmations (ZK-FFS)

[l-monninger]

Summary

MIP-103
Roadmap for FFS through to Baker Confirmations

[apenzk]

Suggested change

	1. **Unidirectional**: A Baker Coin protocol MUST intend ONLY to post a commitment the state of a given Ledger B onto Ledger A, not vice versa.
	1. **Unidirectional**: A Baker Coin protocol MUST intend ONLY to post a commitment to the state of a given Ledger B onto Ledger A, not vice versa.

[apenzk]

Rename to STAKE_INTENT as we should cover also unstake through this. amount could be negative, thus it can handle stake and unstake type intents

[l-monninger]

Yeah, good call.

[apenzk]

Wdym? Would it not make sense to apply the effects of stake at the start of a new epoch.

[apenzk]

Also why "sufficient"? "Verified" or "sufficiently verified" seems enough

[l-monninger]

So, "sufficient" here refers to checking multiple peers or otherwise that protocol finality is indeed reached.

[apenzk]

ok its not very clear. i suggest to rewrite a bit, with mention of threshold many verified responses

[apenzk]

There should be sufficient delay in making stake effectice for the voting. The easiest would be to demand that stake becomes effective at the end of the next present_epoch (not this present_epoch). Epoch length could be for example 1 hour. Note that i say 1 hour in the current setting since it should be larger than the finality of A, which for Eth is O(15min)

[l-monninger]

Yeah, so you should always stake and unstake into the $n+1$ epoch as before. But, with the additional synchronicity questions between the Baker Confirmations network Ledger A, I would actually suggest this should be $n+2$--giving observers one epoch to propagate messages.

[apenzk]

you are 100% correct.

[apenzk]

this should be mentioned as well in the file.

[apenzk]

why coin? this information is missing and the reasoning not provided.

[l-monninger]

Because at the heart of the protocol is a presumed COIN. The effects/hooks are no more abstract than coin slashing and rewarding.

[apenzk]

ok. can we add a note on this. it would help with reading

[apenzk]

Observing attesters is rather confusing. as lateron we refer to "attester" without Baker. For clarity Obsering Attester --> Observer or A-Observer or similar

[l-monninger]

It has the role of Observing and attesting to Ledger A events. We could also go for Light Observer or something .

[apenzk]

Figure is missing the A-Observer

[apenzk]

also if the participants are active on or with Ledger A this should be indicated by having the boxes within (or touching) the Ledger A box on the right.

[l-monninger]

Yeah, the figure doesn't show the Baker Coin protocol; it's showing high-level Baker Confirmations which are just a gossip of attestations and a race to submit a proof of consensus.

[apenzk]

can we have both a BakerCoin protol figure and Baker Confirmations? Otherwise this is confusing.

[apenzk]

when you say participant do you mean A-participant or some other kind of participant? i think participant is too generic and thus confusing. I suggest to use some more descriptive. I updated Leder A participant to A-participant

[l-monninger]

Yeah, the participant is an Attester. I will update for clarity.

[apenzk]

Here and in the figure you refer to participants as actors in the Baker protocol (off-Ledger A).. However you also refer to A-participants as participants. Are these identical ?

[l-monninger]

Lower-case participants is always just participants in the most general sense.

[apenzk]

ok. then it is ever more important to distinguish A-participants

[apenzk]

content missing

[l-monninger]

Yeah, needs to be removed.

[apenzk]

this needs explaining. i do not understand the problem. is the validator not simply providing a proof?

[l-monninger]

The Validator will have to submit a message containing the outputs of the ZK program as well as the proof. Under the Baker Coin class of protocols, this output contains slashing and reward commands which are inherently $O(|Validators|)$ to apply.

[apenzk]

this clarifies. plz add.

[apenzk]

this problem does NOT exist in postconfirmation as described in MIP-37, as this is trivially resolved by separting the role of a) attestation and b) postconfirmation+rollover. This paragraph describes a problem that does not necessarily exist any longer and should be revised to reflect a scenario with and without a separation of the roles.

[l-monninger]

Yes, the acceptor concept is one way to take care of this, but it does just shift the liveness problem to the liveness of the acceptor. It doesn't go away entirely.

[apenzk]

ok. this was too specific to MCR in this case. i have rewritten it to be more generic

see f2a8892

[apenzk]

this is resolved by the honest supermajority assumption. 2/3 exist that do not perform such strategy. what you describe falls into the strategy of 1/3.

you could carry the argument about the "last validator" forth: find a solution to fix the "the last validator" problem. Now it becomes a problem of the second-to-last validator.

[l-monninger]

this is resolved by the honest supermajority assumption. 2/3 exist that do not perform such strategy. what you describe falls into the strategy of 1/3.

Somewhat. By some definitions, the Validator in the standoff is still being honest; it's just maximizing its reward which is more like the phenomena described herein, some which influenced Goldfish development. You still want unliveness disincentives is the bottom line.

you could carry the argument about the "last validator" forth: find a solution to fix the "the last validator" problem. Now it becomes a problem of the second-to-last validator.

Not exactly. The second-to-last validator doesn't actually know if has the chance to be the second-to-last validator.

For simplicity, imagine there are three validators remaining. Any two of which are know to compute the supermajority vote for this commitment.

Validator A doesn't know that if it holds off on committing, Validators B and C won't commit rendering its standoff meaningless.

You could say there is a probabilistic strategy or that the Validators could collude. I can model this as a information incomplete game if you want to dive deeper.

But, the bottom line is that, in contrast, when a validator absolutely knows that committing to a certain state root by itself would cause a rollover, it is rational for them to maximize rewards from this privilege however possible.

If there is no deterrent for being unlive, we could reach a point in our chain where a previously completely honest and live validator realizes it can hold the network for ransom indefinitely.

[l-monninger]

This is also again to say that Validator A, B, and C is inherently different from partitions of such weights consisting of more Validators--nor that it matters if all three know and are working together. But, that same point is just another motivation for the to create liveness constraints.

Yes, you can generalize this to halting the protocol on the whole whenever the expected value of not committing and waiting for ransom is greater than committing--not just the simple last validator. No, that does not change the fact that requiring commitments by a certain point in time greatly lessens the expected value of such behavior.

[apenzk]

Somewhat. By some definitions, the Validator in the standoff is still being honest; it's just maximizing its reward which is more like the phenomena described herein, some which influenced Goldfish development. You still want unliveness disincentives is the bottom line.

this is rational, not honest. See e.g. https://arxiv.org/html/2405.07557v1

• Honest Players: Also called altruistic players, they follow the specified protocol honestly.
• Rational Players: These players follow the strategy which gives the highest payoff based off of some utility structure (which is protocol and agent type specific5). Therefore, such players deviate from following the protocol honestly only if there exists a strategy with a higher payoff.

[apenzk]

validator realizes it can hold the network for ransom indefinitely.

this seems a byzantine behaviour and not even rational (a rational actor would have to commit eventually to not miss out on rewards for next rounds)

[apenzk]

Generally i would like to raise the question if we consider more than 1/3 of validators to act rational, why should we not consider 2/3 or 100% to act rational?
If 100% act rational what is the reason to commit at all. everyone may attempt to get close to the 2/3 threshold. The abbys of rational actors is a deep.

[apenzk]

at the core this is why i am trying to separate the attestation from the validation. avoid timing games. attesters should just be comfortable and submit at their earliest point and have no advantage about the when (as submitting later has no advantage). it is a weak nash equilibrium that removes being rational for attester permitting the required >2/3 honest majority.

[apenzk]

yes. and this introduces a censorship problem on A. Unless multiple validators provide proofs on A -- but then what is the advantage of this solution against the postconfirmations described in MIP-37?

[l-monninger]

1. Multiple Validators providing proofs is still potentially cheaper.
2. The off-chain implementation is more flexible.

[apenzk]

can we add those points as motivation compared to MIP-37 at the beginning.

[apenzk]

The entire point of using a base settlement layer is to prevent equivocation on this. Hence why this is called anchoring. The settlement layer A provides higher priority consensus and this should be utilized (otherwise what is the point of having a settlement layer) This is simply done by only allowing the first successful proof.

revise to also consider this assumption, e.g. a second scenario

[l-monninger]

The entire point of using a base settlement layer is to prevent equivocation on this.

I disagree somewhat. The point of using the base settlement layer is to anchor the security of a supermajority vote to that layer. The exact quorum is secondary.

[apenzk]

if there can be A) multiple supermajority votes (forks) settled to L1, then this B) removes the sybil protection, which in turn C) removes the security of the supermajority vote.

At what point of this sentence would you disagree?

[apenzk]

the contract on A does only need to accept the first valid proof to commitment $C_1$. if there are further proofs to $C_1$ this indeed should be accepted to increase the union for actors to be rewarded. But we SHOULD NOT accept a proof for $C_2$ (that is in theory also valid) that comes after $C_1$ . If we would accept $C_2$ as well this would defeat the purpose of an anchoring layer.

[l-monninger]

If we would accept $C_2$ as well this would defeat the purpose of an anchoring layer.

1. It should not be possible to send two different supermajority commitments under the Byzantine assumption. The broadcasted votes in the Baker Network could not contain supermajorities for two completely different commitments.
2. If $C_1 = C_2$ but $Validators(C_1) \neq Validators(C_2)$ "accepting" both commitments is irrelevant as they are the same. This is simply a matter of rewarding.

[apenzk]

under the Byzantine assumption

if honest Attesters are assume to only cast their votes once, it is not possibe to send different supermajority commitments. any byzantine assumption is fine for safety. consensus comes from L1. For liveness, we require at least 51%.

[apenzk]

If $C_1 = C_2$ but $Validators(C_1) \neq Validators(C_2)$ "accepting" both commitments is irrelevant as they are the same. This is simply a matter of rewarding.

i am bit lost about the lingo of attesters and validators at this point - do you mean attesters, not validators?
My assumption was Atestters A1,A2,A3... can cast for one commitment, e.g. C1 or C2. I am assuming C1 neq C2.

The proofs in my understanding could be Proof_of(V1) = C1(A1,A2), Proof_of(V2) = C2(A3). if Proof_of(V1) is valid (i.e. contains a supermajority of votes) it should be the one recorded as the new postconfirmed state.

Now if A3 equivocates and also votes for C2, and forwards this to yet another validator V3, creating a valid proof e.g. Proof_of(V3)=C1(A1,A2,A4). Then this proof of course should also be accepted. the contract on A should now have : C1 -> A1,A2,A3,A4 + separate slashing of A3 for equivocating.

[l-monninger]

Attesters broadcast their votes for given commitments. Validators summarize supermajority agreement on a commitment and post it on $\text{Ledger A}$.

[l-monninger]

Now if A3 equivocates and also votes for C2, and forwards this to yet another validator V3, creating a valid proof e.g. Proof_of(V3)=C1(A1,A2,A4). Then this proof of course should also be accepted. the contract on A should now have : C1 -> A1,A2,A3,A4 + separate slashing of A3 for equivocating.

That is Byzantine behavior from $A_3$. My statement about was that, if we make our Byzantine assumption about $A$, we could not have this scenario.

Our Byzantine assumption is that, given $n = |A| / 3$. The number of honest attesters is $|A_h| \geq 2n + 1$, thus Byzantine nodes $|A_b| \leq n - 1$.

$|A_b|$ can contribute to an arbitrary number of fraudulent commitments. However, because ultimately $|A_b| \leq n - 1$, they cannot create one that would be accepted without members of $|A_h|$.

In other words, for any proven supermajority vote $C_i$, $|A_h(C_i)| > 1$. In fact, it's $|A_h(C_i)| \geq n + 2$.

Because $|A_h|$ is assumed honest, they should agree on $C_i$. This thus implies that any proven supermajority containing fraudulent commitments from $|A_b|$ should in fact contain commitments from $|A_h|$ and is thus correct.

Now, you might naively argue that a Validator could collaborate with $|A_b|$ to create the proven commitment. However, because the program tabulating stakes and votes is ZK proven, the Validator cannot fudge anything. (You do have to make Merkle Root commitments to the state though.)

[apenzk]

a proof of stake L2 confirmations system.

we should distinguish clearly between a confirmation layer and a finality layer. E.g. Fastconfirmations are a confirmation layer, whereas Postconfirmations are a settlement layer (think finality).

Why is this important ? Because the final say is by the settlement layer (the base truth). Would the settlement layer reorg, so would have to do the confirmation layer (ideally with no consequence on the transaction order, but possibly with impact on e.g. hashes - for example if the confirmation layer intakes finalization data from L1.)

Maybe the following is representive of this

Confirmation Layer	Who Confirms	Settlement Layer	Who Settles
Espresso	Espresso validators	Ethereum	Ethereum Validators
Arbitrum Sequencer	Arbitrum Sequencer	Ethereum	Ethereum Validators
Optimism Sequencer	Optimism Sequencer	Ethereum	Ethereum Validators
StarkWare	StarkWare Provers	Ethereum	Ethereum Validators
Polygon PoS	Polygon PoS Validators	Ethereum	Ethereum Validators
Avalanche Subnets	Avalanche Subnet Validators	Avalanche C-Chain	Avalanche C-Chain Validators
Polkadot Parachains	Parachain Collators	Polkadot Relay Chain	Polkadot Relay Chain Validators
Near Aurora	Aurora Validators	Near Protocol	Near Validators
Cosmos Hub Zones	Cosmos Zone Validators	Cosmos Hub	Cosmos Hub Validators

[apenzk]

so are you referring here to the confirmation system or the finality system?

[l-monninger]

So, in the long run because of generalization, I was actually thinking we might benefit from a new term because of confusion this can cause. I've used "Confirmations" as the general term here because every layer involved uses this voting mechanism to confirm that a certain state has been reached, whichever one is the ultimate is finality.

In other words, not all confirmations are finalizations, but a finalization is a confirmation.

[apenzk]

would you class this as the prototype stage? would be more clear than General. it looks like prototype as its decoupled from full node logic

[l-monninger]

Prototype isn't quite the ambition. It's more a push to extract FFS as a generalizable software. All of what's leading up to that in development is essentially a prototype.

[apenzk]

does this address MD-37: FFS: Postconfirmations or MD-65: FFS: Fastconfirmations ?

[l-monninger]

Yes, it would be good to include those.

[apenzk]

done

[apenzk]

should start to think of a suitable name, rather than Multi-Commit-Rollup.

• PCP ( PostConfirmation Protocol)
• AP (Anchoring Protocol)
• APP (Anchoring Postconfirmation Protocol)

[l-monninger]

Yeah, I mean MCR is just what we'll keep for that first contract we share for the games as it is what that implementation was originally called and we're not planning to keep it.