In my last post, I talked about fee-less transactions for dApps – thanks to the Hypernodes framework – as well as why fees are usually needed.
Let’s take some time to dig deeper into these, how Bismuth addresses the issues and what it means for the various actors.
I know this is quite lengthy for a “roadmap”, yet I feel it’s important you understand the landscape as well and not the road only.
Fees as a reward for miners
In most cryptocurrency chains, fees can be an important part of miners rewards. They reward miners for the work in building the chain – be it PoW or PoS – while avoiding too high a monetary dilution.
This is the cause of some attacks or at least gives an incentive to cheat, steal blocks, attack other nodes, clog network…
With Bismuth side chains – Hypernode like chains – there is no currency on the chain at all, and no reward at all for forging a block.
However, rightful Hypernodes can be rewarded anyway. The Bismuth Hypernodes are the living example of that working: Hypernodes do publish metrics on their PoS chain, and these metrics then serve as base for a private contract to issue rewards – from main chain, the one with $BIS currency.
We can see some differences in there: there is no advantage in trying to mine more blocks than you are supposed to – nor to attack other nodes. Metrics from other nodes testing yours are in fact part of what account for your rewards (plus what node does forge what block is deterministic from on chain data).
In our approach all Hypernodes have an incentive to operate a smooth network and cooperate nicely.
The rewards are sent by a private contract – which working can be replicated and audited any time – because based upon on chain data and public algorithm. Remember the “Clear line of trust” Bismuth pillar.
Fees as a way to avoid censorship
One reason for fees in Bitcoin and other cryptocurrencies is to avoid censorship. Even in times of high network usage, or if some nodes want to actively censor your transactions, you are likely to have your transactions mined anyway by setting a high enough fee.
The financial incentive will be enough so that some miner will indeed include your transaction in a block to get the reward.
This can however take some time, and has side effects, like raise the fees for everyone in times of high traffic, and still you could be censored if your miners collude or share a common motive.
With Bismuth side chains, there is a motive to include transactions as well and not censor them. A Bismuth side chain does not use the “longest chain” paradigm, but rather something like the “most diverse” one.
That is, in case of two competing chains – like after a network partition or if some nodes do censor transactions and filter blocks from others, then the most diverse chain wins. That is, it is in every node’s interest to include as many transactions sources as possible. Censoring nodes do penalize themselves.
Moreover, since every node gets to eventually forge a block – on a deterministic basis – there will always be a block that is yours to forge.
For that block, you rule and you can embed your transaction there for sure.
Fees as spam protection
Another argument in favor of fees for transaction is spam protection.
In fact, if all transactions were for free, what would prevent someone to send hundreds, thousands, millions of transactions and paralyze the whole network?
Fees may be necessary on a fully open network, with no restriction whatsoever. But in the context of Bismuth side chains, we have a joker in hand…
Say we have an upper limit of transactions that can make it in a block. We keep that number low enough that we are pretty sure the network can handle it. Under standard operations, we can embed all the transactions without filtering anything.
What if someone then spams?
Well, we then can enforce some restrictions…
Permission to embed
Active Side chains nodes have to be registered on the main chain (see the Hypernode registration step). The collateral for Bismuth Hypernodes is 10k, 20k or 30k. Other side chains could use any other amount they want.
Using that, we can enforce a transaction quota for every registered Hypernode, and use the spare capacity if any to embed “anonymous” transactions.
This way:
- The network still is permission-less. Yes, you have to register and lock some $BIS, but you do not have to ask anyone for permission.
- Under heavy load, every node has the same weight and is sure to have its transactions go through.
- The transactions diversity is better enforced than by fee amount.
- No app will bug, get stalled or be abused because gas fee are too high: every node will be able to send its due share of transactions.
- Need more throughput? Just lock more collateral and run more nodes.
- No one “pays” for transactions. A node operator just locks some $BIS he can get back anytime, to gain access to a reserved – I’d even say guaranteed – share of network throughput.
Sending fee-less transactions In practice
That’s where the roadmap kicks in.
In order for anyone to take advantages of these features, more – development and doc – work has to be done
Hypernode plugin
The plugin frame we used on both the PoW nodes and the Tornado wallet proved to be very effective, and can be used for Hypernodes as well.
The default Bismuth PoS chain – your current Hypernodes instances – will be able to run plugins, plugins that will allow your Hypernode to provide additional services – and be rewarded for them.
That feature is in the works.
Hypernodes framework
As you may have understood already, the current Hypernodes are just one limited use case of the Bismuth side chains.
Nothing limits the side chains to one chain only, nor to the specific configuration we now have.
Everyone should be able to run a dedicated instance of a BIS side chain, with its own parameters and registration rules, block time, transaction types etc…
There, it is more about getting the right doc to the right people.
Getting the history pruning right is also part of this picture. That is a more complex issue I will not discuss right now.
An answer to the scalability issue
You should now have understood how our global Bismuth architecture answers the scalability issue.
Once an app needs more throughput than what the regular Hypernodes can provide as free transactions it can just start a new side chain or use another existing one: several apps could share a common side chain.
Need more throughput? Use more side chains.
Other cryptocurrencies have to focus on one main use case, because scaling and required on chain processing of smart contracts (ex: Non fungible tokens) Bismuth has no such concerns. One NFT – or one dApp – can be one plugin or one side chain.
Next episode
In the next episode I will dig a little more into these Bismuth side chains – we named them “op shards” for operational shards – scalability vs safety and the resulting benefits for BIS – the currency.