Adding IRC IIPs for XCall compatible token types

[bawinkl]

These are proposal tempaltes/extensions for IRC-2 and IRC-31 token types that both maintain the existing interface requirements and extend the functionality to work for cross chain communications using XCall.

These may be better served as independent token standards that forgoe the existing interface requirements and define their own, but this is at least a starting point for that discussion.

These are being submitted as part of the XCall incentivized test net challenges and represent similar implemetnations on the Berlin Test Network.

[iconjc]

Hello, @bawinkl

I have a few questions.

. How does read-only functions work on BTP? For example, how does x_balanceOf() knows the balance of another chain and returns it on the spot?

. iip-XChainFungibleToken.md document has some typos. For example, x_balanceOf() doesn't have _id param, but the comment has it.

[bawinkl]

Hey @iconjc!

The read only methods don't perform cross chain references or calls. Instead this is a proposal to modify the way balance are referenced on the contract so they use a BTP formatted address string for storage and reference.

As a comparison:
The existing balanceOf(Address address) (on IRC-2) expectes an "ICON Address Type" which is specifically an address hash like : "hxc5e0b88cb9092bbd8b004a517996139334752f62". This proposal suggests that we use a new NetworkAddress type (as a string) in the BTP/Network Address format like [btp://][network_id][address_hash]. So if we were referencing an address on, say, the ICON Berlin Test Net the address would be "btp://0x7.icon/hxc5e0b88cb9092bbd8b004a517996139334752f62" or on Havah's Altair Test network it would be: "btp://0x111.icon/hxc5e0b88cb9092bbd8b004a517996139334752f62".

By storing the balance references in this way, we can know the balance for addresses on any supported chain, regardless of the addressing scheme.

You would still have to access the read only method on the installed network (or through an API) to use the x_balanceOf() function, but you can pass in any BTP Address. You might also be able to use a creative nested calling structure using XCall/BTP (or another relay technology) to get the read only data on chain (from across chain), but that may be more expensive than its worth.

Instead I would suggest having a dapp that can connect to the referenced chains to fetch the needed read only data and leverage it however needed before passing it onto the contract.

Hopefully that helps clarify. If not, feel free to ask more questions.

Also, thanks for the heads up on the typo(s), i'll review it and fix those ASAP.