31–40 of 45 posts
Not sure how that would actually help but they somewhat _can_ talk to each other through WebRTC. I wonder if that would change anything here
I actually made this a few years ago for an ill-fated application to YC (I was still a sophomore in college). The first big problem is that you can't trust any of the results that you receive from the workers. You can alleviate this somewhat by not accepting job results until they've been replicated by at least several other workers (lowering efficiency of the system), but then you're still vulnerable to sybil attack…
You can send the checking to other nodes and check those randomly as well.
I actually made this a few years ago for an ill-fated application to YC (I was still a sophomore in college). The first big problem is that you can't trust any of the results that you receive from the workers. You can alleviate this somewhat by not accepting job results until they've been replicated by at least several other workers (lowering efficiency of the system), but then you're still vulnerable to sybil attack…
Check 10% of submissions randomly - if some are wrong, blacklist that source. You can send the checking to other nodes and check those randomly as well.
So then you need a proof of work scheme to defend against sybil attacks, but even then an attacker could choose to only produce incorrect output when they detect that a quorum group is made entirely of their compromised nodes, and otherwise produce correct output. That would once again render blacklisting ineffective.
I'm not saying it's impossible, but securing this sort of browser-based grid computing scheme is a nontrivial task. And that's coming from someone who is very fond of this technology.
Earlier quoted context omitted.
Check 10% of submissions randomly - if some are wrong, blacklist that source. You can send the checking to other nodes and check those randomly as well.
That's what you would initially think, but a clever adversary can produce arbitrarily many identities, so even if results agree, there is a non-zero chance that all of the agreeing nodes are compromised. Even if you begin blacklisting nodes, an attacker can simply spoof new ones. So then you need a proof of work scheme to defend against sybil attacks, but even then an attacker could choose to only produce incorrect o…
IPs are not so cheap, anyway. If you have enough legitimate traffic it would be tough to spoof enough.
Earlier quoted context omitted.
That's what you would initially think, but a clever adversary can produce arbitrarily many identities, so even if results agree, there is a non-zero chance that all of the agreeing nodes are compromised. Even if you begin blacklisting nodes, an attacker can simply spoof new ones. So then you need a proof of work scheme to defend against sybil attacks, but even then an attacker could choose to only produce incorrect o…
Use homomorphic encryption to ensure attackers can't tell when they get the same thing twice. IPs are not so cheap, anyway. If you have enough legitimate traffic it would be tough to spoof enough.
Earlier quoted context omitted.
Use homomorphic encryption to ensure attackers can't tell when they get the same thing twice. IPs are not so cheap, anyway. If you have enough legitimate traffic it would be tough to spoof enough.
You're thinking in IPv4.
Earlier quoted context omitted.
Check 10% of submissions randomly - if some are wrong, blacklist that source. You can send the checking to other nodes and check those randomly as well.
That's what you would initially think, but a clever adversary can produce arbitrarily many identities, so even if results agree, there is a non-zero chance that all of the agreeing nodes are compromised. Even if you begin blacklisting nodes, an attacker can simply spoof new ones. So then you need a proof of work scheme to defend against sybil attacks, but even then an attacker could choose to only produce incorrect o…
Earlier quoted context omitted.
That's what you would initially think, but a clever adversary can produce arbitrarily many identities, so even if results agree, there is a non-zero chance that all of the agreeing nodes are compromised. Even if you begin blacklisting nodes, an attacker can simply spoof new ones. So then you need a proof of work scheme to defend against sybil attacks, but even then an attacker could choose to only produce incorrect o…
How does Steem and Nano solve this? They much have the same problems.
I'm not very familiar with either of them, but Steem seems to be a non-centralized database of reddit-like posts. This doesn't seem to be offloading arbitrary computations to others like OP wants to do.
Nano also doesn't seem to be offloading arbitrary computations to others.
Ethereum does allow arbitrary computations, but it is not offloading, it is requiring every node to rerun every computation, which is obviously much less efficient than a single centralized computer doing the computation.
Earlier quoted context omitted.
Compared to what? Useless to compare anything without numbers.
Compared to what? The compute market in general. AWS is a premium provider charging premium prices, they've essentially priced themselves as the most expensive provider on the market. It feels insane to describe them as "very cheap". You might as well be calling a Bugatti Chiron "pretty cheap". Any datacenter provider will be able to sell you compute time at a fraction of the cost of EC2. Look at OVH for example.
Earlier quoted context omitted.
Compared to what? The compute market in general. AWS is a premium provider charging premium prices, they've essentially priced themselves as the most expensive provider on the market. It feels insane to describe them as "very cheap". You might as well be calling a Bugatti Chiron "pretty cheap". Any datacenter provider will be able to sell you compute time at a fraction of the cost of EC2. Look at OVH for example.
Spot instances are insanely cheap, not talking about EC2.