Credits Blockchain Strategy 2021
Here we would like to present our strategy for Blockchain development in 2021.
This article explains the current status of the Node, the Smart Contract Executor, and the API Interface, why we think further updates are needed, and what we are planning to improve in 2021.
New Credits Node v2.0
As we all know, the start-up time for a node needs to be reduced, and we are now creating a very cool feature that substantially reduces the time it takes to synchronize a node so that you start earning rewards sooner. To achieve this, we are developing a blockchain “state”, so the node does not have to reload the whole blockchain from scratch.
We are also developing a new user-friendly interface so it’s easier to work with the node from the desktop. The current “console” interface is clunky and needs to be replaced.
As well as the above, we are improving the technical specifications to increase the speed and response times for the node.
Further information regarding the blockchain “state”
To help you better understand what we are doing to reduce the node start-up time, consider the following:
Blockchain “state” = contents of all wallets + state of all smart contracts.
When the node starts up, the stored “state” is loaded, and the missing blocks from the blockchain are then synchronized so that the “state” is updated and subsequently stored for future start-ups.
As you may gather, each block has the capability to change the blockchain “state”; either by a transaction that simply transfers funds from one wallet to another wallet that changes their balances or by the execution of a smart contract method that changes the state of the smart contract. Saving a “state” allows for a faster start-up of the node.
Additional areas that need optimization
One area that needs to be optimized is the use of memory (RAM) and processing power, and we fully realize this needs to be addressed.
Under high workload levels, synchronization consumes about 75% of resources and this is a result of the memory and processor resources not being optimized, as mentioned above.
At these high workload levels, the process of synchronizing transaction packets is impacted and, as a result, the processing of the transactions takes longer, which affects the speed of the blockchain.
Optimizing the use of RAM and processing power will, as such, improve the blockchain speed and power.
Aside from introducing the ability to store the blockchain “state” for a faster node start-up as outlined above, we will also be introducing the ability to store enhanced historical blockchain “states”, or “control states” for other purposes.
Use case examples of these “control states” include expedited node start-up times for new nodes, high-speed downloads of “control states” instead of having to download the whole blockchain, portable transfer of control states via thumb drives, and finally, distributed blockchain disaster recovery when historical “control states” are utilized.
Regarding the blockchain disaster recovery feature mentioned previously, similar checkpoints are used in Microsoft Windows. It saves the system state between updates. If, after some Windows update, the system begins to work incorrectly, then you can roll back to the previous one. With the Credits’ blockchain, we will not roll back; we will just use the previous “control state” for a quick re-launch, should the need arise.
Additionally, we will be updating the user interface, so it offers you the option to load the node as a service or an application, with the ability to change certain settings for optimum node performance.
We will also be creating a mechanism for adaptive synchronization of packets and blocks, which will balance the existing network speed with the computer resources so that optimized data packets are transferred to achieve quicker synchronization times and greater blockchain speed.
Ongoing blockchain optimizations
We continue to search for code fragments and algorithms that can be optimized. So the speed and processing power of the Credits blockchain can be increased.
New Smart Contracts Executor 2.0
Our main programming task regarding the smart contract executor is to optimize the use of random access memory (RAM) so that less memory is used to store the smart contracts.
At the same time, we also want to make sure the normal functionality of the node software and the smart contract executor, and all its utilities work in collaboration with each other as we make these changes.
As a result of the above, we are increasing the productivity and reliability of the smart contract executor by reducing the number of failures of the smart contract executor.
Additional areas that need optimization
As the Credits blockchain evolves, and an increasing number of smart contracts are deployed, more memory will be needed to maintain the state of all the active contracts, to support the high-speed functionality of the blockchain. As more memory is needed, either two things will happen; the computer starts using disk-based memory; which will slow down the blockchain, or the computer will run out of memory; which will cause the node to go offline due to its inability to maintain the smart contract states.
We are aware of the above and are mitigating this.
We also found limitations to the power of the smart contract executor during internal speed/load tests on smart contract transactions, and this will be improved upon in due course.
We will also be simplifying the procedure for creating smart contracts.
To transfer parts of any unused smart contracts and their states to the database. So these inactive smart contracts do not consume memory.
Ongoing smart contract optimizations
The capabilities of the Java language used to create a Credits’ smart contract is vast and, as a direct result, the scope for unauthorized attacks on a smart contract increases. Although there are no known security breaches regarding our smart contracts, we are very aware of the importance to protect users from third-party interference, and this is our main focus regarding smart contracts; to make sure our security for breaches is rock solid regarding smart contracts.
We continue to study the behavior of the smart contract executor under large workloads and identify those places in the code where optimizations to the code can be made.
We are updating the Thrift and REST APIs for software developers by making it extremely easy to create smart contracts. We are also improving the associated documentation that is used in conjunction with these updates.
In addition, we are making available a subset of the API calls more accessible for the end-user, so end users will have more direct access to the API calls that are normally only available to software developers.
Finally, we are optimizing the API code to handle even greater workloads so we can maintain our lead as the fastest “non-sharding” blockchain. Yes, the public speed/load test infrastructure is being prepared. We know this is very frustrating for all parties to have it delayed, but it will be well worth it when these tests verify our position in the crypto space.
Additional areas that need optimization
We are aware of the request for additional API calls for some software developers, but please be patient as we are terribly busy readying the core functionality of the API interfaces. Over time, our Thrift and REST API’s will include even more methods to provide easier access to even more Credits blockchain data.
We also know the documentation for using either the Thrift or REST API is not 100% clear to software developers, and this will be updated. We have contracted a third party software developer with over forty years of software development experience to update the API documentation. He has advised us that his main aim is to make it as easy as possible for software developers to use either the Thrift or REST APIs to interface with our blockchain. He has made it very clear that the fewer rabbit holes a software developer needs to go down, the better.
We have had several requests for larger data sets to be stored on the blockchain. So we have it in our plan to develop additional components allowing us to work with large amounts of data. Such updates will make it possible, for example, to send a batch of transactions at once.
We also will be creating additional functionality to provide blockchain users with the ability to work with these new components.
One area we will also be expanding upon, is to update the existing services so they cater to different users.
As mentioned, the documentation will be improved, but we are also planning to provide more examples by creating online test interfaces for the Thrift and REST API’s that allows the end-user to observe the operation of API functions in real-time.
In summary, our goal is to help as many third-party software developers create blockchain applications on the Credits’ blockchain as possible. We truly believe a high speed, low cost, non-sharding blockchain is the answer to writing the easiest smart contracts in the crypto space. It’s as simple as that.