💙 Are you a DApp? We're helping DApps reach out to more users with our promotion service. Contact us now!
← View all posts
2020-03-02

Development of a new programming language for smart-contracts is a big mistake

Article credited to Dexaran and provided by EOS GO

Development of a new programming language for smart-contracts is a big mistake-big

The main purpose of this article is to explain the uncertainty associated with the development of new programming languages for smart contracts. Many new projects offer their own programming languages for the development of smart contracts, but in fact, new programming languages should be considered bad or even harmful feature.

The utilization of an own programming language for a smart-contract platform, the following disadvantages can be noted:

  • 1. Development for the sake of development: This kind of development is not necessary since there are plenty of already existing programming languages that can solve everything a new language is intended to solve.

  • 2. Waste of development resources: The development of a new programming language is a waste of development resources. In addition this introduces the necessity to establish a toolchain (compiler, IDEs, testing environments, syntax analyzers) that will do exactly the same as what already existing toolchains are doing for already existing languages.

  • 3. Major security flaw: Newer programming languages lack coding and security standards.

  • 4. Disrespectful attitude towards developers: Introduction of a new programming language forces every developer willing to launch a DAPP on the platform to spend his/her time on learning a new language for no particular reason or advantages in doing so.

1. Newer programming languages do not introduce any advantage over existing ones.

Smart-contracts are not more than other programs. Such powerful programming languages like C++ or Java can solve nearly all possible tasks associated with implementing an idea in code. This also applies to smart-contracts.

There is no necessity to develop a new language for smart-contracts since the existing widely adopted languages are suitable for developing smart-contracts.

If some are stating that the newer programming language is necessary because it is better in something or introduce any advantage that other smart-contract development platforms lack then it is mostly a marketing move. Technically the current limitations of smart-contract development platforms are not tied to the programming languages. The bottlenecks of smart-contracts are tied to the underlying platform architecture and its capabilities.

Development of a newer programming language is a highly specialized task which is not anyhow related to the development of a smart-contract development platforms and methods of how this platform executes contracts.

There are no tasks related to the smart-contract development that widely adopted programming languages are not suitable for. This renders the development of a new programming language absolutely unnecessary as ready to go time-tested solutions already exist.

2. Waste of development resources and toolchain maintenance.

It should be noted that custom programming languages require the development of the appropriate custom toolchain that will do exactly the same with what existing tools are doing for existing programming languages already.

Developing a new compiler is extremely specific task that requires highly qualified team experienced in exact this area. All the custom compilers are orders of magnitude worse compared to the existing ones such are GCC or LLVM. This should be noted that GCC is in development for 32 years already while LLVM is 17 years in development. If someone decides to use a custom programming language for smart-contracts and developed a new compiler for it then it is reasonable to expect that it will take about 15 years to bring this tools to the level of performance of nowadays LLVM assuming that a team of highly specialized experts is dedicated for this task.

This should be noted that compiler is not the only task that developers will face if they decide to develop a new programming language. Literally they will be forced to re-implement a wide variety of tools from scratch and solve a number of tasks that could be avoided by simply relying on existing programming languages and compatible toolchains.

A good example is comparison of Ethereum (Solidity is a custom programming language developed for Ethereum contracts, Solc is a custom compiler) and EOS (C++ is a widely adopted programming language). Ethereum's contracts can't work with cycles. Attempting to perform a simple mathematical operation like multiplication in 100 iterations pushes Ethereum to its limits and renders its unable to perform it (excess of block gas limit). In EOS it was possible to perform 200000 of iterations each containing three calls of number multiplications. This is an illustrated difference between tools that passed years of development and those built from scratch recently.

3. Security and maintainability standpoint

It is very important to understand that the choice of a programming language is not just a matter of preference. When it comes to security syntax matters and coding standards matters.

Programming languages have such characteristics as:

  • Readability - how easy it is to read the code and understand the underlying logic. This is the most important characteristic since this determines the ability of maintainers to work on a project and the ability of security auditors to identify attack vectors and other security flaws.

  • Compactness - a good programming language must provide the opportunity to make programs as compact as possible. The number of characters per logical expression should be minimal as it greatly affects the ability of a code reviewer to focus on the logic of the program. The attention of the auditor should be focused on what the program does, and not how it is written.

  • Adoption - this includes the number of experts who are already familiar with the programming language as well as the existence of guidelines that could help newcomers to learn and avoid common mistakes. The absence of the time tested guidelines and known practices will result in repeatedly reproducing of mistakes until the most common ones will be figured out by trial and error (in case of smart-contracts this translates into "hacks, thefts and robbed investors"). This should be noted that not all possible programming practices are advised. For example the excessive use of templates is possible in C++ but it is not recommended since this negatively affects the readability of a program.

The level of adoption of newly created programming languages is always low, the advised practices are not established and the number of experts familiar with the language is minimal.

In large projects, coding standards are tightly fixed and mandatory. Otherwise it would be incredibly hard to understand, modify or debug the code that was written decades ago by people who are no longer working on a project. It would be impossible to properly coordinate and merge the work of multiple programmers if they would adhere to their own coding styles. This would be even harder to review the code and identify security flaws for a third party reviewer.

GNU is a good example of a large-scale project that passed years of development cycles. GNU coding standards describe the necessity of proper coding style and attributes, programming language preferences and other aspects that serious software development projects must take into account.

3.1 Special note regarding formal verification and security-oriented programming languages

Formal verification is not a self sufficient method of security assurance but a helping method of reducing the overhead for software testers. Formal verification is not reliable on its own as it is impossible to prevent business model flaws, every logical flaw or indirect attack vectors using the formal verification.

The best a programming language can do to improve security is to be time-tested and well-readable.

Sacrificing readability and adoption for the sake of formal verification is a great security worsening.

If a smart-contract development platform is designed to provide secure smart-contracts then it is way more productive to introduce multiple layer of "security enhancements" instead of trying to make one of them (programming language) perfect. Perfected security assurance is not achievable (general paradigm of system security engineering) and the only productive security enhancement strategy is the diversification of security layers.

4. Newly created programming languages are restricting DAPP developers

Newly created programming languages force developers to spend their time on learning. Being a programmer always means learning something new, but it also means correctly allocating your time to learn what you need and use ready-made tools when it saves you time. The crypto industry and smart-contract development platforms are evolving quickly. The first question that rises when a smart-contract development platform features its own programming language is "Why should I spend my time on learning this new language that is useful for nothing but writing contracts on exactly this platform if it is likely to be deprecated or replaced by a better platform in the next year or a couple of years?"

Most likely, the answer to this question is: “Just because the developers of the platform decided to create their own language or thought they could surpass the results of decades of work of the rest of the community of programmers in a matter of months.”

The attempt to discard the results of the rest of programming community work and trying to build everything from the ground up looks like a typical junior's mistake. This mistake however introduces a great number of problems for anyone willing to use the developed platform.

As the leader of a security auditing organization, I can conclude that it will be just an additional overhead for us to make all our security auditors learn the new language which does not have any advantage over existing ones. In most cases newer languages have worse readability and uncommon syntax expressions which further increases the complexity of preforming a code review.

Conclusion

Common programming languages are completely suitable for the development of smart-contracts and the creation of new programming languages is unnecessary and poses no advantages.

Newly created programming languages intended for smart-contract development are orders of magnitude worse security-wise, performance-wise and adoption-wise.

In case of development of a custom toolchain for the newly created language it should take decades to bring them to the level of todays toolchains for common languages. It is possible to integrate the newly created programming language with existing tools in some cases but this is still a hard and resource consuming task which could be avoided by simply using a common programming language.

Newly created programming languages introduce an entry barrier for DAPP developers which leads to the lack of professional developers, lack of time-tested well-worked coding standards and increasing expenses for those willing to hire a developer or a security auditor.

Well architected smart-contract development platform must not feature its own programming language for the development of smart-contracts.

EOS GO is funded by EOS ASIA and powered by YOU. Join the community and begin contributing to the movement by adding eos go to your name and joining the EOS GO telegram group.