Specify deposit IDs

[pixelcircuits]

Updated deposit ID compute process

[pixelcircuits]

Not sure exactly what we want to make up the deposit ID. Technically the depositNonce would be enough, but I figured it might be useful to hash in other data bits to be able to more easily prove their existence if not immediately accessible in smart contracts / scripts.

Also, please advise where else this would need to be specified. I see #103 added to the tx_format part of the protocol to specify withdrawal outputs, but I'm not sure what the parallel would be for deposits.

@adlerjohn @simonr0204

[adlerjohn]

You can leave specifying a deposit state element (similar to a UTXO) to a future PR, and only specify the actual identifier for a deposit in this PR.

[adlerjohn]

Hmm. Lots of stuff in the FuelVM works best at word alignment (i.e. 8 bytes). I would instead use 32 bytes for addresses, and left-pad with zeroes (which is what FuelLabs/sway#1452) does. This would also be forwards-compatible with the proposed address extension: https://ethereum-magicians.org/t/thoughts-on-address-space-extension-ase/6779

Also, is there a need for 32 byte nonces? Would prefer 8 bytes (i.e. uint64) since it'll just be easier to deal with in the FuelVM.

[pixelcircuits]

Changed address to be 32 bytes left-padded with zeroes and deposit nonce reduced to 64bits (still plenty)

[adlerjohn]

Looping in @simonr0204 and @rakita for reviews from the perspective of the contract and the relayer, respectively.

[simonr0204]

How are we defining precision in the general case? For the current ethereum bridges it's relative to 18 decimal places, since ether and many ERC20 tokens have 18 digits of precision.

Do we want to be stuck with this definition for non-evm deployments ?

Also - is the address the depositor (on L1) , or the Fuel address receiving the deposit?

[adlerjohn]

Good questions. The precision here should be against units, e.g. wei for Ethereum. So a precision of 3 would mean 1,000 wei. Does that work? Potentially a different name is needed.

As for address, it should be the receiving address on Fuel, which is 32 bytes so no padding necessary. The sending address is irrelevant for the Fuel chain.

[simonr0204]

Makes sense. I'll update the contracts to reflect.

For the address, depositor may be a bit misleading then, as it sounds like it's referring to the L1 address initiating the deposit. Is there a better word? Receiver? Beneficiary?

[pixelcircuits]

Maybe we refer to depositor as recipient instead?

[adlerjohn]

Recipient ain't bad

[rakita]

Looping in @simonr0204 and @rakita for reviews from the perspective of the contract and the relayer, respectively.

Relayer does not care what is inside of hash, we just need some kind of id, only having nonce would be sufficient enough for our side.

Regarding deposits, in fuel ecosystem we don't have u256, we are using u64 as an amount, so it is best to restrict max deposit amount to u64::MAX.

I am not exactly getting how precision is going to work inside FuelVm, what is the idea behind it is this some data that is going to be used by VM or something like additional info that is tied to coin?

[adlerjohn]

I am not exactly getting how precision is going to work inside FuelVm, what is the idea behind it is this some data that is going to be used by VM or something like additional info that is tied to coin?

The FuelVM won't actually use the precision. Token contracts can be provided the preimage to the ID to extract the precision, then use that to mint an appropriate number of Fuel-tokens.

[adlerjohn]

Actually, just remembered we need a notion of asset ID for deposits. This should be independent of the user, the amount, and the nonce. Should be computed as token address + token precision.

Then you can use this asset ID in the deposit ID computation instead of duplicating usage of the token address and precision