There are a couple major changes upcoming to Hive base coding that is going to add a couple features that address bottlenecks. One focuses upon users while the other is tied to infrastructure.
The information for this article came from the reports posted by @blocktrades that can be found HERE and HERE.
Lite Nodes
Scaling is crucial to any network. The ability to grow is essential. In the digital world, that is often summarized by the word "bandwidth". Basically this means enough throughput to process whatever it required.
When it comes to blockchain-based networks, the ability to decentralize is also crucial. This means having enough nodes in operation so that there is no only redundancy, but also unrelated parties operating the software.
As the amount of data grows, challenges are encountered. The size of the nodes required to ensure proper "bandwidth" gets larger. If left unchecked, this could get to the point where the database exceeds the technology on the market.
Fortunately, Hive is not at this point. The last hard fork saw new compression that reduced the size by around 50%.
Evidently, the next phase in the evolution is Lite nodes.
What is a lite node?
It is a node that runs only a certain portion of the database, opting against maintaining all blocks. This is a way for applications to run their own infrastructure without having to keep everything. Naturally, you cannot have all lite nodes some many have to maintain all since the genesis block. However, this will provide another option for developers.
Here is how it was phrased:
Ideally, hived nodes should retain the entire blockchain history, as this provides more redundant storage to any node that is not yet in sync with the current Hive head block, allowing such nodes to get the old blocks they don’t have from their peers.
But at some point, such storage becomes overkill, and it also increases the costs to run services that require a hived node becomes of the associated storage costs. Currently, even with the new features for compressing block storage that cuts storage costs in half, the block_log file is 486GB in size (almost ½ a terabyte).
For those who do not require the entire blockchain, this could be a viable options.
Here is how it essentially works:
Setting the block-log-split option to any larger value tells hived to maintain at least that many million recent blocks. For example, setting `block-log-split=2’ means keep at least the last 2 million blocks. In this mode, the block log is stored in multiple files (e.g. block_log_part.0084 contains blocks up to 84M, block_log_part.0085 contains blocks up to block 85M, and the “top” file block_log_part.0086 contains blocks from 85,000,001 to the current head block), each 1 million blocks long and split at 1 million byte boundaries (except for the currently “top” file which will only contain blocks up to the current head block).
The node operators consider how many blocks they want to store. We also see, in the articles, different ways to store the legacy data if switching to this setup.
Hence, technical teams will have the choice of running a scaled down node if this is all that is required.
Lite Accounts
This is something that was discussed over the years and is now being developed.
Lite accounts will provide the ability for people to engage with applications while not requiring a full Hive account. Notice how it says "sign second layer transactions".
We are creating a new HAF app to manage the creation and maintenance of “Lite” accounts that can be used by any 2nd layer app to sign 2nd layer transactions. The specification for this also includes documentation for how we plan to support 2nd layer transactions.
This is a problem that Hive has battled. We know it is not easy to get a Hive account and some applications looked to build their own. The results, so far, are varied.
Here we are seeing this tied to HAF, a server system any application can tap into. This is a way for any layer 2 application to provide people with Lite accounts in a manner that allows engagement and interaction without having to have a full account.
This is going to expand in the future:
We also have a plan for how to create namespaces for other blockchains and also non-blockchain apps such as google/facebook, etc, but I’ll go into that more in a later report.
This means allowing access from accounts people already have.
Next Hard Fork
There also appears to be a date on the next hard fork. In fact, we are going to get a couple in a small window.
We’re planning to release 1.27.7 sometime in July (probably near the end of July). As part of this release, we’re also setting what we expect will be the final “trigger date” for hardfork 28: September 24, 2024 at 14:00 UTC (to allow a little time after the upcoming HiveFest in Croatia).
September 24 seems to be the date that was selected.
We also get this:
We plan to first implement support for BLS in the new WAX API library, where it will initially be useful for 2nd layer apps, then assuming we find no problems, add support for BLS in the 1st layer (in HF 29, which is scheduled for a relatively quick release after HF 28).
For full details of the check back to the two articles linked at the top.