e-Xpert Solutions Genève
Auteur : Wojciech Myszkorowski
Date de publication : 29 octobre 2018 - Dernière mise à jour : 29 octobre 2018
The financial world has been shaken since the arrival of Bitcoin in 2008. Ever since new cryptocurrencies have emerged, introducing a complete decentralization to the world controlled until then by the classical financial major organizations. One of these cryptocurrencies, Ethereum, added to this decentralization the use of smart contracts. Any smart contract is a simple program defined by lines of code working and being executed directly on the blockchain. Since the smart contract codes are permanently available on the blockchain, the paradigm of privacy has changed. Privacy, as known so far in computer science, does not exist on the blockchain since any information is available to everyone having a network access. In this article, the specific blockchain is the Ethereum one. This blockchain has the particularity of having codes living inside it and not only transactions.
The Ethereum blockchain can be qualiﬁed through a few key points such as:
The best way to deﬁne a smart contract is to see the code as an agreement between two entities working on the mechanism of the blockchain and never relying on any kind of trusted authority. A smart contract can be represented as a sort of account controlled by some code inside the Ethereum blockchain. A concise example of such a code, written in Solidity, follows below.
Solidity has been implemented with algorithms coming from other languages, such as the inheritance using the same linearization algorithm as Python. However, some algorithms concerning features that are only implemented in smart contracts are proper to Solidity, e.g., the transaction cost of every instruction.
Inheritance is a valuable feature of a programming language. In Solidity, it allows to inherit a contract from another one, add or specify functions of a parent
This example shows that the inheritance known from Java and C++ applies directly to Solidity. The second contract subprimary will have access to the methods of primary. This allows for shorter and therefore less difﬁcult contracts to analyze. The price to pay is the problem of trusting another contract, having not necessarily access to the corresponding Solidity code of the contract it is inheriting from.
In principle security implementation is easier in contracts being smaller in terms of lines of code. In view of the above this statement is true if special conditions apply, i.e., when the inheritance is made from a trusted contract.
In terms of inheritance, OpenZepplin (library proper to Solidity) offers the use of the concept of Ownable. This option allows to set an owner of a contract and add the modiﬁer onlyOwner() granting the use of a method only to the owner of the contract. This improves security as it gives the right only to the owner to call the functions marked with this modiﬁer. For example, if we want to create a transfer function for withdrawing a given amount from the balance of the contract, instead of using the keyword private, we can apply the modiﬁer onlyOwner() and in this way allowing only the owner to transfer money.
Inheritance implies shadowing. In Solidity the redeﬁnition of functions is possible making the concept simple. If a contract inherits from another one and wants to redeﬁne a function it simply must have the same signature of the function.
Below is an example of a contract using multiple inheritance classes.
The focus is on the exploitation which can occur. The following code can be exploited due to the linearization algorithm. newUserEther can be deployed by a certain actor and inherits from the Ownable library. However, since the hackTime contract is placed at the end, any function having the same signature will be instantiated by the ones inside the hackTime contract. In this example, the newUserEther contract will use the redefinition of transferOwnership() of the hackTime contract and not the Ownable contract. Subsequently the actor thinks that he uses the address speciﬁed inside the contract, but in fact another owner will be set instead. One must be very careful in setting the inheritance and always place the key libraries at the end so as to avoid the shadowing effect.
Solidity has evolved a lot since it has been published. The first version was not even numbered the way they are now. Currently Solidity compiler is at version 0.4.25, a new version is coming out roughly every four months. For a programming language like Solidity this is very fast, particularly since smart contracts cannot be upgraded nor changed once they have been published. This implication has an important disadvantage since any modification to a smart contract in terms of security will request its redeployment.
To judge the maturity of Solidity one way is to have a look at the repository on GitHub and analyze the way people commit changes for the next release.
Figure 1 Solidity Repository
A few conclusions can be drawn from the two graphics. Firstly, it takes time for a project to get notoriety and attract developers. Secondly Solidity is a language which handles money under a specific form increasing the interest by malicious people to find its weaknesses. Majors attacks have been discussed over the last two years and glued an image of immaturity to Solidity. When talking about attacks, it is very important to keep in mind that Ethers were not only stolen from smart contracts, e.g., 2016 DAO attack but also from wallets which belonged to the particulars.
Figure 2 Python Repository
Security in its general form is not a module which can be activated for a specific feature, but a process which must be applied to many places such as the wallets, mathematics relying inside the blockchain and the programming language Solidity for Ethereum.
Regarding Solidity, most of the weaknesses can be addressed and avoided therefore allowing for some real-life projects to see the daylight. This is due, among others, to the growth of the number of experts in this domain.
The paradigm of the blockchain has changed the privacy as every information can be accessed by everyone. In terms of CIA, the concept of blockchain has altered the confidentiality. Indeed, it is not recommended to store sensitive information on the network. A special feature needs to be used to get information outside the blockchain. Now privacy and confidentiality must be distinguished.
Integrity is guaranteed by a mathematical algorithm called Merkle Tree exploiting an inviolable data structure has been proven resistant to many attacks. Compagnies can use smart contracts and exchange information with the confidence of the non-repudiation. For major compagnies data is the most valuable information and needs to be well protected. The blockchain with its cryptographic signature helps to achieve the corresponding data integrity.
Availability is guaranteed also by the core functioning of the blockchain since every information is “stored “on every node on the network making it almost impossible to bring down.
Despite what was said, the use of smart contracts for particular security purposes it is not yet a bulletproof idea. Specially for compagnies who need to share confidential information, the blockchain is not the right platform.
However, the integrity resulting from the fact that transaction proofs cannot be altered offers an asset to numerous applications such as supply chain management, financial or any other transactions. Both the financial and other compagnies can rely on this concept in view of simplifying their daily business and therefore decrease their spending and save time.
Solidity and the smart contracts technology are improving regarding the security issues and progressively removing their existing ﬂaws. This is mainly due to the constantly increasing popularity of Ethereum, and consequently the observed growth of the Ethereum community. We have also witnessed the appearance of the ﬁrst projects going beyond Ethereum but still using smart contracts technology, as for example the ﬁrst crowdfunding site
Despite the security enhancements, Solidity remains vulnerable because of its constant updates and its still unresolved problems, e.g., the linearization algorithm. The latter one needs urgently to be ﬁxed as it represents a major ﬂaw for such functionalities as the inheritance. Some other algorithms, such as the revert process, remain poorly handled.
Regarding compagnies which might consider starting security projects using technologies based on the blockchain will have to evaluate correctly the purpose of the smart contract and limit the kind of information that will be shared on the blockchain. The advantages regarding the cost they can spare by automating some of the daily process might be worth taking a serious look at this technology.