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

feat(IRO): IRO module implementation #1201

Merged
merged 77 commits into from
Sep 24, 2024
Merged

feat(IRO): IRO module implementation #1201

merged 77 commits into from
Sep 24, 2024

Conversation

mtsitrin
Copy link
Contributor

@mtsitrin mtsitrin commented Sep 5, 2024

Description

Implement IRO based on this ADR: https://www.notion.so/dymension/ADR-x-IRO-533f1c2f5a2345838150dd8e954c99c6?pvs=4


Closes #1164

All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow-up issues.

PR review checkboxes:

I have...

  • Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
  • Targeted PR against the correct branch
  • included the correct type prefix in the PR title
  • Linked to the GitHub issue with discussion and accepted design
  • Targets only one GitHub issue
  • Wrote unit and integration tests
  • Wrote relevant migration scripts if necessary
  • All CI checks have passed
  • Added relevant godoc comments
  • Updated the scripts for local run, e.g genesis_config_commands.sh if the PR changes parameters
  • Add an issue in the e2e-tests repo if necessary

SDK Checklist

  • Import/Export Genesis
  • Registered Invariants
  • Registered Events
  • Updated openapi.yaml
  • No usage of go map
  • No usage of time.Now()
  • Used fixed point arithmetic and not float arithmetic
  • Avoid panicking in Begin/End block as much as possible
  • No unexpected math Overflow
  • Used sendCoin and not SendCoins
  • Out-of-block compute is bounded
  • No serialized ID at the end of store keys
  • UInt to byte conversion should use BigEndian

Full security checklist here


For Reviewer:

  • Confirmed the correct type prefix in the PR title
  • Reviewers assigned
  • Confirmed all author checklist items have been addressed

After reviewer approval:

  • In case the PR targets the main branch, PR should not be squash merge in order to keep meaningful git history.
  • In case the PR targets a release branch, PR must be rebased.

@mtsitrin mtsitrin marked this pull request as ready for review September 9, 2024 11:31
@mtsitrin mtsitrin requested a review from a team as a code owner September 9, 2024 11:31
Copy link
Contributor

@omritoptix omritoptix left a comment

Choose a reason for hiding this comment

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

There is a lack of consistency in variables naming in the code when it comes to describing costs as int/dec or with denom (i.e sdk.Coin)

for example:

costCoin := sdk.NewCoin(appparams.BaseDenom, cost)
totalCost, takerFeeCoin := k.AddTakerFee(costCoin, k.GetParams(ctx).TakerFee)

costCoin - refers to amout of coins
totalCost - refers to amount of coins
takerFeeCoin - refers to amount of coins

For me confusing and inconsistent.

I suggest:
costAmt - the int/dec repr (so just a number)
cost - the actual cost of amount + denom .

so in the following example:

costCoin -> cost
totalCost -> costWithTakerFee
takerFeeCoin -> takerFee

x/rollapp/keeper/rollapp.go Outdated Show resolved Hide resolved
}

rollapp.GenesisInfo.Sealed = true
Copy link
Contributor

Choose a reason for hiding this comment

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

this function is called when bonding a sequencer.
assuming no IRO, seems like we don't validate all genesis fields exists before sealing.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

validated few lines above
if !rollapp.AllImmutableFieldsAreSet()


// check pre launch time
if rollapp.PreLaunchTime.After(ctx.BlockTime()) {
return nil, types.ErrBeforePreLaunchTime
Copy link
Contributor

Choose a reason for hiding this comment

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

assuming no IRO, currently this field is not set (i.e the preLaunchTime).
how does the non-iro flow looks like in that case? and why do we validate it in the non-iro flow?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

if it's not set, the expression is always false

Copy link
Contributor

Choose a reason for hiding this comment

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

I see. imo this implicitness is confusing. we can add a comment to clarify or alternatively explictly check this in the case this sequencer is launched for rollapp with IRO.

also thought of suggesting it would be cleaner to move preLaunchTime to only live on the IRO object if it's only IRO related but than checked the IRO object and I see it also has a preLaunchTime. and seems like it's a duplicate var living in both places. so I think worth just leaving it on the IRO, change it's name to EndTime and make sure a rollapp can't start until rollapp.iro.EndTime is over.

would also address #1201 (comment)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

actually I think it's better to have preLaunchTime as rollapp's field, as it might be enforced for different reasons in the future, not only from IRO.
I left it on the IRO plan object as well for clearity, but it's not used and can be removed from the plan store if u prefer.

Copy link
Contributor

Choose a reason for hiding this comment

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

actually I think it's better to have preLaunchTime as rollapp's field, as it might be enforced for different reasons in the future, not only from IRO.

I'm fine with that.

I left it on the IRO plan object as well for clearity, but it's not used and can be removed from the plan store if u prefer.

also fine with that, but imo we need to change it's name to EndTime cause I don't see the logic of Pre-Launch time on the IRO object, especially with it's comment related to rollapp.

// UpdateRollappWithIROPlan seals the rollapp genesis info and sets it pre launch time according to the iro plan end time
// - GenesisInfo fields must be set
// - Rollapp must not be Launched
func (k Keeper) SealGenesisInfoWithLaunchTime(ctx sdk.Context, rollapp *types.Rollapp, preLaunchTime time.Time) error {
Copy link
Contributor

Choose a reason for hiding this comment

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

why do we couple the SealGenesis with setting launch time?
If I want to seal genesis for rollapp without an IRO plan (and hence without LaunchTime) ?
currently the sealing logic is maintained in multiple places. here and on SetRollappAsLaunched. We should dry it out.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

genesis info sealing logic is rollapp.GenesisInfo.Sealed = true
not sure what there's to dry out
SetRollappAsLaunched and SealGenesisInfoWithLaunchTime have different pre-conditions.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

renamed

Copy link
Contributor

Choose a reason for hiding this comment

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

genesis info sealing logic is rollapp.GenesisInfo.Sealed = true

not really, cause you always want to validate that all pre-requirements are set.
currently the pre-requirements check are delegated to the caller vs just creating a Seal function which validates pre-requirements in one place and seals.

so now you're checking both independetly and sealing in:

  1. SetIROPlanToRollapp
  2. SetRollappAsLaunched

the next caller will also need to implement the checks and the sealing vs just calling Seal

x/rollapp/types/rollapp.go Outdated Show resolved Hide resolved
x/iro/keeper/trade.go Outdated Show resolved Hide resolved
x/iro/keeper/trade.go Outdated Show resolved Hide resolved
x/iro/keeper/trade.go Outdated Show resolved Hide resolved
x/iro/types/iro.pb.go Outdated Show resolved Hide resolved
x/iro/types/iro.pb.go Show resolved Hide resolved
if rollapp.GenesisState.TransfersEnabled {
return false
}
if rollapp.PreLaunchTime.IsZero() {
Copy link
Contributor

Choose a reason for hiding this comment

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

wby do we check it implicity vs explicity, i.e a rollapp iwth an unsettled IRO plan which has finished?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

it's the same. if IRO exists, preluanch is not zero. if it;s settled, than TransfersEnabled .
added comment to clarify

Copy link
Contributor Author

Choose a reason for hiding this comment

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

removed

Copy link
Contributor

Choose a reason for hiding this comment

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

yea I understand it's the same, just don't understand whats the reasoning for checking this vs GetPlanByRollap result. I assume there is a reason.

x/rollapp/transfergenesis/ibc_module.go Show resolved Hide resolved
x/rollapp/transfergenesis/ibc_module.go Outdated Show resolved Hide resolved
omritoptix
omritoptix previously approved these changes Sep 20, 2024
Copy link
Contributor

@omritoptix omritoptix left a comment

Choose a reason for hiding this comment

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

Some var name suggestions and also a duplicate variable it seems but nothing which is a blocker.

you can either address now or merge and open a technical debt issue with link to the comments and address them later.

x/iro/keeper/trade.go Outdated Show resolved Hide resolved
x/iro/keeper/trade.go Outdated Show resolved Hide resolved
x/iro/types/params.go Outdated Show resolved Hide resolved
if rollapp.GenesisState.TransfersEnabled {
return false
}
if rollapp.PreLaunchTime.IsZero() {
Copy link
Contributor

Choose a reason for hiding this comment

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

yea I understand it's the same, just don't understand whats the reasoning for checking this vs GetPlanByRollap result. I assume there is a reason.


// check pre launch time
if rollapp.PreLaunchTime.After(ctx.BlockTime()) {
return nil, types.ErrBeforePreLaunchTime
Copy link
Contributor

Choose a reason for hiding this comment

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

I see. imo this implicitness is confusing. we can add a comment to clarify or alternatively explictly check this in the case this sequencer is launched for rollapp with IRO.

also thought of suggesting it would be cleaner to move preLaunchTime to only live on the IRO object if it's only IRO related but than checked the IRO object and I see it also has a preLaunchTime. and seems like it's a duplicate var living in both places. so I think worth just leaving it on the IRO, change it's name to EndTime and make sure a rollapp can't start until rollapp.iro.EndTime is over.

would also address #1201 (comment)

@mtsitrin mtsitrin merged commit 5601240 into main Sep 24, 2024
116 of 128 checks passed
@mtsitrin mtsitrin deleted the feature/IRO branch September 24, 2024 13:45
message GenesisState {
// Params defines params for x/sponsorship module.
Params params = 1 [ (gogoproto.nullable) = false ];
// VoterInfos hold information about voters.
Copy link
Contributor

Choose a reason for hiding this comment

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

wrong name

k.SetPlan(ctx, plan)

// Emit event
err = ctx.EventManager().EmitTypedEvent(&types.EventClaim{
Copy link
Contributor

Choose a reason for hiding this comment

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

@zale144 I guess this place should use the sdk util method you wrote, instead of directly like this?

@@ -0,0 +1 @@
package types
Copy link
Contributor

Choose a reason for hiding this comment

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

empty file

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

IRO Impl
3 participants