Topic: Turing completeness and state for smart contract (Read 12240 times)

This is why I love this forum. 
As someone who only knows basic programming, its amazing to come to a thread like this and learn about things like "Turing Completeness" on my lunch break.

Is it possible to feel smarter and dumber at the same time?
The more learn, I realize how little I know...

 https://www.reddit.com/r/ethereum/comments/4g1bh6/greg_maxwells_critique_of_ethereum_blockchains/d2e24sy

Well.. anyone who has worked in SQL would know what a ROLLBACK is. (..and running out of gas could be considered a time condition ie it's taking too long, fail )

That is a technology that has had to manage complex financial 're-orgs' for a looong time.

There are many occasions on a daily basis that a SQL function call fails mid-sequence and you have to 'go back to the beginning..' .. undoing everything that the transaction has done up to that point. It's absolutely taken into account in the design of your system, and expected. 

Maybe using a system similar to the way SQL handles rollbacks and designing your system with that 'paradigm' in mind, would prove helpful when writing and running smart contracts, and then the re-orgs when they invariably do fail.

Exactly, if someone care to modify the technology then it would prove be  very beneficial for us. As because many cryptocurrency are coming up each day so to contest the compedition it's necessary to bring the latest change.

That makes more sense. Thanks for clarifying.

You misunderstood what I was saying.

A declarative model doesn't reflect the reality of these systems well. It is easier to get started, but hard to do things right, and very hard or impossible to to be confident that you got things right when you did.

A more functional model reflects the reality of the systems better, while also providing powerful scaling and analysis benefits.  I believe it is possible to construct systems which are harder to get started, but once you get something working its very likely to get things right, and hard but far from impossible to _prove_ you're achieving the properties that you set out to achieve.

I haven't proven that better can be done, yet (unless you count Bitcoin script)-- but what DAO/ETH seem to be proving is that at least that design is too dangerous to be used-- when their highest profile contract, reviewed by the designers of the system/language, got robbed blind by a rather simple vulnerability.

Just seeing your comment now. Yes, the DAO stuff is evidence against having such an expressive scripting language. However I see the mutable state vs script-like language are fairly orthogonal. Assuming that Bitcoin's more constrained system of state is better, what I wonder is whether a more declarative way to write Bitcoin-script-equivalent stuff would still be preferable. As mentioned above, I think the declarative style puts less mental load on developers and is more 'natural'.

The gist of an earlier comment of yours seemed to be: "writing smart contracts is inherently hard and unnatural, so it's fine if the scripting language is hard to understand." I just don't see how one aspect of writing contracts being hard (getting the logic right) implies that it would be better for other aspects to be harder than they need to be.

If a declarative version of Bitcoin script made mistakes less likely, what is the downside? Are you worried about newbs who just learned a bit of javascript thinking they can write secure smart contracts just because Bitcoin script v2 might look a bit more like javascript? So the fact that current script looks intimidating is actually good? If so would it have been even better if Satoshi made all op codes of the form OP_XYZ where X, Y, and Z were digits? And maybe disallowed spaces when not including them would still be unambiguous? That would certainly reinforce in people's mind that writing Bitcoin script is tricky.

Exactly.

But this is where we are now: a lot of money has been put into the big "blockchain" pot. Who put that money wants results sooner rather than later and there it goes the lack studying and preparation.

I want to stress my point of view that you can easily find somewhere else: we can not allow any smart contract to rule anything that is subject to so much discretionality.

I would agree that the amount of effort required in order to get such things written and working "as expected" is far from trivial (even with such a tiny program such as the Crowdfund example I posted).

However it really isn't that much different to writing critical code for other things (such as medical equipment or software for spaceships) so I don't think it is without precedent (but is perhaps quite alien to the vast majority of programmers).

Rushing into writing complex "smart contracts" (and putting them in charge of millions of dollars worth of tokens) is not a good idea. This is a new and emerging field that is most likely only going to improve through a lot of unfortunate mistakes.

Thanks gmaxwell.
I gave the exact same explanations to a group of friends who are developing on ethereum. I totally agree with this.

And, moreover,, thinking how legalese is complex and "dumb" at the same time I don't know if it is that good to make some software run this "complexity dumbness" with code.

 

It's not "data" but "code" and numerous instances of this code has been running on the Qora and Burst blockchains for well over a year (it is how much of the development funds have been raised).

Details of AT itself can be found here: http://ciyam.org/at/
(it is highly technical documentation)

Where is that data from?

Whilst this probably won't be understood by nearly anyone on this forum the AT CF code is as follows:


This is AT machine code (there is no high-level language for AT at the moment and after the DAO bungle we aren't in any hurry to add one), however, it has been in production for well over a year (without a single issue being reported from two separate blockchains that are using it).

It is *minimal* and incredibly efficient (it doesn't even basically do any executing until the CF expiry time is reached).

I don't think that Turing complete smart contracts are impossible to do right but they are extremely difficult to do right and so should IMO at this stage be limited to very small things like the example above (and tested for every feasibly possible scenario).

With the clear difference is that the attack universe of the first is more Turing complete.

 

Ethereum and Bitcoin are heavily flawed in their own ways. Maybe even being polar opposites. Smart contracts aren't the best use for hashing power, but it's a good start.

The argument in Bitcoin is simple: If doing anything interesting with Bitcoin forces you back to a purely trusted third party, the value of Bitcoin as a permissionless asset is diminished.

Bitcoins value comes partially from decentralization, and that value is maximized by minimizing the frequency at which you need to put those benefits aside. No more justification is needed.

Re other things copying ethereum's smart contracting system. For me, the recent snafu in ethereum is experimental confirmation of a long held belief about that design. My view that the design is flawed wouldn't be changed by putting it another altcoin or a sidechain. That doesn't mean I'm opposed to other people trying other things, -- more experimental evidence.

Interesting thread thanks  

Personally I think bitcoin script was already overly complex, I'd rather see things compartmentalized in accordance with unix philosophy.  Also keep in mind that contracts are conflict resolving tools, and as such fixing them with code totally misses the fact that conflicts arise due to circumstances unknown at first, which therefore haven't been coded for.  As such, they could only make business more difficult.  Even if somehow there was a magically trustworthy oracle.  

That being said, I could see the thing as more of a tool for decentralized automation.  Change the name and now it makes more sense.  But not a whole lot more.  When I think of automation I think of a project with a planner.. in which case - why the decentralization?  Extra useless overhead.  However I can' t immediately rule out the existence of a reasonable use-case somewhere like I can easily do for smart contracts.  

Add to this that ethereum has the economic distribution model of dogecoin and I'm not sure what's left.  I mean seriously, did nobody on that team consider that their coin would be around long enough that the money supply would matter?  

Do u think, this statement is valid for those who are building smart contract on bitcoin blockchain, e.g. Rootstock or CounterParty?

How about now?

Though your example is making a distinction without a difference, something like that could easily be converted to something more Bitcoin script like... but the real differences I'm highlighting are things like avoiding mutable state, which-- among other benefits-- would absolutely preclude vulnerabilities like that re-entrancy race in the DAO, which is currently in the process of proving to the world that ethereum isn't the decentralized system it has claimed to be (so, in that sense, the error prone smart contracting programming model has done the world a service).

Really interesting read, still my biggest fear about Ethereum is if their scaling plans fails, then we will have just another fancy "dead horse"