Comment by kefka | Hacker News Reader

Comment by kefka | Hacker News Reader

Parent Full thread

In all honesty, I need to try building something that does semi-distributed computation. Here's my idea to throw in the pool.

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).

> Ethereum is a joke in many ways

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)

We did an experiment on distributing work via IPFS and an Ethereum contract:

* 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

https://github.com/flowhub/jsjob-ethereum

What's your goal here? Right now it just sounds like you want to use a bunch of cool technologies.

Why is Ethereum a joke? It seems to do exactly what you are trying to, and you just discount it?

Primarily because they have engaged in the "We didn't really like the way project XYZ worked out, so we're going to re-do."

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.

Elaborate?

Do you support Ethereum Classic and consider "being hacked by the DAO hack" == "things not going [their] way"?

Just curious.

By Ethereum's own documentation, their code is the contract and the contract is the code.

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.

Right. This also means that you can't currently trust code that runs on the blockchain since there are likely more bugs like the one that was exploited. Thoughts on that?

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?

> This also means that you can't currently trust code that runs on the blockchain since there are likely more bugs like the one that was exploited.

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.

You don't understand what happened. The CEO (lol) doesn't just get to choose. The network's hashing power gets to choose.

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."

> Primarily because they have engaged in the "We didn't really like the way project XYZ worked out, so we're going to re-do."

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.

Reply on news.ycombinator.com