Blockchain App TCO
A thought exploration by Jacob Gadikian
TCO refers to total cost of operation, not total cost of ownership. No one owns a blockchain, they are alive and they pay humans for the things they need to survive.
Claims
- Blockchains mediate communities
- Blockchains are alive
- Blockchains have vital signs
- P2P Network Activity → synapses passing between neurons
- Block Production → pulse
- Node Count → cellular division
- Blockchains eat to survive:
- Human time
- Software development
- Operations
- Integrations
- Exchanges
- Apps
- Community building
- Governance
- Servers
- Validators / Witnesses
- Full and seed nodes
- Web interfaces
- Human time
- Blockchains have vital signs
Ideal Blockchain Organisms
The ideal blockchain organism has a low total cost of ownership because low TCO makes it more robust, decentralized and survivable. The ideal blockchain organism consumes as little human time and machine capacity as possible. Low total cost of operation ensures that a blockchain application can be effectively decentralized.
High total cost of operation prevents this from happening because the blockchain depends on a particular core set of individuals or even a single company for its survival because those individuals are typically writing code and running machines to ensure the continued operation of the blockchain community. The more centralized a blockchain is, the more acceptable a high total cost of operation is.
Security and economic problems in software become ways to harm the blockchain organism by increasing total cost of ownership. Time is finite. If your blockchain organism's opponent can run its humans out of time effectively, the blockchain organism may die.
Well designed API interfaces generated with a system like Swagger or postman for easy development and generation of client libraries reduce a blockchain's total cost of ownership while making it easier for that blockchain to expand its economic footprint through software integrations.
Liquidity is a core requirement of healthy blockchain communities. Without access to liquidity, a blockchain can starve and die because it is not able to purchase the time of humans for upgrades and servers for its continued operation. Today it is possible for a newly launched blockchain to have several near instant sources of liquidity:
- Uniswap via RenVM
- Cosmos IBC
- Other DEX integrations
- Coinbase Rosetta
DEX integrations make a blockchain organism far more robust. Exchange integrations that are programmed instead of being purchased are much more powerful and durable than CEX integrations. volume on decentralized exchanges is never faked because transaction fees make fake volume impossible.
Technologies like IBC, Rosetta, and RenVM ensure that the blockchain organism cannot starve, and should be default features of any healthy, competitive blockchain organism.
Evolution
Organisms that do not evolve are not as competitive as those that evolve rapidly. Consider humans: is it better to be a fast learner or a slow learner?
Every existing blockchain is a slow learner when compared to traditional software.
Today, no matter what blockchain framework you use, upgrades are either relatively difficult (Graphene, Cosmos, Scorex) or done on a layer of abstraction above the blockchain itself (Polkadot).
Baby Blockchains
A baby blockchain is a blockchain that rapidly evolves to:
- Defend against threats
- Attacks on a blockchain can kill it, so it is a good idea to ensure that your blockchain is well armed.
- Expand its economic footprint
- A blockchain must buy resources from humans, so evolving to have a larger economy is vitally important to the well being and survival of a blockchain.
- More effectively serve its community
- POS blockchains mediate specific communities, and communities evolve over time. Therefore, blockchains must also evolve to meet the communities needs.
A blockchain community may wish to launch as a baby blockchain and rapidly evolve to meet the needs of its community.
Less is more
In a public blockchain, every piece of software and every feature creates additional attack surface area. The best approach here is to carefully define a minimal set of features that are necessary for lunch and ship nothing more than that.
Principles and guidelines
- If your blockchain takes 15 minutes to compile, then that you're going to spend 15 minutes x 500 compile attempts compiling it.
- That everyone in your community who attempts to compile it will have the same problem and this will hinder adoption by developers.
- If an API interface is a little bit funny and doesn't strictly follow standards so it's hard to generate clients for different programming languages, the community running the chain pays the cost because it will not win integrations and attract developers easily.
- Always generate your APIs
- If compiling the chain is difficult, it is harder to onboard new developers.
- The first build is the most important so you should make it extremely easy.
- If the default front end and the chain are loosely coupled and it's difficult to run tests of the front end against the chain, you lose that rigor.
- Monorepos encourage thinking of the product as a whole thing while preserving some segmentation.
- If the failure of servers run by the core team results in inaccessibility of front end interfaces or APIs, then your chain is not sufficiently decentralized.
- Try not to have a core team, it is a weakness. Launch a chain with a group of people who have all of the needed skills and are drawn together by the community that you'd like to build.
- If an average user can't run a node and easily interact with your blockchain, then your chain is not sufficiently decentralized.
- Running a full node or validator should be as easy as possible.
- If your chain is difficult or risky to upgrade, your software development process will slow significantly after launch.
- Experiment with upgrades before launch and create a secure process for upgrading your chain in production.
- If there isn't a robust governance process controlling chain upgrades, your chain will be at risk for hostile takeovers.
- Upgrades should be approved in a stake-weighted fashion, not just implemented by validators/witnesses at their option.
Summary / Conclusion
Blockchains are alive. Like all living organisms, they compete, and more efficient chains will inevitably win. Primarily, blockchain organisms consume two resources:
- Time
- Money
Healthy Blockchain Organism
- High economic value
- Well-compensated validators
- Engaged community
- DEX integrations
- Rosetta and Blockatlas
- Tightly defined API
- Zero Configuration
- Quick Compile Times
- Tightly-coupled UI
- served by full nodes by default
- covers all API endpoints
Interesting to see it all laid out like that @jacobgadikian, thank you.
Blockchains — and that would include Blurt — remain in their infancy. As I see it, we are still in a place similar to the early days of the Internet, itself. A lot of people were putting a lot of effort and energy into "the Internet" in hopes of it bringing value... but the Internet (the structure) offers only a tiny fraction of the value of what you can DO with the Internet.
With blockchains, we are at that same critical point where simply saying There's a Blockchain! excites people... we have to answer the question "yeah, but what does it DO? How is that USEFUL to people?"
It was only 20-ish years ago a bunch of hopeful investors and developers learned — the hard way — that simply saying "we have a web site!" doesn't amount to a hill of beans unless you can DO something that a lot of people are interested in, with that web site. An estimated US $1.7 TRILLION worth of "value" was lost in the dot-com bust, most of it because people were concerned with the "thing" rather than developing the utility of the thing.
So, at least from my perspective, the first questions have to be WHY are we building this? Why does this EXIST? How do we make that purpose come about? WHO is interested in that purpose? How do we reach them?
Otherwise we're just building an amazing car in a garage in a village with no roads...
Definitely an important topic and discussion!
Speaking is one of the people who helped build blurt, I can tell you that we built blurt because we loved steem and we thought that something better could be created.
Along the way, we inherited many of steem's problems. It will take time, but those problems will be addressed.
That is definitely a worthy goal! I also loved the early ideals of Steem (or "Steemit") and wish it had gone in a different direction... so Blurt is a brave experiment to find that direction, perhaps.
As you mentioned in your comment to @offgridlife, you find yourself in the position of being Blurt's "patron," which is expensive. In some ways, that is the nature of pioneering, which is basically what we're doing here... this is new territory in many ways. Thus, patience is essential.
So the challenge is how to make Blurt self-sustaining, so you are not footing the bill.
As far as I can figure, that leads us to commerce. Various attempts were made on Steem and Hive to create some version of peer-to-peer marketplaces... be that initiatives like "SteemBay," or "Homesteaders Co-op" or the "Leo Shop" (still active) or even the Splinterlands marketplace and others.
Although it is a way to generate funding, it also meets with some resistance from those who perceive using the blockchain as a "market maker" and collecting fees sounds "too centralized."These critics seem to conveniently "forget" that it costs money to someone, somewhere, to keep the chain running.
I have to easy answers to that... but we need to keep exploring.
Let the complainers put up the cash then. No matter how you look at it things cost money to run. Until we are 100% crypto funded ... we still need Fiat. Let’s generate some Fiat with places like HideoutTV , Youtube, Adsense, Publish0x, and Amazon.com to generate Fiat to help run Blurt. That’s what I’m doing.
I certainly don't mind being Blurt's patron-- but in order for it to be healthy, it cannot depend on me.
Interesting idea, just I do not think I understand fully, lol.
The less a blockchain costs to operate, the more independent and decentralized it can be.
Thank you for explain, it is more clear to me now.
@jacobgadikian thank you for sharing this information. I highly agree on liquidity requirements for this young project to be successful. The more exchange listing, the more visibility and success going our way.
If blurt get listed on Coinbase, that's gold. I hope to see this happening very soon.
Cheers,
@Yehey
Hopefully the micro payments to post, comment, upvote will help cover the Cost to keep Blurt going Forever. I think it’s an awesome upgrade to how things work here.
They don't.
Blurt is underwater.
You can think of me as Blurt's patron, to the tune of about $500/mo-- and god only knows how much when you consider the time.
But, blurt can be fixed, and this approach can lead to more prosperous blockchain organisms overall.
Could you add Adsense to people’s posts if they opt in ? I make about $50 a month from Adsense on Youtube. It helps. I would let you add Content related ads to all my posts if it could help out.
You should create a Blurt Channel on Youtube.... ask everyone to Subscribe. As soon as you hit 1,000 subscribers you could monetize. You could also monetize any videos with HideoutTV ... I get $200 a month there.
How about set up as an Amazon.com associate and add Content related Amazon Ads at the end of each post for those that opt in.... Something like this... https://blurt.world/photography/@offgridlife/photography-stormy-day-on-the-lake
These are all good ideas, but I should tell you that my favorite idea is adding commerce capabilities to blurt.
I would also like to figure out how to do ARM64 cross compilation for blurt so that we can move validation (witnesses) to the edge of the network (edge == people's homes and offices). I recently put this together for Cosmos SDK based chains, where validators can run on raspberry pi devices. It works quite well.
Also, in the long term I prefer solutions that do not actually involve me. I am concerned that my death could kill blurt. I don't plan on dying of course, but people die or get sick or have various troubles and the chain should not rely on any one individual. It is stronger that way.
Maybe we should get a conversation going on this topic because I think it's important to ensure that Blue is an independent entity. It is alive and it shouldn't need me (or anyone else) to survive.
My wife is working on selling her jewelry here with Blurt.
I will build a huge Artist community here on Blurt and through billions of original art posts the Blurt micro payments for posts, comments, votes should skyrocket.
Agreed. Yes Blurt needs many backup drivers.... I wish I had a few hundred Bitcoins to sell and help you. I will continue promoting Blurt like crazy to increase the micro $blurt you receive from every post, comment, vote etc etc....
Just to be clear the problem isn't actually lack of money. I can certainly afford blurt's upkeep costs, and I do not mind paying them.
The problem is that those costs are caused by a bad structure that assumes that there is a core group backing the blockchain.
Blurt cannot afford to lose me, And that is a problem.
Also, to be clear, blurt the chain would be fine without me-- just not any of the public facing wevb properties with the exception of blurterr.com
this can be fixed :)
The chain should not depend on an individual, or it is not decentralized.
Just so you know the action plan here, is of course not to abandon blurt at all In fact to carve out additional time to work on some outstanding issues and lessen blurts dependence on me by engineering more effective solutions.
I am honored to be Blurt's patron.
oh and I just realized that you're talking about the transaction fees that flow to one of the foundation controlled accounts. In fact, I wish to burn those fees instead of transferring them to a foundation controlled account because that is a far more decentralized solution.