4 ms·
Found this less convincing than expected. They seem to mostly base the criticism on (a) it's cheaper to use non-blockchain equivalent for the use cases they cou
by zmmmmm 4y ago
Found this less convincing than expected. They seem to mostly base the criticism on (a) it's cheaper to use non-blockchain equivalent for the use cases they could think of, and (b) some point in the blockchain equivalent process generates a need to trust another party.
It seems to me that block chains will win at the things they are good for a bit the way git won at version control: decentralised systems just require lower overheads and less barrier to entry in general, so people just automatically use them.
It's fine to point at legacy use cases where all the trust relationships are already established. Those are living off fully amortised costs. But new systems do not have that benefit and for that context, you are faced with a proposition of having to set up a whole lot of new trust infrastructure and associated processes.
So for example, if you were setting up a library today and there were no pre-existing library systems out there. You might want to maintain a history of who borrowed each book, so you know who last had it. You will either have to establish a whole legal entity to become the owner of the books, electronic systems to track them and administer everything, and everyone will have to agree on its governance, who controls it and most importantly, trust them implicitly not to tamper with the transactions.
It'll be a whole lot of work. So why would you do all that work when you can opt for a block chain with literally no overheads?
- thraxil 4y ago> It seems to me that block chains will win at the things they are good for a bit the way git won at version control: decentralised systems just require lower overheads and less barrier to entry in general, so people just automatically use them. Git really only had an inflection point of adoption when Github came out and offered a really compelling centralized service. Before Github, there wasn't a huge drive to move away from SVN (there was some but it was more because the new decentralized ones were better in other ways besides being decentralized and fixed some annoying bugs that SVN had) and it was much less certain that git would win out over mercurial or bazaar or one of the others. My experience at the time was also that the decentralized nature of git/hg/etc was arguably a barrier to their adoption. Existing teams were used to a workflow with a central repository and it wasn't clear how you would replace that with these decentralized tools. You had to do a lot of work to come up with a new workflow for your team or you made a central server somewhere and tried to make them work as similarly as possible to a centralized system. I remember a lot of pushback on moving to git from people who didn't understand the whole decentralized thing and found it more confusing than what they were used to. And with Github, that seems to be the approach that the vast majority of the world has gone with. Yeah, you can use git as a fully decentralized tool and there are people who prefer that to using Github, but that's pretty uncommon compared to how many teams just centralize with Github.
- AndrewDucker 4y agoHow does a blockchain enable you to avoid ownership, tracking, and governance?