bosnet/sebak

SEBAK, the next BOScoin Blockchain

SEBAK

SEBAK is the core node for BOScoin Tokennet.

Getting Started

Please read our Getting Started page on how to build, setup and run SEBAK.

Contribution

We welcome contributions by the community. Please open issues for any bug you find, or for enhancement requests. Pull requests are also very welcome. Before submitting, please read the contribution guidelines.

License

sebak's Issues

Same target with 'SIGN'ed ballot in boxes will wait until finished

Situation:

1. account, a0 sent tx0, which has the target account, a1
2. tx0 is escalated to SIGN state
3. account, aX sent txX, which has the same target, a1
4. txX will wait until tx0 is finished

API: Account changes to event stream

This api will produce the latest balance of account. If 'text/event-stream' header is set in request header, the node will continuously send the balance of data as response without disconnecting connection.

Basically the 'content-type' of response will be 'application/json' and the data of BlockAccount must be included.

API: Metrics to event stream

(almost same with #3 )

The metric data will have,

• number of current ongoing ballots in each boxes
• validators
• connected validators
• etc.

'Checkpoint' must not be made formerly, client can not guess the checkpoint of it’s transaction

API: Operations by account to event stream

(almost same with #3 )

This api will produce the all the operations of each account. The account address can be set in path. The response will have 'BlockOperation' data.

Change '--validator' value to be URL

Requirement is so simple,

--validator GBWCMWDUZK67YNUZ44UPNVFYZRSCCS4OLE6ORWD4ZLI2MVGY4KJDPHMO,https://localhost:12346

to

--validator https://localhost:12346?address=GBWCMWDUZK67YNUZ44UPNVFYZRSCCS4OLE6ORWD4ZLI2MVGY4KJDPHMO

It will be more meaningful and intuitive like --endpoint.

Support 'CircleCI'

Support inflation

Check compatible version of incoming message

Currently the Transaction.H.Version and Ballot.H.Version is empty, we should set up the versioning policy for these messages.

Graceful Stop

Useful library: https://github.com/facebookgo/grace

Migration from Stellar tokennet to sebak tokennet

Limit the incoming ballot, only from known validators

If unknown validator send ballot, the ballot will be ignored.

Support 'LevelDB.Transaction' in `FinishTransaction`

The way to use LevelDB.Transaction can be found at https://godoc.org/github.com/syndtr/goleveldb/leveldb#Transaction .

CLI: Node info command interface

Add node info command interface for #9

e.g. sebak node info --endpoint=localhost:12345 (default: localhost) ?

ps) IMHO, The cli can be useful for monitoring and diagnostics. If this issue is not necessity or duplicated, remove or close it freely :-)

Versioning 'Transaction', 'Ballot', etc.

The incoming messages like Transaction, Ballot, etc already have Version field, at this time in development we just leave it blank. We need the version management and versioning itself.

• How to manage version of messages
• How to make version(string)

API: All transactions to event stream

(almost same with #3 )

This will produce all the transactions. Using query string, the ordering can be set.

Test consensus for 'HTTP2Network'

sebak crash when no data is passed as body

curl -k -X POST -H "Content-Type: application/json" https://localhost:2822/message

Node "response"

127.0.0.1 - - [07/Jun/2018:09:01:40 +0000] "POST /message HTTP/2.0" 200 0 "" "curl/7.58.0"
panic: runtime error: slice bounds out of range

goroutine 25 [running]:
github.com/owlchain/sebak/lib.(*NodeRunner).handleMessage(0xc420098750)
	/go/src/github.com/owlchain/sebak/lib/node_runner.go:206 +0xe3c
created by github.com/owlchain/sebak/lib.(*NodeRunner).Start
	/go/src/github.com/owlchain/sebak/lib/node_runner.go:74 +0x51

Compressing in transferred message

Compressing the response body of API will be reduce the network traffic and latency. With #390 , the compressed data can be saved in cache, it will be more beneficial. For information, https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding .

The records in 'BlockTransactionHistory' can be removed after a given time?

API: Node info

The basic node information will be produced,

• node alias
• node status #10 #11
• public address
• endpoint
• validators
• connected validators(?)
• etc.

Expired 'VotingResult' in 'WaitingBox' must be moved to 'ReservedBox'

If VotingResult is stayed too long(almost over 2 minutes) in WaitingBox, (this means that it's ballot failed to be broadcasted), it should be moved to ReservedBox.

API: Node status to event stream

(almost same with #3 )
(similar to #9)

The node status will be produced thru event-stream

Same source with boxes will be ignored

Situation:

1. account, a0 sent tx0
2. tx0 is escalated to SIGN
3. a0 sent new tx1
4. if tx0 is not finished, the tx1 will be ignored.

Expired 'VotingResult' in 'VotingBox' must be moved to 'ReservedBox'

If VotingResult is stayed too long(almost over 2 minutes) in VotingBox, it should be moved to ReservedBox

Support 'HTTP-Problem' in API response

The detailed specification of 'HTTP-Problem' can be found in https://tools.ietf.org/rfc/rfc7807.txt .

Provide a way to accept the list of validator via environment variables

Currently all arguments can be provided via environment variable, with the notable exception of --validator.
Fixing that would simplify the docker process a bit.

New Command line option for setting the thresholds of 'SIGN' and 'ACCEPT'

Please make to accept the 'threshold's for SIGN and ACCEPT in 'cmd/sebak/cmd/node.go'. The threshold is hardcoded at https://github.com/owlchain/sebak/blob/49a885f9e31675079e872aec698ffc0c672f3693/cmd/sebak/cmd/node.go#L269 .

Create a docker image to start a network

It would be very useful for both testing and our users to have an almost 0-config image one can start to get a network up and running, and submit commands to it.

An example of such a setting would be https://github.com/stellar/docker-stellar-core

CLI Wallet: Payment

Machine readable generating keypair's output

In stellar, generating keypair is anoying to launch multiple nodes especially in containers.

Currently generating keypair's output is:

$ sebak key generate
       Secret Seed: SCN4NSV5SVHIZWUDJFT4Z5FFVHO3TFRTOIBQLHMNPAZJ37K5A2YFSCBM
    Public Address: GALQG5SCKCPXUG4ODPMFZJGZ6XBVJTLAJFR7OJKJOJVARA7M4H5SGSOG

It is hard to parse in a command line.

If it prints a format which is machine readable like:

$ sebak key generate --json
{ 
    "secret-seed": "SCN4NSV5SVHIZWUDJFT4Z5FFVHO3TFRTOIBQLHMNPAZJ37K5A2YFSCBM",
    "public-address": "GALQG5SCKCPXUG4ODPMFZJGZ6XBVJTLAJFR7OJKJOJVARA7M4H5SGSOG"
}

It's much better to launch nodes in Docker, Docker compose or Kubernetes.

Use `Amount` consistently for internal representation (& define it)

We currently store monetary amount in a string representation. In addition of being inefficient space wise, it forces conversion to/from string pretty frequently. To add insult to injury, we have an Amount type supposed to represent a monetary amount, which is converted to/from uint64 (and Amount is defined as uint64).

Since Amount is unsigned, it leads to quite some surprising code when doing substractions

Last but not least, I didn't see any place where the relation between 1 Amount and 1 BOSCoin was defined. Most (all?) cryptocurrencies represent monetary amount using integers (e.g. Bitcoin's Satoshi, ETH's Wei...) because dealing with floating point is just too error prone.

So I propose the following:

• We define Amount as being 1/10^6 BOSCoin (1 million Amount == 1 BOSCoin). This can be changed later, but will allow us to get all the fractional calculations right.
• We use Amount consistently within the code base. No string, no uint64
• We cap the maximum balance to 2^64-1 / 10^8 (notice the 10^2 of "margin" for safety). This should leave us plenty of space. I would even say we could cap it to something closer to what the whitepaper V1 defined.
• We make sure never to represent negative numbers in Amount. Functions should always be passed a positive amount, even if they are going to substract that amount from the account.

Would that make sense to everyone ?

Create node status: 'consensus', 'catchup' and 'booting'

Node will get it's status:

• consensus: node is currently participating consensus process
• catchup : node is catch up the blocks
• booting: node is preparing to be consensus
• terminating: node is going to shutdown(#9)

Modify 'README.md' for better readability

To improve performance, keeping sources in VotingBox

SourceManager manages a source list which has unique sources in the boxes.
The type of source list should be map[/* Source */ string]bool for checking uniqueness.
When a new ballot came, the source from the ballot is inserted to the list. Then, the ballot process finished, it deleted from the list.
While the ballot is in the list, new ballots from the same source are not processed.

It is related with #13(https://github.com/bosnet/sebak/pull/49/files#diff-18683a7542195386fa853b4683d31b7bR38)

Finished ballot will store the reason in 'BlockTransactionError'

If the ballot is finished and failed to get consensus, the reason must be stored in BlockTransactionError

API: Transactions by account to event stream

(almost same with #3 )

This api will produce the transactions of one account. The response will have 'BlockTransaction' data of account address.

CLI Wallet: List transaction history

Like

$ sebak wallet history

will list the transaction and it's operations history.

At booting status, check validity of entire data in storage

Catchup process

When new validator join a network, it will have no blocks, so the newbie should catch up all the blocks from other validators.

Web wallet

• Basically support main feature of current web wallet
• and password based 'secret seed' protection

Monitoring network

Expired 'VotingResult' in 'ReservedBox' must be removed

If VotingResult is stayed too long(almost over 2 minutes) in ReservedBox, it should be removed.

API: Transaction history -to event stream-

(almost same with #3)

This api can be used to check how the transmitted transaction(from client) is finished,

• tx gets consensus successfully?
• or tx is failed because of some reason

---

• If tx gets consensus successfully, the response will have BlockTransaction data.
• If failed, the response will have BlockTransactionHistory data.

Scaling by sharding

Redesign 'Checker'

Instead of using 'context', how about making Checker to be struct and value can be stored in properties.

Unreasonable 'Checkpoint` Validation

When transaction stores, it updates the Checkpoint of target account. This causes problem that target account can not know his/her latest checkpoint when he/her tries to make new tranaction.

For example, there are 3 account, a0, a1 and a2, each account has 1 BOS, and send payment transactions between each others.

souce	description	target	a2 balance	a2 checkpoint
a0	tx0 sends 1 BOS	a2	1 BOS -> 2 BOS	chk0
....
a2	tx2 sends 1 BOS	a0
....
a1	tx1 sends 1 BOS	a2	2 BOS -> 3 BOS	chk1

If a2 sends tx2 before tx1 is stored, but tx1 is stoed during tx2 under consensus. Of course, the Checkpoint of tx2 is chk0. What happened?

Current implementation will think, tx2 is invalid, that is, tx2 does not have latest checkpoint, so tx2 will be failed to get consensus.

This problem is caused because the validation just checks whether Checkpoint of transaction is the latest checkpoint of account, or not.

If the validation checks that the Checkpoint exists in transactions of the account and at that Checkpoint the balance is sufficient or not, the problem will be solved.

This is new strategy.

How Checkpoint can be made

checkpoint is: <subtracted>-<added>

• <subtracted>: hash of last paid transaction, it means balance is subtracted
• <added>: hash of last added transaction, it means balance is added

Validating Checkpoint

• if checkpoint is final checkpoint of source, check balance
• if not, try to find existing checkpoint of source
  • if not, say no
  • if found,
    • check, <subtracted> is same with <added> of final check
      • if not, say no
      • if same, check the balance of that time.

Checkpoint Changes Example

account	initial checkpoint
a0	tx0-tx0
a1	tx1-tx1
a2	tx2-tx2

source	target	transaction	checkpoint of transaction	checkpoint of source	checkpoint of target
a0	a1	tx3	tx0-tx0	a0: tx3-tx3	a1: tx1-tx3
a0	a2	tx4	tx3-tx3	a0: tx4-tx4	a2: tx2-tx4
a1	a0	tx5	tx1-tx3	a1: tx5-tx5	a0: tx4-tx5

Dashboard and transaction browser

• Transaction flow
• Network status
• Trace transaction, operation and account

Throttling incoming transactions from client

To prevent the network to be hanged out with massive incoming transaction from clients, node should throttle the incoming messages. For your information, the Stellar's horizon server uses https://github.com/PuerkitoBio/throttled .

Transaction Fee should be collected to 'Common Budget Account'

In SEBAK, there are 2 special accounts,

• genesis account(most of blockchains does)
• common budget account

'Common budget account' of our BOScoin is unique feature, it's balance can be used for entire BOScoin network and our community, it's like common goods.

When transaction is finished, it's fee will be collected to 'Common budget' account.