We are proud to present the details of the parameters that will be used for V7.
Our old DefyX algorithm contained a modified version of RandomX + yescrypt + KangarooTwelve. In Panthera, we’ve substituted yescrypt with yespower, so our new algorithm Panthera becomes RandomX + yespower + KangarooTwelve.
Since yespower is meant to be a PoW and not a password hashing algorithm, it will provide our network with the right needs.
We named our new algorithm after the genus of cheetah because it’s both fast and efficient.
In our tests, Panthera has proven to hold a more stable hashrate across devices (including mobile devices) and also more resistance against specialized hardware and even GPUs.
We have also made sure that the new PoW and difficulty algorithms are effective and secure by testing them extensively on private networks.
Inclusion of Diardi
Before going any further, let us introduce you to the delayed-proof-of-work (dPoW) concept.
Essentially with dPoW, you checkpoint the daemons blocks onto another stronger chain (like Bitcoin).
However, we didn’t want to “bloat” Bitcoin because we all in the team love Bitcoin and thought that dPoW was just too pollutive towards other networks. We then agreed that the idea of locking a lock with another lock is not the smartest idea, because if one lock becomes weaker than the other, it can create new vulnerabilities.
Deriving from the ideas of dPoW we figured we could adapt it to our needs. So we got to work on our own version of dPoW which doesn’t use any other blockchain. Instead, our variant (Diardi) will use the same database as that of our own blockchain. This will be made possible by a system utilizing the Lightning Memory-Mapped Database Manager (LMDB).
This database is incredibly fast and also simple at its core, and with this auxiliary database, we will store checkpoints for all other nodes in the network. These nodes will also ship with a version of IPFS and Webtorrent to facilitate future development to the network, including the use of IPFS which will allow dPoW nodes to host a list of node-lists — as our whitepaper mentioned.
How will we trust these Diardi nodes?
Every hard fork from the beginning the community will democratically elect 16 members from the community to run and maintain these nodes. Node operators are not required to own a single coin of Scala to run these nodes but should have expertise in the management of servers, and also a basic knowledge of blockchain technology.
In addition, because these nodes are able to be publically monitored, if they try to “cheat” in any way, their action is open to public acknowledgment, essentially undermining the validity of their own well-being. And for the services provided by the maintainers of these light dPoW nodes, they will receive 90 blocks worth of rewards daily.
Over the years, we have had a lot of users complain about how slow the block times have been. Even if it was not the most urgent issue, we thought why not address it as well since we are making a fresh start.
Since we will now be using Panthera, which is a fast and resilient proof-of-work, we decided to drop the blocktime to 2 minutes and include a modified version of the difficulty adjustment algorithm.
We decided to move away from a capped supply to an infinite supply with a tail emission similar to Monero. The rewards will no longer have erosion but will drop by a certain percentage at certain block heights.
Starting from block 0 to block 1,000,000, it will be 5,000 coins, including the share that will go to Diardi maintainers (25% of the block reward will go to 16 Diardi maintainers). After the first 1M blocks have been mined, the next reward will be determined by how the network conditions are instead of having an eroding curve.
Tail emission basically means when the total supply runs out, the miners will still be incentivized to make new blocks.
This is a brilliant idea that we’ve adopted from countless other Cryptonote-based coins.
After overcoming problems we had with our short 0.6% premine when we first started (Stellite), V7 will have officially addressed everything that we initially had set out to finish in our whitepaper and more. Unfortunately following this development, we quickly have run out of funds to continue forward.
Luckily in the past, we were able to push on with the help of a handful of very dedicated and brilliant programmers and designers. But sadly it has been hard to keep up with everything, we’re struggling to pay for seemingly simple things like web servers, build servers, DNS charges, etc. This is disregarding the countless hours of work our team has put forward for the development of the project.
We have tried donations and other schemes, but as soon as the first and second months are over, it inevitably dies out with no one to blame. We would also like to hire freelancers to help us bring more products onto the table (like a mobile wallet), but this is currently not possible for us.
With all of this in mind, we have decided to set aside around 3 years’ worth of PoW rewards for the development and progression of the project for the next 5 to 6 years, which is around 3.8B coins.
The majority of these coins will be stored in cold storage with trusted nominees will be selected from the core team. The view keys of associated wallets will be given to the community to assess the movement of the coins.
The coins will be allotted in such a way that incentivizes developers and the community to come up with new and bright ideas and to help implement the ones that we already have, such as a complete ground-up built mobile wallet and new applications that are built upon the Scala blockchain, like a network of storage devices. Any community member will be able to propose an idea and if there is support seen for the said idea they can be allocated funds for working on it with milestones.
It is very important for us to be very transparent with our community, presenting expenditure reports and forecasts on how the funds will be used. We will also put in place mechanisms for the community to verify the integrity of these funds and to challenge financial decisions.
We will prepare an article presenting our future roadmap and how we plan to use the premine.
The issues that are currently causing a ruckus in the chain are partly caused by our current proof-of-work algorithm (DefyX).
We considered the two following options to fix the problem:
- Revert n number of blocks — however, since we don’t know up to which point back we have to revert, this will become an even bigger problem to mitigate.
- A swap — starting with a new network built from scratch, with mitigation measures in place to address the issues.
Although it’s not an easy task with a chain as big as ours (volumetrically speaking), we decided to go with the second option: the swap.
The swap ratio will be 1:1. The swap instructions can be found here.
These are some of the biggest changes coming to Scala’s V7 iteration. We hope you all like what we presented because it was not an easy run, to be honest; it took months of hard work from every team member.
We truly believe this fork will help us get back on track and allow us to keep building the future with you.
Thanks for your support!