We are glad to announce a major blockchain update, MainNet 2020!

We are glad to announce a major blockchain update, MainNet 2020!

Credits MainNet was successfully launched in spring 2019 and is boasting a stable operation for a rather long time now.

Up to now a lot of work has been done on the blockchain, project services, community, and integrations with third-party services and systems. 

And now, after more than a year-long operation of MainNet, our development team identified several points requiring optimization and improvements, and also taken into account community feedback.

What has been done in MainNet 2020 update?

Node & Blockchain Changes

Node & blockchain saw some of the most important changes.

Due to these, our network has become more secure and stable.

 

1. Security update:

1.1 Added fork protection

A restriction has been implemented to prevent the consensus from forking in 2 equal parts. Now the number of Trusted Nodes can only be an odd number.

1.2 Added protection from a fake notification about changing round

Additional checks upon receiving tables of the round have been added. If the node when checking the table of the round identifies that a table with this number could not be generated, it rejects such a table.

1.3. Added verification of signatures on the node side.
Verification of signatures on the node sides carried out in several stages:
- verification of the transaction signature when receiving a node through the node's API is carried out during a complex verification of the transaction. After that, the transaction is placed in a packet and sent to all nodes on the network.
- each node that received the packet checks the signature of the one that created the packet. Anonymous packages are ignored. Verification of the package signature is followed by transaction verification. If invalid transactions are found in a batch, the node that created such a batch is marked by everyone as unreliable and, depending on the share of invalid transactions in the batch, is placed on the blacklist or on the list of candidates for the blacklist;
- the next verification of the transaction signature is performed by trusted nodes in consensus when assembling the block;
- finally, the last signature verification occurs immediately before the block is written to the blockchain by all nodes, like trusted ones.
currently, each node verifies the transactions from which it collects blocks. This mechanism makes it possible to guarantee most of the nodes of the blockchain against writing an invalid transaction.

1.4 Added protection against fake extraction

2. Network module update:

2.1 Optimization of the packets fragmentation increased the assembly reliability and speed on the receiving node

The network algorithm was adjusted to send each message in the form of network packets fragments. Hashing these packets increases the speed of their identification. This makes it possible to process more packets in less time which also increases reliability.

2.2 Version check is implemented on the network layer to prevent the nodes with the legacy version from connecting to the blockchain

Now the network can prevent the connection from the nodes with the legacy version.

3. API Update: 

3.1 FilteredTransactionsGet retrieves a list of transactions by a given key list starting from a defined number.

This change can significantly improve the functionality of the services and applications that are already developed (e.g. Credits Wallet) and being developed.

3.2 GetActualFee outputs a fee to be paid according to the transaction size 

This function is necessary for some services to calculate a final fee, and will also make the services more convenient and clear for the end-users.

3.3 Upon successful transaction, a node outputs transaction ID, paid fee, and an additional fee (ExtraFee) for token transfer

3.4 Adjusted information returned by the node for executed smart contract transaction Now the node returns complete information.

4. Updated Thrift interface to fit new functionality (see p.3)

Credits provide an alternative for those not willing to use REST API. This update will allow you to get the full functionality of the REST by connecting directly to the node.

5. Fixed bugs:

5.1 Changed typing of the variable which serves as an iterator in API Fixed an error that under certain circumstances can cause undefined behavior and lead to node shutdown.

5.2 Changed settings of the referring to the database, lmdb, where a node stored indexed block hashes Fixed an error that in an unlikely event could lead to the changes of some database records causing a corruption of the database.

5.3 Adjusted validator check of the fields for the transaction to cancel delegation Fixed an error that could make it impossible to cancel delegation.

5.4 Adjusted processing for the wallet creation time

In addition, at the beginning of the year, the credits team added a new functionality

1. Validators
Validators - currently each node acts as a validator. This happens either in the status of a trusted node, when the node verifies transactions before forming the block, or when receiving information for assembling the block. Block assembly information is checked by each node: all transactions that will be placed in the block are checked for compatibility with the current state of the blockchain. Then, depending on the result, this block is written to the blockchain.
2. Delegation 
Delegation - the current state of delegation: any user who has accumulations has the right to delegate them, that is, transfer them to the selected node in order for the node to participate in the consensus. The more funds a node collects, the more likely it will participate in the consensus and be able to earn more commission. The minimum amount for delegation is 5CS. At any time, the delegate can be revoked either the entire amount or in parts, but not less than 5 CS. You can also delegate until a certain time. In this case, the entire amount of the delegation will be returned to the sponsor as soon as the time of the current blockchain block is longer than the end of the delegation.

Changes in REST API:

1. Models of the source code were fully restructured

2.New features:

2.1    GetFilteredTransactionList is a function that allows you to retrieve a package with token transactions/transfers, sent or received by the accounts from the list in the request. Request can specify a transaction number, from which the search should start to get a more actual list.

2.2    GetBlocks() returns a block set in requested range with a set of output parameters

2.3    GetNodeInfo returns information about the node with the given IP and PORT

2.4 GetMethods(ContractKey) returns methods of the ContractKey

2.5 Validate(contractCode) returns smart-contract structure with byte-codes

3. Changes made to the existing functions:

3.1 ExecuteTransaction() function beside transaction ID now also returns:

    - Fee paid for the transactions with CS or tokens

    - Result of a Smart contract execution (if text output was requested)

3.2 PackTransaction() function now allows you to send a transaction even if the fee is not specified. I.e. if a sender has only 1 CS, he can specify "Amount = 1" without specifying the fee. As a result, the user will receive the amount "1 CS minus actual fee", sender's balance will become empty.

3.3 GetBalance(PublicKey) returns balance in CS of the given account, besides the token balances are returned and the delegations data

3.4 GetTransactionsByWallet returns transactions from given PublicKey account

3.5 GetTransactionInfo(TransactionID) returns the information of the transactions (including smart contract data)

3.6 Contract/GetFromTransaction returns contract code from the given transaction

4. Bug fixes:

4.1 GetBlocks function in the blockchain module notifies when the connection is off, now it can't be confused with the set of empty blocks

4.2 Improved validity check for users' request to REST with returning appropriate error codes

5. Introduced additional exceptions interceptors

Web-Wallet Changes:

1. Web-wallet architecture transferred to the use of REST for scalability purposes that also simplified the access to the Credits services for users.

2. Introduces an interface for CS delegation

Now users can delegate their coins to any public addresses that allow them to support other nodes or launch their own with more security.

3. Added an interface to deploy and execute smart contracts

This feature provides easier access to smart contracts functionality. It is no longer necessary to launch your own node and work via desktop wallet.

Next steps for Credits?

Credits always aspired to make blockchain and cryptocurrencies accessible and clear for people. We are always developing infrastructure around the project, encouraging third-party developers and developing our own services that will help us to grow into a large ecosystem.

This is the reason we launched two separate wallets to meet your every need.

1. Credits Wallet to work with cryptocurrencies and fiat. This is the one for all those who want a simple service to store and buy cryptocurrencies. Soon, Credits team plans to integrate digital cards into the application which will combine the traditional and cryptocurrency markets.

2. CS Crypto is a decentralized wallet for those who value privacy and anonymity. 

In Credits, we think simple access and an ecosystem developed around the blockchain is the vital element that drives the whole project forward.

For this very reason, our priority is not only to support and develop the blockchain, but also to develop and launch of the services aimed at the adoption of the blockchain and cryptocurrencies!

We hope you will enjoy this journey with us!