Add cross-VM transfer NFT/FT to and from EVM

[sisyphusSmiling]

Closes: #85

Description

Adds transactions that transfer tokens & NFT between VMs. Functionally, this allows a signer to both bridge an asset & transfer to any address within the target VM in a single Cadence transaction. The caveat here is that bridging and transferring from EVM to Cadence has the same limitation as any transfer in Cadence - the recipient must be configured to receive the transferred asset.

---

For contributor use:

• Targeted PR against main branch
• Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
• Code follows the standards mentioned here.
• Updated relevant documentation
• Re-reviewed Files changed in the Github PR explorer
• Added appropriate labels

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 86.21%. Comparing base (02aab3f) to head (dbd804d).
Report is 40 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #90      +/-   ##
==========================================
+ Coverage   86.19%   86.21%   +0.01%     
==========================================
  Files          18       17       -1     
  Lines         884      921      +37     
==========================================
+ Hits          762      794      +32     
- Misses        122      127       +5     

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

[joshuahannan]

Good work! Well documented transactions

[joshuahannan]

With the new token standards, NFTs aren't required to have the name NFT any more, so there is a small chance that NFTs might have different names in the future. Maybe this should be a transaction argument?

[sisyphusSmiling]

Good point. I think it'd be best to update txn interfaces to take type identifier and parse the identifier for the contract name and address. Then we can just build the composite type from the identifier without the risk that the NFT has some other name.

[joshuahannan]

Why 1.10?

[sisyphusSmiling]

The extra 10% is a buffer, but tbh the exact buffer of 10% is about the limit of what was successful in my testing - nothing very rigorous or formal.

When I was testing, I found that the storage used as calculated on withdrawal was different from storage used when escrowing. This is likely because the bridge may additionally store extra pieces of information that weren't present in the source NFT collection when it was withdrawn.

[joshuahannan]

Same comment about naming of types as the NFT one

[joshuahannan]

Can you add these generic transactions to the flow-nft and flow-ft repos also?

[sisyphusSmiling]

Yeah definitely. I may do so without the dependency on FlowEVMBridgeUtils and just parse the contract address & name in the transaction.

[sisyphusSmiling]

Updated transaction interfaces in dbd804d to allow for more precise asset bridging due to the issue raised by @joshuahannan in this comment

With the new token standards, NFTs aren't required to have the name NFT any more, so there is a small chance that NFTs might have different names in the future. Maybe this should be a transaction argument?

This new interface, in addition to being simpler in the number of arguments required to execute, will resolve the vault & collection metadata for the exact type from the source contract.