(image)

Programming Hotmoka
A tutorial on Hotmoka and smart contracts in Takamaka

Chapter 7 Hotmoka blockchains

The experiments of the previous chapters have been performed on a Hotmoka node already existing online, part of a blockchain installed by somebody else. Namely, we have used the Hotmoka node at ws://panarea.hotmoka.io:8001, that is part of a blockchain based on a proof of space consensus algorithm [28], and the Hotmoka node at ws://panarea.hotmoka.io:8002, that is part of another blockchain, this time based on a proof of stake consensus algorithm [12]. Both are able to execute Hotmoka transactions, store smart contracts and interact with them, but they are different for the way they create new blocks and synchronize their state among all the nodes of the blockchain they belong to. Namely, in the case of proof of space, each node of the blockchain increases the likelihood of winning the right to create a new block if it allocates a larger data structure on disk (typically, on SSD) than the other nodes of the same blockchain. Instead, in the case of proof of stake, only a restricted, modifiable set of nodes (called validators) has the right to create new blocks, in a round-robin way, and the prize earned for the creation of a new block is proportional to the shares of validation power owned by each validator. Other nodes can just verify the transactions. We do not enter into the (sometime religious) discussion about which consensus algorithm is the best. Probably none of them, as each of them (and others, that we do not even speak about here) has its advantages and drawbacks. What is important to highlight is that Hotmoka is not bound to a specific consensus algorithm, but is rather a software layer for the execution of smart contract transactions, that can be plugged on top of different consensus engines, giving rise to distinct blockchains with distinct consensus algorithms.

This chapter shows how to build new blockchains or connect to existing blockchains, both for proof of space and for proof of stake consensus. It will present this by using docker, so that you do not need to install anything on your machine beyond docker itself. Namely, there exist preconfigured docker images that allow one to run Hotmoka nodes of a blockchain without preliminary, complex configuration. They are meant to simplify the life of users who just want to install nodes with a standard procedure that should cover most typical use cases. For less standard use cases, such docker images can be partially configured or Hotmoka nodes can be installed with Java code, as it will be shown later in Ch. 8.

7.1 Tokenomics

The way coins are minted and transaction fees are computed is the same in all implementations of Hotmoka, independently from the underlying consensus algorithm. In particular, there is an amount of coins \( \mathit {minted}_h \) that gets minted for the creation of the block \( b_h \) at height \( h \). This minted coins, plus the \( \mathit {fee}_h \) resulting from the execution of the transaction requests inside \( b_h \), go to the creators of \( b_h \). Who are these creators depends from the consensus engine. For instance, for proof of space based on Mokamint, the creators are a peer and a miner and \( \mathit {minted}_h+\mathit {fee}_h \) gets split, equally, between the two. For proof of stake based on Tendermint, instead, there is a single validator peer that creates \( b_h \) and gets all \( \mathit {minted}_h+\mathit {fee}_h \) coins. Note that \( \mathit {minted}_h \) are minted coins, while \( \mathit {fee}_h \) are coins paid by who required to execute the transactions: they are not minted.

The computation of \( \mathit {minted}_h \) follows a decreasing hyperbolic curve. Namely, there are consensus parameters, decided at the time of blockchain launch, that determine \( \mathit {minted}_h \):

  • • \( \mathit {initial\_supply} \) is the amount of coins that already exist at launch time. Initially, they are all inside an account called gamete, typically controlled by the person who launched the blockchain; this amount can well be zero;

  • • \( H \) is the height at final supply, that is, the block height when all coins will have been minted: coins will only be minted for blocks \( b_h \) at height \( 0\le h<H \): subsequent blocks will only distribute \( \mathit {fee}_h \);

  • • \( \mathit {final\_supply} \) is the amount of coins that will exist, in total, at height \( H \); it must be \( \mathit {final\_supply}\ge \emph {initial\_supply} \).

For instance, for the main network maresia of Hotmoka (Fig. 1.1), the above parameters are \( \mathit {initial\_supply}=0 \), \( \mathit {final\_supply}=10^{30} \) and \( H=42048000 \), as it is possible to verify with the command moka nodes manifest show --uri ws://lipari.hotmoka.io:8001.

The hyperbolic curve that dictates how many coins get minted at block \( 0\le h<H \) is the following:

\[ \mathit {minted}_h=\frac {6(\mathit {final\_supply}-\mathit {initial\_supply})(h^2-2hH+H^2)}{(H+1)(2H+1)H}. \]

For instance, Fig. 7.1 reports how many coins maresia will mint at different block heights.

.
\( h \) when (days after launch) \( \mathit {minted}_h \)
0 \( 0 \) 71347029418270905255751
4320 \( 1 \) 71332369822860396367870
129600 \( 30 \) 70907896753038047445079
1576800 \( 365 \) 66096333972020030822086
3153600 \( 2\times 365 \) 61046302046008043309452
4730400 \( 3\times 365 \) 56196933640234942717850
6307200 \( 4\times 365 \) 51548228754700729047280
7884000 \( 5\times 365 \) 47100187389405402297742
9460800 \( 6\times 365 \) 42852809544348962469235
11037600 \( 7\times 365 \) 38806095219531409561761
40996800 \( 26\times 365 \) 44591893386419315784
\( \ge 42048000 \) \( \ge (26\times 365 + 244) \) 0
Figure 7.1: The amount of coins \( \mathit {minted}_h \) that the maresia main network of Hotmoka will mint at different block heights \( h \). For the days after launch when a block will be minted, consider that maresia is programmed to create a block every \( 20 \) seconds, on average.