User:AiliA SA/sandbox

Takamaka Blockchain

Takamaka is a project of AiliA SA; it is a blockchain 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 a 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;
 * calculate 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.

hese two types of tokens are renamed red and green.

 Red token
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.

 Green token
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 incentive the expansion of the network expansion (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;
 * check 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;
 * ubsequent 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 other blockchains it’s virtually impossible to have an accurate estimation of the effort required to include a given transaction in a block due to several issues that need to be addressed. 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.

 Glue protocol
Decide asynchronously the execution results of a smart contract in the blockchain using the following rules:
 * 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.

 Upload contract

 * The serialized jar of the contract is included in a block if the Contract Sender have 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 point to CI in converted in the last valid CC,a wallet that call 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: 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.
 * 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.

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