Quote from: zooitje on May 28, 2017, 06:50:33 PM

Quote from: klosure on June 22, 2016, 08:29:46 PM

Quote from: e1ghtSpace on June 21, 2016, 09:47:15 PM

Quote from: ohad on June 21, 2016, 09:31:09 PM

turing complete languages leave you helpless predicting what your code is going to do, except the "wait and see" way

Ohad, can you give us an example of this? Show us how it would work, because I don't understand how it works.

I can try to give you an analogy. Let's take cargo ships for instance.

Generalist ships can carry stuff of all shape and form with no restriction other than their size and weight limits: space rockets, airplanes, cranes, train wagons, whatever. It's cool because you can really carry anything. But it comes with its own difficulties: it's pretty much impossible to plan in advance how exactly you are going to arrange the things you need to load so that they will fit neatly and optimally and won't move during the trip. Sometimes your guys at the dock will manage to find a solution quick. Sometimes they'll have to load and unload things so many times that it seems like it takes forever. And that's when you don't have someone asking you to ship something so enormous that it blocks your docks for a week when you figure how to ship it at all. This type of ship is turing complete. In theory it could ship the moon. It could ship anything of any size if you have an infinitely large ship, and infinite number of dockers and an infinite amount of time. But in practice that doesn't really work like that, and the actual ships that end ups being used are all limited in size, and your docks have only that many cranes and that many dockers to help. Those ships are a watered down finite version of the real thing. So what happens with the real-life finite turing ships is that they work ok until it don't. And you can't really tell in advance when things are going to be smooth at the dock or when it will become really messy because the only way to decide how things gonna fit and what ship to use is to try to fit them in the ships. Of course there are many trivial shipments but the problem is you have no guarantees that a shipment will be easy to handle, difficult or downright impossible. But that's not the worse thing: the nightmare of turing-complete shippers is the outsourcing business, that is to say when another shipping company asks them to ship the cargo of their clients who may themselves be shipping companies outsourcing for other shipping companies and so on. Since they are all in the same business of turing-complete shipping as you are, they can't tell what the size of their cargo will be, and their clients don't know either etc. And if you yourself start to outsource unknowingly to one of the clients of one of your own client, that's where things start becoming self-referent and in some cases paradoxal, leading to capacity planning decisions that are sometime inconsistent.

Some other ships are specialized in carrying containers. They can carry only containers, and all the containers need to have exactly the same dimensions. No exception allowed. The containers are spacious, and inside the containers you can arrange things the way you want so it's not a problem for a large majority of the typical use cases. This type of ships is called total functional ships. The advantage is that even a 10-year-old could tell you just how many containers you can load on your ship if you give him the dimensions of the deck and the height limit so it's really easy to make sure that you always have the exact right capacity for your cargo, and your dock is working in continuous streaming loading container after container and ship after ship 24/7. But the problem is that you just can't carry anything larger than a container, making the shipping solution non-complete. Well, in fact there is a little secret: with some coordination you can carry anything of any size, but you'll need your customers to be smart and figure a way to breakdown the cargo into components that can fit in a container. You'll still be able to ship a plane, a rocket, the moon or even the whole infinite universe, but it will all have to be done in small parts, chunks and/or raw materials, that you will reassemble on the other end, effectively recovering the full expressiveness of what turing-complete ships are able to do, but over a controlled sequence of individual containers possibly carried by an infinity of ships. That requires a lot more thinking and engineering ahead of time than just shipping things piecemeal, but the reward is that at least at the time the cargo arrives at the dock, you don't have to worry that it could be too big to handle, and there is always a solution to the questions of how to load the cargo and how long it will take to your dockers to do the job. Like in the case of turing-complete shippers, you can also handle the outsourcing business of other containers shippers and outsource yourself, but since everybody can forecast what they are going to ship because nobody accepts cargo that's not already been quantified, it's impossible in the total functional shipping business to get requirements like "I will ship through you what is being shipped through me" but rather requirements like "I will ship 159 containers". This forced determination in relationships prevents the occurrence of self-referent cargo and guarantees that capacity planning leads to results that are always consistent.

In this analogy, Tau-Chain is a container ship company and Ethereum a generalist ship company.

Tau-chain can tell to its client how much their cargo will cost to ship, how long its gonna take and when a single ship isn't enough and will use all and any container ship available of any size regardless and manage to dispatch all the cargo optimally. It can make all sorts of predictions on the shipping like checking that weight is well balanced, or that temperature in the containers remains within a certain range etc. Clients can attach to containers fast automated procedures called proofs which took them quite some time to prepare but that will allow to clear automatically and very fast custom, security, and quality controls at the arrival point so that the cargo can be deployed right away to its intended use and used on the spot. Another interesting aspect of Tau-chain is that it finds its container system (Tau) so good that the company decided to eat its own dog food and sequence itself in a continuously evolving series of its own containers with custom procedures to maintain its own integrity as it evolves.

Ethereum on the other hand can't quite tell in advance just how big a ship will be needed for any specific cargo nor if it will fit at all in any ship, so what it does is to let the client decide themselves what size of ship they want to use (the client would typically simulate a dock in his backyard to try to predict what volume his cargo could take) and make them pay for the service in advance. When the cargo arrives at the dock, if it fits in the planned ship Ethereum sends the ship even if it's not full. And if the cargo doesn't fit, it's just thrown in the sea. Either way they keep the money. Cargo doesn't come with any sort of automated clearance test, so it's up to their intended users to figure if the cargo is correct and have it pass all clearance tests before they can use it safely (which is never entirely certain as the case of the DAO has shown).

I hope this analogy helps making these computing paradigms less abstract. There are many approximations and concepts that I had to stretch to makes them work with the analogy and are not really exact but that should give a rough idea of the differences, and how these affect the distributed computers that implement them.

After the response on reddit by 'just some guy' i'm interested in what experts here think about this (https://www.reddit.com/r/ethereum/comments/6doeqc/what_does_ethroll_take_so_long/di53vny/):

Quote

Cargo doesn't come with any sort of automated clearance test, so it's up to their intended users to figure if the cargo is correct and have it pass all clearance tests before they can use it safely (which is never entirely certain as the case of the DAO has shown).

vbuterin: I really have to push back against this part of the description. The vast majority of attacks against smart contracts, and smart contract bugs, have nothing whatsoever to do with the Turing complete versus bounded execution dichotomy.

Thanks for sharing, this was quite clarifying. I wonder if there are posts like this which also deserve to be bumped.