Bridge with many validators

faq
#1

We’d like to deploy the bridge with many validators (about 100) which seems to a bit unusual. Would this be feasible or is there some reason we’re not aware of why this wouldn’t work?

My naive assessment is that gas cost scale linearly with the number of validators, so this shouldn’t be that big of a deal (validators have to decide on a appropriate fee of course which might be a bit higher than normal). Transfer time might also become higher, but not by much.

What are typical gas costs of a transfer? Have you thought about batching many transfers into one to make it more efficient?

#2

Why would you want to have 100 Validators on a POA Bridge? What would you consider to be the advantage? Without a compelling use case it would seem that you are complicating bridge operations.

#3

It will not really be PoA (even though from an implementation point of view it’s quite similar): Our validators are anonymous and we have a different mechanism to manage the validator set. So we have a different security assumption which would break with few validators. We’ve got a blog post with some more details if you’re interested (it’s about the chain, but the bridge validator set would mirror the chain validators).

#4

Hmm. I think 100 validators is quite big number. The main issue that could appear is the block gas limit. For example, please look at the method executeSignatures: it expects 65 bytes as r, v, s components of the signature per validator plus 104 bytes to keep the message data. Imagine that you have 100 validators that needs to provide 51 signatures. It means that 3419 bytes will be passed in this method. And it will consume more than 230000 of gas just to be sent in a transaction. How many of gas is needed to handle this set of signatures requires additional investigation.

BTW, you can take a look gas usage for the bridge operations at the GAS CONSUMPTION document.

Regarding “batching many transfers”… Yes, I though about this and even have some ideas. For example, we could combine all the bridge requests appeared in one block in one validator transaction. This is the simplest way to implement batching. But in fact before thinking about batching it is necessary to understand possible traffic through the bridge. If it is going to be 1-2 transaction for each 100 blocks in average - there is no need to batch something.

3 Likes
#5

Thank you very much for the answer, especially the gas cost table is really helpful. Another weird thing about our bridge is that we only need one direction: ERC20 (foreign) -> native (home), but not native (home) -> ERC20 (foreign). So gas costs and limits on the foreign chain should be irrelevant fortunately.

I guess we have the same problem on the side chain though. But at least we can stretch the gas usage over multiple blocks as every validator submits their signature in a separate transaction here if I understand correctly. So if throughput is not too high and users are fine with waiting for, say, 10 minutes for their transfer to go through, this should be fine.

Regarding batching, if you’re interested, I came up with an approach described here. It has the advantage that validators don’t have to care about it and that it requires no coordination between users.

#6

If you set up your own chain and keep the validators list in a whitelist registrar, they could pay zero gasprice for their transactions. Moreover since every validator will send their signatures to the contract at home site directly and there will not be a phase when collected signatures are handled altogether, the validators do not exceed the block gas limit. So, yes - in the case of the one-way bridge (erc20-to-native) it is possible to have more than 100 validators without any changes in the code.

2 Likes