Difference between revisions of "Cardano"

From Organic Design wiki
m (Monitoring your pool's rewards)
m (Staking in Cardano)
(35 intermediate revisions by the same user not shown)
Line 9: Line 9:
 
Cardano uses a proof-of-stake (PoS) mechanism based on the [https://aft.acm.org/wp-content/uploads/2019/10/Ouroboros_AFT19_Tutorial.pdf Ouroboros protocol family]. The usual "longest chain rule" that secures proof-of-work blockchains like Bitcoin is not directly applicable in PoS systems. Nodes that (re)join the network for the first time or after being offline for a while therefore need to trust the information that they receive from other nodes. This is known as the '''bootstrapping problem''', which increases the network’s vulnerability to '''long range attacks'''. In a long range attack, a node is offered an alternative version of the blockchain and the node has limited or no recent information available to distinguish whether this is the correct version. Proof-of-stake systems have been around since 2011, but as of late 2019 Cardano is the first one to overcome all of these design challenges in order to reach the same level of security as Bitcoin.
 
Cardano uses a proof-of-stake (PoS) mechanism based on the [https://aft.acm.org/wp-content/uploads/2019/10/Ouroboros_AFT19_Tutorial.pdf Ouroboros protocol family]. The usual "longest chain rule" that secures proof-of-work blockchains like Bitcoin is not directly applicable in PoS systems. Nodes that (re)join the network for the first time or after being offline for a while therefore need to trust the information that they receive from other nodes. This is known as the '''bootstrapping problem''', which increases the network’s vulnerability to '''long range attacks'''. In a long range attack, a node is offered an alternative version of the blockchain and the node has limited or no recent information available to distinguish whether this is the correct version. Proof-of-stake systems have been around since 2011, but as of late 2019 Cardano is the first one to overcome all of these design challenges in order to reach the same level of security as Bitcoin.
  
There have been a number of versions of the Ouroboros protocol released so that the various aspects could be tested and developed in phases - not to be confused with Cardano's eras. The first version which is now being called "Classic" was the basic PoS system that depended on all nodes being constantly connected and in-sync. the next version was "Praos" which allowed for nodes to come and go as they please, which is of course an essential aspect of a real-world peer-to-peer network. The next version was called "Genesis" which was major, because that's what brought all Cardano's promises of a new superior system into reality.
+
There have been a number of versions of the Ouroboros protocol released so that the various aspects could be tested and developed in phases - not to be confused with Cardano's eras. The first version which is now being called '''Classic''' was the basic PoS system that depended on all nodes being constantly connected and in-sync. The next version was '''Praos''' which allowed for nodes to come and go as they please, which is of course an essential aspect of a real-world peer-to-peer network. The next version was called '''Genesis''' which was major, because that's what brought all Cardano's promises of a new superior system into reality, and is the version we're currently running in the Incentivised test Network (ITN).
  
 
Since Genesis, Ouroboros was the first PoS protocol that is mathematically proven to guarantee persistence and liveness in both a synchronous and semi-synchronous setting — under the assumption that a honest majority participating, just like Bitcoin. Hence, it is more secure than other PoS protocols that require at least 2/3 honest participants (e.g. Ethereum Casper, Algorand) and equally secure as Bitcoin, but with a much lower energy expenditure and better performance.
 
Since Genesis, Ouroboros was the first PoS protocol that is mathematically proven to guarantee persistence and liveness in both a synchronous and semi-synchronous setting — under the assumption that a honest majority participating, just like Bitcoin. Hence, it is more secure than other PoS protocols that require at least 2/3 honest participants (e.g. Ethereum Casper, Algorand) and equally secure as Bitcoin, but with a much lower energy expenditure and better performance.
  
The version that was first released with the Shelley testnet was called Chronos which allows nodes to operate together without depending on a global time external to the network, making the system more independent and resilient. The final planned version of the protocol is Hydra which introduces sharding into the system.
+
The next version is called '''Chronos''' which allows nodes to operate together without depending on a global time external to the network, making the system more independent and resilient. The final planned version of the protocol is '''Hydra''' which introduces ''sharding'' into the system.
  
 
== Staking in Cardano ==
 
== Staking in Cardano ==
Cardano uses the [https://cardanodocs.com/cardano/proof-of-stake/ Ouroborus] (Currently the [https://eprint.iacr.org/2019/838.pdf Chronos] version) proof-of-stake algorithm to secure the network. In addition to the main block chain, this system divides time into '''epochs''' and '''slots'''. In the mainnet, there are '''21,600''' slots each lasting '''20 seconds''' which makes an epoch '''5 days'''. In the incentivised testnet, slots are only '''2 seconds''' long and there are '''43,200''' of them making up an epoch of '''24 hours'''.
+
Cardano uses the [https://cardanodocs.com/cardano/proof-of-stake/ Ouroborus] (Currently the '''Genesis''' version) proof-of-stake algorithm to secure the network. In addition to the main block chain, this system divides time into '''epochs''' and '''slots'''. In the mainnet, there are '''21,600''' slots each lasting '''20 seconds''' which makes an epoch '''5 days'''. In the incentivised testnet, slots are only '''2 seconds''' long and there are '''43,200''' of them making up an epoch of '''24 hours'''.
  
At the start of each slot a '''slot leader''' is randomly '''elected''' and it is their right to create the next block in the blockchain if one is needed at that time, and receive a reward for doing so. If they're not able to create the block, they miss out and someone else is elected in their place. In the testnet there are roughly '''3000''' blocks created during each slot. During each epoch, random numbers are written to the blockchain; those numbers provide a mechanism to randomly select future slot leaders. In essence, this mechanism signifies the symbology behind the Ouroboros name: a snake eating its own tail.
+
At the start of each slot, one or more '''slot leaders''' are randomly '''elected''' and it is their right to create the next block in the blockchain if one is needed at the time of that slot, and receive a reward for doing so. The first one to create block for the slot and publish it to the network will receive the reward, if none are able to create the block, it will be created during a subsequent slot. In the testnet there are roughly '''3000''' blocks created during each slot. During each epoch, random numbers are written to the blockchain by the slot leaders using [[w:Publicly Verifiable Secret Sharing|Publicly Verifiable Secret Sharing]] (Specifically [https://www.win.tue.nl/~berry/papers/crypto99.pdf Schoenmakers's] variation of the original Stadler PVSS from 1996) to avoid people gaming their numbers. Those numbers provide a mechanism to randomly select future slot leaders at the start of each slot in a way that can be determined independently by any node, but also cannot be known before the end of end of the last epoch. In essence, this mechanism signifies the symbology behind the Ouroboros name: a snake eating its own tail.
 +
 
 +
In Ouroborus classic, this leader election schedule was know publicly (i.e. it could be calculated by anyone at the start of an epoch), and there was exactly one leader for every slot. But this gives rise to the possibility of the leaders being attacked in order to prevent them creating their blocks. In the Praos version, the mechanism is improved by using a [[w:Verifiable random function|Verifiable Random Function]] (VRFs were introduced by Micali, Rabin, and Vadhan in 1999) is used so that each node can determine for themselves what their own leader schedule is (i.e. what slot they are the leader for in the current epoch), but nobody else can know this information. A VRF is a way of executing a function using your private key so that you can also provide a proof that your output did indeed result from execution of that exact function with the specified inputs, and then anyone can verify your proof using your public key. In this way when a node creates a new block, other nodes will only accept it if it's accompanied by a valid proof that the node was indeed a true leader for the slot. Using this system there may be more than one valid leader for a slot, or also there may be no leaders at all.
  
 
The Cardano staking system fundamentally works to incentivize two primary activities. The first is making sure that stakeholders are online. The second is participation in the protocol, i.e., block creation. Because there are many people who are either unable to run their own servers with 24/7 uptime or who don't want to create a stake pool, they will be able to delegate their stake to a pool of their choice. Delegation addresses are different from standard ADA addresses.
 
The Cardano staking system fundamentally works to incentivize two primary activities. The first is making sure that stakeholders are online. The second is participation in the protocol, i.e., block creation. Because there are many people who are either unable to run their own servers with 24/7 uptime or who don't want to create a stake pool, they will be able to delegate their stake to a pool of their choice. Delegation addresses are different from standard ADA addresses.
Line 36: Line 38:
  
 
==== Performance ====
 
==== Performance ====
A pool's '''performance''' is measured as ''(n / N) * (S / s)'' where '''n''' is the number of blocks produced by the pool in the last epoch, '''N''' is the number of slots in the epoch, '''S''' is the total stake delegated to pools in the last epoch and '''s''' is the stake owned by the pool in the last epoch. It's a measurement that applies purely to the last completed epoch and represents how well a pool is doing taking into account it's size. It's the proportion out of all possible blocks that were created by the pool, multiplied by how many of that pool it would take to occupy the whole stake.
+
A pool's '''performance''' is measured as ''(n / N) * (S / s)'' where '''n''' is the number of blocks produced by the pool in the current unfolding epoch, '''N''' is the number of slots this epoch, '''S''' is the total delegated stake this epoch and '''s''' is the stake owned by the pool this epoch. It's a measurement that applies purely to the current epoch and represents how well a pool is doing taking into account it's size. It's the proportion out of all possible blocks so far that have been produced by the pool, multiplied by how many of that pool it would take to occupy the total stake. This is the formula used in Daedalus, but it is averaged over a number of epochs according to the [https://github.com/input-output-hk/cardano-wallet/blob/f003b3139ff883fd5b6bb0566c4aa9786c838eca/lib/core/src/Cardano/Pool/Metrics.hs#L430 code comments].
  
 
==== Delegation ====
 
==== Delegation ====
Line 60: Line 62:
  
 
=== Running a staking pool on the incentivised testnet ===
 
=== Running a staking pool on the incentivised testnet ===
To run a staking pool you'll need a reasonable server that is on a reliable high-bandwidth connection. First you need to install the node software, then create the cryptographically signed staking pool parameters associated with a funded pledge address, and then finally register your pool so it shows up in the staking wallets. This section is mainly based on the instructions at [https://github.com/input-output-hk/shelley-testnet/blob/master/docs/stake_pool_operator_how_to.md Stake Pool Operators How-To] with a few differences.
+
This section was getting rather large and has been moved to its own article at [[Set up a Cardano staking pool]].
 
 
==== Install and configure Jormungandr ====
 
We start by installing the latest release (not a pre release) of ''Jormungandr'' from the [https://github.com/input-output-hk/jormungandr/releases official repo] (it's a good idea to subscribe to the repo's [https://github.com/input-output-hk/jormungandr/releases.atom feed] so you can know as soon as new stable releases are available). One important difference from their procedure is that we need to use the '''itn_rewards_v1''' [https://hydra.iohk.io/build/1523436/download/1/index.html configuration] rather than the ''beta'' configuration. A couple of differences from their procedure too: first I had to change both 0.0.0.0's in the config to my external IP not just the public one, second a storage location needs to be added to make the chain data persistent. The first few sections of your config file should look something like this:
 
<source lang="json">
 
{
 
  "log": [
 
    {
 
      "format": "plain",
 
      "level": "info",
 
      "output": "stdout"
 
    }
 
  ],
 
  {!"storage": "./storage/",!}
 
  "p2p": {
 
    "listen_address": "/ip4/{!1.2.3.4!}/tcp/3100",
 
    "public_address": "/ip4/{!1.2.3.4!}/tcp/3100",
 
    "topics_of_interest": {
 
      "blocks": "high",
 
      "messages": "high"
 
    },
 
    . . .
 
</source>
 
 
 
Another issue is that I was not able to find any genesis hash in the configuration as it says there should be, I had to obtain it myself from the last page of slots for [https://shelleyexplorer.cardano.org/en/epoch/0/ epoch 0] which yields [https://shelleyexplorer.cardano.org/en/block/8e4d2a343f3dcf9330ad9035b3e8d168e6728904262f2c434a4f8f934ec7b676/ this] (later I found this parameter and others [https://github.com/cardano-foundation/incentivized-testnet-stakepool-registry/wiki/Protocol-Parameters here]).
 
 
 
I create a script called '''start.sh''' to run it with the correct parameters in the background and redirected its output to a log file:
 
<source lang="sh">
 
#!/bin/sh
 
nohup ./jormungandr --config itn_rewards_v1-config.yaml \
 
      --genesis-block-hash 8e4d2a343f3dcf9330ad9035b3e8d168e6728904262f2c434a4f8f934ec7b676 >> debug.log &
 
</source>
 
 
 
If you see no errors in the log and the daemon keeps running, you can check the sync progress by running the '''node stats''' command and checking that the '''lastBlockDate''' matches the current epoch and slot shown in the [https://shelleyexplorer.cardano.org Shelley explorer].
 
<source lang="bash">
 
./jcli rest v0 node stats get --host "http://127.0.0.1:3100/api"
 
</source>
 
 
 
<source lang="json">
 
blockRecvCnt: 41
 
lastBlockContentSize: 0
 
{!lastBlockDate: 7.35623!}
 
lastBlockFees: 0
 
lastBlockHash: "f78c64c030383899ebb1b25dac7ae9d360d222d0b80320323375dc51762651d2"
 
lastBlockHeight: 26342
 
lastBlockSum: 0
 
lastBlockTime: "2019-12-21T15:15:20+00:00"
 
lastBlockTx: 0
 
state: "Running"
 
txRecvCnt: 45
 
uptime: 886
 
version: "jormungandr 0.8.3-8f276c0"
 
</source>
 
 
 
To shut the node down gracefully use:
 
<source lang="bash">
 
./jcli rest v0 shutdown get --host "http://127.0.0.1:3100/api"
 
</source>
 
 
 
==== Monitoring your node with a sentinel ====
 
This may be just a problem on the testnet, but nodes seem to get stuck a lot and require a restart. This used to happen a lot with Masternodes as well, and the general solution was to run a "sentinel" script that checks on the node and perform the necessary processes when something's not right. In the case of ''Jormungandr'' a simple restart of the node seems to resolve the issue, so I made this [https://code.organicdesign.nz/tools/blob/master/crypto/cardano-sentinel.pl sentinel.pl] script that is to be run from the ''crontab'' every minute. It checks if no new block hash has been created for more than a certain time, and if not it restarts the node. If it's still stuck on the same block even after restarting, then the node has probably gotten itself onto a fork, so the sentinel backs up the chain data and logs and restarts the node from a clean slate.
 
 
 
The script takes two parameters, the first is the number of seconds to wait between polling the node (must be a multiple of 60), and the second is the number of seconds of seeing no new block hash after which we should assume that the node is stuck and restart it. Both parameters are optional and default to 5 and 120 respectively. The script assumes a local node to be running on port 3100, and also expects a script called ''start.sh'' in the same directory that starts the node in the background with all the necessary parameters.
 
 
 
The script writes the situation to a file in the same directory called ''sentinel.log'' which will look like the following snippet. The first part in square brackets is the Unix timestamp of the entry followed by a duration after the slash.
 
<source>
 
[1577145836/040] Epoch:10 Slot:8709 Block:34597 Hash:7c1db1bbb77d88636349371d5e7ef60e3cb8a2257e2d9aa8d109eecce3236689
 
[1577145891/055] Epoch:10 Slot:8735 Block:34598 Hash:fb84bb2a0e48233837d1d5773219b3be9661f333f3aaea41867372f0ed224197
 
[1577145916/025] Epoch:10 Slot:8746 Block:34599 Hash:c3da1a7f72815280f70e1956b33fda993ad788317515dbd2a5c74e96293b5c2b
 
[1577146041/125] Stuck on 10.8746, restarting node...
 
[1577146046/000] Status unknown, check if the node is running!
 
[1577146051/030] Bootstrapping
 
[1577146086/000] Epoch:10 Slot:8821 Block:34600 Hash:c93189408bcf7e9fe954e72502f720b661002fb365c3283b16b0a8260bd2cf4f
 
[1577146126/040] Epoch:10 Slot:8854 Block:34601 Hash:c3af8796c932f635067757b4cbaa1c58c6e7623d1660902172f0cf59b439d12e
 
[1577146136/010] Epoch:10 Slot:8858 Block:34602 Hash:b21af406419002e5b57b7e3bee7dec5378d10f76670d7780a642fbe1d2e60082
 
[1577146167/031] Epoch:10 Slot:8872 Block:34603 Hash:573c2b9142eff7435d2aa1cd657b808546c592c62e3710d0143670032ad0fecc
 
</source>
 
'''Note:''' The sentinel misses blocks that are generated quicker than the polling period, so the log shouldn't be used as a definitive chain report, for this application it's only the slow updates that we're concerned about, so missing blocks are not a problem.
 
 
 
==== Creating and funding a reward address ====
 
Now we need to create three files for our reward account, a public/private key-pair and it's corresponding ADA address which I did by following the instructions in [https://github.com/cardano-foundation/incentivized-testnet-stakepool-registry/wiki/How-to-register-your-stake-pool-on-the-chain#protocol-parameters how to register your stake pool on the chain].
 
<source lang="bash">
 
./jcli key generate --type ed25519 | tee owner.prv | ./jcli key to-public > owner.pub
 
./jcli address account --testing --prefix addr `cat owner.pub` > owner.addr
 
</source>
 
 
 
You can then send funds (minimum 510 ADA) to the account from ''Daedalus'' or ''Yoroi'', and then check the balance:
 
<source lang="bash">
 
./jcli rest v0 account get {!YOUR_ADDR!} -h http://127.0.0.1:3100/api
 
</source>
 
 
 
<source>
 
counter: 0
 
delegation:
 
  pools: []
 
last_rewards:
 
  epoch: 0
 
  reward: 0
 
value: {!550000000!}
 
</source>
 
 
 
==== Create the stake pool and publish to the blockchain ====
 
Finally we need to create the stake pool itself which can be done by calling the handy [https://github.com/input-output-hk/jormungandr-qa/blob/master/scripts/createStakePool.sh createStakePool.sh] and [https://github.com/input-output-hk/jormungandr-qa/blob/master/scripts/send-certificate.sh send-certificate.sh] scripts. You only need to run the former script which calls the latter, make sure both are executable first. The script takes four parameters, the listening port, the fixed tax (in lovelace), the percentage as a fraction and the private key of your reward address that you put in the ''owner.prv'' file above. For example:
 
<source lang="bash">
 
./createStakePool.sh 3100 1000000 5/100 {!OWNER_PRIV_KEY!} | tee results.txt
 
</source>
 
This will create a pool that takes 1 ADA (1M Lovelaces) fixed rate, and 5%. Note that the instructions say you need another ''tax_limit'' parameter, but this must have been removed at some point. This script returns two important values that you need to keep, the '''Pool ID''' and '''Pool Owner''', but by appending the ''tee'' command, all the output is also captured in '''results.txt'''. It also creates the important '''node_secret.yaml''' file that is used when starting ''jormungandr'' from now on. Check the output for errors and successful signing and sending of the new pool registration transaction, you should see something like this in your output:
 
<source>
 
## 10. Encode and send the transaction
 
56ded95ea6868470337272ef899264abb5c27dcdd2f9aae839924dca19b5dd3f
 
## 11. Remove the temporary files
 
## Waiting for new block to be created (timeout = 200 blocks = 400s)
 
New block was created - 8fe7ac108640778ca53ce4d38ed8b7b6092454770d4aaf04a38ec548cc66b330
 
</source>
 
 
 
'''Note:''' If anything goes wrong in this process, you're best creating a new pledge address before trying again, because if you end up with more than one pool operating on the same pledge address, only the last one will work.
 
 
 
'''IMPORTANT:''' As soon as you've created an address and node secret, create a directory for it using the stake id, or its first few characters, as the name and copy all the specific files into it so you have them in case you need them later. For example you need them if you want to retire the pool, or sign any messages as that pool owner, even if it's just a dummy run and you're sure you'll never need to refer to them again, do it anyway! The files are '''node_secret.yaml''', '''stake_pool.id''', '''owner.prv''', '''owner.pub''', '''owner.addr''' and '''results.txt'''.
 
 
 
 
 
Now you're ready to shut your node down and restart it with you secret key parameter to start it as a pool!
 
<source lang="bash">
 
./jcli rest v0 shutdown get --host "http://127.0.0.1:3100/api"
 
nohup ./jormungandr --config itn_rewards_v1-config.yaml {!--secret node_secret.yaml!} \
 
      --genesis-block-hash 8e4d2a343f3dcf9330ad9035b3e8d168e6728904262f2c434a4f8f934ec7b676 >> debug.log &
 
</source>
 
'''Note:''' Remember to add the <tt>--secret node_secret.yaml</tt> parameter to the command in your ''start.sh'' script.
 
 
 
==== Register the pool in the official registry ====
 
To allow people to delegate their stake to your pool in a supporting wallet, you need to add your pool to the public registry. This is done by creating a JSON file containing your pool's details, and a file signing the JSON content with the owner's private key, and committing these files to the [https://github.com/cardano-foundation/incentivized-testnet-stakepool-registry/blob/master/registry/ed25519_pk1fhjw9hv6szzzhfnnk2ft4nqwp7jg2esd7x7a4pr2hj8n9m043snqwp3hlc.json registry's Github repo].
 
 
 
The name of the pool is your owner public key (which is in the ''owner.pub'' file) appended with a <tt>.json</tt> file extension. The content of the file is as follows. The "owner" field is the same key as used in the filename, and the "pledge_address" field is the owner address which is in your ''owner.addr" file.
 
<source lang="json">
 
{
 
  "owner": "{!OWNER_PUBKEY!}",
 
  "name": "Pudim o gatinho com fome",
 
  "description": "All your stake are belong with PUDIM!",
 
  "ticker": "PUDIM",
 
  "homepage": "https://pudim.od.gy",
 
  "pledge_address": "{!OWNER_ADDR!}"
 
}
 
</source>
 
'''Note:''' This file must be valid JSON (e.g. you must use double quotes) otherwise the pull request will fail.
 
 
 
 
 
Then to sign this JSON file with the owner's private key, you use ''jcli'' as follows:
 
<source lang="bash">
 
./jcli key sign --secret-key owner.prv --output {!OWNER_PUBKEY!}.sig {!OWNER_PUBKEY!}.json
 
</source>
 
 
 
 
 
You then need to fork the Cardano foundation's [https://github.com/cardano-foundation/incentivized-testnet-stakepool-registry/ incentivized-testnet-stakepool-registry] Github repo, clone your new fork of it, add your two files into the ''registry'' directory, add, commit and push them and then create a [[git#pull requests|pull request]] on the Github site in your forked repo page. Note that it's always best to create a new branch for a pull request, because all commits even after you've made the request are automatically included in the pull request at the upstream repo. Note that the following example is assuming that you've cloned the repo in your pool directory, if you haven't adjust the path to your keys as necessary.
 
<source lang="bash">
 
git clone git clone git@github.com:{!YOUR_GITHUB_USERNAME!}/incentivized-testnet-stakepool-registry.git
 
git checkout -b PUDIM
 
cd incentivized-testnet-stakepool-registry/registry
 
cp ../../{!OWNER_PUBKEY!}.* ./
 
git add *
 
git commit -m "PUDIM"
 
git push --set-upstream origin PUDIM
 
</source>
 
The pull request will verify your that your JSON is valid and your signature verifies, and if so the team should approve it for inclusion in the registry shortly after, and your stake pool will be listed in the delegation interface of Daedalus!
 
 
 
The image below shows two pull requests to the official registry repo, our [https://github.com/cardano-foundation/incentivized-testnet-stakepool-registry/blob/master/registry/ed25519_pk17nxgfr5kaarkv2aj70e253vv62we6ahsp2g7dakgfqsayjzhc7lsft8ek8.json PUDIM registration] has passed, meaning that the JSON syntax is all correct and the signature has been successfully verified, but the MORON pool registration has not been successful. Even after a successful pull request, manual validation is required by the Cardano team, ours was [https://github.com/cardano-foundation/incentivized-testnet-stakepool-registry/pull/967 accepted] the next day.
 
{{table
 
|[[File:Pudim-pool.jpg|300px]]
 
|[[File:Pudim-pool-accepted.jpg|252px]]
 
}}
 
 
 
'''Note:''' If you want to remove your pool from the register or change it's details, see [https://github.com/cardano-foundation/incentivized-testnet-stakepool-registry/wiki/How-do-I-delete-or-update-my-pool-metadata%3F these details] which involve creating two [[Git#Pull_requests|pull requests]], one for a signed "voiding" of the old metadata file, and another to add the new metadata and signature files.
 
 
 
'''Congratulations PUDIM!''' She produced her [https://shelleyexplorer.cardano.org/en/block/094ca84f50fefb80916e247bb67dcf5f46f6f7502c50a8665dd734bf4da9036d/ first block] in the early morning of December 27<sup>th</sup> 2019 🎉 🎉 🎉
 
 
 
All blocks produced by PUDIM can be seen in the Shelly Explorer [https://shelleyexplorer.cardano.org/en/stake-pool/13639654c2910f5fdcaa4a44d3f0bd01ad634768dcef52ac8c7d54c59bc46305/ here].
 
 
 
==== Monitoring your pool's rewards ====
 
Another kind of monitoring that is very useful is to be notified by email when your node has produced a new block! I've made a script for this too called [https://code.organicdesign.nz/tools/blob/master/crypto/cardano-pool-blocks.pl cardano-pool-blocks.pl]. It uses the official IOHK testnet block explorer and registration repo to get the information on the blocks your node has created, and to get your node's metadata to make the message more friendly.
 
 
 
The script is called with two parameters, the first being the email address to notify, and the second being the ID of your stake pool (as shown in the ''stake_pool.id'' file). It will create a log of the created blocks in the same directory called ''cardano-pool-blocks.log''. It should be called regularly on the ''crontab'' and will send email such as the following example after a new block is made. I've highlighted the parts that come from your registered metadata.
 
<source>
 
{!PUDIM!} has produced a new block!
 
</source>
 
<source>
 
Congratulations!!!
 
 
 
This is the 18th block produced by {!Pudim a gatinha com fome!}!
 
 
 
Epoch:17 Slot:36049 Block:58639
 
Hash:6d5f133d01221117b2bb2b5ee4c042588c679eaeab10d83e40f5e7c0cc902a3c
 
 
 
{!All your stake are belong with PUDIM!
 
https://pudim.od.gy!}
 
</source>
 
  
 
=== Staking resources ===
 
=== Staking resources ===
Line 261: Line 71:
 
*[https://www.youtube.com/watch?v=2pdkIXDU1no 7 part lecture series on the Cardano incentives and staking mechanism]
 
*[https://www.youtube.com/watch?v=2pdkIXDU1no 7 part lecture series on the Cardano incentives and staking mechanism]
 
*[https://pooltool.io/ PoolTool.io] & [https://adapools.org/ ADApools.org]
 
*[https://pooltool.io/ PoolTool.io] & [https://adapools.org/ ADApools.org]
*[https://forum.cardano.org/t/useful-resources-to-run-and-operate-stakepools/28402 Useful resources for operating stake pools]
 
  
 
== Cardano address types ==
 
== Cardano address types ==
Line 304: Line 113:
  
 
== See also ==
 
== See also ==
*[https://pudim.od.gy/ Pudim's Cardano staking pool]
+
*[[Set up a Cardano staking pool]]
 
*[https://medium.com/@undersearcher/how-secure-is-cardano-5f1e076be968 How secure is Cardano?]
 
*[https://medium.com/@undersearcher/how-secure-is-cardano-5f1e076be968 How secure is Cardano?]
 
*[https://forum.cardano.org/t/summary-pos-delegation-incentives-lars-brunjes/11880 Summary of incentives in the Cardano staking system]
 
*[https://forum.cardano.org/t/summary-pos-delegation-incentives-lars-brunjes/11880 Summary of incentives in the Cardano staking system]
 
*[https://medium.com/coinmonks/running-a-cardano-node-with-docker-f03c4c13cbd3 Running a Cardano node using Docker]
 
*[https://medium.com/coinmonks/running-a-cardano-node-with-docker-f03c4c13cbd3 Running a Cardano node using Docker]
 
*[https://github.com/clio-one/cardano-on-the-rocks/tree/master/scripts/Jormungandr Cardano on the Rocks] ''- a self-hosted stake pool running on a Rock Pi''
 
*[https://github.com/clio-one/cardano-on-the-rocks/tree/master/scripts/Jormungandr Cardano on the Rocks] ''- a self-hosted stake pool running on a Rock Pi''
*[https://input-output-hk.github.io/jormungandr/introduction.html Jormungandr users guide]
 
 
*[https://adascan.net/rich-list/ Cardano rich list]
 
*[https://adascan.net/rich-list/ Cardano rich list]
 
*[https://medium.com/@CardaniansI/satoshi-would-like-cardano-and-refuse-bitcoin-maximalism-ad23d71990a8 Satoshi would like Cardano and disagree with Bitcoin maximalists]
 
*[https://medium.com/@CardaniansI/satoshi-would-like-cardano-and-refuse-bitcoin-maximalism-ad23d71990a8 Satoshi would like Cardano and disagree with Bitcoin maximalists]
 
[[Category:Cryptocurrency]]
 
[[Category:Cryptocurrency]]

Revision as of 21:07, 13 January 2020

Cardano is home to the ADA cryptocurrency, which can be used to send and receive digital funds. The currency is named after Ada Lovelace, who was the first ever person to recognise that a machine had applications beyond pure calculation, and she published the first algorithm intended to be carried out by such a machine. A millionth of a single ADA token is called a Lovelace, the smallest denomination in the Cardano network. Fast, direct transfers are guaranteed to be secure through the use of cryptography and require no trusted third party just like Bitcoin. Unlike Bitcoin however, Cardano does not require a computationally expensive mining operation in order to secure the network, and has been mathematically proven to be as secure as Bitcoin without it.

Cardano is more than just a cryptocurrency, however, it is a technological platform that will be capable of running financial applications currently used every day by individuals, organisations and governments all around the world. The platform is being constructed in layers, which gives the system the flexibility to be more easily maintained and allow for upgrades by way of soft forks. After the settlement layer that will run ADA is complete, a separate computing layer will be built to handle smart contracts, the digital legal agreements that will underpin future commerce and business. Cardano will also run decentralised applications, or dapps, services not controlled by any single party but instead operate on a blockchain.

Cardano development eras

The Cardano functionality is being developed in five so-called eras, each gathered and presented on its own dedicated page: Byron (laying the foundation), Shelley (staking and decentralisation), Goguen (smart contracts), Basho (network optimisation and scaling), and Voltaire (decentralised governance). Each page has an overview of the goals of the era, as well as descriptions of the core functional components, links to associated academic research, status updates, and even real-time code commits. Each era is centred around a set of functionalities that will be delivered across multiple code releases. While the eras of Cardano will be delivered sequentially, the work for each era happens in parallel, with research, prototyping, and development often in progress all at once across the different development streams.

The Ouroboros protocol family

Cardano uses a proof-of-stake (PoS) mechanism based on the Ouroboros protocol family. The usual "longest chain rule" that secures proof-of-work blockchains like Bitcoin is not directly applicable in PoS systems. Nodes that (re)join the network for the first time or after being offline for a while therefore need to trust the information that they receive from other nodes. This is known as the bootstrapping problem, which increases the network’s vulnerability to long range attacks. In a long range attack, a node is offered an alternative version of the blockchain and the node has limited or no recent information available to distinguish whether this is the correct version. Proof-of-stake systems have been around since 2011, but as of late 2019 Cardano is the first one to overcome all of these design challenges in order to reach the same level of security as Bitcoin.

There have been a number of versions of the Ouroboros protocol released so that the various aspects could be tested and developed in phases - not to be confused with Cardano's eras. The first version which is now being called Classic was the basic PoS system that depended on all nodes being constantly connected and in-sync. The next version was Praos which allowed for nodes to come and go as they please, which is of course an essential aspect of a real-world peer-to-peer network. The next version was called Genesis which was major, because that's what brought all Cardano's promises of a new superior system into reality, and is the version we're currently running in the Incentivised test Network (ITN).

Since Genesis, Ouroboros was the first PoS protocol that is mathematically proven to guarantee persistence and liveness in both a synchronous and semi-synchronous setting — under the assumption that a honest majority participating, just like Bitcoin. Hence, it is more secure than other PoS protocols that require at least 2/3 honest participants (e.g. Ethereum Casper, Algorand) and equally secure as Bitcoin, but with a much lower energy expenditure and better performance.

The next version is called Chronos which allows nodes to operate together without depending on a global time external to the network, making the system more independent and resilient. The final planned version of the protocol is Hydra which introduces sharding into the system.

Staking in Cardano

Cardano uses the Ouroborus (Currently the Genesis version) proof-of-stake algorithm to secure the network. In addition to the main block chain, this system divides time into epochs and slots. In the mainnet, there are 21,600 slots each lasting 20 seconds which makes an epoch 5 days. In the incentivised testnet, slots are only 2 seconds long and there are 43,200 of them making up an epoch of 24 hours.

At the start of each slot, one or more slot leaders are randomly elected and it is their right to create the next block in the blockchain if one is needed at the time of that slot, and receive a reward for doing so. The first one to create block for the slot and publish it to the network will receive the reward, if none are able to create the block, it will be created during a subsequent slot. In the testnet there are roughly 3000 blocks created during each slot. During each epoch, random numbers are written to the blockchain by the slot leaders using Publicly Verifiable Secret Sharing (Specifically Schoenmakers's variation of the original Stadler PVSS from 1996) to avoid people gaming their numbers. Those numbers provide a mechanism to randomly select future slot leaders at the start of each slot in a way that can be determined independently by any node, but also cannot be known before the end of end of the last epoch. In essence, this mechanism signifies the symbology behind the Ouroboros name: a snake eating its own tail.

In Ouroborus classic, this leader election schedule was know publicly (i.e. it could be calculated by anyone at the start of an epoch), and there was exactly one leader for every slot. But this gives rise to the possibility of the leaders being attacked in order to prevent them creating their blocks. In the Praos version, the mechanism is improved by using a Verifiable Random Function (VRFs were introduced by Micali, Rabin, and Vadhan in 1999) is used so that each node can determine for themselves what their own leader schedule is (i.e. what slot they are the leader for in the current epoch), but nobody else can know this information. A VRF is a way of executing a function using your private key so that you can also provide a proof that your output did indeed result from execution of that exact function with the specified inputs, and then anyone can verify your proof using your public key. In this way when a node creates a new block, other nodes will only accept it if it's accompanied by a valid proof that the node was indeed a true leader for the slot. Using this system there may be more than one valid leader for a slot, or also there may be no leaders at all.

The Cardano staking system fundamentally works to incentivize two primary activities. The first is making sure that stakeholders are online. The second is participation in the protocol, i.e., block creation. Because there are many people who are either unable to run their own servers with 24/7 uptime or who don't want to create a stake pool, they will be able to delegate their stake to a pool of their choice. Delegation addresses are different from standard ADA addresses.

Unlike Ethereum, or other staking protocols, users funds are not at risk of being "slashed" or destroyed in case they attempt to participate in the protocol in an inappropriate fashion; the design of the system makes that unnecessary. In fact, user's funds are not at risk at all in any way because they never leave a user's wallet and can even be spent at any time without needing to be "locked up" into the staking system.

Staking pools

To stake your ADA coin, you can either set up your own staking pool or delegate your stake to an existing public pool which can be done from within a supporting wallet such as Daedalus or Yoroi. The person who maintains and controls the pool, and sets its parameters is called the pool operator. A pool's chance of winning is proportional to the total amount of ADA the pool holds for staking (every single staked Lovelace, the Cardano version of a Satoshi, is like a single lottery ticket) which is called the controlled stake. This means that everyone's rewards will average out over time to be in proportional to what portion of the total staked coins they have at stake. But the problem is that the smaller the portion of your coins are, the longer it would take to average out - someone with only a millionth of the total stake would be waiting centuries to realise the average and may go decades without even receiving any rewards at all!

This is why it makes sense to delegate your stake to a pool if you have less than say 0.01% of the total stake. The pool has a lot of individual people's stakes delegated to it, and so as a whole it receives regular rewards in proportion to it's total. Then at the end of each epoch, the rewards the pool received are automatically distributed to the delegators by the Cardano protocol.

Rewards

Rewards are distributed among all stake holders every epoch (which is 24hr in the testnet and 5 days in the mainnet). Rewards automatically contribute back to your stake, but your stake is not locked up, so any amount of stake can be spent at any time. In the testnet, approximately 3.8 million ADA are awarded per epoch, and there are usually around 3500 blocks generated which means that each block is worth around 1K ADA or $40 at current prices. My personal results are showing an average of $35/block. Also non-productive pools that don't create their assigned blocks will cause the reward per block to increase throughout the epoch in the testnet.

Tax

Pools can charge a percentage (called margin or tax-ratio) and/or a fixed amount (tax-fixed or pool cost) per epoch. There is also an optional parameter called tax-limit that allows a pool operator to specify an upper limit to the amount they can take each epoch. These costs can be changed by the pool operator any time and will take effect at the start of the next epoch, staking wallets will notify users of changes in their pools costs. Each pool has a chance of being elected as the slot winner for every slot and gaining the right to create the block corresponding to that slot.

Performance

A pool's performance is measured as (n / N) * (S / s) where n is the number of blocks produced by the pool in the current unfolding epoch, N is the number of slots this epoch, S is the total delegated stake this epoch and s is the stake owned by the pool this epoch. It's a measurement that applies purely to the current epoch and represents how well a pool is doing taking into account it's size. It's the proportion out of all possible blocks so far that have been produced by the pool, multiplied by how many of that pool it would take to occupy the total stake. This is the formula used in Daedalus, but it is averaged over a number of epochs according to the code comments.

Delegation

You delegate your stake to a pool with a special type of transaction which supporting wallets will do for you. This transaction will not take effect until the end of the next epoch, and then you will start earning rewards until the epoch after that, and you'll receive your first rewards at the end of that epoch. I created my first delegation transaction to LEAF pool in epoch 3, and then my first reward transaction arrived at the start of epoch 7. During epoch 7 I changed my delegation to BCSH, in epoch 10 I changed to LCP01 and in epoch 11 I changed to our own PUDIM pool. I received rewards continuously throughout all those changes, so it seems there's no downtime resulting from changing delegation.

Desirability

This is the most important metric for choosing a pool and reflects the real rewards you're likely to receive. The wallet orders pools by desirability. Desirability is composed of reliability (mainly up time), pool costs, profit margin, saturation and pledge. See this video for details about how desirability works.

There is a network variable called k which maintains equilibrium between efficiency and decentralization, by limiting the desirable number of pools appearing to ADA holders for delegation selection. K will start at around 100 and will ideally aim to be around 1000. As far as Cardano's framework is concerned, the majority of delegated ADA must go to those owners of pools that make it into the top k pools which are called competitive pools, and will be the only ones displayed in the staking-capable wallets. Those that don't make it into the top k will not be visible and are called dead pools. The stake pools that make the k do not have to go out and ask for ADA they will be saturated naturally, by design.

Quote.pngEven if every user were to run a node that was online all the time, it would be hard to keep all those nodes well enough in sync to avoid forks and still keep a short slot length. Our delegation design is aimed at keeping the number of nodes that produce a significant amount of blocks reasonably small (about 100 or 1000 nodes), so that effective communication between them is feasible.

Saturation

To help prevent any single stake pool from growing too large, there is a mechanism to ensure pools saturate at a certain percentage of the total stake in the network. If any stake pool exceeds this percentage, then the rewards for that stake pool will no longer increase but will be shared among delegators, making the pool less desirable. This is 1/k (if k is 100, then pool rewards are capped at 1%) and is discussed in this incentives paper.

Pledge

The pledge variable makes the separation of operator and owner(s) possible, maximising the number of pool owners within k. It's an elegant solution that enables Cardano to reach its k target of 1,000 public pools while encouraging those with limited Ada to pool their holdings and pledge to a pool operator, thus maximizing the diversification of pool owners while maintaining network efficiency. The Incentivised Testnet has the concept of pledging, whereby stake pool operators delegate their personal stake to their pool and register a pledge address when they register the stake pool with the Cardano Foundation. Pledging is not currently enforced by the network protocol (although it may be in the future) and functions to increase the attractiveness of a pool, meaning that other delegators are more likely to delegate to that pool. The person(s) who pledges to the pool is called the pool owner. Pledging follows the same process as delegation.

The effect that the pledged amount has on a pool's desirability is determined by a network parameter called a0. An a0 value of zero would mean that the pledged amount has no effect on rewards at all, and a high value like 0.5 gives pools with large pledges are big advantage. This is explained on detail in the article Preventing Sybil Attacks.

Private pools

In section 4.6 (Individual Staking) of the Staking Design Specification, it says stakeholders should not be forced to delegate their stake to a pool. Instead, they should have the option of running their own node, using their own stake. Technically, such stakeholders will create a private pool, which is just a stake pool with margin m = 1 (i.e. owners will take 100% of the profit), and without providing metadata. Such pools will pay all rewards to the pool operator (which is not a special rule, but just the effect of having a margin of 1), and they will not be shown in the stake pool directory in Daedalus (although even if they were, they would always be listed at the very bottom, since they would not promise any rewards to their members).

Running a staking pool on the incentivised testnet

This section was getting rather large and has been moved to its own article at Set up a Cardano staking pool.

Staking resources

Cardano address types

Todo... There are four types of addresses in Cardano:

Base addresses:

Pointer addresses:

Reward addresses:

Enterprise addresses:

Wallets supporting ADA

Daedalus issues

On the Incentivised Testnet version of Daedalus, some problems sometimes occur such as not being able to connect for a very long time, the stake pools disappearing and staked balance mysteriously moving back to the old balance wallet with no transactions having occurred. The latter two issues can be resolved by stopping the wallet, nuking all data, restarting it and restoring your rewards wallet. On Linux the chain and wallet data is stored in ~/.local/share/Daedalus, in mainnet or itn_rewards_v1.

Token distribution

In a PoS protocol, staking coins is necessary to participate in the consensus mechanism. Since the existence of coins is required to execute the protocol, a certain initial coin distribution was required. At the time (2015), the concept of Initial Coin Offerings (ICO’s) was becoming popular, but there were concerns that holding an ICO by minting virtual assets and selling them to the general public might fall under security regulations. IOHK, Emurgo and the Cardano Foundation therefore chose to sell 25,927,070,538 ADA ‘vouchers’ in a private sale in Japan and a few other Asian countries that were redeemable for ADA after the main-net was launched in September 2017.

Particularly Bitcoin purists, that believe only Bitcoin had a fair launch, tend to react adversely to the idea of a new form of money being created and sold. At Bitcoins’ launch, Satoshi Nakamoto first shared the code to run a Bitcoin node publicly, allowing anyone to participate in network consensus from the start. While Nakamoto clearly had an advantage since just a few people knew of Bitcoin’s existence, the fact that anyone could have participated and that it was all but a given that Bitcoin would be a success arguably made it fair. However, the recent launch of the Grin privacy coin illustrates that a similar ‘fair launch’ is perhaps no longer possible, as ~$100 million in venture capital money was rumoured to be invested in mining Grin. In essence, the choice for Cardano’s private sale was a trade-off between geographical distribution and regulatory certainty, where the latter was chosen as a priority.

In total, 25,927,070,538 ADA were sold for $63 million (= $0.0024 per ADA) to over 10.000 people during voucher sale that was held between September 2015 and January 2017. According to the distribution audit that was held on behalf of the Cardano Foundation, 94.45% of the ADA was sold to Japanese citizens, 2.56% to Koreans, 2.39% to Chinese and the remaining 0.61% to citizens of 5 other Asian countries.

The other 5,185,414,108 ADA (20% of the amount of ADA sold during the voucher sale and 16.7% of ADA’s 31,112,484,646 ADA total supply), were distributed over IOHK, Emurgo and the Cardano Foundation. IOHK has publicly shared its ADA address and that one third of the 2,463,071,701 ADA they received (of which ~97.5% is still there) is available immediately, one third is made available on June 1st, 2018 and the final third on June 1st, 2019. While the Cardano Foundation and Emurgo haven’t publicly shared their ADA address, it is believed that Emurgo originally held 2,074,165,643 ADA in this address and the Cardano Foundation originally held 648,176,763 ADA in this address, as the sum of these amounts adds up exactly to the original total. Finally, the remaining 13,887,515,354 ADA of the 45 billion ADA that will ever exist (maximum supply) will be minted as block rewards.

As of December 2019, there are four ADA billionaires, thirteen addresses hold over 100M ADA, 157 addresses hold over 10M, and there are about 3000 ADA millionaires. There are about 290K addresses in all with just over a third holding under 1K ADA, just over a third holding 1-10K and about 20% holding 10-100K, 7.5% with 100K-1M and 1% are the millionaires.

Official sites

See also