Topic: Decentralized programming language (Read 1685 times)
You should also look at multi-party computation. It allows for multiple co-operating nodes to run a program together, without each node being able to see all the inputs to it. The problem is it's very complex / expensive / slow.
One approach is to perform computations on encrypted data without knowing how to decrypt the data,
And there are quite a number of interesting implementations of this idea.
One of the concepts is SecreC (secret C). There is more on this here: http://sharemind.cyber.ee/research
Another group is in Denmark: http://viff.dk/ or the Sepia guys in Zurich http://www.sepia.ee.ethz.ch/
Actually, this is a fascinating research area
In place of the blockchain, what would be "in the cloud" so to speak?
I'm guessing you mean various libraries, so that a local client, "IDE + compiler" can access those libraries in a torrent-like fashion. I imagine compilation would be very slow due to networking bottlenecks, and people would quickly run into problems with bloated libraries, multiple variations of the same classes and so on. When it came to editing libraries, some kind of robust version control with conflict resolution would have to be built-in... It all seems like a lot of work, when people can just freely download libraries anyway.
I'm guessing you mean various libraries, so that a local client, "IDE + compiler" can access those libraries in a torrent-like fashion. I imagine compilation would be very slow due to networking bottlenecks, and people would quickly run into problems with bloated libraries, multiple variations of the same classes and so on. When it came to editing libraries, some kind of robust version control with conflict resolution would have to be built-in... It all seems like a lot of work, when people can just freely download libraries anyway.
The big question is, how do you achieve this? What is considered the "same node"? Even nodes in completely different physical locations could collaborate to capture data. If you can solve this problem, the rest is easy.
Well perhaps the "next node" could be part of the protocol so that the nodes themselves could not freely choose who to send to.
I will read up on twobitcoins proposal later.
One approach is to perform computations on encrypted data without knowing how to decrypt the data, which is called homomorphic encryption.
This is apparently a practical implementation: An MIT Magic Trick: Computing On Encrypted Databases Without Ever Decrypting Them
This is apparently a practical implementation: An MIT Magic Trick: Computing On Encrypted Databases Without Ever Decrypting Them
I'm thinking data protection might be achieved by never executing subsequent instructions on the same node - context information is thus lost.
The big question is, how do you achieve this? What is considered the "same node"? Even nodes in completely different physical locations could collaborate to capture data. If you can solve this problem, the rest is easy.
Not just fault tolerant, but decentralized as bitcoin. ie. lets call this language Torrent sharp or T# - if I publish a program in this language, as long as someone uses it with their T# client it must keep running.
It must be independent from me and no node should be able to see the data or variables inside the program.
E just looks distributed to me which alone is simple.
With this envisioned language I could program a bitcoin currency with a program-centralized DB, no public key cryptography and no work proofs and it would be every bit as safe as the bitcoin we have now.
I am thinking that a client adds points to a given program, but does not itself necessarily get that programs bits.
Instead hosting and storage distribution is randomized with programs "buying" hosting time automatically for their points.
Program used files/variables (say a JPEG or w/e) would have to be hidden, broken up or ciphered from the hosting node somehow.
It must be independent from me and no node should be able to see the data or variables inside the program.
E just looks distributed to me which alone is simple.
With this envisioned language I could program a bitcoin currency with a program-centralized DB, no public key cryptography and no work proofs and it would be every bit as safe as the bitcoin we have now.
I am thinking that a client adds points to a given program, but does not itself necessarily get that programs bits.
Instead hosting and storage distribution is randomized with programs "buying" hosting time automatically for their points.
Program used files/variables (say a JPEG or w/e) would have to be hidden, broken up or ciphered from the hosting node somehow.
Bitcoin is decentralized which provides it both safety, security and performance.
However Bitcoin is pretty simple. My question is: Could a programming language be created that is completely decentralized?
Necessary characteristics:
1. Each node must be unable to access at least some critical data.
2. Each nodes individual instruction execution must be verified to be correct as defined by the language.
3. Protocol enforcement must either be maintained cryptographically or via strong incentives - such as "program-runtime-points" for instance.
We know bitcoin is possible. Multi-sig txs are also at least theoretically possible, though I don't know much about it.
To what degree can we take it? My vision is like torrents but with programs.
I'm thinking data protection might be achieved by never executing subsequent instructions on the same node - context information is thus lost.
Maybe all types should be split up too so that one node never has a full variable... basically each node would emulate a small part of a micro processor getting some, but not all bits and would have no idea of what was going on.
Performance is a bitch though.
Bedtime for me I think...
However Bitcoin is pretty simple. My question is: Could a programming language be created that is completely decentralized?
Necessary characteristics:
1. Each node must be unable to access at least some critical data.
2. Each nodes individual instruction execution must be verified to be correct as defined by the language.
3. Protocol enforcement must either be maintained cryptographically or via strong incentives - such as "program-runtime-points" for instance.
We know bitcoin is possible. Multi-sig txs are also at least theoretically possible, though I don't know much about it.
To what degree can we take it? My vision is like torrents but with programs.
I'm thinking data protection might be achieved by never executing subsequent instructions on the same node - context information is thus lost.
Maybe all types should be split up too so that one node never has a full variable... basically each node would emulate a small part of a micro processor getting some, but not all bits and would have no idea of what was going on.
Performance is a bitch though.
Bedtime for me I think...
Jump to: