Rails Network
Scalability & Finality
The PoWbA consensus and the Rails Network validator (nodes) architecture and approval are designed to minimize forking, secure the network, and ensure finality quickly.
Even in a perfect world, if all validators are thoroughly vetted and all validators are honest, there still may exist more than a single chain at any moment (different validators create different blocks). In such a scenario, both forks will continue to validate blocks and add new blocks. This process lasts until one of the chains validates a block before the other chain completes and becomes the longest chain. At that point the longest chain becomes the accepted chain and transactions mined on the shorter chain are rejected (it is possible that the transactions rejected on the shorter chain might have been included in other blocks on the longest chain).
Blockchain transactions are usually perceived as immutable, but this finality is only probabilistic. For example, it is recommended to wait for at least 6 confirmations on Bitcoin (avg. 60 minutes), 20-25 confirmations on Ethereum (avg. 6 minutes) and 2/3*N+1 confirmations = 15 on BSC (75 seconds).
Finality measures how long a user should wait until there a reasonably high guarantee that transactions in the blockchain are irreversible. Waiting for an hour might be acceptable to personal transactions but could pose significant hurdles for a business.
The two most typical attacks which can affect PoW finality: selfish mining and 51% attack, are mitigated by the PoWbA design (all miners = mining pools are validated and trusted)
Given The Rails Network estimated avg. block time (3-5s) and the consensus architecture, finality can be easily achieved in under a minute (20s-30s should be sufficient for most applications)
In PoWbA there is little to no concern of miners colluding to increase the base fee (e.g. via spamming transactions) and therefore the block fees are not burned as in other networks but rather distributed along with the block rewards.
Copy link