Comments (6)
Ideally we could have an extraData
field not only on finalizeWithdrawal
but on finalizeDeposit
too. There are cases where a contract on L2 might get sent tokens from L1 but only want to allow them to be withdrawn by users after some condition is met.
Specifying the condition is currently not possible (unless my assumption above is correct that you could do this with 2 calls).
from contracts.
Re 1: Uh sure it's prob possible, but does not sound like great UX
Re 2: Agreed
from contracts.
I have a plan in motion to collect this and other feature requests for the bridge so that we can get a proper community-driven implementation, stay tuned :)
I have been thinking about another bit of devex here which you folks might have a good grasp on. I was wondering--would it be useful to expose the unique identifier for cross-chain messages more readily in the messengers and token gateways? For example, sendMessage
could return a messageHash
or nonce
, and then the gateways could return that back through initializeDeposit/Withdrawal
. Seems like this might be useful info to be able to access, but I'm not positive that it actually is. Any thoughts?
from contracts.
One thing to note: The PoC is incorrect/unsafe because the message being validated allows anybody to specify to
. The correct message would be one which commits to the withdrawal's receiver being the MM address (MUST be immutable) AND any additional data the user provided (e.g. the actual receiver, any fees they want etc.).
bytes memory data = abi.encode(to, (address))
bytes memory call = abi.encodeWithSelector(L2ERC20.withdrawTo.selector, address(this), amount, data);
and client side the user would submit the withdrawal as done here, but by also encoding their data (js pseudocode below):
// user specifies their address in the extraData because their address is not passed to the L1 messenger
// due to the call-flow being: User -> L2ERC20 -> L2Messenger -> L1Messenger, meaning that the l2_msgsender
// is L2ERC20
withdrawalTx = await L2_ERC20.connect(l2account1).withdrawTo(
marketMaker.address,
amount,
abi.encode(['address'], [await l2account1.getAddress()]
)
Separately from that, the PoC is missing features like greenlightMany
, and allowing the MM to specify fees, but that should be downstream of getting the above implemented.
I think that this approach is the simplest one for getting Fast Withdrawals minimally enabled, without introducing any additional mechanisms/overheads. The client side watcher for this should also be pretty simple:
- Define an L1 and L2 endpoint,
- watch for
WithdrawalInitiated
events on L2 for your token(s) (or filter forSentMessage
on the L2 relay which come from the L2 tokens you're watching) - check if
to
is your MM contract address and decode the data - call
greenlight
with the parameters specified, and set a T timer - once T passes, call
claim
on the L1 contract
What's nice about this is that it requires 1 L2 transaction for the user w/o any additional approvals, and 1 L2 transaction & 1 L1 transaction by the market maker.
from contracts.
@gakonst I believe it's possible to implement your PoC bridge without this addition if you used 2 xDomain messages right? One where you send the tokens (with no context) and a second one with a custom call using the xDomainMessenger to call a function on your L1 Market Maker contract like registerTokenTransferContext()
which could contain the additional context?
I would still much rather have an extraData
field, just confirming that I'm thinking about things correctly 😅
from contracts.
We seem to agree here. Anyone want to pick up @gakonst's PR again?
from contracts.
Related Issues (20)
- Publish correct version of NPM package HOT 1
- Make `ethers` a peer dependency
- Improve clarity of chainID recovery logic HOT 1
- Update CTC to use `OVM_CTCSequencer` instead of `OVM_Sequencer`
- Clear up compiler warnings HOT 5
- Add progress bar to contract deployment HOT 2
- Decimals broken on oWETH HOT 4
- Commit the typechain contracts HOT 1
- Authenticating sequencer via ecrecover
- L1 <> L2 Create2 Address Mismatch HOT 5
- Consider resetting xDomainMessageSender after relaying a message
- cleanup: Rename all instances of `push2` and `get2`
- OVM_L1ETHGateway references ERC20 in comments HOT 5
- Use ethers.constants.ZeroAddress instead of ZERO_ADDRESS
- [GOOD FIRST ISSUE] Misleading comment on the ETH Gateway
- Use ethers.constants.HashZero instead of NULL_BYTES32 HOT 1
- Lib_MerkleTree overwrites elements of the input array when multiple elements are passed in HOT 3
- Support ERC677 for ERC20 deposit HOT 2
- deprecate mockOVM_ECDSAContractAccount
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
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.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from contracts.