Takamaka blockchain

---

Takamaka

File:Takamaka blockchain blue color tm.svg Takamaka blockchain blue color tm Takamaka logo
Developer(s)	AiliA SA
Initial release	24 March 2020 (2020-03-24)
Stable release	0.12g
Development status	Active
Written in	Java
Operating system	Cross-platform
Available in	en
Website	https://takamaka.io

Takamaka Blockchain

Takamaka is a project of AiliA SA.; it is a blockchain [1] using a Proof-of-Stake consensus algorithm.

Consensus Protocol

The idea behind this time-based proof is to design a PoS that maintains the positive aspects of PoS itself, providing a solution to the problems existing today in an open network (distribution), in PoS (centralization and concentration) and PoW (energy cost) by focusing on the use of resources to make efficiency and maintain the network rather than using them to solve extremely complex mathematical problems.

A series of issues, listed hereafter, have been solved in this perspective.

Open and decentralized network problem

If an interactive algorithm required the participation of some nodes that, due to the unreliability of the Internet, are not reachable, the assembly of each block would be affected.

If, on the contrary, each node was able to decide autonomously how to extend the chain based only on current knowledge, any malfunctioning on the network would affect solely the nodes concerned instead of the entire network.

VRF is an algorithm that allows to calculate autonomously, in a deterministic way, the slot distribution between the nodes of a network, for a given epoch, without needing an active connection and communication between them. Each node gets assigned a number of slots corresponding with its share of stake bet for a given epoch.

The VRF, taken a list of addresses enabled for the mining and relative stake associated:

• determines the total stake bet on all nodes;
• creates an array of nodes with the bets associated with each node;
• creates an array of StakeValue-wide intervals sorted by address;
• calculates the slot distribution of each node
• Assigns a number of slots corresponding to the share of stake on the node
• Verifies the uniformity of the distribution;

The distribution is calculated at the beginning of each epoch and is updated every time the holders modify their stakes on the nodes.

A synchronization function will allow the node left offline, as soon as it is able, to request the missing blocks and be able to reach the same result of distribution.

Control transfer system problem

Existing PoS are based on single-chain tokens for job quantification and control management. One disadvantage is that the only way to acquire coins is from someone who already has them. This can lead to issues with the concentration. In this scenario, if a significant amount of tokens were generated in the initial stages, decentralization would be preserved but, on the other hand, there would be a gradual loss of control.

This involves:

• difficulties in obtaining the tokens needed to pay for services on the network itself;
• the centralization of network control in the hands of those who initially created the chain, nullifying the decentralized nature of the network itself;
• with a PoS consensus mechanism, a project that involves a large portion of chain’s founders makes the project vulnerable to a risk of veto.

The solution involves the introduction of an additional enabling token. In this way, the subject who has initialized the network can continue to operate within it even if he decides to transfer the whole control of the network.

These two types of tokens are renamed red and green.

Red token (TKR)

It is a non-primary token, it has no controllability value, it is generated only once in the initialization phase, in block Zero and can be used to pay transaction fees.

The value of this token is determined by the guarantee that AiliA gives on its convertibility in fiat currency.

Green token (TKG)

It is the primary token, is generated by nodes as a result of mining, can be used to pay transaction fees, can be used to bet on the node to turn it into a mining node, it is used for calculating the weight of the chain and it is used in the calculation of the PoS.

Stake based network balance

PoS has been seen as a more ecological way to come to consensus on blockchains since it doesn’t rely on expensive hardware using vast amounts of electricity to compute mathematical puzzles. The economy of scale leads to the concentration of mining resources to increase efficiency, but in a distributed network this is a problem.

To avoid the problem of having too much stake concentrated on only a few nodes, a solution has been devised to both incentivize the expansion of the network (introducing an upper limit to the amount of stake allowed on the node before incurring in penalties) and make it convenient for the miners to do so (distributing the excess stake among as many nodes as possible to maximize rewards), thus penalizing the excessive concentration of participation on a node looking to reap the maximum possible rewards.

The solution allows a type of relationship [0-n] between a main node and overflow nodes, where:

• a main node can never be an overflow node;
• an overflow node cannot be shared between several main nodes and must be full mining type;
• bets on overflow nodes are transferred to the main nodes.

The algorithm consists of the following phases:

• registering a miner overflow node and linking to a main node;
• checking the stake distribution on main node and its overflow nodes;
• allocation of any stakes incorrectly present on the overflow node to the associated main node;
• subsequent iterations to distribute stakes from main node to overflow nodes until the amounts of bets on main node is greater than a prefixed penalty level:
• a first iteration to assign the minimum amount of stakes to each overflow node equal to the minimum threshold to be activated and considered as a miner;
• a second iteration to allocate the remaining stakes between the overflow nodes in order to maximize these nodes in full stakes;
• any remaining stakes can no longer be redistributed on overflow nodes because they are already in full stakes. They will therefore remain on main node incurring the penalties provided for in case of exceeding the penalty level.
• computing of fees and rewards (green/red) over the limit considering possible penalties

Computational effort calculation

In most blockchains, calculating a priori transaction execution costs can be complex. This is because the mechanisms for determining it are based on parameters such as the workload of the network nodes and the cost that a user is willing to pay to have their own transaction included. These parameters vary dynamically over time. This makes accurate, a priori, estimation of the costs of executing a transaction almost impossible. This is especially true when referring to smart contracts that also require the use of CPU and RAM, which must be taken into account

Three main factors have been determined to calculate transaction costs as accurately as possible:

• data storage;
• working memory;
• CPU time.

These factors have been assigned a weight, expressed as a multiplier. The higher the multiplier, the more expensive is the use of this resource and consequently the greater will be the cost associated with its use.

This made it possible to express through a formula the calculation of implementation costs and successively converted in tokens.

Field	Unit	Scale factor	Network size	Data retention period	Resulting cost in TK*
Storage	Length	FEE.STORAGE	TARGET_NUMBER_OF_NODES	YEARS_FOR_RETAIN	Length * (4*10^5)
Work Memory	Size	FEE.WORKING_MEMORY	TARGET_NUMBER_OF_NODES	NO_RETAIN	Size * (4*10^3)
Cpu	Tick	FEE.CPU_FEE	TARGET_NUMBER_OF_NODES	NO_RETAIN	Tick * (4*10^2)
Total resulting cost in TK*	Length * (4*10^5) + Size * (4*10^3) + Tick * (4*10^2)

Glue protocol

The "glue protocol" is the component of the Takamaka blockchain that allows the separation of smart contract execution from the cadence of block generation.

The rules that allow this kind of separation are summarized, in a very abstract way, in the following paragraphs:

• only allows one vote for each mining node;
• nodes that do not have any slots assigned in the current epoch cannot vote;
• weight of each vote is calculated in relation to the participation quota assigned to the mine;
• votes that have not reached finality (finality is obtained when the majority vote can’t be overruled) in the current epoch are recalculated to every change of epoch with the bets updated and the votes coming from nodes no more miner are discarded.

Takamaka smart contract integration protocol

Upload contract

• The serialized jar of the contract is included in a block if the Contract Sender has sufficient funds for the installation of the contract and has enough funds to cover the transaction fee;
• if the jar compiles in the environment and the unique reference in the blockchain (DP) to the jar is valid, then a contract instance (CI) function can be called.
• CI represents a pointer to the first instance of a contract and is generated by calling its constructor.
• A constructor is a block instructions that initializes the newly created object, in our case a contract.

Call function

Starting from the reference generated by UPLOAD_CONTRACT transaction or reference to other CALL_FUNCTION result, reference that points to CI is converted in the last valid CC, a wallet that calls a method of a contract uploaded in the blockchain, that gets executed. This reference in takamaka is transformed in a 𝚫-group as the state of the contract evolves.

• A 𝚫-group is a transaction that guarantees the orderly and sequential execution of an arbitrary number of TakaMaka transactions that are interdependent between them;
• inside a block, 𝚫-groups have no preferential order of execution whereas inside a 𝚫-group there is an arbitrary order decided independently by each client;
• every event gets launched by a transaction and generates an arbitrary complex flow of calls and TakaMaka assigns every call a “read” or “write” towards a specific CC;
• it is important to distinguish a “write” event that causes the generation of a new delta and the update of the reference to the CC involved with the call.

Submit result and vote

The first node that terminates the execution submits the result, which is essentially the 𝚫-group between the previous state of the blockchain and the new one after the execution of the contract and the validity of the execution. After the first node has presented its results, the others, who present their results, can:

• present results identical to the first one so confirming the result as a vote;
• present a different result that could be confirmed by the other nodes that have not yet voted.

The first result that obtains a majority of the votes is declared to be the correct result and reaches the final character in the group 𝚫. All voting transaction that come after this are discarded.

Confirmation

If the vote has reached the finality the single takamaka delta is included in chain, otherwise the whole 𝚫-group is rejected.

References

This article "Takamaka blockchain" is from Wikipedia. The list of its authors can be seen in its historical and/or the page Edithistory:Takamaka blockchain. Articles copied from Draft Namespace on Wikipedia could be seen on the Draft Namespace of Wikipedia and not main one.

---