7 ms·
The biggest issue I see right now is with organizations trying to jump on the blockchain bandwagon but controlling all nodes. If control of your blockchain is
by mi100hael 8y ago
The biggest issue I see right now is with organizations trying to jump on the blockchain bandwagon but controlling all nodes. If control of your blockchain is centralized, it's no better than an ordinary database. The benefits come when control is decentralized because you can still trust the data hasn't been tampered with.
- fiatjaf 8y agoI don't think that has ever happened in serious cases, but for all enterprise people who ever thought about it, Plasma is the solution.
- zik 8y agoExactly. Blockchain is genuinely radical - but its primary benefit is trustless decentralisation. When a single entity controls all the nodes then you don't have decentralisation any more and you might as well just use a conventional database. The real problem here is organisations jumping on the bandwagon without really understanding what they're doing.
- st26 8y agoWhich is my biggest issue with most mainline coins, I believe they will ultimately incentivize centralization.
- quickthrower2 8y agoYou'd probably implement something "blockchain-like" in the database to get the same benefits, such as not being able to go back and delete old transactions.
- thespirit 8y agoAs someone presented with a startup that needs an "append-only" transaction database with consensus across 2-N servers (depending on scale), and an inherent incentive to exploit any potential "double-spend" issue, an internal blockchain with a single node acting as an authoritative "miner" (aka, controller) seems pretty cheap to roll out considering I can just modify existing bitcoin/blockchain software. Is there any software out there that I could readily adapt to provide the same properties and guarantees without incurring hundreds of hours of development and testing?
- jakeinspace 8y agoMaybe look into datomic
- kybernetikos 8y agoThis is the right way to look at it I think. I've been looking at a blockchain based solution recently, and there has been an awful lot of negativity, and people wondering if it would have been possible to implement the same solution with an oracle database. Well, yes, it would have been possible. There are a couple of minor things the blockchain does better and a couple of things it does worse for this use case, but fundamentally, I believe the blockchain based solution was cheaper to build and will be cheaper to maintain. People need to consider these solutions in the context of whether or not they solve business problems effectively, and put aside knee jerk reactions based on technological prejudices.
- icebraining 8y agoWhy was the blockchain cheaper to build and maintain compared to a traditional RDBMS? I agree that avoiding knee-jerk reactions is good, but I frankly have yet to see a case where it was actually the best solution, except for the case of Bitcoin and other public cryptocurrencies.
- kybernetikos 8y agoBecause we wanted transactions signed with the key of the transactor and a complete audit history (ideally one that couldn't be tampered with, even by an admin). By using ethereum, we didn't need to write microservices to front the database, we didn't need to configure the database (not trivial if you want serializability https://blog.dbi-services.com/oracle-serializable-is-not-serializable/ https://blog.dbi-services.com/oracle-serializable-is-not-ser... ), we didn't need to write any cryptography code, we don't need to run any kind of infrastructure (let alone expensive, distributed infrastructure) to allow people to interact with and update the data. We get broadcasting of changes to clients so that the UIs can be kept up to date for free too. We do have to carefully audit our smart contracts, but they are much smaller pieces of code than the microservices and triggers that we would otherwise have written. Mainly, because our use case was similar to the crypto-asset tracking use case, there was a lot of code we could rely on already in ethereum that we would have had to write ourselves in the RDBMS world.
- wpietri 8y agoI keep talking to people who don't seem to understand this, and I am having a hard time giving polite responses. It's not only no better than an ordinary database, it's worse in a number of ways, including not being boring enough. [1] Even if one needs trust that there's lack of tampering, publishing a real-time transaction log is in many cases sufficient, just as long as you're willing to trust that the central point is ordering transactions fairly. Which is fine in the case where there's a legal relationship between the entities involved. [1] http://mcfunley.com/choose-boring-technology http://mcfunley.com/choose-boring-technology
- komali2 8y agoDefinitely fine where legal relationships exist, but the whole concept of law as trust is being challenged right now, as our own countries break the very laws they exist to enforce. Edit: help me understand why you disagree
- whatshisface 8y agoThen the discussion revolves back to how insane it is that the central authorities in these schemes control the nodes. Either you can trust them (in which case they should use a normal database) or you can't (in which case you can use a coin that they don't control).
- komali2 8y agoI agree, that is insane, and defeats the purpose of using block chain at all.
- whatshisface 8y agoI think the issue people are taking is that they think you are overestimating exactly how much society has declined. The ABCs have special authorizations to essentially break the law, but that practice has not yet trickled down to the local politburo. It is not quite the time to call the stability of US-style contract law in to question. (Even though the attitude behind the special authorizations, namely "I don't care what happens just do something," will be what undermines it if ever anything does.)
- bigger_cheese 8y agoThe radical organizations I'm familiar with (Socialist parties) are big on centralization the whole aim of that current of thought is the centralization of power within the state controlled by the workers ('Dictatorship of the proletariat' to use the Marxist term for it). So from that perspective I don't think a centrally controlled blockchain is a big impediment - may even be desirable.
- panarky 8y ago> If control of your blockchain is centralized, it's no better than an ordinary database Sure, when Maersk uses a private blockchain to track shipments, it's hard to see how it improves on an ordinary database. But let's say you want to build a prediction market for official corruption. The minute you start taking bets on which government officials are taking bribes, you'll have a powerful people trying to take you offline. It's extremely difficult to build a completely anonymous and decentralized application to do this, but decentralized nodes with anonymous validators that you control is a potential hybrid that's resistant to censorship.
- Scarblac 8y agoI'd be much more afraid of powerful people trying to frame non-corrupt government officials for the betting money.
- slfnflctd 8y agoAgreed, the problem with any anonymized system which attracts lots of users is, it creates incentives for bad actors to game the system. Feel free to think up all the rules you want to prevent this, but a motivated entity can always simply pay large numbers of people to act on their behalf. If they're good at it, you won't know until it's too late. Past a certain point, involving people's actual identities in the nitty gritty real world becomes increasingly necessary to establish trust. There are exceptions, but AFAICT they mostly rely on being uninteresting to would-be attackers.
- deleted 8y ago[deleted]
- danmaz74 8y ago> If control of your blockchain is centralized, it's no better than an ordinary database Actually, it's much worse from an efficiency point of view. Which means that all those applications are fad-driven. I'm sure there can be genuinely useful applications for blockchain tech, but for now the only truly compelling one I'm aware of is to execute unlawful transactions (I don't count speculating on the price - something I've done too a bit - as genuinely useful).
- nfin 8y agobecause of the yet still lack of privacy I am not sure that right now it is most compelling for unlawful transactions. There are many use cases (like you mentioned) and most are used only by a handfull of people, but growing by the day the more stuff getting developed (lightning, ...)
- grk 8y agoI think there are usecases where you control the whole chain and have nodes within your organisation. The blockchain becomes a specialised database that's optimised to be a ledger, something like https://chain.com https://chain.com and https://chain.com/sequence/ https://chain.com/sequence/.
- ballenf 8y agoThere's no compelling argument on those pages that addresses benefits over a traditional DB. It's the same circular arguments that completely ignore the tremendous cost of implementation and added complexity. Or did I miss something?
- mi100hael 8y ago> Or did I miss something? I've found myself asking that frequently with the blockchain/cryptocurrency mania. The answer has always been no.
- mike_hearn 8y agoI agree that at first this appears to make no sense. But there are actually good reasons for it, when you dig in. I work on a DLT/blockchain platform that has customers going live like this, so I'm closer to it than most people are. This is a little like how I used to not understand why banks or other large firms cared about blockchains at all - isn't the point to get rid of them? Then it became clear that the problem of individuals trying to sync views of balances over the internet without powerful middlemen is a scaled down (or up) instance of a more general problem that lots of firms have between themselves, trying to sync data between organisations. And that this is a legitimate problem to want to solve with peer to peer technologies. The main reasons you see companies deploying "blockchain but we control all the nodes" - an apparently nonsensical setup - are twofold: 1. They do want the ability for other orgs to run nodes in their blockchain network, or rather, some of their customers want the ability to run their own nodes and rely on the centralised firm less. But many customers don't care. They prefer to trust a centralised authority, at least given the current state of technology. Therefore, firms want the ability to decentralise selectively in response to demand. 2. They're doing a tech refresh. The world is full of financial middlemen who have platforms decades old that have been incrementally patched and upgraded over time, often with lots of customers. They decide it's time to do a rebuild onto more modern tech, but they can't justify a from-scratch rewrite unless there is a significant difference that can't just be bolted on to the existing architecture. Decentralisation is an example of such a change. By betting on blockchain tech now, they open up the possibility of totally new business arrangements in future that would have been blocked by centralisation/lock-in fears today. If you decide to make your existing business app selectively decentralisable - perhaps in order to unlock new features or products in an environment where customers are concerned about data sharing - then it makes sense that you'd maintain one platform, run all the nodes yourself and migrate users to it in bulk. You've opened up new options for yourself and if later the business winds change and you don't want to allow this anymore, OK, you have a slightly more complex architecture than a plain old SQL DB but modern DLT systems like Corda (the one I work on) map blockchain data through to relational databases anyway so you can still use a lot of the same tools and processes that you're used to. It's not quite such a huge leap as it'd have once have been. Why might some customers not want to be decentralised? A situation we see a lot is where a business or industry group wants to allow people to run their own nodes, but isn't sure the usability of taking part in a P2P network is high enough for everyone (or are sure it isn't). Remember that many businesses have very small or sclerotic IT departments, or no IT department at all, and peer to peer networks are historically associated with piracy, viruses, spam etc. So that + the prevalence of the web means that setting up anything that isn't HTTP to port 80, like a business P2P node, is considered to be a bit novel and exotic. Again, because Corda is designed for large firms it has features that help with this, in particular for really large and paranoid firms like banks where the internal IT departments don't always trust each other :) But ultimately if you're trying to pull off a major platform migration, you don't want it to hit the rocks if some users reject the idea of running local infrastructure and just want an ordinary web app. This exact problem is prevalent in the Bitcoin and Ethereum communities too. Many users don't run nodes or even SPV wallets. They just dump all their coins on an exchange and trust a centralised service completely. They could go full P2P but that involves small sacrifices like having to back up your private keys, so they choose centralised trust instead. The nice thing about cryptocurrencies is users can choose their own configuration. As a consequence of all this, a popular feature request for Corda and something we're spending a lot of time thinking about is how to split a node up, so parts of a node run in some cloud somewhere, and other parts run locally on e.g. a mobile or desktop app. For instance private keys and transaction signing could be done locally, with everything else run remotely - this is "share the my data but not my authority". In more advanced setups you allow people to migrate from hosted nodes to local nodes and back again in smooth automated ways.
- Scarblac 8y agoOne point I've heard is that some large organizations don't necessarily trust themselves (or all their employees). Then a bunch of nodes with a chain inside the organization might be harder to tamper with than a database.
- icebraining 8y agoIn that case, the blockchain actually makes it easier to tamper with, since the nodes will trust whoever mines the longest chain. If you just want to avoid tampering, you're better off with servers publishing (signed) messages and clients storing those in an append-only log; a good example are the CT logs: https://en.wikipedia.org/wiki/Certificate_Transparency https://en.wikipedia.org/wiki/Certificate_Transparency