By Michael Kong
Since the beginning of the year, we have made continuous optimisations to Go-lachesis, added additional features to the Xar Network, and made improvements to the explorer and wallet applications.
Fantom will be releasing fortnightly updates from today onwards.
1. Aggressive P2P Propagation of Events
One of the simplest ways to reduce time-to-finality (ttf) was to make P2P events propagation more aggressive so that events would travel between nodes faster. Before the network had a balance between used network throughput and latency, but now gives up more throughput for lower latency.
This did not require a hard fork, and is fully compatible with existing nodes.
2. Changed bootnodes from being static nodes to using discovery
By default, nodes are configured to accept no more than 50 peers. If static nodes have the same limit, then the network won’t scale past 50 nodes without discovery.
We have specified bootnodes as discovery nodes, not static nodes (so discovery would work).
We will also implement a node that does nothing except discovery itself and would serve only as a bootnode. We may re-use this type of node from geth (cmd/bootnode).
3. Added in Support for future SFC logs, including increaseDelegation function
4. Added missing RPC call required to deploy contracts with Truffle
5. Adding multiple addresses for validators in ledgers
Usually, there are multiple addresses for validators in ledgers. For example, an address for receiving rewards, an address for collateral/calling contract calls, or an address for signing consensus messages. This improvement allows the splitting of rewards between different users if the reward address is a splitting contract. A user can now also call contracts from a multi-signature address.
6. Experimented with optimising event emission
7. Added ability to check validator node versions
8. Added flag to stop node from synching once it had downloaded the latest DAG
9. Fixed newHeads subscription in API
10. Refactored subscription and filtering in Lachesis
11. Additional Validators Documentation
We have added some additional documentation for Validators, that we think will be helpful, available here.
The documentation covers the role of a validator, how scores are calculated (which influence validator rewards), reward distribution, and downtime calculations.
In addition, the documentation covers the following related to safety and security:
- Launched 2 load balances for API, monitored performance
- Fixed varies issues related to http 404 and 504 errors
We have also pushed a series of improvements to the Xar Network, including the following:
1. Refactored functions
2. New CSDT Interest Rate Model
3. Added different global currency denominations
Fantom is busy working on many new technologies and updates, including the following:
1. Lachesis standalone module, made as compatible with Tendermint ABCI as possible
We are implementing a Tendermint-like module, which also manages the database, p2p protocol, and tx pool. We may make this module to be as compatible with Tendermint as possible, so it would be easy to use Xar modules over this core module.
We can divide the existing code into consensus and tendermint interface, but apart from implementation of web3 API. Tendermint concerns only logic, but not service things (web3 API). The point is that if we replace the current economy with another ABCI-app, the node will no longer provide web3 API. We will be able to adapt the web3 API to changes in go-lachesis.
Our plan is to gradually separate Fantom consensus (poset+gossip+txpool) and Fantom ABCI-app (evm+economy) — logic and database.
It will be divided gradually, in small steps (small PR).
The code mustn’t lose its actuality and functionalities (further optimizations and division of go-lachesis to consensus and ABCI-app must be synchronized).
2. Improvements to the SFC
We are making several immediate improvements to the SFC, which include the following:
- Adding multiple addresses for validators in ledgers: Usually, there are multiple addresses for validators in ledgers. E.g. An address for receiving rewards, an address for collateral/calling contract calls, and an address for signing consensus messages. It would enable split rewards between different users if the reward address is a splitting contract, and call contract calls from a multisig address.
- Updating SFC to allow collecting rewards (but not withdrawing) before target is reached for 6 month: Currently, it is impossible to claim rewards before 6 month have passed since 27 December 2019, or if the percent of staked tokens > target. This means the following: 1. If validator/delegator withdraws, his rewards get burnt. 2. If validator is withdrawn, then his delegators will get earned rewards, but only if they don’t withdraw. We should allow delegators/validators to claim rewards now, but rewards will be transferable to their account only after 6 month since staked ratio >= target. I.e. instead of `delegator.transfer(reward)`, we do `collectedRewards[delegator] += rewards`, and add function `transferCollectedRewards` with allows to withdraw collectedRewards if `checkBonded()` returns true.
3. Allow user to use collected rewards to mint fUSD (the USD pegged stable coin) and other Synths
We are currently designing and building functionality to allow FTM holders to stake their FTM (and rewards) and generate collaterise Synths out of it. For example, a user can collateralise their FTM at a 300% ratio to generate “fUSD”, a USD pegged stablecoin, or generate synthetic ETH, BTC, and other assets.
Credit: Source link