Cosmos-sdk: "Red Wedding" (first GoS hard fork) master to-do list

Created on 11 Dec 2018  路  19Comments  路  Source: cosmos/cosmos-sdk

This hard fork will be carried out with use of the zero-height export mechanism introduced in https://github.com/cosmos/cosmos-sdk/pull/2827.

Tendermint changes

SDK changes

State changes

Port script at https://github.com/cosmos/game-of-stakes/pull/260

  • [ ] Multiply Atom amounts by ~10e18 for "micro-Atoms"

cc @faboweb @alexanderbez @zmanian

All 19 comments

I may be misunderstanding something here but if the current values are 'atoms', then wouldn't multiplying by 10^18 result in 'attoatoms'? Seems a bit overkill! Microatoms would be 10^6 no? 1 million microatoms = 1 atom.

afaik, atoms are a unit for which 10^9 of these units corresponds to a single atom.

Because of the fee distribution and inflation model, we need to make sure there is a mechanism in place that allows delegates to still get rewards when they only hold a very tiny portion of a validator's stake. The end result is us needing ~10e18

I'm sure someone else can elaborate further.

Are you saying that the current values are _already_ 'nanoatoms' then, basically? And so after this issue is resolved getting the 'atom' value will require dividing by 10^27? There's actually not even a name for that it seems -- 1 septillionth, 10^24, would be yoctoatoms, but that as far as the names go 馃槄

I guess ultimately I'm just trying to make it clear because I will be needing to implement interfaces that accurately display (and name) amounts and so on.

No, afaik, the current values are _not_ nanoatoms.

Hmm ok but you said:

afaik, atoms are a unit for which 10^9 of these units corresponds to a single atom.

Can you clarify what you meant by that?

They will be*.

I'm truly sorry if I'm being dense here :wink: ... but if it will be nanoatoms, that's 10^9. This issue describes doing 10^18 which would be attoatoms, but it calls them microatoms...

Clarity on this is super important before I try to update our interfaces. I believe you that you need more precision and so on, all good. So I'm really just looking for specific confirmation and details here -- when this launches what would I divide the values by to get 'atoms'.

@rfunduk You are quite right to be precise - I intended "micro-Atoms" to simply reference a smaller denomination - we haven't decided exactly what that will be.

I agree that 10e18 is more precision than required. Probably 10e6 or 10e8 is enough. We should see if there are any particular numeric types we would want to support (e.g. uint64, and assuming some reasonable total supply limitations) and decide accordingly, at which point we will adopt the standard SI prefix for the minimum unit (although we might have an additional name a la "wei" as well).

Micro atoms should not be in game of stakes, as we will overflow valid power amounts.

Micro atoms should not be in game of stakes, as we will overflow valid power amounts.

Then we should fix that too - you're referring to https://github.com/cosmos/cosmos-sdk/issues/2513, right?

That is what I was referring to! I guess this gets to how close we want game of stakes to get to the hub launch code. I am agnostic on this, but micro-atom inclusion does require #2513.

micro-atom -> quark?
avoid stepping on reserved metric system names 馃槃

plz quarks! if you do the math a quark on average is 10^-9 in size from an atom so it's kind of perfect

Going to close this as 0.30.0 is out!

quarks didn't happen?

Quarks didn't happen?

That doesn't actually require any SDK changes I think - @zmanian could do it when we create the new GoS genesis file (just a community testnet right now).

Not perse, but there are a few places (e.g. tests and local testnet) that could be updated to use quarks instead of the small amounts they do now.

quarks also imply post processing all outputs in CLI and REST endpoints to still show atoms imo, so I think it will require some patching of the SDK.

quarks also imply post processing all outputs in CLI and REST endpoints to still show atoms imo, so I think it will require some patching of the SDK.

That's true, but we can push those changes in a non-breaking release.

Was this page helpful?
0 / 5 - 0 ratings