[WIP] ideas for syncing validator set from one chain to another as well as making bridge work with dynamic validator sets

[snd]

thought i'd do this as a branch on the relevant repo. seems cleaner than a bunch of gists

ready for review/feedback:
https://github.com/paritytech/parity-bridge/blob/validator_set_thoughts/docs/bridged_validator_set.md

writeup in progress:
https://github.com/paritytech/parity-bridge/blob/validator_set_thoughts/docs/bridge_with_dynamic_validator_set.md

feedback and questions are greatly appreciated :)

[snd]

@debris @rphmeier

if you have time feel free to take a look at https://github.com/paritytech/parity-bridge/blob/validator_set_thoughts/docs/bridged_validator_set.md

i'd greatly appreciate feedback on that :)
(via comments on this PR)

i'm still working on https://github.com/paritytech/parity-bridge/blob/validator_set_thoughts/docs/bridge_with_dynamic_validator_set.md which builds on top of https://github.com/paritytech/parity-bridge/blob/validator_set_thoughts/docs/bridged_validator_set.md

[rphmeier]

The main issue I see is that the "transaction" actually finalizing a validator set change is extra-protocol and doesn't actually issue any log events. Otherwise it seems reasonable.

[snd]

@rphmeier many thanks for looking at it :)

what exactly do you mean by "extra-protocol"?
the fact that there are validator processes involved that live outside the chain?
the final transaction should be the final call to calledByValidatorProcessOnChangeFinalizedEvent (when there are enough signatures and it emits ChangeFinalized).
the finality of that transaction is only known later.

is my following thinking exhaustive and correct?:
another transaction calling Foo.bar() on home_chain can rely on home_chain.ValidatorSetBridge.getValidators() to be final since if it won't be final then
Foo.bar() won't reach finality either.

i guess by doesn't actually issue any log events you mean something other than https://github.com/paritytech/parity-bridge/blob/validator_set_thoughts/contracts/bridged_validator_set.sol#L49. what exactly?

any pointers on how to solve the issue you see?

[rphmeier]

extra-protocol is the wrong term. it's more like an "implied" transaction calling finalizeChange. EVM code of a contract is run, but there's no corresponding transaction in the block body. thus there's no corresponding receipt where logs would be contained. if logs are used to signal bridge validators to bridge a transaction, they wouldn't be able to pick up on any ChangeFinalized event issued in a validator set's finalizeChange method.

[snd]

i see. wasn't aware of the possibility of that.

so far i thought that the calls (done by validator processes) to calledByValidatorProcessOnChangeFinalizedEvent consume gas, get mined and are added as transactions to a block.

the calls would happen similar to how the bridge currently relays deposits:
https://github.com/paritytech/parity-bridge/blob/master/bridge/src/bridge/deposit_relay.rs#L81

what is the exact terminology for the case you're describing so i can read up on that? do you have any useful pointers to documentation?

[snd]

still adjusting my mental model on how specific parts of ethereum work

[rphmeier]

This isn't something that exists in Ethereum. It's something we added to Parity specifically for the purpose of changing validator sets upon finality of a signal.

[snd]

where's the flaw in my following thought process?:

after waiting for n confirmations (or figuring out finality some other way) on a ChangeFinalized
event on foreign_chain each validator process does a https://github.com/ethereum/wiki/wiki/JSON-RPC#eth_sendtransaction (not a https://github.com/ethereum/wiki/wiki/JSON-RPC#eth_call)
to home_chain.BridgedValidatorSet.calledByValidatorProcessOnChangeFinalizedEvent.

similar to

parity-bridge/bridge/src/bridge/deposit_relay.rs

Line 93 in 5940396

api::send_transaction(&self.app.connections.foreign, request),

all those transactions get mined and change the storage of home_chain.BridgedValidatorSet.

the call to calledByValidatorProcessOnChangeFinalizedEvent that has enough required signatures
"commits" the change to home_chain by updating the validator set

parity-bridge/contracts/bridged_validator_set.sol

Line 45 in d7db58e

validatorSet = newValidatorSet;

and emits a ChangeFinalized event

parity-bridge/contracts/bridged_validator_set.sol

Line 49 in d7db58e

ChangeFinalized(newValidatorSet);

.

the transaction containing the update and event gets mined and now acts as a log of that change to the validator set

[rphmeier]

@snd no problem there really, just pointing out that there isn't an easy way for the validators on chain A to tell when a validator set change on A has been finalized without constantly polling getValidators or introducing an RPC for checking finality of a block hash.

[snd]

@rphmeier very true. i get the issue now and will think about it

[snd]

might have found a much simpler solution to the "bridge with dynamic validator sets" problem.
i'll think it through and sketch it out

[snd]

@debris @rphmeier would it be an option to have two distinct (not synced or relayed) validator sets and associated processes? one on home_chain and one on foreign_chain.

one would be responsible for relaying withdrawals and the other for relaying deposits.

if we then change withdrawals to work analogous to deposits (= remove the "collecting signatures on the foreign_chain" which reduces the number of transactions on the home_chain)
then the "break out" events will always be picked up by the newest validator set processes which correspond to the validator set opposite to the "break out" event. also the "break in" transactions would always happen on the chain that has the validator set corresponding to the validator processes that do the "break in" transaction and therefore trusts them.

this could work and requires no relaying of validator sets! it has the advantage of being relatively simple and probably less error prone. it has the disadvantage of having two sets of validator sets and processes. it also has the disadvantage of resulting in requiredSignatures transactions on home_chain per withdrawal instead of 1 transaction.

[snd]

the two validator sets could represent the same set of addresses! changes would have to be done to both of them individually though.

[snd]

still thinking through other solutions but they all require the relay of a validator set so far

[snd]

i took a break from this to work on paritydb for a bit. had some more thoughts on new approach over the weekend, which is simpler than my previous thinking. in the process of writing it down

[snd]

@rphmeier if you have time could you have a look at my previous comment #52 (comment)

i've thought something through that's based on that assumption. checking whether it's worthwhile to finish my writeup

[rphmeier]

Talked w/ @snd in person about this.

The foreign chain would be able to issue instant-support validator set changes with this event:
https://gist.github.com/rphmeier/7edf97f2bd8b9667d48c631117568262

The new set and signatures could then be sent to the home chain in a transaction, at which point the bridge validators would be updated.

[snd]

currently working on #54 which is unrelated and has higher priority.

i'll get back to this afterwards.

my thinking up till now assumed POW and a fuzzy sense of n blocks deep finality (since that's how parity-chain currently works).

[rphmeier]

most PoA systems have instant or max-depth finality (Tendermint, Honeybadger, CasperFFG) but Aura does not

[snd]

just to be sure:

home_chain would be POW and foreign_chain would be Aura, correct?

[rphmeier]

yeah. although it would also be interesting to explore the cases where both are PoA

[snd]

the deposit case should be fairly straightforward:

since the validator set exists on foreign_chain and transactions on foreign_chain are free for authorities we can have authorities retry ForeignChain.deposit (if no ForeignChain.Deposit event for that deposit after n blocks) until there are requiredSignatures signatures by authorities that are in the current validator set

retrying ForeignChain.deposit until ForeignChain.Deposit event for that deposit would also ensure deposit gets relayed in case ForeignChain.deposit transactions don't get mined

[snd]

closing this in favor of continuing discussion here #33