So first a distinction between the concepts. Blockchain bloat is a block-chain with 1) more transactions than anticipated 2) Total memory that requires lengthy download time to create a full node. A healthy, secure block chain requires that a large percentage of wallets and miners are full nodes. This is for block creation and verification which can (on not all block chain designs) be performed on light nodes. Yet, historical verification is, in theory, also necessary at some constant interval to ensure no tampering with the network. Suffice to say, the greater number of full nodes, the more redundant the decentralization and hence the more secure the network, the more the 51% rule holds. 3) Rate of transactions per second is increasing at an exponential rate. This gives greater risk for unforeseen problems, slowdown becasue there simply are not enough miners to handle all the transactions, fees go up for competition for the time slots, more miners are necessary. This creates higher fees and overall network slowdown. (One solution would be to require all users to also be miners, hosting full node wallets. This may be the way btc and some coins start. Others can elaborate or correct this concept please.) suffice to say, the rate is increasing "out of control".
Well what does "out of control" really mean? For starters, it means that a full node cannot be downloaded quickly, and second, verification takes longer on a large block-chain laden with transactions waiting to find a home (a block) and third, fees go up as competition for the time slots increase.
But Let's not confuse a transaction waiting to find a home because no miners are free at the moment due to processing higher fee transactions in a busy chain, to a more well-known reason the transaction is waiting to be recorded, block-size limits, miners are busy mining a new block because no new transactions can be placed in the current block because it is limited to 1MB for example.
Block-size limits: If a block-chain is deigned so that blocks are created at even time intervals - like bitcoin for example, every 10 minutes, and if a block has a limited number of transactions that can be in it due to it's size being limited to 1MB for example, and if there are so many transactions waiting to get into a block, well, then you'll have delays in the transaction being added to a block.
So, the point of this article is that people understand the different problems caused by block-size limits and block chain bloat and what causes each one of them and with this knowledge explore possible solutions that have not been discussed yet.
Block size limit, in the case of bit coin, is caused by an arbitrary size limit having been imposed in the core code. One way to deal with that problem is introduce a network on top of bitcoin that allows some transactions to happen without being recorded in the block chain until absolutely necessary for example SegWit. That would allow miners to exist in harmony with new core code that recognizes SegWit. Why do we say "arbitrary"? Because someone thought, oh we must have some limit otherwise transactions will keep being added and the block will never close and hence it won't get verified ever? right? That is good thinking, but there is another way to look at it. Same solution though. Let the block size float until the oldest transaction has reached some maximum agreed limit in waiting - say 10 seconds. So block size varies, but no transaction shall wait more than 10 seconds before closing a block, so a block is now every 10 seconds. So now what happens when that chain also has an imposed size limit on the block to say 1 million transactions, and now there are millions of transactions per second - ok so now the wait time increases, until the next block can be mined. Get rid of the size limit, and then all transaction make it into the current block. Simple solution, no limits, as in bitcoin "unlimited".
Yet still a problem can arise if you dont have enough miners because while the bulk of the time in proof of work is finding a correct hash to create the block, if you have millions of transactions to put into the block, verifying no double spends in the very large group of transactions for the block, well that time is not zero, even if close to zero, it can become a bottleneck for which a future solution might have to be to increase (slow) the block time interval unless a new architecture allows machines to work in parallel in some way to verify no double spends in the same block, to add perhaps millions of transactions to a single, already-mined block.
Anyway, these are some of the concepts to consider in your block chain design.
so now on to forks: (taught here by example only)
Assume in both hard and soft forks there exist a chain A to start with and some problem with the chain necessitating a software update. Now, in theory, some problems in a chain can be resolved with a software update that can be introduced right away to all miners and wallet holders. But that would require a halt in all trading, not an easy thing to accomplish. So that concept is not realizable - (feel free to comment here) without designing it into the decentralized chain to begin with - great idea for my next story.
So now that we know that we cant stop trading on the old chain, what do we do? Well, we introduce a Chain B that has different core software than chain A. for the B chain, if you had 50 coins in coin A , now you also have 50 coins in B. Assume there is now a new exchange symbol called B. The value of each coin is beyond the scope of this story but suffice to say each coin in A and B is worth exactly half its former value when one chain existed - or less due to mass hysteria from the split which eventually dies down. The values then change according to what happens next - which chain "takes over" but I am getting ahead of myself. Please have patience. Again, this is an easy example, just to understand the concepts.
soft fork: chain B can handle and in fact does register any changes in chain A. This is important to understand. What it means is that B is a subset of A, or in english, if bob sends Alice coin in chain A - chain B registers it (how? comments here) The B mining software is still looking at the A block chain as well to coordinate everything it does. This means no double spends can happen on B when considering A. B is still based on verifying everything that A does, but can do more. For, example in SegWit, if bob sends to Alice on SegWit which rides on top of chain B, the transaction is not recorded in B until SegWit puts it there whenever it is necessary, hence speeing up the B chain. But if on chain A Bob sends his last bitcoin to Alice and then immediately tries to use SegWit on B to send to Alice, it wont work because the new software is checking for that, it is not letting SegWit operate if either chain B or chain A forbids the operation. One could say chain B softwre has to work double time, extra-hard until all the moiners on A start using B -a dn then chain A just "ends" disappears. At that time, tghe value of all yur coin on B can increase again, allegedly! A can also stick around as a legacy maybe even be traded with real low volume as it is unpopular - but hey you got redundant coin there on a bad chain, you never know! but now you understand what a soft fork is, B is a subset of A recognizes A's transactions, and B is eventually called A again! Fnatastic. What could go wrong? Well, the miners could opt not to accept B in majority, and then the two forks remain. If that happens, the B software might declare " hey we will no longer record what happens on A" so then you have two distinct forks, A likely still becomes a dinosaur, but now double spends can happen, but it is not called double spends now, because ther eis no chance that A can disappear now, becasue B is now completely distinct so that value of B will now be completely independent of A but in a different way then if A just disappeared. Again that is beyond the scope of the story for now.
The point here is that 51% of the miners on A and B adopt the B chain. A can be destroyed or remain as some dusty currency now. In my opinion there should be some consensus that if 51% happens, that A is simply destroyed. that keeps the value in B, if that were in fact the "rule". I am not sure it is, but it may be (comments of experts here).
Hard Fork: So this is easier to explain, becasue you already know that if chain B is not adopted by the majority of miners using A and B, well, then at some point, B software is going to declare "hey everyone, we are not going to record what happens in B anymore" At that point the subset relationship changes, B is no longer a subset of A, in other words B no longer accepts transactions of A, so everything in B is no longer necessarily valid in A, or rather it is a distinct entity, that has a major effect on value of A and B now. Now, A has no risk of being devalued more than it is already due to the potential of B taking its place. But remember that A is likely already significantly devalued from the attempt, and likely A will get worse if B fails, because if B exists, everyone WANTS it to succeed becasue after all it is designed to be an improvement on B.
More later, stay tuned for part 2 where other solutions are explored.
-I'm your huckleberry.