Function X f(x)Core v5.0.x

An overview of our latest v5.0.x upgrade

Upgrade v5.0.x has arrived on f(x)Core and in this article, we are going to explore the two main features that the upgrade will bring to the network: replacing the consensus public key and transferring validator permissions.

Validator Keys

To better understand the new features from upgrade v5.0.x, it is essential to know the keys that a validator handles when it participates in the network’s consensus. In general, a validator on a Tendermint consensus based blockchain, such as f(x)Core and Cosmos, works with three different keys:

The consensus key

The consensus key is used to sign blocks on an ongoing basis, and it is of type ed25519. This key is created as long as a node is initialized.

The validator operator application key

The validator operator application key is used to create transactions that create or update validator parameters. It is generally of type secp256k1 or whichever type the individual network supports.

The delegator application key

The delegator application key is used to handle the stake that gives the validator more voting power. Depending on the chain, this key could be the same as the validator operator application key if you are a node operator.

These keys are usually bech-encoded and will have specific prefixed values appended to them depending on the chain. For example, a validator operator application key on f(x)Core will be prefixed with “fxvaloper”. On f(x)Core, both validator operator and delegator operator keys are of the same type, but with a different encoding.

One important point to note about the consensus key is that it is considered “hot”, meaning that it can and must produce valid signatures at any point in time. In other words, it can be used immediately by our machines. Whereas validator and delegator keys are considered “cold” as they require at least some form of approval before being accessed. There is, therefore, a higher security risk associated with the consensus key compared to validator and delegator keys.

The two features introduced in upgrade v5.0.x to f(x)Core aim to provide contingency measures against security breaches and potential misuse of the consensus key, thereby safeguarding the validator’s authority.

Replacing the Consensus Public Key

In the event a server is compromised or the consensus public key is leaked, the validator’s consensus public key can be replaced through a transaction to update the consensus public key.

#command
fxcored tx staking edit-consensus-pubkey <val> <new-consensus-pubkey> --from 
addr/granter

#example
fxcored tx staking edit-consensus-pubkey fxvaloper123...
'{"@type":"/cosmos.crypto.ed25519.PubKey","key":"...."}' --from=fx456...

The val argument should be the validator’s address, for example: fxvaloper1a73plz6w7fc8ydlwxddanc7a239kk45jnl9xwj. In order to get the argument for new-consensus-pubkey, set up a new node and run the following:

fxcored tendermint show-validator --home /root/.fxcore-node-new
#/root/.fxcore-node-new is the path of the new node

Note that the path of the new node would vary depending on how you set up node; and for the new node, you do not have to set up the validator — this would cause a conflict.

Between addr/granter, addr is the address controlled by the validator, i.e. the delegator application key or simply the token holding account for the validator which was bound to the node’s consensus when the validator was first set up; for example: fx1a73plz6w7fc8ydlwxddanc7a239kk45jmwcesj. The granter is the address (or delegator application key) authorized by the validator, to which permissions are transferred, through the process described below.

It is strongly recommended to update the consensus public key first, and only transfer validator permissions after, because once the permissions are transferred, the old validator operator application key can no longer be used to operate the validator.

Transfer Validator Permissions

1. Transferring Permissions

Should the validator’s private key get compromised, the current validator’s authority can be transferred to another address by executing the following transaction. At this time, the validator’s existing private key will not be able to send any transactions on the f(x)Core chain; and the authorized address can send any type of transaction for the validator’s address. It is recommended not to transfer permissions if the validator’s private key is not compromised.

#------------Transferring Permissions to New Address------------

#command
fxcored tx staking grant-privilege <val> <new-addr> --from addr

#example
fxcored tx staking grant-privilege fxvaloper1vx... fx1g7... --from fx1a7...

The new-addr argument is the address to transfer permissions, i.e. the new permissions holder, for example: fx1uphlwe07477h0yvgcr5h26lyylyc7g709jp8ev.

And the addr argument is the old permissions holder, for example: fx1a73plz6w7fc8ydlwxddanc7a239kk45jmwcesj.

The transfer permissions transaction can be executed multiple times, for example: by val-addr_0→ addr_1, and then by addr_1 → addr_2.

Note that when transferring permissions, new-addr and addr signatures are required, as authorization and signatures are required. More importantly, permissions should not be transferred back to the validator address at any point.

2. Sending Transactions After Transferring Permissions

Once validator permissions are transferred, any subsequent transactions needs to be authorized before the they can be sent. The validator address can no longer directly send transactions, and the new permissions holder must be used to send transactions on behalf of the validator address.

Authorization:

#------------1. Constructing an Authorized MsgSend Transaction------------
fxcored tx authz grant <new-key> generic --msg-type=/cosmos.bank.v1beta1.MsgSend 
--from <old-key> --chain-id dhobyghaut --generate-only > grant_bank_send.json

#--------------2. Execute Authorize MsgSend Transaction--------------
fxcored tx authz exec grant_bank_send.json --from <new-key> --gas="auto" 
--gas-adjustment=1.5 --gas-prices="4000000000000FX" --keyring-backend test 
--chain-id dhobyghaut

The old-key argument is the key of the old permissions holder. And the new-key argument is the key of the new permissions holder. The first authorization step creates a .json file of the Authorized MsgSend transaction, which will then be executed in the second authorization step. The authorization step grants the new permissions holder the authority to send a transaction for the validator address.

Transfer:

#------------1. Construct the MsgSend transaction------------
fxcored tx bank send <val-addr> <new-addr> 1FX --chain-id dhobyghaut 
--generate-only > bank_send.json

#------------2. Execute the MsgSend transaction------------
fxcored tx authz exec bank_send.json --from <new-addr>--gas="auto" 
--gas-adjustment=1.5 --gas-prices="4000000000000FX" --keyring-backend test 
--chain-id dhobyghaut

The new-addr argument is the address of the new permissions holder, which should be authorized at this point. The first step creates a .json file of the constructed MsgSend transaction, which will then be used in the execution of the transaction in the second step. The MsgSend transaction is thus executed by the new validator permissions holder.

Moving forward with f(x)Core v5.0.x

Please note that the above features are currently unavailable for ledger account types. Sending transactions related to transferring validator permissions require signing custom data on the f(x)Core chain with a new private key, however the ledger hardware does not support signing custom data at the moment.

Replacing the consensus public key and transferring validator permissions are available with f(x)Core v5.0.x and you can find the steps to upgrade your f(x)Core node here (we highly recommend using Cosmovisor to perform your upgrade!).

The new features introduced in the f(x)Core v5.0.x upgrade represent a new innovation that the team has worked towards to fortify the network further against potential threats and vulnerabilities; and they ensure that users can transact and interact with the f(x)Core network with confidence.

Next

Thank you for reading this month’s tech update and stay tuned for the next one on f(x)Core developments!

If you’d like to know more about Function X and stay up-to-date with us, check out any of the links below.

Website | Twitter | Forum | Telegram Announcements | Telegram Group | Discord | Github