A Few Words on Smart Contracts
By Wojciech Cichon, SETL Software Developer
We have witnessed a big revolution in the financial world. Suddenly, everyone started talking about blockchains, and the many use cases for blockchain technology. But this was just the beginning. There was something missing, the ability to create and execute credible transactions without third parties. The concept was already there; the idea of smart contracts is over a decade older than bitcoin itself. The term “Smart Contract” was coined by Nick Szabo who described their mechanics in his paper “Formalizing and Securing Relationships on Public Networks”. He defined smart contracts as mechanisms embedded in the software or hardware which can provide mechanisms to fulfill contractual obligations.
On non-permissioned chains there is also a darker side to this, as it opens blockchain instances to various potential risks and malicious activities. Many successful attacks on the Ethereum blockchain prove how serious this threat is. Some of the issues related to smart contracts are typical for classical programs, such as bugs in the business logic, overflow or underflow, usage of insecure libraries, and some issues which might be specific for smart contracts like gas limit or re-entrancy. Damian Rusinek, who is a blockchain security researcher, did a very good presentation, “Outsmarting smart contracts” where he talked about security pitfalls which could be used to attack these kinds of smart contract and how to handle them in a secure manner.
At SETL, we run a permissioned blockchain engineered for financial market needs. When we were designing how our smart contract will work, we paid particular attention to the need for high security and decided to make smart contracts an integral part of our blockchain. We provide an implementation of contract types which meets our customers’ requirements.
This solution has a couple of great advantages. It provides us with the ability to test contract code properly and to spot potential bugs and issues earlier in the life-cycle. Comparing to Ethereum where contracts are stored in state and anyone can access the contract source code in order to look for vulnerabilities to exploit, the SETL solution is safer as contract code cannot be obtained by an unauthorised person.
SETL’s intentional choice to lose flexibility in favour of better security demonstrates SETL’s commitment and understanding of the importance of security in a financial Blockchain environment. Our goal is to provide flexibility, but to always provide the level of security expected by our customers.