ShareLedger Hard Fork 2022

ShareLedger, the underlying blockchain to the ecosystem of ShareRing, will be undergoing a hard fork on 28 March 2022. This ‘update’ will take ShareLedger to Cosmos SDK v0.44.0 and Tendermint v0.34.14, which will further enhance, and release a series of new features to the blockchain. This provides ShareRing with stronger foundations in anticipation of new products to be developed in the future.

So, what new features does this hard fork offer? 

Intercommunication protocols and modules

An introduction of new protocol buffers will bring about significant improvements to our blockchain state and wire communication within the Cosmos SDK. Additionally, we have implemented the Inter Blockchain Communication (IBC) protocol as a module, which facilitates transport across sovereign blockchains, meaning that ShareLedger is able to communicate with other heterogeneous blockchains.

Validator nodes – Single application binary

Validators and nodes now only need to download a single application binary to operate, whereas previously, separate binaries were required. This improves the overall efficiency of the process required to run a masternode.

Simplified fee management for SDK users

We’ve introduced two new modules that simplify the overall fee management process and grant more control to those who use our SDK. Let’s look at the example of ‘document issuance.’ With this new module, the issuer can pay for gas fees using a pool of funds within predefined limits. Furthermore, issuers are able to grant arbitrary privileges between their own accounts, so that grantee accounts can execute certain actions. For example, messages on behalf of the granter.

Chain upgrade process efficiency

Chain upgrades were historically done with the Cosmos SDK by creating an upgrade proposal, halting the chain at the given height, exporting state to a JSON file, making the necessary JSON file changes, and creating a new chain with the modified JSON file as genesis. This procedure is tedious and could take up to several hours. Not to mention that ALL validator nodes must be completely stopped for it to work.

This hard fork introduces a new way of handling upgrades. When an upgrade happens, instead of starting a new chain, the new binary will read the existing database and perform in-place modifications of the store. We expect this method to reduce the migration time significantly.

Removing the risks of ‘denial of service’ and ‘false witnesses’ with block proposals

The upgrade to Tendermint v0.33.6 essentially mitigates the risk of having block proposers sign for wrong blocks, which results in the invalidation of proposed blocks and, as such, a halt to the network (denial of service.) With this hard fork, a ⅔ majority of signatures must be verified for the block prior to committing it to the chain.

In relation to false witnesses, this hard fork removes the risk of proposed blocks not containing 100% verified signatures. Prior versions would have accepted proposed blocks that contained two-thirds majority verified signatures, which resulted in an increased risk of proposers including arbitrary data for the remainder third of signatures.

Denomination system

By nature, blockchains don’t deal with fractions. The minimum amount we can spend for transfers or transaction fees is 1 SHR. As a result, we have faced several issues related to decimalization. For example, staking/reward calculations are calculated by various formulas, and as a result, the user’s reward would sometimes be less than 1 SHR (the numbers are rounded down). With this upgrade, we introduce two new denoms as alternatives:

• nSHR: Nano SHR. Our base and native coin for now. 1 SHR = 10^9 nSHR. It solves pretty much all of our issues. The rounding still happens but at a very, very small scale so that it can be ignorable.

• CENT: Same story. 1 SHRP = 1 USD = 100 CENT. Prior to this point, we have to keep two different denoms (SHRP and CENT) in our chain, which can be troublesome. Now with only CENT, we reduce some conversion-heavy liftings, thereby increasing performance.

With the introduction of the two new denoms users are now able to transact in fractions, for example 9.5 SHR.

Governance module

The concept was introduced back in 2016 in Cosmos SDK whitepaper. It is now implemented, and we’ve decided to plug it into ShareLedger. This module allows for the future development of governance features, for example:

• Proposing some changes to the parameters or features
• Voting
• ShareLedger upgradability
• Until now, whenever we wanted to upgrade ShareLedger, we needed to completely stop the chain by communicating with all stakeholders (validators) and requesting them to stop their nodes. With this module, this is no longer the case.

Block Explorer

In conjunction with the hard fork, we also wanted to take the chance to upgrade our Block Explorer. This new explorer is still built on top of BigDipper, one of the most known open-source block explorers, but using version two. 

The new version is a complete rewrite with many improvements in terms of both UI and performance. The block parser is now written in Go, which can directly use types and interfaces from our Shareledger, making it seamlessly compatible with all structs we implement. This also means it would be very easy for us to scrape more data and include more UI pages for our own modules.

What key existing feature improvements are being made?

We’ve made quite a few improvements. Below is a list of all the updates to existing features:

• ADR-028 addresses: a new specification for deriving addresses for all kinds of addressable accounts to cover a security risk, due to address space collisions.
• Better support for multisig transactions.
• Transaction fees are now saved on-chain and configurable. We can adjust the transaction fee whenever necessary without updating the binary.
• Better modularization on some of our modules. Gentlemint module will now only take care of token-related tasks like load tokens, burn tokens or fee handling, etc. electoral module takes care of authorization.
• Transaction fee will be automatically calculated based on the on-chain values (if not supplied.) Clients can submit higher fees if they want to.
• Automatically load SHR by SHRP when there is insufficient balance for transaction fees.
• Backports improvements to state synchronization and ABCI performance under concurrent load, and the PostgreSQL event indexer.
• Allow state sync fetchers and request timeout to be configurable.
• Retry requests for snapshots and add a minimum discovery time (five seconds) for new snapshots.

What key bug fixes are being made?

• Sometimes a user’s input fee is unexpectedly overridden by the application default fee. This is now corrected.
• Transfer tokens accidentally minted the same amount of tokens to the module’s balance (each module has its own address), causing inconsistent total supply values.
• When the balance is equal to the transaction fee, the transaction is rejected. We now allow spending of ALL available balance, making it zero.
• There is a substantial bug in evidence handling where evidence could sometimes be broadcast before the block containing that evidence was fully committed, resulting in some nodes panicking when trying to verify said evidence.
• Sometimes peers (nodes) try to send messages on incorrect channels, causing errors that could terminate the process.
• A bug with incorrectly handling contexts that would occasionally freeze state sync.
• A memory leak in the evidence reactor.

If you have any further questions, please feel free to visit our FAQ page for our 2022 Hard Fork