Skip to content
This repository has been archived by the owner on Mar 24, 2023. It is now read-only.

Add state representation #32

Merged
merged 49 commits into from
Jun 16, 2020
Merged
Changes from 2 commits
Commits
Show all changes
49 commits
Select commit Hold shift + click to select a range
a453c4d
Add basic state representation.
adlerjohn May 19, 2020
62420a9
Fix typo is size of validator voting power.
adlerjohn May 19, 2020
cf6e484
Update specs/data_structures.md
adlerjohn May 20, 2020
a1340ff
Add nonce field to accounts.
adlerjohn May 20, 2020
a2adee4
First draft refactor: validators and accounts in a single tree.
adlerjohn May 25, 2020
6201f4c
Add consensus constants for unbonding duration and maximum active val…
adlerjohn May 26, 2020
2b14d8d
Add validator and delegation structs to accounts.
adlerjohn May 26, 2020
9ce5d6c
Add additional validator and delegation fields.
adlerjohn May 27, 2020
06f6436
Add explanation for validator status.
adlerjohn Jun 1, 2020
05b2d47
Add explication for delegation status.
adlerjohn Jun 1, 2020
00d4675
Add slashing fields to validator.
adlerjohn Jun 1, 2020
5a60665
Clean up.
adlerjohn Jun 1, 2020
2df269d
Add accumulation of voting power and rewards to validators and delega…
adlerjohn Jun 2, 2020
4cf479a
Reduce the precision of voting power to whole coins (i.e. drop 9 zero…
adlerjohn Jun 2, 2020
411925c
Remove todo.
adlerjohn Jun 2, 2020
7f31112
Add rules for calculating rewards and penalties for delegations and v…
adlerjohn Jun 3, 2020
34d9ddc
Clean up.
adlerjohn Jun 3, 2020
8339f86
Add rule to update accumulated voting power also when validator begin…
adlerjohn Jun 3, 2020
61cbe55
Clarify that accumulated voting power is in whole coins.
adlerjohn Jun 3, 2020
f7bc92b
Add commission calculations.
adlerjohn Jun 3, 2020
0828bf3
Fix tables.
adlerjohn Jun 3, 2020
3f320e0
Fix commissions.
adlerjohn Jun 3, 2020
d87ef53
Rename calculating rewards and penalties to distributing.
adlerjohn Jun 6, 2020
08dfbc5
Clean up.
adlerjohn Jun 6, 2020
313388e
Migrate rationale for reward distribution to dedicated document.
adlerjohn Jun 6, 2020
ecda995
Fix commission calculation for validator.
adlerjohn Jun 6, 2020
4fd51b7
Remove some rationale from consensus document for reward distribution.
adlerjohn Jun 8, 2020
fa9307b
Add preamble to reward distribution doc, clearn up.
adlerjohn Jun 8, 2020
e1d624c
Clean up.
adlerjohn Jun 8, 2020
39bc623
Revamp reward distribution rationale.
adlerjohn Jun 9, 2020
6bba8c6
Fix state data structures for reward distribution.
adlerjohn Jun 9, 2020
6e036ad
Remove redundant entry from validator.
adlerjohn Jun 9, 2020
747b594
Remove other redundant entry from validator.
adlerjohn Jun 9, 2020
62f759c
Fix consensus rules for distributing rewards.
adlerjohn Jun 9, 2020
09f95d2
Cleanup.
adlerjohn Jun 9, 2020
5449c59
Update specs/consensus.md
adlerjohn Jun 9, 2020
e8cc2d3
Simplify naming of accounts tree.
adlerjohn Jun 10, 2020
e4005c8
Clean up.
adlerjohn Jun 10, 2020
8785e68
Clean up informal language.
adlerjohn Jun 10, 2020
70ac923
Refactor consensus rules for validators and delegations to use code s…
adlerjohn Jun 11, 2020
f1cba75
Refactor state tree to use a single unified tree with distinct subtrees.
adlerjohn Jun 11, 2020
a9d5149
Fix typo.
adlerjohn Jun 11, 2020
4fbff8a
Remove redundant state root definition.
adlerjohn Jun 11, 2020
4a50807
Remove redundant validator flag in accounts.
adlerjohn Jun 11, 2020
a8c17a7
Add protobuf definitions for state elements.
adlerjohn Jun 11, 2020
73de678
Add another subtree for inactive validators.
adlerjohn Jun 11, 2020
b4db7e3
Clean up.
adlerjohn Jun 11, 2020
2c4e44c
Fix typo.
adlerjohn Jun 11, 2020
4d87996
Move the active validator count to the active validators subtree.
adlerjohn Jun 15, 2020
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 24 additions & 1 deletion specs/data_structures.md
Original file line number Diff line number Diff line change
Expand Up @@ -43,6 +43,8 @@ Data Structures
- [MessageData](#messagedata)
- [Message](#message)
- [State](#state)
- [Account](#account)
- [Validator](#validator)
- [Consensus Parameters](#consensus-parameters)

# Data Structures Overview
Expand Down Expand Up @@ -475,7 +477,28 @@ enum VoteType : uint8_t {

# State

TODO validator set repr
The state of the LazyLedger chain contains only account balances and the validator set (which is really just extra metadata on top of the account balances).

Two [Sparse Merkle Trees](#sparse-merkle-tree) are maintained: one of [accounts](#account) and one of [validators](#validator). The state root is computed as the [hash](#hashdigest) of concatenation of the account tree root and the validator tree root.

## Account

| name | type | description |
| -------------------- | ------------------- | ---------------------------------------------------------------------------------------- |
| `balance` | `uint64` | Coin balance. |
| `isDelegating` | `bool` | Whether this account is delegating its stake or not. |
| `delegatedValidator` | [Address](#address) | _Optional._ The validator this is account is delegating to. |
Copy link
Member

@liamsi liamsi May 19, 2020

Choose a reason for hiding this comment

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

Why can't accounts delegate to several validators? Also maybe:

Suggested change
| `delegatedValidator` | [Address](#address) | _Optional._ The validator this is account is delegating to. |
| `delegatedValidator` | [Address](#address) | _Optional._ The validator this account is delegating to. |

Copy link
Member Author

Choose a reason for hiding this comment

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

Because that would add complexity (you'd have to hold a variable number of validators and the number of coins each of them is delegated), and if someone wants to delegate their coins to two validators they can just...split up their coins into two accounts.

Copy link
Member Author

Choose a reason for hiding this comment

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

This scheme (which isn't obvious from the data structures, but will be written in the consensus rules) is: "all the coins in an account are either delegated or not; if they're delegated they must be delegated to a single validator."

Copy link
Member

@liamsi liamsi May 20, 2020

Choose a reason for hiding this comment

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

From a user (holding coins) and a UX perspective, splitting up coins into separate accounts whenever you want to delegate to more than one validator also adds complexity, but one the human (not on the software).

Note that in the few delegations based PoS systems that launched, you can usually delegate to one or more validators. This is also true in Cosmos / the cosmos-sdk. Most users I know delegate to several validators to keep the network decentralized (and to hedge their risks).

Copy link
Member Author

Choose a reason for hiding this comment

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

Hmm. I don't see why this can't be abstracted away at the application layer, rather than having to be pushed to the user layer. Moving a portion of your coins to a new address then delegating them (as well as the reverse) can be done just as seamlessly in a wallet---one button press. Users don't even have to know it's happening! It's basically UTXO management; most Bitcoin wallets don't present to lay users each individual UTXO, just their total balance.

Allowing an arbitrary number of delegations per account means fraud proofs are more complex and expensive.

That being said, given that we're using the accounts data model for now, one downside of essentially emulating UTXOs for delegating stake is that the nonce of empty accounts still needs to be kept around forever (which reminds me, a nonce field needs to be added).

Copy link
Member

Choose a reason for hiding this comment

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

I feel that it would actually be more intuitive from a UX perspective to require users to split their coins into different accounts to delegate to different validators. It's the logical purpose of accounts - the same way you might have multiple savings accounts for different purposes.

It seems more complicated from a UX perspective to have users enter each validator they want to delegate to and the amount in some kind of table.

Copy link
Member

@liamsi liamsi Jun 10, 2020

Choose a reason for hiding this comment

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

It's the logical purpose of accounts - the same way you might have multiple savings accounts for different purposes.

But here you'd have multiple accounts for one purpose: namely delegating to validators. Having a different account per validator would be like opening a broker account per same type of investment (or one "account" per stock or bond you buy).

| `delegatedCount` | `uint32` | Number of accounts delegating to this validator. `0` is this account is not a validator. |

In the account tree, accounts are keyed by the [hash](#hashdigest) of their [address](#address).

## Validator

| name | type | description |
| ------------- | -------- | --------------- |
| `votingPower` | `uint64` | Voting balance. |

In the validator tree, validators are keyed by their [address](#address).

# Consensus Parameters

Expand Down