Port Account Actor Functionality

[serg-temchenko]

Consider utilizing the Accounts Management section to cover this functionality.

TODO: @aidan46 needs to define the order in which pallets should be implemented and extend the description accordingly. (IMO, this should be the first for implementation, since account is the main object of any actor).

[aidan46]

I agree with your reasoning that this functionality should be the first to be implemented. We can leverage polkadot-sdk's frame-system and pallet-balances crates for this.

[aidan46]

Are we using a certain SS58 prefix for accounts or going with the default (42)?

[th7nder]

Don't this prefix need to be unique? According to the schema: https://github.com/paritytech/ss58-registry/blob/main/ss58-registry.json#L4C1-L4C68.
As well in the docs: https://paritytech.github.io/polkadot-sdk/master/frame_system/pallet/trait.Config.html#associatedtype.SS58Prefix.
https://docs.substrate.io/reference/address-formats/

We need to create a PR there for our network.

[aidan46]

I was reading this where it says:
"For production networks, however, a network-specific version may be desirable to help avoid the key-reuse between networks and some of the problems that it can cause."
I think we can keep it at 42 for now as the project is not public yet and it only affects the address display format. We can always change this later when a decision is made on the prefix

[th7nder]

Agreed, let's keep it as 42 for now.

[th7nder]

So according to: https://docs.substrate.io/learn/accounts-addresses-keys/
Generic substrate addresses are prefixed with 5, so every Account address on our network will be like that as well (with the prefix kept).
E.g. 5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY
It means, that for the development the address from any parachain will be an valid address in our parachain.

[th7nder]

Default implementation of the runtime, uses AccountData from pallet-balances, but it gets me thinking... This default implementation is about using accounts with fungible tokens, but we're not introducing any token in polka-storage, we wanna use DOT, a native one. Not sure whether we need pallet_balances at all then.

[th7nder]

@asmie do you have any ideas about that? Was the native (DOT-like) coin used in the prototype?

[serg-temchenko]

We should use DOT only for our system. Not sure if we could avoid using pallet-balances since it might contain some required primitives and functionality needed for our specific implementation. You can start without it, but if at some point you will need something provided by this pallet - use it?

[th7nder]

I think the biggest question is we don't know yet, how (in terms of implementation, not the design) we can use DOT in our native parachain.
I suppose we'll have different accounts for the parachain, so how do we transfer/leverage relay-chain tokens in our parachain?
Which operations will cost DOT/which will not?

[th7nder]

Moonbeam example: https://moonbeam.network/education/how-to-transfer-dot-to-moonbeam/
https://moonbeam.network/blog/xcm-on-polkadot/
Transfering DOTs via XCM

[th7nder]

Moonbeam introduces their own xcDOT.
AssetHub (which does use native DOTs) can be an inspiration.
Here it's XCM Config: https://github.com/paritytech/polkadot-sdk/blob/master/cumulus/parachains/runtimes/assets/asset-hub-rococo/src/xcm_config.rs#L215

[th7nder]

Functionality of transferring DOTs, should be done via a Teleport process. Reading docs on it now:

• https://wiki.polkadot.network/docs/learn/xcm/overview-summary
• https://wiki.polkadot.network/docs/learn-xcm-pallet

[th7nder]

There is an example of a teleport in XCM Docs.
It works with using two pallets, pallet_assets and pallet_balances. Pallet Assets is configured to hold native tokens as assets.

I am yet to determine:

• what are sovereign accounts
• what's AssetExchange and whether we should use it
• how to configure our runtime to support teleports
• add pallet_assets to our runtime
• test teleporting assets in our testnet (from relay chain to parachain)
• test whether we can use teleported assets (somehow)
• how AssetHub uses native DOT

[th7nder]

Current summary:

1. A user needs to have an account on our parachain, because a parachain state is separate from a relay chain state.
   It won't be possible to modify a relay chain state from our parachain.
2. Even though it's possible to use Accounts which have the same SS58 prefix
   and look the same from the user's perspective as AssetHub
   does. I.e. PolkaDot Relay Chain has prefix 0 and AssetHub as well, so account address is the same, the state of balances pallet is separate for those two accounts.
3. To be registered on our network, user has to have some existential deposit on their account. Account Creation happens automatically when someone sends a fund to that.
   To transfer funds from Relay Chain to PolkaDot, we need to use XCM Teleport process. It basically burns DOTs in relay chain and mints them in our chain. Note that it is only possible for trusted teleporters, so system parachains and parachains approved by polkadot fellows.
4. I'm not yet sure which pallet will be responsible for handling DOT balances, but it's either pallet-ballances or pallet-assets. I'm on my way to configure our parachain to receive Native Relay Chain tokens and I'll let you know.
5. Yes, we'll need an application for transfering DOTs to our Parachain, something similar to what Moonbeam does.
6. The miner has to have an account on our parachain, as he'll be rewarded from our parachain treasury account, which comes to the next point.
7. We cannot mint DOT, so we cannot reward miners simply. What needs to happen is what AssetHub does. Collators receive a portion of transaction fees. It'll need to be designed and researched.

[th7nder]

I was able to configure our runtime to be able to Native Relay Chain assets to the Parachain.
It's not clear to me how this 40 000 000 issued assets were calculated and where they awarded to, but we got it working.

[th7nder]

TODO:

• verify that all of the Account Actor is covered.
• document and write procedure for creating accounts
• test whether transfer between created accounts work
• document the Teleport Assets from Relay Chain and Parachain