hjorthjort/cosmos-sdk

:chains: A Framework for Building High Value Public Blockchains :sparkles:

cosmos-sdk's Issues

Meeting notes

https://docs.google.com/document/d/1V6pAUuR3yZTwZ_JwCd9SnVtnPVqf1Z65CzEdzDJmJK4/edit

Redelegation

Unbonded

Messages

Delegation

Decide on a K-like state format

Use basic K-style format, but simplify names of common objects.
For example, {} instead of .Map.

Don't use starting object. Instead, just give type descriptions.
You can have default objects.

How to describe bags?

<myBag>
  {
    <id> _ :: String </id>
    <foo> b'' :: Bytes </foo>
   }*
</myBag>

Each module has its own state (and it's own store inside the multistore). So we should probably define one state configuration for each module, and compose them when necessary.

Deliverable 1: High-level system overview

A state description for exact naming of pieces of state

Deadline: 2021-02-08

Break a test and make sure it fails

Make a common slack channel

Bonding

Unbonding

Validator key updates

Waiting UnbondingTime

EndBlock events

BeginBlock lazy fee distribution

Hooked state updates

x/distribution/spec/05_hooks.md

Run tests with Goland

How to model keepers?

Ideas:

• Configuration compostion. If one module has access to the keeper of the former, then that module "imports" the former, with configuration compostion.

<accessee>
   <foo> </foo
</accessee>

<accessor>
  <accessee/>
  <bar> </bar>
</accessor>

• Explicit "keeper" keys. Every module has a "keeper" key (doesn't have to be initialized), an Int. To access the module, the accessor must (by convention) mention the keeper.

<accessee>
   <keeper> K </keeper>
   <foo> </foo
</accessee>

<accessor>
  <accesseeKeeper> K </accesseeKeeper>
  <bar> </bar>
</accessor>

rule foo => . 
  <accesseeKeeper> K </accesseeKeeper>
   <accessee>
     <keeper> K </keeper>
     <foo> _ => 42 </foo>
  </accesseeKeeper>

Build Cosmos SDK

Build in Goland

Roadmap

• Deliverable 1: High-level system overview (2020-02-08)

• Deliverable 2: Staking documentation

  • Bonding, Unbonding, Unbonded
  • EndBlock events and waiting UnbondingTime
  • How are jailed validators handled during delegation (what happens if you try to delegate to a jailed validator).
  • Delegation, redelegation and key updates of validators
    • Sequence diagram for delegating (module interactions)

• Deliverable 3: Distribution documentation

  • EndBlock BeginBlock lazy fee distribution
  • Messages
  • Hooked state updates