We plan to release a new version of the Idena node on September 23, 2020. It will be a hard fork. There are the following changes planned:
1. Introducing increased flip rewards
Motivation: Encouraging people to create AI-hard flips.
This change requires detection of AI-hard flips during the validation session. In order to qualify a flip as AI-hard, 1/3 of the committee votes are required. Once the flip is detected as AI-hard it will be granted x2, x4 or x8 times higher reward depending on the flip security score.
We plan to release the Idena app version that will automatically identify secure flips and calculate the security score. We’ll gradually extend the list of criteria for AI-hard flips with further Idena app updates.
2. Flip reporting system improvement
Motivation: Incentivizing people to report flips more carefully.
1. The number of flips that can be reported will be limited to 1/3. So people will be motivated to pick which flip to report first relying on objective criteria (e.g. both keywords relevance).
2. Every successful report of a flip will be rewarded: The reward for the reported flip which is not paid to the flip creator will be distributed between the committee members who reported the flip.
3. Flip lottery improvement
Motivation: Improving flip lottery performance.
Ignoring invitation relationships between addresses during flip distribution.
4. Last 10 epochs results to calculate the total score
Motivation: Encouraging aged identities that can not improve their total score to keep the identity rather than to terminate it and start a new one.
1. Only the last 10 epochs will be counted to calculate the identity’s Total score.
2. Complete migration to the new system for the existing identities will take the next 10 epochs. The last known total score will be counted with gradually decreasing weight during the next 10 consequent epochs (Wi=0.9, 0.8 … 0) while the short session results will be added as follows:
Total score = (P * Wi + Sum(Pi)) / ( roundToInt(F * Wi) + Sum(Fi) )
Where
P/F = Last known total score before the fork (P — total points, F — total flips solved)
Wi = (0.9, 0.8, 0.7 … 0) for the given epoch number i
Pi — earned points for the shot session starting from the hard fork epoch till the i-th epoch
Fi — total flips solved starting from the hard fork epoch till the i-th epoch
5. Invitations distribution improvement
Motivation: Distributing invitations to a wider range of identities with the Human status having a lower score.
The total number of invitations will not be changed: 50% of the network size plus foundation invitations. Invitations will be distributed in two steps:
1. Identities with the Human status will get one invitation starting with the highest Total score.
2. If there are non-distributed invitations left, identities with the Human or Verified status will get one invitation starting from the highest total score.
As a result, Humans with the highest score will have a chance to get 2 invitations. Humans with the lower total score will get a chance to get at least one invitation.
6. Restricting the stake withdrawal address
Motivation: Preventing stake withdrawals directly to exchange addresses while terminating an identity (exchanges can not properly calculate the amount for such transactions).
When an identity is terminated the stake will only be withdrawn to the identity wallet address.
7. Gas model for transaction fees
Motivation: Supporting dynamic transactions fee calculation when calling smart contract methods
Transactions fee calculation will be based on the gas price. The gas price is to be calculated automatically by the protocol based on the following rule (which is currently used for the fee per byte rate):
The gas price goes up or down based on how full the previous block was, targeting an average block utilization of 50%. When the previous block is more than 50% full, the gas price goes up proportionally. When it is below 50%, fees go down. A user can specify the maximum fee limit for the transaction.
Resulting transaction fees in iDNA for existing transactions will be kept at the same level.
8. Introducing predefined smart contracts
Motivation: As a fully functional smart contract layer takes significant development time, we are to release a set of predefined smart contract primitives. These smart contracts can be combined as building blocks to achieve a complex money flow driven by oracles’ decisions. If A happens then send coins to address B otherwise then if C happens then send coins to address D otherwise make a refund to all initial contributors. A and C are some facts that are certified by randomly selected Idena participants.
These primitives can be used for community-driven funding, prediction markets, dispute resolutions, paid votings, paid polls, games and etc.
The following list of predefined smart contracts will be available for anyone to use:
- TimeLock — Lock coins on the smart contract address until a specified block number. Once the block number is mined the coins can be transferred to the specified address.
- Multisig M-of-N — a multisignature wallet address with specified M and N. In order to send coins from the multisig M specific participants out of N have to provide their signatures.
- OracleVoting — Oracle voting contract. The smart contract can control coins locked by EvidenceLock or RefundableEvidenceLock smart contracts.
- EvidenceLock — a non-refundable smart contract that locks coins until a decision is made by oracles. If the voting result matches the expected value then coins are transferred to the address A otherwise to the address B. Both addresses have to be specified beforehand.
- RefundableEvidenceLock — a refundable smart contract address that locks coins until a decision is made by oracles. It works similarly to the EvidenceLock, however it can provide a refund if either A address or B address is not specified. The refund is provided proportionally to the initial deposit made by an address.
In order to use these smart contracts, the Idena app development is to be finished (ETA end of Q4 2020). Until that these smart contracts won’t be available: An additional hard fork update is planned to enable these contracts.
We are to consider running a hackathon for developing apps based on these predefined smart contracts.
9. Peering improvement
Motivation: Fixing the issue that led to the incident.
Non-blocking messaging to peers.
