Create a Turing-complete contracts language

Proposals Protocol
1

Summary:

Create a Turing-complete contracts language

Abstract:

Scilla isn’t Turing-complete.

Create also a Turing-complete contracts language (namely by modifying Scilla and compiling with different compiler flags and/or a pragma).

Motivation:

It is because Turing-complete languages are undoubtfully useful for general-purpose blockchains and we should compete with Ethereum better in as many aspects as we can.

Specification:

TBD.

For:

  • Widen our problem domain.

Against:

  • “It can be used for creating insecure contracts.” If one does want to create an insecure contract, he or she can do this anyway.

Poll:

  • Yes.
  • No.
1 Like
3

I don’t think you have quite understood the design philosophies behind Scilla: the Turing incompleteness of Scilla IS the feature.

What you are proposing is contradictory to the goal and purpose of Scilla.

Thanks to the fact that Scilla is Turing incomplete the Zilliqa team has been able to write static analyzers, such as the cash flow analyzer - and it is possible to write formal proofs of correctness of smart contracts. This is not possible - or at least not feasible - in Turing complete language such as Solidity.

Speaking of Solidity, in fact 99.9% of the Ethereum smart contracts does not require Turing completeness.

2 Likes
4

It is impossible to write a static analyzer of every feature of a Scilla contract.

For example, it is impossible to check with static analysis if a Scilla contract returning a sequence of bytes returns a finite execution-time algorithm in Godel encoding.

It is possible but hard to check with static analysis whether for a scilla contract that returns back three numbers passed to it always hold x^N + y^N != z^N if N>2.

So, you are defending a purpose that is impossible to attain: making Scilla contracts statistically analyzable.

You want to make it impossible for a user to make a non-analyzable contract. Why?

  • If a user wants to make a non-analyzable contract, he will do anyway.
  • If he does not want, he will just not use the feature I am suggesting.

So, both cases were considered.

5

@porton Yeah wonderful but i think it is difficult. But i want to thanks for sharing incredible post with us.

6

I disagree that turing completeness would significantly widen our problem domain, as the vast majority of smart contracts don’t actually require it. The fact that it would greatly increase the chances of unwittingly creating security flaws outweigh any gains to be had in terms of what kinds of smart contracts could be written.

For those with slightly less programming knowledge, here is a helpful article: Should Smart Contracts be Non-Turing Complete?

TLDR:

Let’s quickly examine some of the common flaws that exist because Solidity is a TC language. We have the security flaws that allowed the DAO hack to happen (recursive call exploit), the possibility of attacking poorly implemented smart contracts (reentrancy attacks), and the fact that fees cannot be accurately predicted thanks to recursion (and the Halting Problem). These things only exist because Solidity is a TC language