Some time ago 
The promise
A lot has changed since the early days of Bitcoin. The innovations tied to crypto are enormous, their adoption also grew aside mere "price go up". But it looks like something might have been lost in the process.
"Be your own bank" - that was the phrase connected to the crypto from the early days. But what does it mean?
Clearly it is not about keeping a stash of gold and other valuables hidden in a place where no one can take it away from you. The treasure has value only if there are other people that want to exchange that treasure for the goods they produce and services they provide, and when there is a way to actually make that exchange (directly or indirectly). So being your own bank is inevitably tied to other people through some financial system, everyone just wants that system to work in their favor. People are different though - some are very wealthy, some are poor, some want to take risks, others prefer safety, some are knowledgeable in financial or technical matters, others have other interests and don't want to need to be IT experts to just spend some coin, some move their funds a lot, other just put them away for couple decades. So the system to work in everyone's favor needs to be safe, cheap and easy to use, and it needs to have little to none counterparty risks. Even if one decides they want to use it via a proxy (because they can't be bothered to do it themselves) it is still beneficial to them if they are not bound to a handful of powerful corporations that traditional banks are today. Let's see different aspects of banking:
Banks follow rules. Clear rules mean predictability and confidence.
Banks not just keep, but multiply money.
Banks keep their own records. They don't need to rely on external services to tell them what's in their books.
Banks are a utility - other businesses use them as a service.
Finally, banks keep things private.
Let's examine each point in the context of crypto. Why are those points important and how much of the "be your own bank" can an individual really achieve in today's blockchains.
Governance
One of the aspects that didn't change from the start is openness of the source code of blockchains. With AI even more people can actively check whether the rules of particular chain make sense and are properly implemented. Same goes with tools that are used to actually interact with the chains.
The openness has no practical impact if one group of people holds exclusive rights to apply the rules and also make adjustments to the code - someone else is enforcing or rewriting law and you have no say in it. Transaction exclusion is within natural rules of all blockchains - not all valid transactions will make it to the blocks, for various reasons, technical or deliberate censorship, it gives block producers power over individual users, even if no changes to the code are ever made and they all run only official code. Even if that power is widely distributed, but limitted to large corporations, it is still not comfortable situation. Such entities are easy targets for external pressure (f.e. regulatory from governments), their interests might not align with interests of smaller holders. While reviewing this aspect of blockchains we'll be looking at who produces blocks, who decides who can be one of block producers and what are practical limitations of that decision.
Important aspect of block production is the incentive structure - does blockchain reward producers correctly in relation to the requirements put on them? The higher the costs or knowledge and time required, the greater the reward needs to be. The opposite is also true - blockchain can be run solely by enthusiasts if it is very cheap to run. If incentives are not alligned, there is a danger of the chain stopping entirely, or that producers will seek revenue elsewhere, which decouples their interest from interests of the blockchain and its users.
There are many potential barriers: financial, hardware, knowledge and time commitments. An example of financial barrier would be the need to hold large amounts of costly tokens in PoS chains in order to become block producer. A hardware barrier is f.e. the need for specialized equipment for mining in PoW chains, but also need for high end server to hold a producer node in other chains. Knowledge and time barrier manifests when blockchain punishes you for mistakes and requires constant uptime, which in turn means you are required to treat block production as a full time job. One could argue that it is a good thing that the task as important as processing and approving transactions, the very thing that makes the chain going, should be performed by people that have the knowledge, time and resources to do so reliably. But high barriers limit potential pool of block producers. The chain can however offer a way to eliminate or lower the barriers when it allows many people to come together to form or support a block producer - one that none of them would be able to become personally. At first sight it puts DPoS chains in advantageous position, but pooled mining for PoW, or delagation of stake for PoS are good mechanisms as well. The key is whether the mechanism adds counterparty risk, is the mechanism permissioned or permissionless, or how easy can you switch who you support in case you change your mind.
How does governance look in top chains?
Bitcoin:
No financial barrier due to PoW consensus - you don't need to hold any BTC to mine it. Hardware requirements are high though - the ASIC miners cost thousands of dollars and you need many (plus access to cheap electricity) to have any chance to actually mine a block. You can mine as a member of a pool, but in such case you don't actually take part in governance as you have no say in what goes into the block - you just lend your hash power to the actual miner (x). Also there is no built-in mechanism for getting block rewards - it is just a "gentleman's agreement", based solely on pool operator's reputation.
(x) There are alternatives showing up where instead of getting a block from the pool operator, you propose your own block - operator accepts it if it is valid and the coinbase transaction (the destination of block reward) is correct according to the pool requirements. Then you keep trying to mine that block. That way still does not fix a problem of reward distribution, but at least gives power over content of blocks back to the owners of hash power instead of concentrating it in a few pool operators.
The knowledge barrier is tied to proper hardware setup, not the chain code, as it is a world of difference if you just run your hardware "as is", or setup a heat exchange or other ways to make up for the electricity costs. With that kind of knowledge you can make it so you only mine when your electricity is free (when it would go to waste anyway).
Ethereum:
High financial barrier of entry - 32 ETH (~86k$). There are however mechanisms to lower it through use of contracts - you can passively lend your small amount of ETH to a pool that supports independent validator (Rocket Pool), or you can take active part with use of threshold signatures (Distributed Validator Technology). In both cases Ethereum only sees one validator and pays out rewards accordingly, which means you need to be aware of the details of the smart contract that governs shared validator. It therefore shifts financial barrier into knowledge (or trust) barrier, also switching between validators is problematic (you are shareholder of a specific pool, usually through some special token that might or might not be tradeable and/or pegged to ETH - you can't just take away the ETH you put in the pool to move it to other pool).
The hardware to run validator node needs to be solid, but still consumer grade PC. It means that as long as you have the capital, it is fully realistic (and used in practice) to solo validate at home.
Knowledge and time: it is always better if you understand what you are doing, but the process of setting up the validator node is standardized, so not that hard for people with average IT expertise. There are penalties for mistakes that harm the network, like double signing, so that needs to be taken into account. There is no need for extremely high uptime - you only lose on the opportunity to earn if you miss a block. You need to stay on top of the changes though, because if you fail to apply a hardfork, you won't be able to participate.
Solana:
While formally there is no minimal stake, that is misleading, because being a validator costs voter transaction fees. To cover those with validator rewards, you need tens of thousands of SOL in stake which is an enormous financial barrier. While it does not need to be your own stake (it can be delegated to you), it means that if you fail to attract enough capital, you'll be paying a lot (400-700 SOL / 45k$-80k$ - a year) to keep being a validator.
Hardware requirements are outrageously high, and the requirements on network throughput make it impossible to not have the node in a high end data center.
Knowledge and time: full time high end devops job for multiple people, full coordination with other validators required in case of incidents, high rate of new releases.
I've mentioned that the stake does not need to belong to validator. So how does the situation look like from perspective of a person that has some SOL and want to delegate it to someone that does all the work? It is actually quite decent - all the staking is permissionless and built into protocol. The actual validator takes some commission (typically couple percent to even 10% but can be anything between 0 and 100%) and the rest of the reward is split among delegators. If you want to remove your support (because validator misbehaved), it takes couple of days (to unstake), but if you just want to regain your capital, there are services that offer to buy your stake account for a certain fee, so if the fee is acceptable, you can be out pretty much instantly. The stake remains yours all the time, validator has no control over it at any point.
Cardano:
In theory there is no minimal stake, however in order to be allowed to produce block, you need enough stake to push probability of being chosen above zero. The stake requirements are high, but typically most of it comes from delegations - block producer's own stake only serves to attract delegations (and has some tiny influence on rewards).
Hardware requirements are pretty relaxed, low grade consumer PC is enough. Same with knowledge and time, probably the easiest of all big chains.
From perspective of a delegator - you need to pay a tiny and refundable stake fee, select a validator to support, looking at their declaration of costs, margin and pledge (the stake that is owned by validator). Those parameters will affect your rewards for delegation (costs and margin are covered before the rest of rewards is split among delegators and pledge in proportion). The process is permissionless, however there is a mechanism that promotes delegating to smaller pools (oversaturation). Delegated funds remain in your control all the time. You can regain delegation quickly, but it takes several days for the delegation to fully activate (start to generate rewards), so that's the time (and cost of missed rewards) you realistically need to switch between validators.
Other chains:
During research Claude got me info on chains such as BNB, Polkadot, Avalanche, Cosmos, Aptos, TON and Tron, but for those chains situation is pretty similar in at least one aspect to above - institutional level of capital, hardware and/or knowledge and commitment. BNB is even de facto permissioned.
Hive:
In order to become block producer (witness), you only need to register as one - no stake required. Even with just your own stake you will eventually be selected to produce a block, it just might take a year or more. However since it is mostly predictable (how fast you move in the queue in relation to other witnesses depends strictly on votes - read about the mechanism in article about the time we've made a bug in it), technically you don't even need to be running a node at all until it is near your turn to produce a block. How "near" depends on how fast can you make it to the top of the chain - on modern hardware replay from scratch or sync with checkpoints takes below 10 hours, on decade old PC it might take a day, couple days if you are running some low end mini-PC. You can also use snapshots provided by other witnesses to speed up the process.
There is no hardware barrier. The speed depends mostly on single core performance, but even Raspberry Pi with 8GB RAM or old smartphone is enough to run a witness node (there is pretty much no difference between regular node and a witness node). And we didn't even tell the last word when it comes to optimizations, so you can expect the requirements to lower even more in the future. You might think it is because the chain is underused - true, but we know (and test) its behavior on high traffic.
I might be biased, but I think Hive is pretty straightforward to setup and use, no knowledge barrier whatsoever. To be a good witness, the one that can attract delegations, so you can produce more blocks and get more rewards, that takes more, both in terms of knowledge and hardware (take active part in HIVE price oracle, provide seed node, host some API nodes etc, also show up on meetings and conferences, write a blog - be visible to potential delegators). But the bare minimum is such that anyone can be a witness. And if you fail to produce a block you only lose on the reward of that block.
Most hardforks are years apart and it is a big event when one approaches, so it is hard to miss the info when you need to update your witness node.
Hive is a Delegated Proof of Stake chain. While there are stake delegations, they are not connected to block production. Everyone can vote for up to 30 witnesses (and that is just a technical limitation - in principle you could support unlimited amount of witnesses). 20 witnesses with most stake plus one runner up produce one block each every 21 time slots (63 seconds) regardless of how much stake they have or how many people vote for them or with what voting power. All top witnesses get the same reward, runner ups (as they change with every schedule so effectively produce a lot less blocks) receive even bigger reward for block. The rewards are not shared with people who voted (there were such arrangements in the past, but they were frowned upon by the community). Votes can be swapped to other witnesses at any moment but they will only affect selection of new witnesses for future schedule when current schedule ends. Since there are no rewards for voters, you don't lose anything while switching to other witnesses. By the way, if you can't be bothered to monitor witnesses to vote for (or you have multiple accounts you'd like to vote as one), you can use proxy mechanism to designate some other user as the one that actually votes (you basically automatically vote like they do).
Becoming top witness is very hard in practice - you need to attract a lot of votes. Unlike in legacy chain we forked from, Hive has no monstrously oversized stakeholders with enough voting power to single-handedly select top witnesses, which in itself prevents Sybil attack on governance - every top witness is a concrete person or group of people, widely known to Hive users, there is no way to sneak multiple accounts of a single person into top spots.
Investment
Let's say you have a 1000$ to invest. What opportunities exist to multiply that level of capital, preferably built into the chain itself? On purpose I'll omit the issue of speculation - changes in the price of token you need to acquire to operate on chain. For the purpose of this analysis we'll assume the price is constant across long time. Also all L2 solutions not tied directly to chain, especially those that leave your funds in third party custody, don't matter for this analysis, because they are no different than what traditional banking system offers.
generated with Ideogram
For most chains main way to invest is to delegate to validators and partake in their rewards. It was already described above, so where applicable I'll just briefly repeat main points from investor perspective.
Bitcoin:
No native ways to multiply bitcoin holdings.
Ethereum:
Only through smart contracts. With that level of capital you are out of option of earning directly as a capital provider for a validator (validator holds validator key, but you hold withdrawal credentials), so only the second layer solutions remain, which means you need to understand not just the protocol, but also the third party contract. Aside of Rocket Pool and DVT mentioned in paragraph about governance, there is Lido - one mega contract (1/4 of total stake) that you can buy into like you would buy a company shares. You get share tokens, the pool gets your ETH to finance validators. The share tokens are liquid, you can trade them, but it also means extra layer of price slippage you need to take into account, or alternatively you can "unstake" but you need to wait days in the queue. Additional issue of Lido is its concentration, by investing that way you are adding to the problem.
Solana:
Very good way to invest built into protocol. Your only risk is when validator that you supported missed a block - you are not getting rewards for that. No minimal capital required, you know upfront about the commission the validator takes, all the fees that validator needs to cover are their problem, not delegator's. Exit takes couple days. There are also third party solutions (Marinade, Jito) that offer liquid staking, but it has the same problems as in Ethereum.
Cardano:
Just like Solana, Cardano has investing through validator delegations built into protocol and fully automated. In this case however validator's cost and earnings (margin) are taken out of rewards before rest is distributed. Those are public values though, so just choose validator accordingly.
Cosmos chains:
Instead of keeping control of your funds, you are putting them in bonded pool - a mechanism built into protocol that manages those funds. The funds are subject to potential slashing and downtime penalties. Exit takes several days while your funds are still susceptible to slashing. Rewards need manual claiming, which means transaction fees will dip into them.
Polkadot:
There is a trap for small investors - when you delegate too little (called nominating there), you are bonding your capital and receive nothing in return (your nominated validator might not be chosen, not produce block so receive no rewards - that is normal, but on top of that, you need to be selected as active nominator and even worse, only limited top nominators for active validator receive any rewards). There is however a built-in mechanism for small investments: a nomination pool. Such pool acts as a single bigger nominator (controlled by pool operator who decides on nominations) and once it receives rewards, they are distributed among contributors. Note: pool might be taking commission on top of validator's commission. The biggest risk is very aggressive slashing - if you nominate a validator that confirms invalid transaction you can lose all capital. But even smaller mistakes can result in large penalty in case multiple validators from the set you nominated do similar (coordinated) mistake close in time (and that might happen in practice f.e. when they shared the same invalid configuration). The way slashing is performed is scheduled to change though (or was changed already recently) - nominators' stake is to not be subject of slashing, only validator's own stake.
Polkadot has relatively long unstaking time - 28 days.
Avalanche:
Minimum required capital - 1000$ is at the edge of that requirement. You pledge your capital for the time you need to chose upfront - 2 weeks to a year. Limit on who you can support - validator can only have at most 5 times their own capital delegated to them, so good validators are likely to be full, even though formally the system is permissionless. Also percentage based delegation fee.
Hive:
Voting for witnesses does not give any rewards, but there are other ways for protocol to multiply your capital, both in passive and active ways.
First, you can turn dollars into HBD (well, not directly) and put them into savings. Witnesses decide about interest rate. It takes 3 days to free funds from savings balance. You can claim interest by moving any funds on your HBD saving account after 30 days from previous claim. Personally I find that mechanism completely wrong for many reasons, but it works. HBD is bound to the value of dollar, but sadly hardly any exchange allows for such swap directly (to asset backed stablecoins). In practice you need to convert HBD into HIVE of equivalent value over 3.5 days (and price of HIVE is determined by witness oracle) or use internal DEX to do it quicker (but that depends on liquidity at that moment) and then sell HIVE. There is safety mechanism built into protocol. When price of HIVE (as reported by witnesses) is too low (or to be more precise, when HIVE equivalent of HBD in hands of users compared to actual HIVE is too high) then that price is corrected - HIVE is treated as if its price was higher than it actually is, which in practice means you won't be getting one dollar worth of HIVE for your HBD in such situation. It is to prevent HBD holders to get dangerously high amounts of HIVE during conversion which could jeopardize governance when subsequently used for staking and witness voting. It is not strictly theoretical - previously, when the safety margin was much lower, there were times when that mechanism activated (what is the marginal price for the activation and how far Hive is from that can be seen f.e. here).
Second option is to stake HIVE. Unstaking takes very long time - you get 1/13 of your staked capital every week for 13 weeks, but you retain benefits of all the parts of the remaining stake except the one that is for current week. What do you get for such long pledge?
First, part of inflation is added to vesting fund which increases value of staked HIVE (VESTS/HP) over time, a completely passive income. Stake also gives you voting power - not just voting for witnesses or proposals, but voting for content. Hive is a social media blockchain where users post their articles, comment on them and vote to reward the most engaging / best / their choice content. The rules were changed over time, but currently half of reward the content gets is split among those who voted for it (not directly in proportion to voting power used, those who discovered the content and exposed it to others, namely the ones that voted during first day, get bigger reward than those who came later). It is more engaging, but since reward pool is 65% of inflation (as opposed to 15% for staking), half of it gives more than twice the potential for earnings, even more if you consider that not everyone uses their voting power in full. There is a catch - if you vote late, or vote for content that gets downvoted (there are many reasons, some legitimate, others not so much), your earnings might decrease. Some people use scripts to follow votes of others, or delegate to voting pools to get share of rewards later, but that's outside protocol.
Finally you can earn with no capital at all. Hive is one of a few blockchains you don't need to buy into. Instead of capital you can allocate time and commitment. If you create content that attracts votes, you'll get portion of the other half of reward pool. I'd say it is far easier to earn "something" on Hive than on Web2 social media where you might be rewarded for views, but where minimum reward is a barrier that is hard to cross, where you are subject to censorship and are basically at the mercy of a corporation that runs that Web2 app. Some people try to exploit that feature - don't be such person if you don't like downvotes and ruined reputation :o)
Own node
Let's say you want to keep the chain honest by yourself, you don't want to rely on someone else to do the validation for you or tell you where the funds are. If possible you'd also like to be able to see history of the chain from your own source, at least for selected accounts/addresses or within limited recent time window. Finally you don't want to rely on others when sending transactions to the network, f.e. because public API node can track your activity or censor you, it might also turn out not to be available when you most need it. Is it even possible to run your own node at home? What about other basic services? Can you validate whole blockchain from its genesis or you have to trust some snapshot of history? How long does it take to setup and replay a node?
source: 
Note that it is not automatically impossible to run a node just because you can't be a validator on consumer grade PC. Validators might have a lot more to do, they might also be bound by time constraints in much stricter way than regular consensus node.
Bitcoin:
A golden standard. Consensus node is easy to run, well documented, there are ready distributions. Runs reliably on mini-PC or even Raspberry Pi, 8 GB RAM is more than enough, space requirements are very reasonable for such long running blockchain (~700 GB) and it can be reduced because pruning is supported. There is also ready to use database optimized for typical questions users might have about balances, history etc. (Fulcrum) that needs 100 GB extra for indexes. Synchronization from genesis takes couple of days at most (a bit more when you are also filling Fulcrum). Base node comes with cli wallet, there are other more sophisticated wallets that you can run locally as well.
Ethereum:
Situation here is more complicated. Since "The Merge", when Ethereum switched to PoS, there are two separate layers - an execution layer (the classical part that runs transactions and computes state) and a separate consensus layer that tracks stakes, decides who is a validator, finality of blocks, and most importantly which chain is the valid one. There are actually good reasons for that architecture, but it is not important for this article, except one thing: you can replay from genesis and have self verified state, but when reaching a block when switch to PoS happened, you still need an external source (preferably many that agree) to tell you which of potential follow-up PoS chains is the official one ("weak subjectivity"). From that point you continue validation on both layers.
Ethereum requires stronger hardware than Bitcoin, but that is understandable, since it does a lot more. 32 GB RAM, 2 TB NVMe, that would be a minimum, but better hardware gives faster sync. On average consumer PC sync can take weeks. If you are not fully paranoid, there is a light client (Helios) that is able to validate responses from external source - it can run on anything, including a smartphone, and is ready to work in seconds, but I can't say I understand fully what it actually does and how. Since it uses external source, you are still subjected to its potential tracking and availability problem, but at least you can be sure the responses are correct without having to run a node yourself.
If you want to host history locally, you have options: lighter Otterscan + Erigon, for personal use, or bigger Blockscout that indexes to PostgreSQL. Both solutions give you a block explorer functionality. It is possible to run it on a PC, but it needs to be high end one, especially fast and large storage is important. Size can be reduced with use of pruning.
Solana:
Absolutely not possible on home PC - hardware requirements are pretty close to that of a validator node, including 512 GB RAM and ultra fast connection. Syncing from genesis is not possible - ledger itself is pruned, so you always have to start from someone else's snapshot. It also means that there is no access to very old transaction history - you need to ask someone who indexed that information when the transaction was still fresh. No light client.
Cardano:
Better than in case of Ethereum - older/weaker hardware is ok (24 GB RAM, ~200 GB storage). Full sync from genesis is possible and takes couple days. There is also separate mechanism of using stake weighted signed snapshot - it makes setting up new node very fast (about 30 minutes), but you need to trust the stake holder(s) that confirmed the data.
Full block explorer can be run locally but takes a lot more space and time to sync (cardano-db-sync with PostgreSQL), or if you want just selected addresses you can use lighter solution (Ogmios + Kupo).
Cosmos chains:
Even lighter than Cardano when pruning is used. Sync from genesis is technically possible, but requires a lot of extra work due to necessity to recreate all the upgrades that happened along the way. Typically new node is started from snapshot and that requires trust.
Full history is very heavy.
Light client (CometBFT) runs on a laptop and allows for broadcasting transactions, keeps mempool, tracks validators, tracks order of transactions, block finality etc. but does not validate or execute transactions and has no state - in other words it verifies that proper validators checked and executed transactions, but not whether that check was run properly. Additional plus for that light client is that it is actual part of consensus - full nodes run it too, just do the other work as well.
Polkadot:
Requirements on similar level as Ethereum. Full sync possible, but typically warp sync is used, where snapshot is taken from peers and cryptographically verified against finalized state - it allows node to start running quickly, history is pulled later in the background (if needed). Used for light client (f.e smoldot - runs even in the browser), to allow verifying responses acquired from full node.
Hive:
Full node is pretty much the same as witness node, and since the latter runs on Raspberry Pi, so does full node. Synchronization from genesis is possible and takes 10 hours to days depending on your hardware (mostly single core performance). You also have an option to first acquire block_log (~600 GB) and then replay it with full validation (--validate-during-replay). Synchronization can be sped up if you use checkpoints (see the article describing it). Pruning is supported - you can run a node that has no block_log at all or only holds last couple million blocks. You can start node from snapshot and it is very fast, but it has a downside - not only it requires trusting the source, it depends on node configuration (some plugins add their own state) and also node version (any internal change in state representation means new version won't load snapshot prepared for older one).
I like the signed snapshot idea of Cardano - we need to do something similar for Hive.
Locally hosted history (account-history-rocksdb) is easy to set up and adds couple hundreds of GB for everything, or much less if you filter history just for selected accounts.
Hive is a social media network, so transaction history, while functional equivalent of what other chains offer, might not be enough for typical uses, you might want to host Hivemind (which entails HAF) that is source of data for various front-ends that present content posted to Hive. That is heavy (~4 TB) and demanding for hardware, takes days to sync, but you have everything indexed. Many front-ends are open source and available for self hosting.
I know that topic of pruning and filtering both HAF and Hivemind was discussed couple times, as far as I know it was also implemented in HAF at some point, but I'm not so sure it is an official feature at the moment. It is something I find really important though.
One more general note that might influence how you look at solutions that might require some compromise - less requirements for a bit of trust in external source of data. One of the aspects of that trust is the ability of rogue actors to fake content of the chain. Hive has a feature called TaPoS (on top of chain id) included in transaction digest => signature. It prevents replicating transactions in a fake copy of a chain (or simply forked version of it). You might scream "mirrornet" here, but even if it had the same chain id, the transactions on mirrornet would still be different, signed by different key and have different ids. So if you see the chain that has your transaction in it, at least up to the hight of TaPoS referenced block, the chain is a valid one (or more precisely - it is the chain you trusted once already). While that feature is not unique to Hive (transactions in Solana also refer to recent block hash - in that case it also acts as transaction expiration that is a separate data in Hive, Polkadot uses solution most similar to TaPoS), chains like Ethereum, Cardano or Cosmos only use chain id, and Bitcoin does not have even that.
Third party applications
Modern blockchains can carry custom data. For some it is a basic feature, but even Bitcoin, despite the outrage of maximalists, also allows attaching some data to transactions. Applications can utilize that feature getting open and distributed ledger of their application related events, ability to recreate history without having to host it themselves, allowing their users to do the same - it increases confidence, reduces risks and costs related to maintenance and customer relations. Plus the app gets a native payment network without extra effort.
How various blockchains look when seen from the perspective of an independent developer? What are the costs - mainly fees for both the app host as well as users, can user costs be covered by app related account through protocol mechanism? Are the costs stable or change wildly? What are the risks - does the chain work reliably, what is the chance the feature used by app will disappear in some future update? A question that determines app responsiveness - how fast does the blockchain work, how fast does it provide finality of transactions? Last but not least - how easy it is to develop with use of particular blockchain, are there any ready tools or you are on your own entirely? Is there a way to filter history to extract only what you need?
There are three models for apps. First is the base model: your app client needs to be able to send user signed transactions to the chain, your server might need to send responses there as well. All the history of application events is directly stored on blockchain. It is not always needed. If your app generates a lot of events you might choose not to send everything to the blockchain, just a cryptographic proof that validates what you later present to your users from your own server. That solution might be a lot cheaper (no transaction fees) and faster (you are not bound to pace of target blockchain), but it also puts more responsibility on you (you are the one that holds history of transactions, blockchain only contains hashes related to that history). Third model is a compromise - you provide your own distributed blockchain that you hook to main chain with cryptographic proofs. Some blockchains might already offer second layer side chains, in such case that model might be preferable.
When it comes to fees blockchains can be split into two categories - in first one transactions are included in blocks according to fee auction. Those are Bitcoin, Ethereum, Solana and pretty much everything else. Second one uses stake related bandwidth. Those are more rare. Examples would be Tron, EOS and of course Hive. First category not only increases cost of operating your app in base model (and somewhat limited in both remaining models), but those costs can radically increase in no relation to your app. The reliability is also a problem, because users might have their fee limit set at certain level, and those transactions will silently never reach blocks when fees that the chain demands increase above it. At least in stake bandwidth case when chain is overrun with traffic and bandwidth costs increase, users get a clear message about failure of their transactions.
There is also a question of who pays a fee. Is it possible for users to pass the cost of using your app to you? Surprisingly such solutions are very common, usually called paymaster. Out of big chains only Bitcoin lacks that feature. For stake bandwidth chains the bandwidth cost can be covered by app account through delegations. Hive has two types of delegations, you can delegate stake (VESTS/HP) giving your users all but governance power, but you can also delegate only related bandwidth (RC delegations). There is a third option - user might authorize app related account to use posting authority, that way your app can pay RC for user by including app key along with user authorization (however with that solution user loses certainty that they posted that transaction, since your app is doing it in their name).
One of the planned future features is a way to authorize others to use your RC. It will further extend list of ways in Hive for making app related account to pay for other accounts. The details are still vague though, since we might actually want to implement script engine and custom authorities first. There is also a too-long-in-development feature of L2 accounts (lite accounts), where app user signs with their key, but the actual Hive transaction is signed by the app and the user signature is part of the data payload.
Fee costs vary greatly and are also tied to the price of tokens. Not surprisingly cost on blockchains with top capitalizations is the highest - Bitcoin and Ethereum also have a history of large spikes in fee costs. With assumption of 100k transactions a month and 300 bytes of data payload, fee costs on those blockchains are in hundreds of thousands of dollars a month. Other big chains offer much cheaper transactions - monthly fees with the same requirements would cost you couple thousands at most on Solana, Arbitrum or Avalanche, low hundreds on Polygon or NEAR. Stake bandwidth chains have no fee costs and the stake required is recoverable.
Chain reliability might be critical or optional depending on what model you've chosen for the app. When chain goes down you might lose some data if the app sends events without buffering. Your customers might be angry at you for something outside of your control. In some cases you might even be legally liable.
The best we can do is to look at historical metrics, which of course say nothing about the future, but might help with decision which chain to use. Bitcoin and Ethereum are extremely reliable - they never stopped. Solana historically completely stopped for many hours fairly frequently, there were also times of very high transaction failure rates while chain was formally progressing. Nowadays some changes in the protocol made it a lot better in that regard. Cosmos chains had some failures during upgrades. L2 chains, like Arbitrum, also had multiple failures. Hive never stopped since it forked from legacy chain.
If high reliability is a must, then third application model (with a custom sidechain) is probably the best. When sidechain is provided by you, the problem is entirely on you, but you might distribute sidechain nodes across many different locations and your app won't have to compete with other apps for the same sidechain. If the sidechain is public (like in case of L2 chains), you have basically the same problems as with any other public chain, with the exception of high costs (because sidechains are usually made precisely to lower the costs).
When it comes to the reliability of the feature of being able to store data on the chain, it is rather certain in all cases. Only Bitcoin has a loud but small crowd that would like the feature gone, because it "allows shitcoins" on their belowed chain. I'm not sure if EVM chains are compatible enough to allow migrating apps across chains, but that might be worth considering. Hive on the other hand is so cheap to deploy, that in case of complete failure of the main chain, you still have the option of quickly setting up a private fork (with different chain id and change of witnesses - there is already code for doing just that from the time Hive split from legacy chain).
Finality is very important for any application that puts serious data on chain. Bitcoin offers only probabilistic finality, it is also very slow. Six confirmations are considered final in Bitcoin, but many applications take risk and accept single confirmation, because six means waiting an hour on average. Ethereum offers finality after several minutes, L2 chains based on Ethereum however offer instant optimistic finality (might not be enough for some apps, since it just means that sequencer promises to include the transaction when passing it to L1). Chains like Cosmos or NEAR finalize in couple seconds. Solana has finality within 12.8s, but upcoming (implemented already?) Alpenglow should drop it to ~150 ms with cryptographic proof. Hive achieves finality after 45 seconds during sync, but in live mode it uses One Block Irreversibility (OBI). That solution is basically what Solana is planning to do - witnesses exchange block confirmations without waiting for their turn to produce block (block acts as hard confirmation). The only two differences are: OBI is already implemented and works for very long time, second: Hive does not include OBI confirmations in blocks (Alpenglow in Solana is supposed to produce finality certificate out of validator confirmations).
How easy it is to filter out only the information your application needs from the blockchain? Is there any easy way to distinguish it from other transactions? Are there ready solutions? The question is somewhat related to what we've discussed already - how feasible it is to host private node and/or (filtered) history.
Bitcoin offers nothing, you need to scan OP_RETURN on your own. At least hosting a local node is cheap.
Ethereum has ready solutions for self hosting, especially if you are only interested in events from your own contract (Ponder). Reorgs (forks) are handled by frameworks. You could also rely on public RPC, but they tend to limit block range. L2 chains make it order of magnitude cheaper.
Solana is doomed in that regard, unless you only need recent data. It is because ledger is pruned, so you have to rely on external providers (which means dependence and cost) when it comes to historical transactions. There is no easy way of filtering, you need to handle forks yourself. The most convenient solution is to have your own validator and use Geyser plugin, but the costs...
Hive exceptionally shines in this category. Easy and cheap self hosting. custom_json operations are exactly designed for the purpose of custom data. Account history plugin supports filtering and you can ask it for all or only finalized (irreversible) data (not that it matters much with OBI). If you prefer PostgreSQL, the way to go is to run application based on HAF - whole framework built specifically for that purpose ("HAF of your work is already done"). If your application is small (because you just started and there is not much traffic related to it yet), it is perfectly feasible to use public nodes as source of data and only start self hosting once the app grows (the same API - it also means you can use public nodes as fallback in case your servers fail).
Existence of frameworks such as Wax (that reuses code of Hive node, so it is always up to date with the changes) allow for easy interaction with the chain and APIs.
Hive has one additional advantage. Since it a social media blockchain, your app not only gains access to financial part (presence of stablecoin in form of HBD is not unique, all EVM chains have much more used - despite blacklist/freeze features and counterparty risk - asset backed stablecoins), but you also have a forum to present your app, document its progress and releases, handle customer relations etc. If needed the application itself can publish data in form of comments.
Overall Hive rules for application development, but not without a catch. If you decided to use first model of application (all data directly on chain, user transactions independent of you), the greatest problem is onboarding. Hive accounts cost 3 HIVE, and while it is currently just several cents, with enough users that can turn into serious position in costs. Hive allows to create accounts for free, but it requires a lot of RC and number of available free account tokens is very limited. Claude also told me that for some applications, due to legal compliance requirements, having just 21 independent validators (witnesses) might not be enough.
Due to wide availability of known tools and potential of jumping between chains, any L2 EVM chain (Arbitrum, Base, etc.) with app related contract will be a good choice, despite higher costs, especially if chain brand is a factor. If financing for your app comes from someone else, that might be the easiest choice to convince nontechnical decision maker. Running directly on Ethereum L1 is only viable in second or third model (hooking to Ethereum with Merkle roots), first model fails on transaction costs (even if the app is still viable despite the cost, those are the money you could be taking for yourself, so L2 solutions win).
Privacy
All above mentioned chains (but Hive) offer pseudonymity. There is a multitude of techniques to track users despite lack of clear connection between addresses and a real person. You need to be an expert in them to know how to stay private (and yes, that includes self hosting node, because otherwise you expose connection between your IP and transaction). There are chains that have privacy built into protocol (Monero). Full privacy might not be always desirable due to legal compliance reasons, so some chains have strong privacy with a way for selective audit (Zcash). Chains that handle smart contracts have an edge, because while they might remain pseudonymous only, they offer more options for staying private, both within themselves as well as through DEX gateway to privacy focused chains. I should probably mention Secret Networks and Trusted Execution Environments, zero knowledge proofs but only as keywords, because this article is about Hive (in comparison to other chains) and Hive offers almost no anonymity.
from "A Scanner Darkly" movie
Hive is a social media blockchain. It is hard to stay anonymous when main function of the chain is to present yourself, your interests, your opinions and reactions to what others have to say. The focus of the chain is anti-anonimity. Sure you can make an account and never show yourself, but then you are only as private as in any MMORPG.
That being said, there was and still is a concept/plan of implementation of free floating balances. It would put Hive in line with level of pseudonymity of Bitcoin.
That concludes my comparison of Hive with other blockchains from various perspectives. The article was supposed to be understandable for people not familiar with Hive, hence some mixing of terminology (like "stake bandwidth", which is more descriptive than Hive specific term "resource credits") or talking about things obvious for Hivers.
There is still a lot of work to do in Hive, like above mentioned support for pruning on HAF/Hivemind, which in turn should make self hosting of related APIs viable (how many times did you run into a problem of "api.hive.blog does not work"?). There are more optimizations in the works, to make sure we don't explode even if traffic increases, in particular generalization of a mechanism of pushing least used data out of memory, which is needed to confidently implement f.e. free floating balances or custom authority. I'm particularly excited about script engine. Script itself is actually pretty easy to implement - we (part of