The Giant Smart Contracts Code Update

This article opens a series of materials devoted to the unique features of the Giant blockchain on which the Giant.Exchange platform is developed. Let us look at the first function — the smart contract code update.

The implementation of smart contracts of the Giant blockchain (GiantContract) provides a number of useful features:

JavaScript of ECMAScript 6 standard - a programming language for writing Giant smart contracts

the possibility to edit the code of the deployed smart contract

the possibility of the smart contract destruction

the signature of a smart contract with a private key of the Giant masternode for its deployment into the main Giant network

In order to clarify the process of the implementation of the Giant smart contracts, let us look into the history of the emergence of smart contracts.

Computer programs that automatically fulfill the terms of the contract recorded at the time of its creation are called "smart contracts". Their concept became known in 1994, but due to the lack of a reliable execution environment, it had not gained popularity. In 2008, with the advent of the Bitcoin, the concept of smart contracts was able to increase its prevalence. Bitcoin utilizes Bitcoin Script to validate transactions. This system is capable of running scenarios that are more complex than just a transfer of funds. At the same time, Bitcoin Script is not an independent entity in the Bitcoin blockchain, and therefore it does not have its own balance and cannot create new transactions. As a result, Bitcoin Script cannot be described as the optimal environment for the functioning of smart contracts, and it makes impossible to transfer funds from one smart contract to another in the Bitcoin system.

Ethereum blockchain, launched in 2014, has become a full-fledged environment for the execution of so-called smart contracts, but its implementation has a number of disadvantages.
Disadvantages of the Ethereum blockchain. Why we can't we update its smart contracts?

It might be asked: why do smart contracts need to be updated at all? In fact, there are several reasons for that:

iterative extension of the functionality of the smart contract

fixing of the bugs that can expose to risk the balance of the smart contract or its basic logic

```
changes in business requirements
```

community consensus on changing the operation of the contract

The impossibility of updating the smart contract also exists in the NEO, but we will consider it on the example of the "digital equivalent of oil".

Probably, every programmer who writes Ethereum smart contracts ponders on what he will have to do if it is necessary to expand their functionality. However, you cannot change the smart contracts that are uploaded to the network. We can only imagine approaches that allow us to solve this problem:

The division of one smart contract into many that are connected to each other. For example, a contract for the sale of tokens. The rules for calculating the number of tokens that need to be transferred to a crypto wallet (where the Ether was transferred from) are not clear. A separate contract can calculate it, providing a replacement for itself if necessary. This option is only possible in Solidity and it makes no sense to consider it for a long time. Let us just say that the main drawback of this approach is the inability to change the external interface of the system of one or another contract. Because of this, you will not be able to delete or add the function.

Application of the delegatecall. The instruction was suggested at the EIP-7. It allows you to call a code from another contract, but its context remains the same. The code/contract that is called will be written to the storage of contract which called it. The msg.value and msg.sender will remain unchanged. There are examples of this mechanism in the network. In each example, you can see the utilization of the Solidity Assembly.

The idea of the methods using delegatecall lays within the implementation of the fallback function where you need to read the calldata and then to provide the transfer through delegatecall. There are several such methods but their use cases are limited. There are two reasons for that. In order to run this method of code updating, you cannot alter the structure of the information storage. It is also required to carefully delimit an access to fallback which changes the address of the active contract.

It turns out that the emergence of the smart contracts updating feature will solve a lot of problems. The problems which are constantly faced by the developers of smart contracts for such networks as the Ethereum, NEO, etc. We are sure that the appearance of contracts in which such function is correctly implemented will inevitably lead to the loss of the popularity of these blockchains, to a collapse of their currencies and to the outflow of most their users.
Smart Contracts Code Update - it's real in Giant!

We have examined why it is impossible to update the code of Ethereum smart contracts. After all, this mechanism is in great demand, but with all its advantages it is absent in the ecosystems of Ethereum, NEO, etc.

Our team has managed to introduce an upgrade feature into the Giant.Contract, providing the users of the Giant smart contracts with a number of useful features:

to instantly fix bugs in an active smart contract

to iteratively develop a "smart contract" with a gradual improvement of its functionality

not to lose any confidential information stored on a smart contract during its update

To write the Giant smart contracts, the JavaScript of ECMAScript 6 standard is used. It is a dynamic programming language that allows you to define a data type, to parse, and to compile just in time. Each smart contract has its own isolated storage, which stores the status of the smart contract execution. It stores the status since the moment of its deployment into the blockchain and until the last call of any smart contract method. Because of the dynamic nature of JavaScript, the method declared in a smart contract class is also an object that is kept in the smart contract storage. This allows you to replace the smart contract method, through a special method provided by the developer of the smart contract. See Giant Contracts Whitepaper page 6 for more info on this matter.

An example of the implementation of such a mechanism when changes to the smart contract code can be made by the same user who deployed the smart contract:

'use strict' import Contract from 'GiantContract' import {getCallerAddress} from 'GiantBlockchain' export default class ChangableContract extends Contract { constructor() { this.owner = getCallerAddress() this.a = 1 this.b = 2 } get() { return this.a } changeCode(newCode) { if (this.owner === getCallerAddress()) { eval(newCode) } } }

In the above example of a smart contract, we illustrate how it can change its code just in time through the changeCode method. Eval is a function in the JS that executes arbitrary code. Thanks to its call, you can address this to change the code of a smart contract.

// before the change, the get method returns the values of the a field giantjs> const c = new ChangableContract() giantjs> c.get() 1 // we change the smart contract code so that it returns the value of the b field giantjs> c.changeCode('this.get = () => this.b') // now get will return the value of the b field giantjs> c.get() 2

This mechanism is applicable to the developers of smart contracts but can cause a vulnerability to smart contracts in cases of a neglect or malicious utilization by the developer. Let us consider the situation: suppose that Alice has a smart contract that accumulates money into her account which has the specified rules of their distribution. After the accumulation of a certain amount on Alice's account, Bob interferes in the contract making an attempt to change the code of the smart contract and thereby tries to change its rules in his favor. Alice, if Bob's actions are successful, may lose her funds kept on the account. It may seem that such actions will become a problem of Giant smart contracts and a threat to the security of transactions.

However, there are several solutions for cases of malicious smart contract modification:

Smart contracts must have an access to the balance through an unchangeable or secure method.

Some smart contracts need to be unchangeable - as a variant the code of a binary option contract (because it is quite simple).

```
To use multisignature:
```

multisignature is required for the code change
multisignature is required for funds withdrawal

JavaScript has built-in mechanisms to protect object properties from being overwritten. The code of the smart contract in this situation will be as follows:

… export default class NotChangableContract extends Contract { … } Object.defineProperty(NotChangableContract.prototype, 'get', { value: () => this.a, enumerable: false, configurable: false, // will not let you redefine the object’s this field writable: false // will not let you overwrite the object’s this field });

In this case, the progress in the JavaScript shell is the following:

giantjs> const c = new NotChangableContract() giantjs> c.get() 1 giantjs> c.changeCode('this.get = () => this.b') giantjs> c.get() 1

In the future, we plan to introduce support for the ES7 standard, which has decorators (shorter solutions). Thanks to them, the code will look as follows:

… function notModifyed(target, key, descriptor) { descriptor.writable = false; return descriptor; } export default class NotChangableContract extends Contract { … @notModifyed get() { return this.a } }

Giant smart contracts are a revolution in the cryptocurrency field. Even though our blockchain repeats some of the Ethereum's solutions, it also offers a number of unique ones.

For more information about the JavaScript in the smart contract code read our next article.
An analogy from the legal practice

And finally, a few words about the legal aspect of the possibilities of changing contracts in practice. From the point of view of the contract system, changing the terms of the contract after its conclusion is a common practice. In real life, the parties who decide to change the terms of the contract use services of a notary to legally make the changes. In addition, the changes to the contract often occur at the conclusion of framework contracts, the terms of which may be subject to additional agreements. It is important to remember that supplementary agreements should not contradict the terms of the contract itself. In view of these aspects, the addition of the possibility to alter the contract by an agreement of the parties into the blockchain network is a mandatory step. This step leads towards the modernization of legal relations of the contract supporters and towards the approximation of a contract cryptocurrency transactions to the legally correct form.