Update zenlink currency conversion for Amplitude and Pendulum

[ebma]

We need to update the 'zenlink_id_to_currency_id' function to something that can also derive our Spacewalk currencies (as we also want to use Spacewalk/Stellar assets on Zenlink).

Now when we define the conversion from a zenlink to a local currency ID, right now we always assume the provided asset_index to be the XCM index. But we somehow have to link to our Stellar assets in this conversion function because we have to be able to derive it from the ZenlinkAssetId.
Since the asset_index is of type u64 but the XCM index we use in our CurrencyId can only be u8 I'd say it's safe to start assigning Stellar assets with 256 (because u8 only ranges from 0-255)

match asset_id.asset_type {
		NATIVE => Ok(CurrencyId::Native),
		LOCAL => {
			let foreign_id: u8 = asset_id.asset_index.try_into().map_err(|_| {
				log::error!("{} has no Foreign Currency Id match.", asset_id.asset_index);
				()
			})?;

            if foreign_id <= u8::MAX {
			    Ok(XCM(foreign_id))
            } else {
               // TODO add some hard-coded lookup
               match foreign_id {
                    256 => Stellar::StellarNative,
                    257 => yadda yadda ....
                    _ => None
            }
		},
		other => {
			log::error!("Unsupported asset type index:{other}");
			Err(())
		},
	}

[vadaynujra]

Hey team! Please add your planning poker estimate with Zenhub @ashneverdawn @ebma @RustNinja @TorstenStueber

[TorstenStueber]

@ebma makes sense. What currencies shall we encode right now? (also @vadaynujra)

[ebma]

While we could implement different conversion functions per runtime I'm not sure if that'd be a good idea as it might lead to confusion. From what I can tell we would at least need the currencies defined in this ticket ie XLM, USDC, TZS, and BRL.
@vadaynujra what else would we need?

[vadaynujra]

The ones in this ticket are enough for now.

[vadaynujra]

@ebma is this ticket ready to be worked on and is relevant for the current Zenlink work?

[ebma]

Because ticket #241 is probably getting rid of a function mentioned in this ticket, I now marked this ticket as blocked by #241 and we should wait for the outcome of that ticket. This ticket might not be necessary afterward.

[adelarja]

After reading this issue, I realized that I need to make a minor change in this PR.

I believe that implementing a hard-coded lookup is the best approach for converting ZenlinkAsset to StellarAsset. I was trying to figure out how we could convert Stellar assets to ZenlinkAssets using the StellarAsset code (and vice versa), but it's challenging because the StellarAsset code ranges from 32 to 96 bits (4 to 12 bytes), while the ZenlinkAsset index is a u64 (8 bytes) value. This could cause difficulties when generating a pool with a Stellar asset.

However, I didn't consider the possibility of creating a pool with Stellar assets. In such cases, the ZenlinkLPToken(u8, u8) enum value won't be sufficient since we can't distinguish between Stellar and XCM tokens using u8 ID values.

We have two options to address this:

1. Change the enum value from ZenlinkLPToken(u8, u8) to ZenlinkLPToken(u16, u16).
2. Change the enum value from ZenlinkLPToken(u8, u8) to ZenlinkLPToken(u8, u8, u8, u8). In this case, two of the u8 values represent the token IDs, while the other two represent the token types used in the pool (e.g., 0 for XCM tokens, 1 for Stellar tokens, etc.).

In both cases, the bitwise operations remain similar to implement.

In the first case:

let lp_token_index: u64 = (discriminant << 8) + (token1_id << 16) + (token2_id << 32);

// Reverse operations:
let discriminant: u8 = (lp_token_index & 0x0000_0000_0000_ff00) >> 8;
let token1_id: u16 = (lp_token_index & 0x0000_0000_ffff_0000) >> 16;
let token2_id: u16 = (lp_token_index & 0x0000_ffff_0000_0000) >> 32;

We can use the discriminant to determine if the index represents an lp_token, XCM token, or Stellar token. Additionally, we can identify whether a token is an XCM token or Stellar token based on its token ID value (0-255 for XCM, greater than 255 for Stellar tokens). If the asset index is for a non-lp_token, the index directly represents the token ID (greater than 255 indicates a Stellar token, while others indicate an XCM token).

In the second case, we have a similar approach:

let lp_token_index: u64 = (discriminant << 8) + (token1_id << 16) + (token1_type << 24) + (token2_id << 32) + (token2_type << 40);

// Reverse operations:
let discriminant: u8 = (lp_token_index & 0x0000_0000_0000_ff00) >> 8;
let token1_id: u8 = (lp_token_index & 0x0000_0000_00ff_0000) >> 16;
let token1_type: u8 = (lp_token_index & 0x0000_0000_ff00_0000) >> 20;
let token2_id: u8 = (lp_token_index & 0x0000_00ff_0000_0000) >> 32;
let token2_type: u8 = (lp_token_index & 0x0000_ff00_0000_0000) >> 40;

This approach allows us to determine if the index represents an lp_token, XCM token, or Stellar token using the discriminant. Furthermore, with the token_type, we can identify if the token represents an XCM or Stellar token. If the asset index is for a non-lp_token, the index directly represents the token ID. By setting different discriminant values, we can determine the type of token it represents.

These changes will enable us to handle both XCM and Stellar assets effectively.

[ebma]

Thanks a lot for this amazing write-up @adelarja! 🙏 Out of the two approaches I would say option two (ie. ZenlinkLPToken(u8, u8, u8, u8)) is preferable because it will be easier to see what type an LP token has eg. when we look it up in on-chain data.

[TorstenStueber]

What are the possible values of the discriminant?

[adelarja]

I believe we need to define one discriminant value per CurrencyId. This approach is similar to what Bifrost is implementing here.

We could use the token discriminant as the token type for each currency that comprises the ZenlinkLPToken.

[TorstenStueber]

Their CurrencyId is a big enum, so is ours. Their discriminator is the variant of this enum but does that really make sense for us? Isn't that actually specified through the token1_type and token2_type as you wrote above? (maybe also @ebma).

[ebma]

Since our CurrencyId is a little nested, we could do something like this maybe?

pub fn discriminant(&self) -> u8 {
		match *self {
			Self::Native(..) => 0,
			Self::XCM(..) => 1,
			Self::Stellar(Asset) => match Asset {
                                StellarNative = 2,
                         	AlphaNum4 { .. } => 3,
                          	AlphaNum12 { .. } => 4,
                         },
                        Self::ZenlinkLPToken(..) => 5,
		}
	}

@TorstenStueber I think we actually really need the discriminant because without it we could not be 100% sure what we are dealing with. Let's say we are facing a Zenlink asset_index (u64). Now we are doing the bit-shifting to split the u64 into the sub-parts. With the discriminant, we immediately know which type of CurrencyId we are facing. Without it, we might face rare circumstances where we can't know. For example, if we happen to have an asset_index that when split into sub-parts yields only 0 values for token1_type, token1_id, token2_type, token2_id. How would we know if this is supposed to be our native token or some LP token combining our native token and something else?