| I took a quick look. 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! [1] https://www.cs.umd.edu/~elaine/docs/permacoin.pdf |
>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.