kowala-tech/kcoin

A stable cryptocurrency that algorithmically targets $1 USD using the Kowala Protocol

kcoin's Issues

Sync stops eventually

I'm running a miner and 10 archival nodes. At first all nodes were getting new blocks, but slowly they got stuck, some earlier than others:

I checked the logs for the first one that stopped and it never received block 32. And then blocks started piling up in the queue, here the log when it receives block 37:

DEBUG[02-02|08:01:30] Queued propagated block                  peer=36250e11b212afc0 number=37 hash=341947…57d520 queued=5
TRACE[02-02|08:01:30] Fetching scheduled headers               peer=143800df3533b9b9 list="[[52 25 71 8 235 73 145 100 227 172 82 85 149 31 173 195 2 251 98 78 103 81 3 250 219 102 157 102 101 87 213 32]]"
DEBUG[02-02|08:01:30] Fetching single header                   id=143800df3533b9b9 conn=inbound hash=341947…57d520
DEBUG[02-02|08:01:30] Failed to deliver headers                err="no sync active"

Set up functioning internal testnet

Depends on #1, #27 #32 and #39

Dashboard for testnet

We need a dashboard for the testnet that allows casual users some sort of overview and visual status.

It should include:

• netstats
• access to faucet (even if it's just a link)
• basic instructions on how to run a validator

[testnet] Coin faucet

We need to let testnet users get initial funds for testing. For that we can use a faucet.

Ethererum has one: https://github.com/kowala-tech/kUSD/projects/1

and there's https://faucet.rinkeby.iom which uses social media.

[testchain] define tendermint minimum requirements

Measure comparative work between proposer and validators

We need to know how much 'work' the proposer does in comparison to a validator. Ideally the proposer would do more 'work' than all validators combined in any scenario.

How do we define and measure 'work'? How much 'work' do validators and proposers do, on average?

[p2p] message scope

• restrict consensus messages to the validator nodes
• the nodes currently just handle by default 25 peers max and number of validator peers should be based off the latest contract state.
• if there is more than one validator entering at the same round, we might need to take into account the time it takes to get both of them connected.

Faucet error

Type:

Issue

What happened? / What do you need?:

I'm running the faucet and it shows errors:

TRACE[02-06|10:04:13]                                          msg="sending {\"jsonrpc\":\"2.0\",\"id\":7,\"method\":\"kusd_getBlockByNumber\",\"params\":[\"latest\",false]}"
TRACE[02-06|10:04:13]                                          msg="<-readResp: response {\"jsonrpc\":\"2.0\",\"id\":7,\"error\":{\"code\":-32601,\"message\":\"The method kusd_getBlockByNumber does not exist/is not available\"}}"

If it's an issue, how can we reproduce it?:

Run the faucet and open the web interface

Affected servers or services:

No

Priority:

Low

[package tests] review

Review & add missing tests
Depends on #4

Mining stakes (deposits / punishments)

How do we punish validators who are trying to cheat or attack the network?

Do we make them stake kUSD? How about mining tokens? How can we otherwise lock them out of the network, given that banning a node won't work?

Transaction fees

The transaction fees need to go somewhere. I will confirm who should get them.

[consensus] validators - delays

Tendermint allow for peer delays (to a maximum of 1-2 rounds). Should we support this? If so, what are the use cases?

[doc] package level documentation

Here's a good reference: https://medium.com/@francesc/documentation-at-source-d-4251b0419108.

Automated end-to-end tests for blockchain features

This is dependent on #39

Code review

Especially the kusd/validator package

Minimum miner stake

Validators must stake a minimum number of tokens in order to be considered for election as the proposer.

The number of tokens required should be dynamic, and scale with the network.

How should that work?

[stats] modify ethstats to take into account PoS instead of PoW

• The current set of stats takes into account pow fields.
• As discussed with @yourheropaul, it would be interesting to have something like ethstats.net(https://github.com/cubedro/eth-netstats) to do basic monitoring.
• afaik, In ethereum the nodes are not required to log metrics.

Unit tests

We need some unit tests (if only for regression) for at least

• the consensus package and sub-packages
• the clique / reward packages
• critical smart contracts

[ethereum] import/review package tests

Base: 1.73

puppeth improvements

Improve puppeth to generate a genesis file and initialize the contracts storage with user provided data. This is meant to eliminate some of the (somewhat convoluted) setup process.

Initialization of the network contracts data should be done using user provided data instead of editing the respective contract.

[contract] dynamic validator set & initial conditions(deposit)

reference: https://github.com/ethereum/casper/blob/master/casper/contracts/simple_casper.v.py

Additional use cases:
"All investors are expecting to be validators. I don't know how many of them there will be, but we will know before launch."

[process] document all the steps to create a new network (ID)

Here's some examples:
https://docs.decred.org/research/overview/
https://docs.status.im/#my-first-interactive-suggestions-area

@yourheropaul

[params] review denominations (names)

Ethereum denominations:
https://github.com/kowala-tech/kUSD/blob/master/params/denomination.go

[kUSD] remove elements that will not be used

ex: pow consensus

[go-ethereum] rebase to the latest go-ethereum release (v1.73)

https://github.com/ethereum/go-ethereum/tree/v1.7.3

Token management UI

There are two parts to this: [1] token owner management and [2] mining node management.

For [1], this could just be the console. It's really just for assigning mining delegation and rewards (see #27).

For [2], this may need to be special web frontend fr a mining node. It will need to:

1. Show the public address of the node, its current status and block number, and other basic info (security not required).
2. Allow the node administrator to accept mining delegation assignments (see #27). This will require security.

[benchmark] block's fragments size

Taking into consideration:

• number of validators
• latencies
• block size

[client] light client implementation

• If the header was signed by over two-thirds of the static VS, the client can be certain that it is a valid block that has been included in the chain.

• With a dynamic validator set, a client has to keep track of the changes to the validator set. For this reason, any time there is a change in that set, the client has to download a new header, verify the validator set change is valid, and update the local validator set.

• The Tendermint Proof-of-Stake algorithm introduces a four week unbonding period in order to avoid long-range nothing-at-stake attacks. This means that as long as the last trusted header was more recent than the unbonding period, a client is secure.

• If the validator set did change considerably in the time a client was offline, it still does not have to download all headers. Instead, it can find a path of intermediate headers. The requirement for this path for any two consecutive headers is that the validator set changes by less than one-third.

  https://blog.cosmos.network/light-clients-in-tendermint-consensus-1237cfbda104

Block rewards

Rewards must be assigned to proposers during the mining process. The amount of block reward is defined in the whitepaper (modifications pending); it's the variable block reward plus transaction fees minus stability fees (see #30).

Validators must not be paid for validating. Instead, they must have validated previous blocks in order to be eligible to be the proposer (see #32).

[rpc/discussion] replace the current core apis with a grpc implementation

• interface @ node/service.go (type Service interface)

Review gas costs

UPDATE There are now answers:

• Remove variable gas price
• Fix gas price to 0.0000004 (so that a 21,000 gas price transaction costs about k$0.0084, or just less than a penny).

---

• In Ethereum the cost of operations are not measured in the token directly due market prices - change rapidly. From a marketing point of view we can use our own stable token to address and give "human" prices instead of using terms such as gas and gas limit. In volatile networks it's important to separate the price of computation from the price of the token. In our case it's not since we have a stable coin.

• The other part to the gas issue is to identify whats an acceptable "gas limit" for 1 second block times. Ethereum has a dynamic gas limit but in our case we're interested in the maximum amount of transactions in that block of time.
  A dynamic one might make sense in some scenarios.

[consensus] Interval between blocks

Ethereum force a delay between blocks for processing time. Do we need this? If so, how much delay?

[dependencies] replace glide with dep - official

add token management address (mUSD contract)

Currently the mUSD contract uses a single address to manage ownership/delegation of tokens and mining. In order to reduce the exposure of the miners private key, an address needs to be added for mining purposes only any kUSD rewards should be paid to the token management address.

[test - core.types] fix block_test.go

Depends on #4

[consensus] port tendermint to go-ethereum

references:
https://github.com/tendermint/ethermint
https://github.com/tendermint/tendermint

Implement stability fee

The stability fee must be implemented. The amount is indicated in the whitepaper, but it should be deducted from the transaction fees paid to the miner and not as an additional transaction fee.

[contracts] rename balanceOf() method (mUSD contract)

balanceOf() is a bad name that doesn't reflect the actual return value of the method. Taking delegation into account, this method returns the amount of tokens under control of the address, not the balance of the address.

[doc] modify README with kUSD details

ex: tendermint

Validation starts even without the --validate option

I have a node mining blocks and when I connect a 2nd node to it, it synchronizes and tries to start validating, but it doesn't have the --validate option.

Merge code into dev and master

In order to start testing (and building in DockerHub) we need to merge to code. Are we ready for this?

Dockerised testnet

We need a set of containers and some orchestration to quickly spin up testnets for local development, e2e testing and server deployment.

The containers should live on DockerHub, and be as abstract as possible.

[consensus] Complete the proposal mechanism.

• The current model selects the first validator as the proposer.

Oracle contract

• Oracles must hold mUSD
• They bet on the price of kUSD as often as they like
• and if they're 'correct' they get back their bet plus (some fraction of oracle reward)
• min and max bets
• scale bets by mUSD?
• increase oracle reward until the target oracle account is met
  • targetOracleCount = max(3, [marketCap/1000000])

[test - core.types] complete proposal_test.go

Dependes on #4

[params] review protocol params

files:
https://github.com/kowala-tech/kUSD/blob/master/params/protocol_params.go
https://github.com/kowala-tech/kUSD/blob/master/params/gas_table.go - bring the last gas prices from the ethereum codebase.

[kusd] review fork changes/logic

Problem: the current codebase contains a lot of code that has to do with the ethereum forks and we should just keep the latest version (all the forks) as our initial version. In order to do so, there's a chain config for the main net and for the other testnets. The extra logic should be cleaned up based on those values. We also need to verify if the fork changes make sense (use cases)

[client] review the client (cmdline) flags

has dependency to #4.

End-to-end tests

This will require some scenarios and the containerised testnet.

[test - core.types] complete vote_test.go

Depends on #4