There is tremendous value in distributed ledger, but also tremendous empty hype at the moment. As a rule of thumb, people who tout distributed ledger based solutions ought to ask themselves the following questions:
- Can this be replaced by a centralized database?
- If not why?
- If security / trust is a factor, what is the exact threat model?
That depends on your threat model, that depends on what you're trying to achieve. There are very large engineering costs to using this type of solution, and in many cases, the benefits are much lesser.
There are, but I contend that most of what is being hyped makes no sense. What are the applications that can truly benefit from this model according to you?
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.
For those asking about what kind of applications could be created on top of this here are a couple of ideas.
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.
I'm curious to hear more concrete examples of where companies can actually sit (and be profitable) in these new layers. I understand the basics of the blockchain, and always find myself nodding my head in agreement while reading these types of articles, but by the end of the article it seems like it just washed over me and I don't have anything concrete to hold onto.
I'll try to drill down to specifics in the series of posts that will follow this, but I wanted to set the general stage first.
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.
Given that value won't be created in the same way as traditional business do now, what plausible business models do you foresee for software companies operating in this landscape?
One example is Onarbor, https://onarbor.com. Onarbor is a crowdfunding site with a Blockchain backend. The Blockchain parts are several fold:
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.
Yeah, I don't fully understand the "primitives" that the blockchain offers. Surely there can't be that many: The interesting part is how much each costs to invoke, and how long it takes to complete.
Tricky to design an application around an API with multi-minute latency!
That's where overlay networks come in: a combination of a purpose-specific overlay network (maybe something like counterparty, or maybe something like Side Chains) to make up for Bitcoin's blockchain's deficiencies while taking advantage of its liquidity and network effects.
So, I'm purposefully posting this way down in the comment chain because it's not ready and I don't want it to get too much attention, but I've recently written a whitepaper for a potential distributed application platform. It's still very rough, but I would really appreciate it if somebody could provide feedback. The people that I've shown it to so far either haven't had the expertise to review it or weren't interested in reading the paper.
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.
>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.
I think creating a purpose-specific overlay network that gives you performance comparable to what we see today with centralized solutions while simultaneously preserving the guarantees from the blockchain is the hardest problem here by far. If you can create such an overlay network, you should be able to turn around and use it to create a much faster blockchain.
All you get from the Bitcoin blockchain is the ability to store some public data that's hard for anybody to alter once the data has settled. That's useful for a few special problems, but not widely useful.
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.
"All you get" is a distributed & anonymous consensus algorithm that's resilient to malicious actors.
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.)
>All you get from the Bitcoin blockchain is the ability to store some public data that's hard for anybody to alter once the data has settled. That's useful for a few special problems, but not widely useful.
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?
Sorry, just used to the Bitcoin community, who tend to act like the blockchain they have speculated on is the only one that has ever existed. What are your reasons for bitcoin maximalism?
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.
- Can this be replaced by a centralized database?
- If not why?
- If security / trust is a factor, what is the exact threat model?