v1.0 last updated 1/25/2023(changelog)
Before reading, please review the Flash consensus, and read about DTP.
At a very high level, the prime goal of the system is to allow DTPs to perform update transactions with millions of users. And will enable each Wallet to opt-in and out from DTP groups. We will have a few vast and small blocks in the system.
Blocks are enumerated with block IDs. Each Validator creates a block with the same ID value. It then shares it with other validators. Once a Validator receives a block with ID N from all the validators, it creates a block with ID N+1 and shares it. The time between two block ids is called a block cycle.
During the bootstrap process, all the Validators agree on a list of Validators and the current balance of all the wallets in Confidence Coin. Only the Validators from the Validators list are considered for voting.
The voting system is embedded in blocks. It saves time on communication and increases system security.
Each block contains zero or many topics with one or many items. When Validators create block id N+1, they vote for all the topics of blocks with id N. A topic is approved if it receives 2/3 votes of all the Validators.
Topics include transactions, opting requests, scoring, and more.
Confidence Coin uses three networks
Validators publish new blocks over IPFS and announce the Content Identifier (CID) over pubsub. The CID must be signed with Curve25519. Only hashes signed by validators from the Validators list are considered valid. Other messages are dropped. This is to prevent DDOS attacks.
Validator Id is Curve25519 public key.
After each block cycle, validators generate a snapshot of the entire blockchain and publish it over their IPNS. The sequence(version number) must be the block number. The IPNS must link to a directory that has a new file for each snapshot. Also, there is no requirement to have the entire blockchain there.
Note that the snapshots directory and the files inside are not duplicated times the number of the Validators. There is a consensus about the content of those snapshots. All the Validators produce the same files that result in the same CIDs.
It serves multiple purposes.
It contains block time T, a new line, and then the below items, separated with a new line. Each item is a headless TSV list. The list terminates with a new line.
Wallets and DTPs create topic items. They use the HTTP protocol to contact Validators. The list of the HTTP remotes is obtained from the Validators list in the snapshot that is hosted on IPFS by all the Validators and some other Wallets and DTPs. Those are the most popular files in Confidence Coin.
HTML requests use JSON API. The response is a success or error code. In this documentation, I placed the HTML API in a table. The topic structure inlines all the columns and delimiters them with a tab.
For example, the below documentation: |param|description| |-|-| |param 1| param1 description| |param 2| param2 description| |param 3| param3 description|
Translates into the below JSON request
{
"param1" : "data",
"param2" : "data",
"param3" : "data"
}
And the below line in topics.
param1 param2 param3
Wallets can opt in and off to and from any DTP.
| param | description |
|---|---|
| wallet address | Curve25519 public key |
| DTP id | DTP wallet address |
| signature | Curve25519 signature |
There is a T seconds timeout waiting to get blocks from other validators.
In case no RED was removed, and there is less than 10% YELLOW, the time is reduced to have 10% YELLOW and up to 1% RED(not inclusive) by 2/3 votes, based on the last block cycle. For this calculation purpose, a RED with a low score will be calculated as T.
The goal of this algorithm is to remove slow Validators and always operate at maximum network capacity. Aka not running into timeouts. This makes the block time inconsistent. It will improve as technology improves.
| param | description |
|---|---|
| pubsub score | the time in integer seconds, round down it took to announce the block |
| IPFS score | the time in integer seconds, round down it took to download the block from IPNS |
Note that topics are already sectioned by Validators, so there is no need to include a validator id. Also, there is no HTTP API for scoring. This is a particular internal action.
A wallet can convert itself to DTP if it opt-out from other DTPs. It must provide an update time in seconds for how often it will sync Wallet balances to the blockchain via the update transaction.
| param | description |
|---|---|
| Wallet address | DTP wallet address |
| update time | the time in seconds for the periodic update |
| signature | Curve25519 signature |
DTP must perform an update transaction within the update time from its conversion to DTP or the last update transaction. If it fails, it loos all the Wallets in the DTP group and converts back to regular Wallet.
Only the Wallets ids and the new balance are required when making the transaction. The ids come from the Balance list in the Blockchain snapshot. The snapshot must be fresh from the last ten snapshots. DTP should try to use the latest.
| param | description |
|---|---|
| Block id | Block id for wallets ids mapping |
| new Wallet addresses | Comma-delimited list of new wallet addresses, optionally concatenated with the DTP address(Wallet address is fixed length). |
| Wallets ids | Comma-delimited list of Wallets ids from the Balance List |
| balance ids | Comma-delimited list of balances corresponding to the Wallets ids and the new Wallets |
| signature | Curve25519 signature of the DTP |
When opting for a DTP, the Wallet is automatically removed from other DTPs. To synchronize the off-chain transactions inside the DTP with opting requests. When the Wallet belongs to a DTP group, its opting requests be delayed until the next DTP update transaction or until it is automatically removed from the DTP because the DTP didn’t update on time.
| param | description |
|---|---|
| DTP id | The wallet address of the DTP |
| opting | in/out to opt-in or out |
| signature | Curve25519 signature |
Blocks use JSON API and have the below structure:
Note that there is no block hash in here. This is because the system is using CID.
Block time is calculated as the median block creation time of all the blocks with the same block id.
Based on Block time, the system gives block rewards with the following block after the earliest block in a day, consisting of transaction fees and new coins.
The reward is scored based on the stack, and there are penalties for scoring below 50% percentile in the below metrics.
Up to 50% penalty is deducted from the stake value based on the percentile position rounded to integer percent.
There are 1,798,974,000,000 hard-cap coins. It was based on the dollar circulation value in Jan 2020, right before the epidemic started.
The daily reward is calculated using the below function, where X is a day starting from 1.
$f(X)=Max(0,-2,700X + 98,563,309)$
It will be fully mined in 36,505 days(~100 years).
In a system where all the transactions are processed, there is no point in setting up transaction fees incentive on a transaction level. However, the system is more open to transaction DDOS attacks without transaction fees. Therefore transaction fees are set on a system level per transaction type.
Each day in the block follows the reward block. A vote is made to change the transaction fees. In case they are changed, the new value will be applied within a week of the change, starting from the block after the daily reward. The clock would be reset if additional changes were made during that time.
1% of the block rewards will be sent to the Confidence Coin Foundation Wallet. Instead of premining the coin or doing an IPO, we believe in a fair game. Confidence Coin foundation will work hard to bring the Confidence Coin into the mainstream and maximize its value.
With a linear reward system, zero pre-mined coins, and a Foundation behind. Confidence Coin is set for success.