Code Monkey home page Code Monkey logo

fx-portal's Introduction

FX-Portal (Flexible Portal)

FxPortal for Polygon (prev Matic) Chain. No mappings. Seamless communication with the Ethereum Network.

Audits

Contents

What is FX-Portal?

A powerful yet simple implementation of Polygon's state sync mechanism. (The Polygon POS-Portal bridge is also based on it, but relies on a centralized party mapping tokens on one chain to their contract on the other.) There are examples of how to use the bridge in the contracts/examples directory. You can use these examples to build your own implementations or own custom bridge.

In short, this bridge allows arbitrary message bridging without mapping, with built-in support for a number of token standards.

In more detail, FX-Portal makes use of a message passing mechanism built into the Polygon POS chain, leveraging it to pass messages from one chain to another. Using a mechanism for generating deterministic token addresses, this can be used to create asset bridges without the need for a centralized party documenting the relationship between assets on the two chains (commonly referred to as a 'mapping' here).

Some usecases of FX-Portal

What about POS-Portal?

POS-Portal is another bridge, but it works only for few ERC standards and requires mappings. It is more developer-friendly in some ways, and allows customization without much headache.

While FX-Portal focuses on permissionlessness and flexibility, a developer might have to write more code than POS-Portal. On the other hand, FX-Portal requires no mapping, meaning that there is no need to rely on an authorized party to submit the mapping with FX-Portal.

Can I build my own custom bridge?

Yes. You can check docs here: https://wiki.polygon.technology/docs/pos/design/bridge/l1-l2-communication/fx-portal/

What can I build with FX-Portal?

  • Arbitrary state bridge (examples/state-transfer)
  • Normal ERC20 bridge (examples/erc2-transfer)
  • ERC20 token generator bridge (example/mintable-erc20-transfer)

What are FxChild and FxRoot?

FxChild (FxChild.sol) and FxRoot (FxRoot.sol) are the main contracts on which the bridge works. It calls and passes data to user-defined methods on another chain without needing a mapping. You can deploy your own FxChild and FxRoot, but there is no need. If you pass the data to the deployed instances of FxChild or FxRoot, the clients will pick up the data and pass it to the other chain.

Deployment Addresses

Mumbai

Contract Deployed address
FxRoot (Goerli) 0x3d1d3E34f7fB6D26245E6640E1c50710eFFf15bA
FxChild (Mumbai) 0xCf73231F28B7331BBe3124B907840A94851f9f11

Mainnet

Contract Deployed address
FxRoot (Ethereum Mainnet) 0xfe5e5D361b2ad62c541bAb87C45a0B9B018389a2
FxChild (Matic Mainnnet) 0x8397259c983751DAf40400790063935a11afa28a

Development

This project can be compiled and tested with Hardhat and Foundry. Hardhat unit tests are located in /hardhat and Foundry unit + invariant tests can be found in the /test directory.

  • Setup: yarn install and/or forge install
  • Compile: yarn build and/or forge build
  • Test: yarn test and/or forge test -vvv
  • Coverage: yarn coverage
  • Lint: yarn lint, yarn prettier:write

Proof Generation

A common question is how to generate proofs for the bridge. We'll explain what that means, and then list solutions.

To withdraw tokens on the root chain, first we call the relevant withdraw() method the child tunnel contract (which burn the respective tokens on child); and we use this transaction hash to generate proof of inclusion which acts as the argument to receiveMessage() in the respective root tunnel contract. Please see here.

To generate the proof, you can either use the proof generation API hosted by Polygon or you can also spin up your own proof generation API by following the instructions here.

The test suite also replicates proof generation (located at hardhat/tunnel/payload), the following hardhat task can help generating the proof for custom chains.

Usage: npx hardhat exit-proof --help

hardhat [GLOBAL OPTIONS] exit-proof [--sig <STRING>] --tx <STRING>

OPTIONS:

--sig log event hex signature (defaults to 0x8c5261668696ce22758910d05bab8f186d6eb247ceac2af2e82c7dc17669b036 for `MessageSent(bytes)`)
--tx burn transaction hash

exit-proof: Generates exit proof for the given burn transaction hash

Example: npx hardhat exit-proof --network polygon --tx 0x1cfc2658719e6d1753e091ce4515507711fe649269e75023c0f1123cd6e37c1a

➜ npx hardhat exit-proof --network polygon --tx 0x1cfc2658719e6d1753e091ce4515507711fe649269e75023c0f1123cd6e37c1a
0xf909988201f4a0c8e08649aed43a802751213ece497804bd3acaee5d237326e0839c413b0920408402ae4af38464ae328da0d4ab5e911c81df7bfdc20e816de49c97f4808fcb1bcad63e328d0bca15a099e9a05e130cf2c4fb5778776309c95af5ca17ecbb47f6d3fc81c09bf110786269e2a6b903e702f903e3018355f7a2b9010000000000000000000000000000000000000000000000000000000000000000000000000000000200000000000001000000008000000000000000000000000000000000000000000000000008000000800008000000000000000100000000000000000000020000000000000000000800000000000040000080000018000004000040000000040000000000000000000000020000000000000000000000000000200000000000001000000000000000000000000000000000000000000000004000000002000000000401000000000000000000000000000000120020000020000000100000000000000000000000000000001000000000000000000000100000f902d8f89b94aaf7701db5f8704450c6db28db99ea0a927e76adf863a0ddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3efa000000000000000000000000086eb278eeed79a44b5e3c83a012b96aa450912aba00000000000000000000000000000000000000000000000000000000000000000a0000000000000000000000000000000000000000000000087de5c5bd1dccf709cf8f994d531cf2142d9b9dc8b077df3c4e93b46e7cf879ae1a08c5261668696ce22758910d05bab8f186d6eb247ceac2af2e82c7dc17669b036b8c000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000080000000000000000000000000922ac473a3cc241fd3a0049ed14536452d58d73c000000000000000000000000aaf7701db5f8704450c6db28db99ea0a927e76ad00000000000000000000000086eb278eeed79a44b5e3c83a012b96aa450912ab000000000000000000000000000000000000000000000087de5c5bd1dccf709cf9013d940000000000000000000000000000000000001010f884a04dfe1bbbcf077ddc3e01291eea2d5c70c2b422b415d95645b9adcfd678cb1d63a00000000000000000000000000000000000000000000000000000000000001010a000000000000000000000000086eb278eeed79a44b5e3c83a012b96aa450912aba00000000000000000000000009ead03f7136fc6b4bdb0780b00a1c14ae5a8b6d0b8a00000000000000000000000000000000000000000000000000004f478e611780000000000000000000000000000000000000000000000000000e5dc5800087ecc000000000000000000000000000000000000000000000377f97e15a609a765bd00000000000000000000000000000000000000000000000000e0e7df19f706cc000000000000000000000000000000000000000000000377f9830a1eefb8ddbdb90537f90534f891a02dad7ffa3e44092c885002e5d2a48f58793d842ccc99aeccdb23c0094ac32c7da04696502faee79a586bd17877e2d1a66dd8dc0af8381fc488017c091e09dd3024a0360e2917de87f795b9350a7c29785a74da6582a4aeac0f20890cb0ac9820178c8080808080a0e2c9ed1fad4ea1a707e92bd2823e14a47f3cd5ff74258255c5b4961656bb4d098080808080808080f8b1a0299225ca484915f0ae642515e04aa9ddb2a86388f4404760715fa012f910ad28a0262c2288a6a1205fb045b10c14a9cfbac0196f9bb09b49e6523d90b4b8837cf5a01f727d97002d78492609ee434fc6daf0ab9f8347c393f488a178a59ad79775b7a0aa49afed4d9c80d7146bd606a9b111859a7b2b163e99b6320913a0977f1716aba026620528634fdd31f0bcbe97eef787f9244cf317928675c6da146d416ec282a4808080808080808080808080f903eb20b903e702f903e3018355f7a2b9010000000000000000000000000000000000000000000000000000000000000000000000000000000200000000000001000000008000000000000000000000000000000000000000000000000008000000800008000000000000000100000000000000000000020000000000000000000800000000000040000080000018000004000040000000040000000000000000000000020000000000000000000000000000200000000000001000000000000000000000000000000000000000000000004000000002000000000401000000000000000000000000000000120020000020000000100000000000000000000000000000001000000000000000000000100000f902d8f89b94aaf7701db5f8704450c6db28db99ea0a927e76adf863a0ddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3efa000000000000000000000000086eb278eeed79a44b5e3c83a012b96aa450912aba00000000000000000000000000000000000000000000000000000000000000000a0000000000000000000000000000000000000000000000087de5c5bd1dccf709cf8f994d531cf2142d9b9dc8b077df3c4e93b46e7cf879ae1a08c5261668696ce22758910d05bab8f186d6eb247ceac2af2e82c7dc17669b036b8c000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000080000000000000000000000000922ac473a3cc241fd3a0049ed14536452d58d73c000000000000000000000000aaf7701db5f8704450c6db28db99ea0a927e76ad00000000000000000000000086eb278eeed79a44b5e3c83a012b96aa450912ab000000000000000000000000000000000000000000000087de5c5bd1dccf709cf9013d940000000000000000000000000000000000001010f884a04dfe1bbbcf077ddc3e01291eea2d5c70c2b422b415d95645b9adcfd678cb1d63a00000000000000000000000000000000000000000000000000000000000001010a000000000000000000000000086eb278eeed79a44b5e3c83a012b96aa450912aba00000000000000000000000009ead03f7136fc6b4bdb0780b00a1c14ae5a8b6d0b8a00000000000000000000000000000000000000000000000000004f478e611780000000000000000000000000000000000000000000000000000e5dc5800087ecc000000000000000000000000000000000000000000000377f97e15a609a765bd00000000000000000000000000000000000000000000000000e0e7df19f706cc000000000000000000000000000000000000000000000377f9830a1eefb8ddbd82002201

Future Plans

Polygon has announced its intent to migrate the chain to a zk validium. This would mean changes to the architecture and infrastructure. One solution that has been discussed is an LXLY Bridge, a bridge structure developed for zkEVM. (Alternative presentation timestamped at the section about the bridge)

fx-portal's People

Contributors

akkii4 avatar dhairyasethi avatar gretzke avatar jdkanani avatar pranavdaa avatar qedk avatar raneet10 avatar reddyismav avatar sidhant-shr avatar wschwab avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar

fx-portal's Issues

State Transfer - state message relay time

  • First, this is an amazing feature and was pumped to implement it. Excited that I came across it so soon after its creation.

  • I've implemented this with Goerli and Mumbai testnets.

  • I've successfully run the State Transfer 10 times now, each completed at around 5-8 minutes(root to child).

  • That being said, my use case would ideally entail the relay time to be 2 minutes, tops. Are there plans to implement this for use cases requiring faster turn around? Or is there a method by which I can speed up the State Transfer?

-Really, appreciate that you made this!

Is fx-portal still a valid approach for token bridging?

From token mapper, it says fx-portal was discontinued. What's the reason for that?
Even without the UI, I assume this approach still works since the contracts still there. But I wonder is it safe to continue using this for erc20 bridging?

Is the reason somehow related to polygon 2.0 that POS chain will be migrate to a zkEVM validium, so the state sync may not continue to work?

truffle compile fails for the FxERC721ChildTunnel.sol smart contract inside examples/

When we compile the contracts using truffle compile, the compilation fails with the below error message:

TypeError: Member "ownerOf" not found or not visible after argument-dependent lookup in contract IFxERC721.
  --> project:/contracts/examples/erc721-transfer/FxERC721ChildTunnel.sol:50:31:
   |
50 |         require(msg.sender == childTokenContract.ownerOf(tokenId));
   |                               ^^^^^^^^^^^^^^^^^^^^^^^^^^

Compilation failed. See above.

When we investigate the above smart contract, we find that the contract FxERC721ChildTunnel.sol inherits from the contract IFxERC721 which doesn't contain any definition for the function ownerOf().

How are network fees handled?

Hey!

I just got through this repo and I'm trying to understand how it all fits together. While it makes it complete sense on the contract side, I'm wondering who pays for network fees?

Technical Support Required - FxPortal Implementation `Fail with error ‘Leaf index is too big’` (Goerli/Mumbai)

Hello! I'm the Lead Developer working on integrating GoldHunt Game (thegame.gold) with the Polygon network. I intend to build a custom implementation of the FxPortal Root & Child Contracts (https://github.com/fx-portal/contracts) to enable our community to move tokens between Ethereum <-> Polygon.

I need technical support on implementing this bridge on the Test networks (Goerli, Mumbai).

The problem: when I call function receiveMessage(bytes memory inputData) public virtual on my implementation of the Root contract, I am getting a Fail with error 'Leaf index is too big' error on the transaction.

Failed Transactions (same error):

I generate the burn proof as such:


const execute = async () => {

  const posClient = await getPOSClient();

  const proof = await posClient.exitUtil.buildPayloadForExit(

    "0x76bd13760e3dbea702450f8741b405bf528be0078570d94c405a9183a8911ef9", // Withdraw transaction hash

    "0x8c5261668696ce22758910d05bab8f186d6eb247ceac2af2e82c7dc17669b036"  // MESSAGE_SENT_EVENT_SIG: Do not change this

  )

  console.log(" ----- BURN PROOF -----")

  console.log(proof)

}

Where https://mumbai.polygonscan.com/tx/0x76bd13760e3dbea702450f8741b405bf528be0078570d94c405a9183a8911ef9 is the Withdraw transaction I submitted on the Mumbai network.

My implementation of the FxMintableERC20RootTunnel is deployed at https://goerli.etherscan.io/address/0xC0Af0b1a10F2417D62EE044BC99dB1b40b4DC82e - you'll notice a number of failed transactions all throwing the same error.

My implementation of the FxMintableERC20ChildTunnel is deployed at https://mumbai.polygonscan.com/address/0x38530B465C2937b6f3fB7559a796156D2a0A9f02 - I submitted the Withdraw transaction on Mumbai to this contract (see above) over 24 hours ago.

I am attempting to send GGold (ERC20) back and forth across my tunnel, and am unable to resolve the last step to receive the funds back from the Tunnel on Goerli due to the error above.

GGold (Goerli) - https://goerli.etherscan.io/address/0xbdCDF80D26DDA1ae2F9C0003995d160F4893F20A

pGGold (Polygon) - https://mumbai.polygonscan.com/address/0xC440ddBA14e585fdF395bD74B85797e41fd8317c

I can see that the error is ultimately being thrown by the Merkle library defined as such:

pragma solidity ^0.8.0;

library Merkle {
    function checkMembership(
        bytes32 leaf,
        uint256 index,
        bytes32 rootHash,
        bytes memory proof
    ) internal pure returns (bool) {
        require(proof.length % 32 == 0, "Invalid proof length");
        uint256 proofHeight = proof.length / 32;
        // Proof of size n means, height of the tree is n+1.
        // In a tree of height n+1, max #leafs possible is 2 ^ n
        require(index < 2**proofHeight, "Leaf index is too big");

        bytes32 proofElement;
        bytes32 computedHash = leaf;
        for (uint256 i = 32; i <= proof.length; i += 32) {
            assembly {
                proofElement := mload(add(proof, i))
            }

            if (index % 2 == 0) {
                computedHash = keccak256(abi.encodePacked(computedHash, proofElement));
            } else {
                computedHash = keccak256(abi.encodePacked(proofElement, computedHash));
            }

            index = index / 2;
        }
        return computedHash == rootHash;
    }
}

but this entire section of code was defined as part of the FxBaseRootTunnel.sol file defined in the fx-portals repo which I am using an exact copy of so I'm not sure how to debug this issue.


Please advise on how to resolve this issue - I've already read through https://docs.polygon.technology/docs/develop/l1-l2-communication/fx-portal/ and this issue is not covered and I am unable to find any other sources online about how to resolve it.

Any help you can provide would be greatly appreciated, as we're excited about being able to onboard thousands of new users to the Polygon network once we're able to build out this infrastructure!

FelixTheCat22

FelixTheCat is owner of 0x0000000000000000000000000000000000001010

His new wallet is 0x682f81e57eaa716504090c3ecba8595fb54561d8
Screenshot_20240407_162742_Chrome

State transfer from Polygon to Ethereum

Hello, I am wondering how to transfer data from child to Root, how to generate the proof as an input to receiveMessage() to receive the messages?
In the Doc of Polygon, it shows:
// npm i @maticnetwork/maticjs
// for goerli - mumbai testnet
const getPOSClient = (network = 'testnet', version = 'mumbai') => {
const posClient = new POSClient()
return posClient.init({
log: true,
network: network,
version: version,
child: {
"matic-provider"
},
parent: {
"matic-provider"
}
}
});
}
posClient.exitUtil.buildPayloadForExit("burntxhash","event signature")

I am wondering how to set "matic-provider", "matic-provider" and burntxhash, event signature

Contract Deployment to Sepolia

With Goerli now restricting faucet access, is there any chance of getting the contracts deployed on Sepolia? I am teaching a class on bridging with fxportal, but with the goerli requirement, it makes it very hard for my students to complete their project of bridging NFTs as they have a hard time getting test tokens.

Is this still portal functional?

is this still functional?, it doesn't seem to be sync activity between ethereum and the child contract "fxChild".

Looking at the contract in mumbai, ther las activity was 3 months ago.

About FxERC20Transfer withdraw test code

Hi, i have a question about FxERC20Transfer withdraw testcode in feature/hardhat_unittestbranch.
So i tested erc20 state transfer with test/tunnel/FxERC20Tunnel.ts.
I understand mapToken, deposit function, but i'm little confused of this withdraw line.

In the test code after deposit(), the wallet.getAddress() has 10(i will omit 10^18) in child token contract(the mapped contract).
And also the wallet.getAddress() has 9990 in the root token contract.

child token contract wallet.getAddress() balance : 10
root token contract wallet.getAddress() balance : 9990

When withdraw() function call(withdraw 5 from child token contract) i thought below will be the result.

child token contract wallet.getAddress() balance : 5
root token contract wallet.getAddress() balance : 9995

But instead of above balance, the test code is showing me below result.

child token contract wallet.getAddress() balance : 5
root token contract wallet.getAddress() balance : 9990

So to sum up my question is
Q1. Is the wallet.getAddress() balance I expected right? - child token contract: 5, root token contract: 9995
Q2. Is the withdraw test code resulted becuase the checkpointManager is not working in local test environment?
Q3. What is the checkpointManager0x600e7E2B520D51a7FE5e404E73Fb0D98bF2A913E in the test code? over here.

Thanks for advanced!

Missing default return value in MerklePatriciaProof.verify

The compiler fires this warning:

Warning: Unnamed return variable can remain unassigned. Add an explicit return with value to all non-reverting code paths or name the variable.
  --> @maticnetwork/fx-portal/contracts/lib/MerklePatriciaProof.sol:20:30:
   |
20 |     ) internal pure returns (bool) {
   |                              ^^^^

Is the recent vulnerability fix to the mask needed for the RootTunnel too?

As there was a recent vulnerability fix to revert masks that start with 0x00, does the fix also need to be done for the contracts in fx portal, especially the part where the mask will be used to produce the exit hash which supposed to be unique?

Particularly this part: https://github.com/fx-portal/contracts/blob/main/contracts/tunnel/FxBaseRootTunnel.sol#L79

The usage of the mask looks almost the same as how it is used in the contracts on the main Polygon repo.

This was the fix applied on the contracts in the Polygon repo some time back: https://github.com/maticnetwork/contracts/pull/381/files

Which is mainly this:

require(vars.branchMaskBytes[0] == 0, "incorrect mask");

Should setFxRootTunnel and setFxChildTunnel be made virtual?

Currently, the setFxRootTunnel and setFxChildTunnel functions are non-virtual. Inherited classes are unable to override with their own logic or add their own modifiers to restrict anyone from calling them out of mischief.

Should these functions be made virtual intead?

recieveMessage function error

Hey everyone
I started to get issues w/ this part --> https://docs.polygon.technology/docs/develop/l1-l2-communication/state-transfer
and specifically w/ recieveMessage function (Polygon-->ETH transfer). Couple days ago I tested this function and it worked and now I see a warning "Exception in contract code" and failed gas estimation in MM. Contracts did not change.

So.. I wonder if there were any updates on this state transfer in recent days or maybe some issues I am not aware of on Goerli and Mumbai nets? Thanks.

SOLIDITY CONTRACT

Please remove mr22 contract. And have the owner ship of 0x0000000000000000000000000000000000001010 to 0x5dA1CD01B5d373b1B9Ca25d46660b51708D1dFc8 Felix1 or Felix255

Missing SPDX license in ExitPayloadReader and RLPReader

The compiler fires these warnings:

Warning: SPDX license identifier not provided in source file. Before publishing, consider adding a comment containing "SPDX-License-Identifier: <SPDX-License>" to each source file. Use "SPDX-License-Identifier: UNLICENSED" for non-open-source code. Please see https://spdx.org for more information.
--> @maticnetwork/fx-portal/contracts/lib/ExitPayloadReader.sol


Warning: SPDX license identifier not provided in source file. Before publishing, consider adding a comment containing "SPDX-License-Identifier: <SPDX-License>" to each source file. Use "SPDX-License-Identifier: UNLICENSED" for non-open-source code. Please see https://spdx.org for more information.
--> @maticnetwork/fx-portal/contracts/lib/RLPReader.sol

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.