The Future of FUND - Codegnosis
It’s been a busy month since the successful completion of the MainNet upgrade.
Although the foundation is deep in advisory services and development with our main external partners, the work to improve the internal network and platforms are as prominent/complimentary in the roadmap.
Almost as soon as the last MainNet upgrade was complete, we began working on the next set of improvements for FUND mainchain.
What Upgrade?
A number of improvements and additions will be rolled out in the next update, including:
Cosmos SDK 0.45.x
Bringing FUND mainchain up to date with the latest stable release of Cosmos SDK, und v1.6.x implements the v0.45.x branch of the SDK (v0.45.6 at the time of writing). In addition to allowing FUND to be compatible with IBC and Gravity Bridge (more info below), one of the other things we’re really excited about with this SDK update is the ability to run in-place store migrations for this and future upgrades. This means that Validator operators will no longer need to manually stop their node at a given height, manually export the state to a new genesis, migrate the genesis and restart their node with the new genesis. This cumbersome process is now fully automated and does not require any genesis export/migration — operators can set up the upgrade in advance, with a tool such as Cosmovisor.
IBC & Multi-Chain FUND
und 1.6.x will bring FUND into the larger Cosmos ecosystem with the addition of the IBC and IBC transfer modules. These modules will allow FUND to be transferred to any IBC-supported chain. Once deployed, the Unification Foundation will run an IBC relayer, with channels connecting FUND with the Gravity Bridge chain — the first step on the road to enabling FUND as an ERC20 on Ethereum!
The concept of IBC is quite simple: a user initiates an IBC transfer with the ibc-transfer transaction on the source chain — for example sending some FUND from FUND mainchain to “Chain B”. The FUND is locked in an escrow account within the IBC module on FUND mainchain (note — the source FUND is not burned on mainchain!), and proofs are generated. The proofs and transaction data are forwarded to “Chain B” via the relayer, and if everything checks out “Chain B” mints vouchers to represent the FUND sent. These vouchers can be transferred and used on “Chain B” with normal transactions. If a user wants to send FUND back from “Chain B” to FUND mainchain, then an ibc-transfer is initiated on “Chain B” with the vouchers as the source coin. Once proof has been verified, the vouchers on “Chain B” are burned, and the equivalent amount of FUND is unlocked from the escrow in the IBC module on FUND Mainchain and given back to the user. More details on how it works can be found here.
As previously discussed, the existence and utility of FUND on EVM as an ERC20 (previously referred to as wFUND) is already in plan for private TestNet use of several large-scale projects for oracles and additional usage and will continue to grow in usage with all options including the utility and presence an all prominent EVM based AMM DEXs.
BEACON/Wrkchain state pruning
State bloat has been a long running concern for validator operators. The upgrade includes a major improvement for the BEACON and WRKChain modules to address this, with hash & timestamp state pruning. The vast majority of BEACONs and WRKChains don’t need to keep millions of hashes in-state, so it makes sense to modify the storage of old data sets to optimise network efficiency and state storage. Much like EVM smart contracts, all data submitted to mainchain is effectively archived via Transaction Events, which, with the latest in-place upgrades offered by Cosmos SDK, means event data is no longer “lost” during a chain upgrade. This means that while old data may no longer be held in the state DB, it will effectively still be accessible via transaction query filters to search for BEACON/WRKChain specific events.
Starting from the upgrade height, BEACONs and WRKChains will be allocated 50,000 in-state storage spaces — this is the equivalent to approximately 1 month’s worth of hash submissions, (assuming 1 submission per minute). During the upgrade, the 50,000 most recent submissions for each BEACON/WRKChain will be retained in the state DB, and the rest will be pruned from state. New hash/timestamp submissions will be added to the top of the stack, and old data will be pruned via FILO.
BEACON/WRKChain state storage purchase (and future storage subscriptions)
If 50,000 in-state storage spaces are not sufficient, BEACON/WRKChain developers have the opportunity to purchase more storage — up to a total of 550,000 additional spaces, leading to a total of 600,000 spaces, which roughly equates to 1 year’s worth of in-state storage (assuming 1 hash is submitted per minute).
Further, as with registration and hash submissions, eFUND can be used to purchase the additional storage, meaning that validators will be rewarded for these purchases in addition to rewards already received for registrations and submissions.
Ultimately, this will lead to annual subscriptions for additional BEACON/WRKChain storage, which we believe is a fair way to reward validator operators, and ensure that a steady stream of eFUND is added to the general FUND circulating supply.
eFUND usage — query spent eFUND
Currently, if an end user wishes to see how much eFUND has been added to the general FUND circulating supply, a series of on-chain queries and some additional off-chain calculation is required. This process currently involves querying the chain for completed eFUND purchase orders (a completed PO means that eFUND has been minted and made available to the purchaser to pay for BEACON/WRKChain fees), and a second query to find out how much eFUND is currently “locked” (minted, but not yet part of the general FUND circulating supply — i.e. it can only be used for paying BEACON/WRKChain fees, and not general transfers/transactions). The difference between the two is the amount of eFUND that has been added to the circulating supply.
With the next update, this is all tracked in-state and can be queried completely on-chain — both the total eFUND spent, and for each individual Enterprise address, making “eFUND inflation” much simpler to view.
Staking Module Params
As a requirement for IBC relayers to be able to interact with FUND mainchain, the historical_entries parameter for the Staking module will be set to 10,000 as part of the upgrade process.
BankKeeper Denom Metadata
Also as part of the upgrade process, denomination metadata for nund/FUND will be saved to the BankKeeper.
Documentation
Mainchain documentation is currently part of the mainchain GitHub repository. We aim to migrate all documentation into a dedicated repository, which we believe will make it more accessible and open up more opportunities for community involvement with maintenance and contribution. Further, we anticipate integrating other project documentation into the central repository over the coming months (VOR, OoO etc.).
Wen Upgrade?
Much of the upgrade roadmap is dependent on the date the initial TestNet governance proposal is submitted. The MainNet upgrade will be dependent on the success of the TestNet upgrade. As with the previous upgrade we aim to initialise the MainNet upgrade via governance approximately 1 month after a successful TestNet upgrade takes place.
Further, the date of the actual TestNet upgrade will be difficult to predict, as (unlike the previous upgrade), this upgrade will be based on a future block height as opposed to a Unix timestamp. Predicting the time and date of a future block with fluctuating block times is an interesting task!
The date will be officially announced soon, but the tentative roadmap at the time of writing is as follows:
TestNet
During week beginning 25th July — TestNet governance proposal for 1-ibc upgrade
During week beginning 8th August — Voting period ends (2 weeks after proposal submitted)
Approx. 1 week after voting period ends — TestNet upgrade executes.
Post TestNet upgrade:
Unification Foundation will deploy an IBC relayer and set up IBC connections between FUND TestNet and the Gravity Bridge chain testnet.
Publish IBC channel details in appropriate repos to allow for testing
MainNet
Approx. 1 month after TestNet upgrade is executed (allowing for tests etc.) — governance proposal for MainNet 1-ibc upgrade
Voting period runs for 2 weeks
Approx. 1 week after voting period ends — MainNet upgrade executes.
Post MainNet upgrade:
FUND chain details will be added to the Cosmos chain Registrar repository
Unification Foundation will deploy an IBC relayer and set up IBC connections between FUND MainNet and the Gravity Bridge chain mainnet.
Gravity Bridge proposal submitted for FUND ERC20
We hope to be included in Mintscan explorer
How Upgrade?
The standard method for managing binaries and upgrades with the majority of Cosmos based chains is to run Cosmovisor. Cosmovisor is a wrapper around Cosmos SDK based binaries, and automatically monitors the chain for upgrades (which are created via governance proposals). When detected, cosmovisor automatically halts the node application at the correct upgrade height, and carries out the specified upgrade before restarting the node application with the new binary.
Cosmovisor does require some initial setup and configuration by validator operators, but once this is done, upgrade management is as straight forward as creating a new directory, and downloading the latest und binary.
A full guide to setting up cosmovisor in preparation for the upgrade will be published before the TestNet governance proposal is submitted in order to give validators plenty of time to prepare. A Quick Start guide to migrating systemd service files to use Cosmovisor can be found in our TestNet repo, which can be implemented now for TestNet (the process is the same for MainNet).
It’s been a busy month since the successful completion of the MainNet upgrade.
Although the foundation is deep in advisory services and development with our main external partners, the work to improve the internal network and platforms are as prominent/complimentary in the roadmap.
Almost as soon as the last MainNet upgrade was complete, we began working on the next set of improvements for FUND mainchain.
What Upgrade?
A number of improvements and additions will be rolled out in the next update, including:
Cosmos SDK 0.45.x
Bringing FUND mainchain up to date with the latest stable release of Cosmos SDK, und v1.6.x implements the v0.45.x branch of the SDK (v0.45.6 at the time of writing). In addition to allowing FUND to be compatible with IBC and Gravity Bridge (more info below), one of the other things we’re really excited about with this SDK update is the ability to run in-place store migrations for this and future upgrades. This means that Validator operators will no longer need to manually stop their node at a given height, manually export the state to a new genesis, migrate the genesis and restart their node with the new genesis. This cumbersome process is now fully automated and does not require any genesis export/migration — operators can set up the upgrade in advance, with a tool such as Cosmovisor.
IBC & Multi-Chain FUND
und 1.6.x will bring FUND into the larger Cosmos ecosystem with the addition of the IBC and IBC transfer modules. These modules will allow FUND to be transferred to any IBC-supported chain. Once deployed, the Unification Foundation will run an IBC relayer, with channels connecting FUND with the Gravity Bridge chain — the first step on the road to enabling FUND as an ERC20 on Ethereum!
The concept of IBC is quite simple: a user initiates an IBC transfer with the ibc-transfer transaction on the source chain — for example sending some FUND from FUND mainchain to “Chain B”. The FUND is locked in an escrow account within the IBC module on FUND mainchain (note — the source FUND is not burned on mainchain!), and proofs are generated. The proofs and transaction data are forwarded to “Chain B” via the relayer, and if everything checks out “Chain B” mints vouchers to represent the FUND sent. These vouchers can be transferred and used on “Chain B” with normal transactions. If a user wants to send FUND back from “Chain B” to FUND mainchain, then an ibc-transfer is initiated on “Chain B” with the vouchers as the source coin. Once proof has been verified, the vouchers on “Chain B” are burned, and the equivalent amount of FUND is unlocked from the escrow in the IBC module on FUND Mainchain and given back to the user. More details on how it works can be found here.
As previously discussed, the existence and utility of FUND on EVM as an ERC20 (previously referred to as wFUND) is already in plan for private TestNet use of several large-scale projects for oracles and additional usage and will continue to grow in usage with all options including the utility and presence an all prominent EVM based AMM DEXs.
BEACON/Wrkchain state pruning
State bloat has been a long running concern for validator operators. The upgrade includes a major improvement for the BEACON and WRKChain modules to address this, with hash & timestamp state pruning. The vast majority of BEACONs and WRKChains don’t need to keep millions of hashes in-state, so it makes sense to modify the storage of old data sets to optimise network efficiency and state storage. Much like EVM smart contracts, all data submitted to mainchain is effectively archived via Transaction Events, which, with the latest in-place upgrades offered by Cosmos SDK, means event data is no longer “lost” during a chain upgrade. This means that while old data may no longer be held in the state DB, it will effectively still be accessible via transaction query filters to search for BEACON/WRKChain specific events.
Starting from the upgrade height, BEACONs and WRKChains will be allocated 50,000 in-state storage spaces — this is the equivalent to approximately 1 month’s worth of hash submissions, (assuming 1 submission per minute). During the upgrade, the 50,000 most recent submissions for each BEACON/WRKChain will be retained in the state DB, and the rest will be pruned from state. New hash/timestamp submissions will be added to the top of the stack, and old data will be pruned via FILO.
BEACON/WRKChain state storage purchase (and future storage subscriptions)
If 50,000 in-state storage spaces are not sufficient, BEACON/WRKChain developers have the opportunity to purchase more storage — up to a total of 550,000 additional spaces, leading to a total of 600,000 spaces, which roughly equates to 1 year’s worth of in-state storage (assuming 1 hash is submitted per minute).
Further, as with registration and hash submissions, eFUND can be used to purchase the additional storage, meaning that validators will be rewarded for these purchases in addition to rewards already received for registrations and submissions.
Ultimately, this will lead to annual subscriptions for additional BEACON/WRKChain storage, which we believe is a fair way to reward validator operators, and ensure that a steady stream of eFUND is added to the general FUND circulating supply.
eFUND usage — query spent eFUND
Currently, if an end user wishes to see how much eFUND has been added to the general FUND circulating supply, a series of on-chain queries and some additional off-chain calculation is required. This process currently involves querying the chain for completed eFUND purchase orders (a completed PO means that eFUND has been minted and made available to the purchaser to pay for BEACON/WRKChain fees), and a second query to find out how much eFUND is currently “locked” (minted, but not yet part of the general FUND circulating supply — i.e. it can only be used for paying BEACON/WRKChain fees, and not general transfers/transactions). The difference between the two is the amount of eFUND that has been added to the circulating supply.
With the next update, this is all tracked in-state and can be queried completely on-chain — both the total eFUND spent, and for each individual Enterprise address, making “eFUND inflation” much simpler to view.
Staking Module Params
As a requirement for IBC relayers to be able to interact with FUND mainchain, the historical_entries parameter for the Staking module will be set to 10,000 as part of the upgrade process.
BankKeeper Denom Metadata
Also as part of the upgrade process, denomination metadata for nund/FUND will be saved to the BankKeeper.
Documentation
Mainchain documentation is currently part of the mainchain GitHub repository. We aim to migrate all documentation into a dedicated repository, which we believe will make it more accessible and open up more opportunities for community involvement with maintenance and contribution. Further, we anticipate integrating other project documentation into the central repository over the coming months (VOR, OoO etc.).
Wen Upgrade?
Much of the upgrade roadmap is dependent on the date the initial TestNet governance proposal is submitted. The MainNet upgrade will be dependent on the success of the TestNet upgrade. As with the previous upgrade we aim to initialise the MainNet upgrade via governance approximately 1 month after a successful TestNet upgrade takes place.
Further, the date of the actual TestNet upgrade will be difficult to predict, as (unlike the previous upgrade), this upgrade will be based on a future block height as opposed to a Unix timestamp. Predicting the time and date of a future block with fluctuating block times is an interesting task!
The date will be officially announced soon, but the tentative roadmap at the time of writing is as follows:
TestNet
During week beginning 25th July — TestNet governance proposal for 1-ibc upgrade
During week beginning 8th August — Voting period ends (2 weeks after proposal submitted)
Approx. 1 week after voting period ends — TestNet upgrade executes.
Post TestNet upgrade:
Unification Foundation will deploy an IBC relayer and set up IBC connections between FUND TestNet and the Gravity Bridge chain testnet.
Publish IBC channel details in appropriate repos to allow for testing
MainNet
Approx. 1 month after TestNet upgrade is executed (allowing for tests etc.) — governance proposal for MainNet 1-ibc upgrade
Voting period runs for 2 weeks
Approx. 1 week after voting period ends — MainNet upgrade executes.
Post MainNet upgrade:
FUND chain details will be added to the Cosmos chain Registrar repository
Unification Foundation will deploy an IBC relayer and set up IBC connections between FUND MainNet and the Gravity Bridge chain mainnet.
Gravity Bridge proposal submitted for FUND ERC20
We hope to be included in Mintscan explorer
How Upgrade?
The standard method for managing binaries and upgrades with the majority of Cosmos based chains is to run Cosmovisor. Cosmovisor is a wrapper around Cosmos SDK based binaries, and automatically monitors the chain for upgrades (which are created via governance proposals). When detected, cosmovisor automatically halts the node application at the correct upgrade height, and carries out the specified upgrade before restarting the node application with the new binary.
Cosmovisor does require some initial setup and configuration by validator operators, but once this is done, upgrade management is as straight forward as creating a new directory, and downloading the latest und binary.
A full guide to setting up cosmovisor in preparation for the upgrade will be published before the TestNet governance proposal is submitted in order to give validators plenty of time to prepare. A Quick Start guide to migrating systemd service files to use Cosmovisor can be found in our TestNet repo, which can be implemented now for TestNet (the process is the same for MainNet).