Extend `finalizeWithdrawal` in Standard Bridge Interface about contracts HOT 6 OPEN

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 for SentMessage 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.