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

[genesis] Make the genesis delegator configurable by CLI #4218

Open
miker83z opened this issue Nov 25, 2024 · 1 comment · May be fixed by #4346
Open

[genesis] Make the genesis delegator configurable by CLI #4218

miker83z opened this issue Nov 25, 2024 · 1 comment · May be fixed by #4346
Assignees
Labels
vm-language Issues related to the VM & Language Team
Milestone

Comments

@miker83z
Copy link
Contributor

This is currently fixed with a const, i.e., IF_STARDUST_ADDRESS in iota_genesis_builder

@miker83z miker83z added the vm-language Issues related to the VM & Language Team label Nov 25, 2024
@miker83z miker83z added this to the Mainnet milestone Nov 25, 2024
@miker83z
Copy link
Contributor Author

miker83z commented Dec 2, 2024

In a genesis with migration data (and NOT in a genesis without migration data) each validator must have a delegator address associated. During a genesis ceremony me can reuse the TokenDistributionSchedule that is a list of TokenAllocation. During the ceremony this schedule is setup with a CSV:

recipient-address,amount-nanos,staked-with-validator,staked-with-timelock-expiration
<faucet-address>,1500000000000000,,
<validator-1-address>,1500000000000000,<validator-1-address>,
<validator-2-address>,1500000000000000,<validator-2-address>,

That is parsed as vector of TokenAllocations:

pub struct TokenAllocation {
    pub recipient_address: IotaAddress,
    pub amount_nanos: u64,

    /// Indicates if this allocation should be staked at genesis and with which
    /// validator
    pub staked_with_validator: Option<IotaAddress>,
    /// Indicates if this allocation should be staked with timelock at genesis
    /// and contains its timelock_expiration
    pub staked_with_timelock_expiration: Option<u64>,
}

Here another optional field could be added pub delegator: Option<IotaAddress>, being Some for a genesis with migration data and None otherwise. Then the TokenDistributionSchedule takes this form:

recipient-address,amount-nanos,staked-with-validator,staked-with-timelock-expiration,delegator
<faucet-address>,1500000000000000,,,<delegator-1-address>
<validator-1-address>,1500000000000000,<validator-1-address>,,<delegator-3-address>
<validator-2-address>,1500000000000000,<validator-2-address>,,<delegator-4-address>

This change would suffice if we only work with the ceremony commands. However, the iota genesis command makes use of a default Distribution Schedule during the config build.

let token_distribution_schedule = {
let mut builder = TokenDistributionScheduleBuilder::new();
for allocation in allocations {
builder.add_allocation(allocation);
}
// Add allocations for each validator
for validator in &validators {
let account_key: PublicKey = validator.account_key_pair.public();
let address = IotaAddress::from(&account_key);
// Give each validator some gas so they can pay for their transactions.
let gas_coin = TokenAllocation {
recipient_address: address,
amount_nanos: DEFAULT_GAS_AMOUNT,
staked_with_validator: None,
staked_with_timelock_expiration: None,
};
let stake = TokenAllocation {
recipient_address: address,
amount_nanos: validator.stake,
staked_with_validator: Some(address),
staked_with_timelock_expiration: None,
};
builder.add_allocation(gas_coin);
builder.add_allocation(stake);
}
builder.build()
};

In this case, we could make mandatory the use of a --delegator flag with just 1 delegator address any time that we have either the --local-migration-snapshots or --remote-migration-snapshots flags.

---> This will be used just for testing, the main functionality we need for mainnet should work with the TokenDistributionSchedule CSV file in the ceremony <---

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
vm-language Issues related to the VM & Language Team
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants