[R-W Bridge] (Fees) Redeploy to synch Rococo and Wococo with fees/weights/rewards

[EmmanuellNorbertTulbure]

check and setup weight/fees everywhere

• BridgeHub extrinsics (finality, messages)
• BridgeHub xcm execution (ParentAsUmp for bridge-hub-kusama/rococo)
• Rockmine/Statemine XCM send export_message
• Wockmint/Statemint XCM receive execution
• hints from Slava
  • Backport xcm bridging extensions to the bridge repo #1813 (comment)
  • Backport xcm bridging extensions to the bridge repo #1813 (comment)
• design some tests Add test cases to Cumulus which simulates real e2e message delivery #2078
• type OnChargeTransaction change () -> DealWithFees<Runtime>
• setup reward constants - checking constants will be a part of Add test cases to Cumulus which simulates real e2e message delivery #2078

   pub storage DeliveryRewardInBalance: u64 = 1_000_000;
   pub storage RequiredStakeForStakeAndSlash: Balance = 1_000_000;
  

[bkontur]

One delivered message (local setup) BridgeHubRococo -> BridgeHubWococo:

on BridgeHubRococo:

submitFinalityProof:		0 (Pays=No) (multiple)
submitParachainHeads: 		0.0000505074 	ROC (fee for extrinsic)
submitParachainHeads: 		0.000050478224	ROC (fee for extrinsic)
submitParachainHeads: 		0.000050507133	ROC (fee for extrinsic)
receiveMessagesDeliveryProof:	0.000033512269	ROC (fee for extrinsic)
---------------------------------------------------------------------
Relayer expenses:		0.000185005	ROC (fees)


RewardRegistered:		0.0000001 	ROC `by DeliveryConfirmationPaymentsAdapter<100_000, 10_000>`
claimRewards:			0.000005074699	ROC (fee for extrinsic)

on BridgeHubWococo:

submitFinalityProof:		0 (Pays=No) (multiple)
submitParachainHeads:		0.000050536633	ROC (fee for extrinsic)
submitParachainHeads:		0.0000505368	ROC (fee for extrinsic)
submitParachainHeads:		0.0000505368	ROC (fee for extrinsic) - (block was pruned meantime, but was similar)
receiveMessagesProof:		0.000038495791	ROC (fee for extrinsic)
---------------------------------------------------------------------
Relayer expenses:		0,000190106	ROC  (fees)	


RewardRegistered:		0.000038495791	ROC `by RefundRelayerForMessagesFromParachain`
claimRewards:			0.000005075256	ROC (fee for extrinsic)

[bkontur]

@svyatonik
RefundRelayerForMessagesFromParachain does some reward = compute_fee(call), which is the same as pallet_transaction_payment::ChargeTransactionPayment does, so it makes sense why fee for extrinsic == RewardRegistered.

One thing, I see here that reward is much lower than paid fees on BridgeHubWococo, is it ok?

And second thing, I am just thinking, how to setup those fee consts for DeliveryConfirmationPaymentsAdapter.
I am not sure about this hard-coded constants, maybe this is something which should be able to change by governance (dedicated extrinsic?).

On the sending side we have constants for rewards and on the receiving side we have reward as fee calculation from extrinsic call.

I am just thinking, what if we have the same system on both sides:
receiveMessagesProof: calculate reward from extrinsic call + hard-coded/governance-managed constant (we do now)
receiveMessagesDeliveryProof: calculate reward from extrinsic call (we do now) + hard-coded/governance-managed constant

[svyatonik]

First of all, RBH<>WBH realyer is not using batch transactions now, so the numbers are incorrect at least at BridgeHubWococo side. So just ignore that now. Also - why you're counting multiple parachain heads transactions? Is it how it really works now? To deliver single message, it submits 3 parachain heads? If so, then it is an issue

And second thing, I am just thinking, how to setup those fee consts for DeliveryConfirmationPaymentsAdapter.
I am not sure about this hard-coded constants, maybe this is something which should be able to change by governance (dedicated extrinsic?).

Yep - we may add another signed ext for that (to refund confirmation transaction), so that it'll be consistent on both sides. @serban300 @acatangiu wdyt - do we need to do that/do that now/do that after initial deployment?

Just a brief intro on how it works now:

Right now at the source chain there are two constants to configure relayer rewards - DeliveryReward and ConfirmationReward. So rewards are computed as follows:

1. the "base reward" for delivering messages for given relayer is N * DeliveryReward, where N is number of delivered messages;
2. relayer, which has submitted the confirmation transaction gets portion of other relayer rewards. The "confirmation reward value" is N * ConfirmationReward. So the final reward is N * DeliveryReward - N * ConfirmationReward for relayer that IS NOT submitter of the confirmation transaction and N * DeliveryReward + Sum(N) * ConfirmationReward for relayer that has submitted the confirmation transaction.

The code is here: https://github.com/paritytech/parity-bridges-common/blob/master/modules/relayers/src/payment_adapter.rs#L68-L102

[serban300]

Yep - we may add another signed ext for that (to refund confirmation transaction), so that it'll be consistent on both sides. @serban300 @acatangiu wdyt - do we need to do that/do that now/do that after initial deployment?

Having a consistent approach on both sides sounds good. But I just want to take a look on the code to make sure I understand everything correctly. I'll get back with a more documented opinion.

[serban300]

@svyatonik @bkontur

I looked on the code. I suppose that if the delivery and confirmation fees are configured correctly, they will always cover the costs of submitting the extrinsics, but I think it would make sense to refund the receive_messages_delivery_proof explicitly. It's good for consistency also, but first of all I think it would be more fair to the relayers. Also I think we could implement it in the current refund signed extension. I don't think it would require big changes.

Regarding timing, if we're sure we want to do it, I would do it now, in order to avoid bugs after the initial deployment. I can take the issue if you want. However you prefer.

Another small thing, related to the fees. IIUC right now the ConfirmationReward is just the confirmation reward, while the DeliveryReward is more of a sum of confirmation reward + delivery reward. So for example for

	type DeliveryConfirmationPayments = pallet_bridge_relayers::DeliveryConfirmationPaymentsAdapter<
		Runtime,
		frame_support::traits::ConstU64<100_000>, /// DeliveryReward
		frame_support::traits::ConstU64<10_000>, /// ConfirmationReward
	>;

the confirmation reward is 10000, while the actual delivery reward is (100000 - 10000) = 90000.

I was a bit confused by this. Could we rename the DeliveryReward to something like ConfirmedDeliveryReward ? Or change the DeliveryReward to be just the delivery reward (in this case 90000) ? I think the second option would be better since it would completely prevent situations where the confirmation reward > confirmed delivery reward, which seems like a wrong configuration.

[svyatonik]

I don't mind if you want to take it, of course :) But probably we want a separate signed extension for that - it is for an opposite bridge direction. So it needs to be explored.

If we gonna do it now, then:

1. we'll need audit for that new code. Which is probably fine, because we need an audit for latest changes + fixes as well;
2. this confusion you've mentioned should gone - we should leave single constDeliveryReward in a DeliveryConfirmationPaymentsAdapter implementation. Because we'll handle confirmation reward on signed extension level

[serban300]

this confusion you've mentioned should gone - we should leave single constDeliveryReward in a DeliveryConfirmationPaymentsAdapter implementation. Because we'll handle confirmation reward on signed extension level

I hope I understood correctly. Just checking. So you're saying that we'll replace the confirmation fee with a refund of the batch of calls containing the receive_messages_delivery_proof ?