feat(protocol): introduce message.processor

[dantaik]

Allow the Bridge UI to set message.processor so only this address and message.destOwner can process the message on the destination chain.

[KorbinianK]

Should this be configurable by the user or fixed behind the scene to our relayer? If the first, this requires changes to the bridge flow, new views and logic. Doable but will cost time.

The second would be a small change on the UI.

But either should be thoroughly tested E2E before launch.

[Brechtpd]

I think using PBS is still greatly preferred because it's the only mechanism that allows 100% protection of the relayer (currently the dest owner can still create difficulties). And because the proposer also requires hooking into PBS, I think having the relayer do the same shouldn't be much difference (just connect to different RPC server, but unsure how L1 fee payment would have to be changed there if at all without looking into the specifics).

However, unlike proposing, bridge transactions also need to be processed on L2 where this type of functionality will highly likely not be available for some time (though a grant was given to make something like this), so some reasonable protections for relayers there without a PBS dependency can make sense in the short term.

The approach in this PR is indeed better, but if it's short term I guess mostly depends on how much work the change in this PR brings compared to the other.

[Brechtpd]

Should this be configurable by the user or fixed behind the scene to our relayer? If the first, this requires changes to the bridge flow, new views and logic. Doable but will cost time.

Seems fine to me if it would be fixed because it goes through our UI and our fee estimation, maybe it only needs to be a different value for other UIs?

[dantaik]

Should this be configurable by the user or fixed behind the scene to our relayer? If the first, this requires changes to the bridge flow, new views and logic. Doable but will cost time.

The second would be a small change on the UI.

But either should be thoroughly tested E2E before launch.

It should be set by the UI/relayer directly without the user's awareness. If someone set up another dapp to help users send/process messages, that app can set the processor to another value.

[dantaik]

I think using PBS is still greatly preferred because it's the only mechanism that allows 100% protection of the relayer (currently the dest owner can still create difficulties). And because the proposer also requires hooking into PBS, I think having the relayer do the same shouldn't be much difference (just connect to different RPC server, but unsure how L1 fee payment would have to be changed there if at all without looking into the specifics).

However, unlike proposing, bridge transactions also need to be processed on L2 where this type of functionality will highly likely not be available for some time (though a grant was given to make something like this), so some reasonable protections for relayers there without a PBS dependency can make sense in the short term.

The approach in this PR is indeed better, but if it's short term I guess mostly depends on how much work the change in this PR brings compared to the other.

In terms of implementation, I think this should be easy.

I think even with PBS, we may still want this feature so that even if someone can get transaction inclusion promise from PBS he/she cannot steal messages that sets processor to another address.

[dantaik]

Guys, shall we merge this PR please? Need a quick decision here.

[cyberhorsey]

Guys, shall we merge this PR please? Need a quick decision here.

Not sure if we will even need it because I'm not expecting many relayer competitions tbh, but if you are, we can merge it and I can update relayer and korbi can do UI.

[dantaik]

Guys, shall we merge this PR please? Need a quick decision here.

Not sure if we will even need it because I'm not expecting many relayer competitions tbh, but if you are, we can merge it and I can update relayer and korbi can do UI.

Maybe we should also have a poll for this one. @Brechtpd @adaki2004 @cyberhorsey @KorbinianK please vote against/for it. 👍 or 👎 please