0xpolygon / edge-contracts Goto Github PK

https://github.com/ethereum/solidity-blog/blob/499ab8abc19391be7b7b34f88953a067029a5b45/_posts/2022-06-15-inline-assembly-memory-side-effects-bug.md

Add state sender contract to send data to Polygon chain.

V3 node will listen to these states and relay them on Polygon chain.

Some sections are duplicated or misplaced. Most likely when we merged branches last time.

Currently, there is no support for bridging the native token between rootchain and childchain.

For example, on Ethereum, the native token is Ether, i.e. not an ERC20. This means the RootERC20Predicate contract cannot be used to facilitate the deposit and withdrawal of Ether.

This Github issue proposes adding new contracts RootNativePredicate and ChildNativePredicate which can be used to facilitate the deposit and withdrawal of Ether. (Open to naming convention changes)

One could argue that users can deposit WETH (an ERC20 wrapper of Ether) however, this causes significant UX friction, requiring users to wrap and unwrap, while also introducing issues for non-crypto native users who are not familiar with WETH and the need for wrapping.

I will be implementing the contracts required to support Native Token Bridging and ideally, it would be merged back to this repository. I'll share a draft PR as it progresses. Open to discussion here

Before the audit, we should consider using the latest stables for all packages involved and backtesting, as well as run everything on latest LTS (the CI does this) to prevent any tooling pitfalls in the future.

I am trying to run the test suite out of the box (clone, install deps, run) but Im getting the following errors:

 ~/d/core-contracts/test  forge test --via-ir                          ok  1m 5s  slither-venv py

[⠒] Compiling...
[⠆] Compiling 258 files with 0.8.19
[⠔] Solc 0.8.19 finished in 34.64s
Error:
Compiler run failed:
Error: Yul exception:Cannot swap Variable var_pt1yy with Variable expr_11679_component_1: too deep in the stack by 2 slots in [ var_pt3_mpos RET var_pt1yy var_pt1yx var_pt1yy var_pt1yx var_pt2zy var_pt2zx var_pt1zy var_pt1zx var_pt3_mpos var_pt1xy var_pt1zx var_pt2xy var_pt1xx var_pt2xx var_pt1zy var_pt2zx var_pt2zy expr_11679_component expr_11679_component_1 ]
No memoryguard was present. Consider using memory-safe assembly only and annotating it via 'assembly ("memory-safe") { ... }'.
No memoryguard was present. Consider using memory-safe assembly only and annotating it via 'assembly ("memory-safe") { ... }'.

As you can see Im running the forge test command which results in the above error.

Is it a known issue that the test suites fail or that just misconfiguration on my side?

ERC 20 Bridges / withdraws to Ethereum: To withdraw a token to Ethereum, the withdrawal contract on Ethereum is RootERC20Predicate. At present, this contract has the following features:

• Any amount of any linked token can be withdrawn. The withdrawal is triggered on L2, with the exit being able to be executed as soon as the Checkpoint is submitted.
• There is no pause capability on withdraws.

I suggest the creation of an extension to RootERC20Predicate that does the following:

• Having a pause capability that could pause calls to _withdraw() https://github.com/0xPolygon/core-contracts/blob/main/contracts/root/RootERC20Predicate.sol#L127
• For any withdraw above a selectable limit (by an admin), the withdraw sits in the contract for 24 hours (again programmable) before being released. This would complicate the user interface for people creating the UI for the bridge.
• Have a rate limit "alarm" that would detect large outflows in a given time period. The "alarm" could emit an event, which would be easy for catch and surface in a dashboard. We could also consider when the alarm occurs, allowing the contract itself to automatically pause the withdraw function, or have all withdraws go through a 24 hour hold.

The goal of all of the suggestions is to have a way for us to slow down / stop an in progress attack.

Maybe the new contract could be called RootERC20PredicateLimits.

I am happy to commence work on this. However, before I start, I would like to have a discussion to ensure we have alignment on how this could be added to the repo.