Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Transact from eth to sub #1141

Open
wants to merge 45 commits into
base: bridge-next-gen
Choose a base branch
from
Open

Conversation

yrong
Copy link
Contributor

@yrong yrong commented Feb 7, 2024

Copy link

codecov bot commented Feb 7, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

❗ No coverage uploaded for pull request base (bridge-next-gen@7f41605). Click here to learn what that means.

❗ Current head 68a567f differs from pull request most recent head bfdff26. Consider uploading reports for the commit bfdff26 to get more accurate results

Additional details and impacted files
@@                Coverage Diff                 @@
##             bridge-next-gen    #1141   +/-   ##
==================================================
  Coverage                   ?   79.32%           
==================================================
  Files                      ?       13           
  Lines                      ?      416           
  Branches                   ?       74           
==================================================
  Hits                       ?      330           
  Misses                     ?       69           
  Partials                   ?       17           
Flag Coverage Δ
solidity 79.32% <100.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

contracts/src/Gateway.sol Outdated Show resolved Hide resolved
@yrong
Copy link
Contributor Author

yrong commented Feb 14, 2024

Could we start with the teleport pattern as before which will make things a bit easier? Or by no means that third party chain will accept that?

I'm not sure but as we may notice to support transact it requires some custom xcm config anyway and only DOT from BH is required to pay the xcm fee so maybe not a big deal?

@vgeddes
Copy link
Collaborator

vgeddes commented Feb 14, 2024

Could we start with the teleport pattern as before which will make things a bit easier? Or by no means that third party chain will accept that?

Nope, unfortunately teleportation is strictly not allowed between system and third party chains.

@yrong
Copy link
Contributor Author

yrong commented Feb 14, 2024

@vgeddes To not use teleport for transact in
Snowfork/polkadot-sdk@51b76fe

@alistair-singh
Copy link
Contributor

alistair-singh commented Feb 14, 2024

Nope, unfortunately teleportation is strictly not allowed between system and third party chains.

What if we teleported the DOT after the UniversalOrigin but before DescendOrigin. Then the Target chain would allow teleport of DOT from the Snowbridge Location (GlobalConsensus(Ethereum {chain_id:...})). Only the bridge inbound-queue pallet should be able to assume this location's privilege.

UniversalOrigin(GlobalConsensus(Ethereum)),
ReceiveTeleportedAsset { DOT },
BuyExecution { DOT },
DescendOrigin(AccountKey20 { msg.sender })
Transact { OriginKind = "SovereignAccount" OR "Xcm" }

@yrong
Copy link
Contributor Author

yrong commented Feb 15, 2024

@alistair-singh As Vincent mentioned teleportation is strictly not allowed here so I've removed that in recent commits

@yrong yrong marked this pull request as ready for review February 15, 2024 06:17
Copy link
Collaborator

@vgeddes vgeddes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First round of review comments..

contracts/src/Gateway.sol Outdated Show resolved Hide resolved
.gitignore Outdated Show resolved Hide resolved
Comment on lines 145 to 147
if (
message.call.length == 0 || message.fee == 0 || message.weightAtMost.refTime == 0
|| message.weightAtMost.proofSize == 0
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All this validation can be done inline in Gateway.transact. Its very little code and I don't think it requires its own function.

Copy link
Contributor

@claravanstaden claravanstaden Apr 10, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where did this validation move to? Should it not be done here somewhere?

I see it was removed here: 00abc13 and removed because of @vgeddes comment: #1141 (comment)

Should we not still at least check destinationFee > 0? Ie does it make sense to allow a likely invalid message to be sent and the user to pay for it when it will likely not succeed?

Copy link
Contributor Author

@yrong yrong Apr 11, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree. I think we need these checks on source chain so add it back here 3dd1adc

contracts/src/Types.sol Outdated Show resolved Hide resolved
contracts/src/interfaces/IGateway.sol Show resolved Hide resolved
contracts/src/Gateway.sol Outdated Show resolved Hide resolved
@yrong
Copy link
Contributor Author

yrong commented Mar 6, 2024

One caveat for Parachain to integrate is that since the fee is paid upfront on Ethereum and UnpaidExecution is sent to the dest chain, the risk potentially is a malicious user can spam the dest chain to call expensive transact with a tiny fee. So It's the responsibility of Parachain to inspect/check the fee passed through can cover the execution cost though not charged.

Custom Xcm config for that In Snowfork/polkadot-sdk@c18f771 could be referenced.

Copy link
Contributor

@claravanstaden claravanstaden left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👏🏻 Awesome!

contracts/src/Gateway.sol Outdated Show resolved Hide resolved
web/packages/test/scripts/configure-substrate.sh Outdated Show resolved Hide resolved
web/packages/test/scripts/set-env.sh Outdated Show resolved Hide resolved
@claravanstaden
Copy link
Contributor

@alistair-singh As Vincent mentioned teleportation is strictly not allowed here so I've removed that in recent commits, the current fee flow is:

  • charge fees from msg.sender and deposit to agent of the dest chain, on Ethereum
  • transfer fees from sovereign of dest chain to BH, on BH
  • buy execution and pay fees from sovereign of BH, on dest chain

Does this PR still work this way?

@yrong yrong changed the base branch from main to bridge-next-gen April 11, 2024 02:24
@yrong
Copy link
Contributor Author

yrong commented Apr 11, 2024

Does this PR still work this way?

Nope. Sorry for the confusion, I should have removed it earlier.

@claravanstaden
Copy link
Contributor

Does this PR still work this way?

Nope. Sorry for the confusion, I should have removed it earlier.

Would you mind adding a new comment with the updated functionality? That summary is helpful to understand the PR at a high level.

@vgeddes
Copy link
Collaborator

vgeddes commented Apr 11, 2024

One caveat for Parachain to integrate is that since the fee is paid upfront on Ethereum and UnpaidExecution is sent to the dest chain, the risk potentially is a malicious user can spam the dest chain to call expensive transact with a tiny fee. So It's the responsibility of Parachain to inspect/check the fee passed through can cover the execution cost though not charged.

Custom Xcm config for that In Snowfork/polkadot-sdk@c18f771 could be referenced.

Good catch. At least with paid execution, the Transact includes the weight required at most, and if the user's supplied execution fee does not cover the maximum transact weight, the xcm will not be executed.

contracts/src/Gateway.sol Outdated Show resolved Hide resolved

/// @inheritdoc IGateway
function quoteSendCallFee(uint128 destinationFee) external view returns (uint256) {
Costs memory costs = _calculateTransactCost(destinationFee);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can remove destinationfee from here because only delivery costs are paid in the new fee model.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.


## Explanation

Basically it works as follows:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would add a fee flow section:

  • dApp is represents msg.sender or its sovereign depending on context.
  • Parachain represents the target parachain, its sovereign or its agent depending on context.
Sequence Where Who What
1 Gateway dApp pays(ETH, converted to DOT here) Parachain Agent for delivery costs only (no execution cost)
2 Bridge Hub Relayer pays(DOT) node for execution
3 Bridge Hub Parachain Sovereign pays(DOT) Relayer for delivery (refund+reward)
4 Parachain dApp pays(DOT, Native) for execution only.

Does this balance? Yes because the parachain agent collects fees for delivery on Ethereum side and the Parachain Sovereign pays for delivery on the Bridge Hub side.

Execution costs totally belongs to the dApp prefunding its sovereign on the Parachain.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for summarizing. Added to rfc in 53791d2

}

/// @inheritdoc IGateway
function quoteSendCallFee(uint128 destinationFee) external view returns (uint256) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

destinationFee can be removed from here, as the quote should only return delivery fees.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants