Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: ETCM-8267 Configure and use the native token addresses in partner-chains-cli #68

Draft
wants to merge 14 commits into
base: better-assert-in-cli-test
Choose a base branch
from

Conversation

AmbientTea
Copy link
Contributor

@AmbientTea AmbientTea commented Aug 30, 2024

Description

Generating the chain spec needs three new environmental variables to be configured, after the addition of the native token pallet. This PR modifies prepare-configuration step to also prompt for the addresses and save them, and then uses them in create-chain-spec.

Checklist

  • Commit sequence broadly makes sense and commits have useful messages.
  • New tests are added if needed and existing tests are updated.
  • Relevant logging and metrics added
  • CI passes. See note on CI.
  • Any changes are noted in the changelog.md for affected crate
  • Self-reviewed the diff

Note on CI

If your PR is from a fork, the necessary CI jobs won't trigger automatically for security reasons.
You will need to get someone with write privileges. Please contact IOG Partner Chains developers to do this
for you.

@@ -129,6 +132,21 @@ fn run_sidechain_main_cli_addresses<C: IOContext>(
Ok(())
}

fn prepare_native_token<C: IOContext>(context: &C) -> anyhow::Result<()> {
if context.prompt_yes_no("Do you want to configure a native token for you Partner Chain?", true)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm missing a better explanation here - what is it for and how to prepare the configuration variables.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added a slightly more verbose explanation in the wizard.

{
NATIVE_TOKEN_POLICY.prompt_with_default_from_file_and_save(context);
NATIVE_TOKEN_ASSET_NAME.prompt_with_default_from_file_and_save(context);
ILLIQUID_SUPPLY_ADDRESS.prompt_with_default_from_file_and_save(context);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IlliquidCirculationSupplyValidator is present in addresses output and should be placed in the part of JSON as the other addresses and policy ids.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed this, now the address comes from the addresses output and placed with other addresses in the chain configuration.

Copy link
Contributor

@LGLO LGLO left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this PR missing env variables are set for chain spec creation, but neither user is lectured about the values nor they are used in setup main chain state phase, so it will make this CLI incomplete and chain not set up properly.

@AmbientTea AmbientTea force-pushed the ETCM-8267-native-token-in-cli branch 2 times, most recently from 02d3822 to 3d2f3c7 Compare September 20, 2024 15:05
@LGLO LGLO self-requested a review September 20, 2024 15:19
@AmbientTea AmbientTea changed the base branch from master to better-assert-in-cli-test September 23, 2024 06:10
#[derive(Deserialize)]
pub struct ChainConfig {
pub cardano: CardanoParameters,
pub chain_parameters: SidechainParams,
pub cardano_addresses: MainChainAddresses,
pub native_token: NativeTokenConfig,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A: Is it already approved that we support using exactly one ?

B: this is logically bound to illiquid_supply_address from cardano_addresses. I think it is better to keep this asset id where we have other policy ids. And what is more, if not structurally bound like:

struct IlliquidSupplyConfig {
  asset: AssetConfig, // or assets: Vec[AssetConfig] - depends on decision how many are supported.
  address: String,
}

then at least name here should help to bind these together

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A: Yes, we're supporting only one until MN requires us to support multiple. That's decided by @gilligan

B: Okay, I moved it into cardano_addresses under native_token

context.print(
"Partner Chains can store their initial token supply on Cardano as Cardano native tokens.",
);
context.print("Creation of the native token is not supported by this wizard and must be performed manually before this step.");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a plan, like in JIRA, to have this supported?
What should be the flow? At what point is policy_id/asset_name chosen? Does it involve using smart-contracts CLI?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I talked with Piotr about this, and he told me we don't want to support this at all, at least for the time being. The issue I see with doing that, is that the token policy can have custom logic in it, so whatever we provide would be relevant only to those PC devs that want a token with exactly the logic that we provide (presumably none).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At what point is policy_id/asset_name chosen? Does it involve using smart-contracts CLI?

No, it can be any native token on Cardano. One can even be created using an existing creator, but someone can roll their own token code with custom logic and deploy it themselves

NATIVE_TOKEN_ASSET_NAME.prompt_with_default_from_file_and_save(context);
} else {
NATIVE_TOKEN_POLICY.save_to_file(&PolicyId::default().to_hex_string(), context);
NATIVE_TOKEN_ASSET_NAME.save_to_file(&"0x0".into(), context);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't it a bug? 0x0 doesn't seem to be a syntactically correct hex string. 0x should be empty one, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

0x0 is a valid hex string, I tested it.

0x is also valid, but to me it looks invalid so I went with 0x0.

Copy link
Contributor

@LGLO LGLO left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I cannot even pass generate-keys using this branch.

➜  test-native-token-cli ./partner-chains-cli generate-keys                      
This 🧙 wizard will generate the following keys and save them to your node's keystore:
→  an ECDSA Cross-chain key
→  an ED25519 Grandpa key
→  an SR25519 Aura key
It will also generate a network key for your node if needed.

> node base path ./data

⚙️ Generating Cross-chain (ecdsa) key
running external command: ./partner-chains-node key generate --scheme ecdsa --output-type json
💾 Inserting Cross-chain (ecdsa) key
running external command: ./partner-chains-node key insert --base-path ./data --scheme ecdsa --key-type crch --suri 'grace fence account between allow autumn toilet river river toilet climb repair'
command output: Error: Input("Reading configuration from environment failed: missing value for field native_token_policy_id")
Running executable failed with status exit status: 1

Signed-off-by: Nikolaos Dymitriadis <nikolaos.dymitriadis@iohk.io>
Signed-off-by: Nikolaos Dymitriadis <nikolaos.dymitriadis@iohk.io>
Signed-off-by: Nikolaos Dymitriadis <nikolaos.dymitriadis@iohk.io>
Signed-off-by: Nikolaos Dymitriadis <nikolaos.dymitriadis@iohk.io>
Signed-off-by: Nikolaos Dymitriadis <nikolaos.dymitriadis@iohk.io>
Signed-off-by: Nikolaos Dymitriadis <nikolaos.dymitriadis@iohk.io>
Signed-off-by: Nikolaos Dymitriadis <nikolaos.dymitriadis@iohk.io>
Signed-off-by: Nikolaos Dymitriadis <nikolaos.dymitriadis@iohk.io>
Signed-off-by: Nikolaos Dymitriadis <nikolaos.dymitriadis@iohk.io>
Signed-off-by: Nikolaos Dymitriadis <nikolaos.dymitriadis@iohk.io>
Signed-off-by: Nikolaos Dymitriadis <nikolaos.dymitriadis@iohk.io>
Signed-off-by: Nikolaos Dymitriadis <nikolaos.dymitriadis@iohk.io>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants