The Blockchain Application Stack(joel.mn) |
The Blockchain Application Stack(joel.mn) |
- Can this be replaced by a centralized database?
- If not why?
- If security / trust is a factor, what is the exact threat model?
The point is not whether it can be replaced by a centralized server the point is whether it's more powerful open than closed.
Personally i find that any system where everyone can become the the validator will always be better in the bigger picture than if they can't.
Digital Pokemón Cards. Basically the ability to create digital collectors items.
E-books that could gain value. You could sell ebooks at a premium and allow people to re-sell them. Because the history of their ownership is recorded you could even see them gaining value if they had been owned by a celebrity.
Private but public healthcare records for research and usage. Store the health-records publicly as personas but allow individuals people to link it with their identity. This would help with research in completely new ways.
Voting made public but anonymous Make it impossible to fake voting results by making the results available for everyone.
Artificial Intelligence Using the protocol to create automated consensus models.
Companies without owners Build a company with a political purpose without any owner.
To answer your question what's unsettling about this (and not in a bad way) that since so much of this stack is commoditized it becomes very hard to extract value where traditional software business do (20-50% cut rates, etc.) so it is much harder to be profitable, but at the same time it's much easier to bootstrap an application when you have access to an open pool of data.
I think it's an interesting dynamic that, if this turns out to be true, will really change the way software businesses work at the application layer. But I'm 2-3 posts away from doing a deep dive into that part of the stack – there's some things I'd like to go over first.
1. Accept payments in Bitcoin (obviously) 2. Assign Bitcoin address to every work. Timestamp it with a transaction upon publishing.
This 2nd point is the killer app. It creates provenance/citation (think patents or art work), and at the same time, a payment mechanism and publicly accessible account of fundraising totals.
All things needed by folks at universities, which is what Onarbor is aiming to become.
Disclaimer: I'm one of Onarbor's creators, so would love to speak more if you have any more questions.
Tricky to design an application around an API with multi-minute latency!
The cost of maintaining that blockchain is insanely high - all those giant "mining" operations. Large numbers of machines have to have a copy of the blockchain and track all updates to keep everybody honest. It takes about half an hour before a data item can be considered solidly committed. Even for Bitcoin itself, this is is an operational headache.
If all you need is a certified timestamp on something, several European certificate authorities run free trusted timestamping services. You send in a secure hash of something, they add a timestamp, sign that, and send back a reply.
That is the value. If you don't need these properties, sure, you don't need blockchain.
As for the maintenance cost: Proof-of-Stake is making interesting progress. There are initial ideas around not having an entire copy of the blockchain.
I'm not aware of commit-time reduction work, but would welcome pointers. (Either way, you'll always have a commit-time issue in a distributed system. You might reduce it somewhat, but it won't go away.)
You get more than that, you get a new social trust and consensus model that has never before existed. Eg, the ability for an indefinite number of anonymous, mutually untrusting participants to nevertheless agree on the state of a continually updating communal data source.
The tech is still in alpha stages, but is potentially powerful, and hence isn't cheap in terms of resources, and it shouldn't be. In fact, the big question and ultimate objective now is, is it possible to make the consensus system even more secure at the cost of even less efficiency?
> Sidechains is more than one-way or two-way pegging, and beyond Bitcoin Maximalism.
unfortunately time coinstraints prevented us from doing a deep dive
Bitcoin's liquidity and network effects, in a nutshell. I don't think a competitor will be able to match Bitcoin on those fronts. And it's not just about the developer and technology community, it's about the media, governments, companies, investors, regulators, financial institutions and even regular people who are getting used to the name Bitcoin.
But, honestly, it doesn't matter. This stack is blockchain-independent. Whatever blockchain or currency ends up succeeding in the long run doesn't take away from the fundamentals of this stack: decentralization of data and processes, cost reduction, and consumer power.
I focus on the Bitcoin blockchain because that's what the market has chosen to build on top of because there are no better alternatives yet. We'll see what happens if and when they come (e.g. ethereum), but I worry that it'll be too late by then and the market won't take it.
Also I think too many are focusing too much on the current state of Bitcoin instead of thinking about the potential.
The crypto-protocol is a product of 20years of research just the last 2 years alone we have seen a host of really intersting ways to improve it and make it less power-consuming.
Sidechains, Stellar and so on we have only just begun to scratch the surface and so I see no reason to be so negative around people trying to think about it conceptually.
But each to their own.
I have some doubts about your anti-Sybil attack measures:
* The more CPU my arbiter nodes can prove that I have, the heavier my arbiter vote. But at the same time, I can pretend to be many, many small nodes, which I'll program to side with my arbiters if someone challenges them as being corrupt.
* Can't I just DDoS the other nodes to increase the likelihood that my (sybil) nodes will be selected to be arbiters? I'll just attack nodes (or attack the request submitter) until you pick a quorum of my sybil nodes by chance.
* If all it takes to write to a DHT node is some user's signature on the data (that or an arbiter log; I'm assuming from your wording that one or the other or both will suffice), can't I just create a bunch of key-pairs for each of my sybil nodes and pretend to be a bunch of different users?
Regarding code:
* What steps do you take in the sandbox to prevent the (untrusted) code from denying service to participants? I could use some malicious code to deny service to other nodes (helping my nodes get selected to be arbiters).
* No entropy in the sandbox will limit the things you can do here. You can't (safely) do cryptography, for example.
Regarding storage:
* Have you heard of Permacoin? [1] You can have proof-of-storage without arbiters or a DHT.
* Even then, Permacoin is slow--way too slow for interactive I/O. So is Bitcoin. Your system will be slow as well, since you're not only replicating writes to a blockchain, but also you're funneling them through a handful of nodes that were chosen for their CPU, not their network connectivity. Note that you're writing multiple sets of entries per computation (the arbiter log), in addition to storing the results of the computation.
Regarding presentation:
* Outline your goals up front, as a bullet-point list.
* Outline similarities and differences with related work as a grid, with the set of systems as rows and the set of features as columns. This will make it easier for readers familiar with other systems to quickly grasp what your system does and does not do (readers will look to the text for clarification of the table).
* If you're constructing a protocol, you should consider adding a protocol diagram for both the successful case and the error cases. You should also show (or prove) that your protocol makes certain guarantees, if possible.
Hope this helped!
>At the same time, I can pretend to be many, many small nodes, which I'll program to side with my arbiters if someone challenges them as being corrupt.
I was already thinking about weighting each node's width on the selection surface, in other words making certain nodes more or less likely to be selected, based on the strength of their proof of CPU. That just didn't make it into this draft and should solve the problem you're describing.
>Can't I just DDoS the other nodes...
That would be a pretty powerful DDoS if it can take down enough of the network to leave your nodes as a majority. I don't think even Bitcoin could stand up to that either, since in theory it would let you launch 51% attacks. You do have a point that letting arbiters defer computation to any node of their choosing could be a problem, though.
>If all it takes to write to a DHT node is some user's signature...
All content on the DHT belongs to various user accounts. If the user is going to be able to deploy application content to their account element on the DHT, they will need to be able to unilaterally sign their content and upload it. It isn't possible to forge arbitration logs because it can be easily checked that the correct nodes were selected based on the hash of the initiating request, and also the signatures of the arbiters on the log can be checked to ensure they are who they claim they are. I'm not quite sure what you're trying to say with that last part.
>What steps do you take in the sandbox to prevent the (untrusted) code from denying service to participants?
Assuming the VM is secure, the only thing that you would be able to do is have nodes execute some extremely long-running task, but that would depend on you have effectively unlimited funds. So, if money is no object to the attacker, I suppose they could DoS the network, but at that point it would be indistinguishable from regular activity. Also, since it's not possible to select which nodes fulfil your request, you would inevitably end up DoS'ing some of your own nodes as well.
>No entropy in the sandbox will limit the things you can do here. You can't (safely) do cryptography, for example.
A lack of entropy is crucial for reproducibility of solutions. The VM would still have access to deterministic pseudorandom numbers, seeded by the request body, but any true randomness would break verifiability. Also, it wouldn't be wise to perform cryptography on the network anyway since the nodes doing the processing would potentially be able to peek at the data and also record the keys. VAPUR offers verifiability of computation, but not secrecy of computation.
>Have you heard of Permacoin? You can have proof-of-storage without arbiters or a DHT.
I looked into it. It seems interesting, though I'm not sure if it's a good fit for something like this. I'll have to think about it some more to see if I can work in something like it somehow.
>Even then, Permacoin is slow--way too slow...
VAPUR will be considerably slower than conventional centralized web services, though it should be possible for it to operate with speeds comparable to TOR, and potentially somewhat faster with enough optimization. Confirmation by the blockchain isn't required for requests to complete: that only occurs after the request is already completed and the nodes want to cash in on their work. I will need to put some effort into finding ways to make the data stored more compact, however.
>Regarding presentation...
I completely agree. I threw this paper together in a fit of inspiration and only did some minor editing. I just wanted someone else to check what I'm doing before I put too much work into a dead end.
Anyway, thanks again for the feedback.
Benefits from being distributed, but can use a simple, trusted timestamping service given the low stakes.
> E-books that could gain value. You could sell ebooks at a premium and allow people to re-sell them. Because the history of their ownership is recorded you could even see them gaining value if they had been owned by a celebrity.
Celebrities are, by definition, not anonymous, double signing is not a problem. Doesn't need a public ledger.
> Private but public healthcare records for research and usage. Store the health-records publicly as personas but allow individuals people to link it with their identity. This would help with research in completely new ways.
That's a distributed database with signed edits. Since it doesn't require to maintain a mutable singleton, it doesn't need a ledger at all.
> Voting made public but anonymous Make it impossible to fake voting results by making the results available for everyone.
Potentially a good use of a decentralized ledger.
> Artificial Intelligence Using the protocol to create automated consensus models.
Also potentially a good idea. Those two ideas seem to be related to this proposal, http://tezos.com
> Companies without owners Build a company with a political purpose without any owner.
Potentially a good idea.
We can always discuss the specifics all of these can be centralized but they benefit from being decentralized.
Imagine for instance someone suggesting that a supermarket offers coupons on a distributed ledger. Sounds like a good idea? No, it's dumb. It's dumb because you trust the supermarket to honor the coupon anyway... there's no credible threat model here.
OK so we've figured our supermarket coupon system can be run on a centralized database. Well, you suggest, sure we can, but why not just have it decentralized if we can?
Because it's expensive. It's expensive in terms of engineering to interface with the blockchain, it's expensive to wait for blockchain confirmations, it's expensive to rely on the non-malevolence of a few mining pools. And did I mention there is about no benefit?
However, this is not the most offending use of blockchain technology. You know what, maybe that supermarket gets to federate their coupons to other stores and you can start to see an engineering case. And maybe you're running this in Argentina and there is a credible threat that the government might want to meddle in you coupon scheme, maybe for price control. OK, then maybe you have a case. No, the worse use of blockchain technology is when there is no need for a global mutable singleton.
The whole idea of a cryptocurrency is that you need to have an irreversible consensus. This is the crux of the double spending problem, you need to dissipate heat to be irreversible (yes actual heat). This heat could come from "overwriting" your key, but that's hard to prove, so instead Bitcoin uses the heat from the ASIC. I'm simplifying a bit, but this can be made rigorous.
However, I've heard many proposals where there is zero need to maintain such a consensus. You mentioned medical records, that's one. People have been talking about running webforums or websites on top of a distributed ledger. Most of those proposals are braindead.
For instance it can solve the problem of very slow moving governments and allow people to build solutions that might be necessary for the survival of that society then thats actually quite useful to be able to build your own rules that even if they try can' be shut down by a central unit.