I believe filecoin is going to be a part of IPFS [1] at some point in the future, but development hasn't started yet. I really hope all the decentralized technology is going to blow up.
[1]: http://ipfs.io/
[1]: http://ipfs.io/
A missing piece is decentralized compute at scale. That's hard, especially for security reasons.
It's too bad Amazon branded "serverless" because lambda is not serverless. It's one big mainframe server. This stuff is serverless.
If I'm writing a mobile app that needs heavy compute (too heavy for small mobile devices) can I distribute that compute across larger peers like desktops, NAS boxes, etc.? Not easily and not if it involves anything that anyone might ever want to attack or spy on.
Or is there another way to outsource computation in a secure manner?
might be worth asking there
First, you don't get something for nothing. So you need computers (surprise). Now, how do you share code? You can share code directly via IPFS. Now, admittedly, binary is the fastest, but limits your architecture rather greatly. So an interpreted language seems better.
I'm looking at Erlang, given its functional attributes and ability of swapping code with no downtime. It also works in a cluster.
I also look at Tor for entry points to get requests on these machines. We already can interact with IPFS for files, but it has no logic capability. And Ethereum is a joke in many ways (and it simply can't interact outside its blockchain).
The idea: IPFS filestore for storing functions, and chaining IPFS hashes to be ran by a Erlang cloud connected by Tor Onion links.
It's not completely serverless computation, but you can ideally abstract out the server so it doesn't matter where it is, or who handles it.
Other ways to go about this would be homomorphic encryption (way too computationally expensive at this time)... Or some sort of trusted computing (shudder).
Look at the DAO. It's more than enough reason to dismiss this as a libertarian capitalist's experiment, with straight up dictatorialism if they don't get their way.
Do you support Ethereum Classic and consider "being hacked by the DAO hack" == "things not going [their] way"?
Just curious.
Yes, it sucks that they did not write tighter code and allowed a gotcha.... But when that happens in the legal world, people do pay for it.
Instead, because one of founders put up a lot of ETH, they changed the rules of the game. Now, the question is, "How close to the CEO of ConsenSys do you need to be to roll out bad contracts?".
That's what makes it worthless.
The change in Ethereum was "voted" for by a majority of hash power (but of course as influenced by the Ethereum leadership, so people had the popup in the client along with a recommendation what to vote for). So isn't that correction also in the spirit of Ethereum? Miners decide.
How about fixing obvious bugs, but otherwise upholding contracts?
To elaborate, it's especially hard to trust ETH code because it's not provable in any way. Bugs will hide, and people will find them. If ETH wasn't turing-complete this would be less problematic (because static analysis would be much easier, and possible), but as it stands there's no way to trust Ethereum contracts.
The rules aren't: "the code is the contract".
The rules are: "the code that is accepted by a majority of hashing power is the contract."
As someone who has tried to build a simple DAPP on bitcoin, my god, this is not what bitcoin was meant to do. I mean I love bitcoin, but building smart contracts on bitcoin is like using a screwdriver to implement a calculator.
Bitcoin took a route which isn't suited for things which Ethereum wants to achieve. A great example of this is Augur vs Truthcoin/Hivemind. The team behind former looked at Bitcoin first, but realized how much difficult it would be for them to build this on bitcoin so they went Ethereum route and now they are very close to their alpha, where as Truthcoin/Hivemind went nowhere.
Ethereum is/was pretty interesting; but as with all blockchains, it's solving a globally-distributed byzantine/trustless problem, at the expense of being massively inefficient.
It's a good idea for that domain, but such constraints don't apply to the majority of computing problems. For example, Web app A might want its events to appear in the same order to all of its clients, and Web app B might want the same for its events, but there's no reason to enforce that all clients of all apps see all events of all apps in the same interleaved order, in an open world where new apps can be created without any central authority, and where no app or client trusts any other app or client.
Regarding a practical language, I think something like Morte/Annah/Dhall would be nice as a way to:
- Use pure functional computation as a powerful 'sandbox' against causing nasty effects or having results affected by outside interference
- Use IPFS URLs as function names
- Use Church (et al) encoding and strong normalisation as a form of statically-checkable duck-typing (i.e. if it encodes to a duck, then it's a duck)
* JavaScript function to run, stored on IPFS
* Input data stored on IPFS
* Result of the execution gets stored on IPFS and hash written as contract fulfillment