Since high transaction rates imply many conflicting blocks are created, it would be quite useful if these blocks were not really lost. In fact, each block can be seen as supporting not just transactions inside it, but also those embedded in previous blocks. Even if a block is not in the main chain, we can still count the confirmations it gives previous blocks as valid. This is the basis of our proposed modification, which we call the "Greedy Heaviest-Observed Sub-Tree" chain selection rule.
Roughly speaking, since each block contains a hash of its predecessor, all blocks form a tree structure, rooted at the Genesis Block. Bitcoin currently selects the accepted history as the longest (or rather heaviest) chain in the tree. We suggest another approach: At each fork, pick the sub-tree containing the most blocks (or rather the blocks with greatest combined difficulty).
What is nice about this is that it is backwards compatible.
For blocks that are off the main chain, you only need to send the headers. This could be made part of the headers first system. Each node would download the entire header tree first and then download the full blocks.
In high transaction rates, GHOST builds slightly less blocks in its main-chain (because it doesn't always extend the longest chain), thus slightly lowering the number of transactions accepted per second, but it does so more securely!
The difficulty update would have to be the main chain length, so the block rate would remain the same.
In fact, we estimate that 1 second blocks can be easily combined with rates of over 200 TPS.
A faster block rate mainly helps with confirmation time rather than transactions per second. Your node still needs to process the entire block to make sure all the transactions are valid.
A much higher block rate (with lots of blocks thrown away) would mean that nodes would end up verifying multiple blocks.
This implies quite fast authorization times, but much more importantly, an increased granularity in confirmations. Even 1 confirmation gives some level of certainty regarding irreversibly, and it comes almost instantly when blocks are generated every second.
Since Bitcoin's security relies primarily on the number of confirmations received instead of on elapsed time, we end up getting irreversibility of transactions with very high probability in far less than 10 minutes.
It depends on the hash value too. Your transaction needs to have hashing power built on it that is much more valuable than the transaction. The block rate determines protection against random reversal.