Return to Operational Data

Return to Top

Return to Top

A Constructor is a special group of Operators that are called when an Object is first created. In most Object-Oriented Programming (OOP) languages (i.e., C++, Java and C#, e.g.), the Constructor has the same name as the Object. It is the initial stage in the Lifecycle of Object Data (see 2.3.4.5 Data Lifecycle Taxonomy). For example, for an Object called Vehicle, the Constructor would also be called Vehicle. The constructor is responsible for the setup of the Object: the initialization of Field Data, the allocation of memory from the Heap. For example, if there are dynamic Field Data, then the memory needed for those Fields is usually allocated from the Heap. Although Constants are generally managed and allocated by the compiler and are from the Stack, Static Field Data can be allocated from the Heap and can be set during construction. For example, the values of Field Data initialized by using initialization parameters on the Constructor or read from initialization or setup files.

Generally, there are three kinds of constructors available in OO:

• Default Constructor is a constructor which does not take any arguments (i.e.parameters) when it is called.
• Parametrized Constructor is a constructor which is generally called after the Default Constructor and has arguments (i.e., parameters) that it can use during the construction process.
• Copy Constructor is a constructor that is called to create a replica of the first object. The designer of the Copy Constructor needs to understand the object to determine what needs to be part of a Deep Copy and what can remain as part of a Shallow Copy.

There is always a default Constructor that required no parameters, however, there can be other Constructors allowing for the passing of values to be used during initialization. For example, the minimum or maximum values used for the Field Data.

Regardless of the number of Constructors, there is always a Constructor that is called when an object is created. Often the calling of a Constructor is automatic and used the default Constructor, but the programmer can use any of the Constructors defined for the Object. See: https://www.tutorialspoint.com/solidity/solidity_constructors.htm

Return to Top

When Data Object is deployed in Ethereum, the following occurs:

The contract is initialized using the optional Constructor method named: constructor(). A Constructor is a special function declared using the constructor keyword. It is an optional function and is used to initialize state variables of a contract. Following are the key characteristics of a constructor¹⁾

• A contract can have only one constructor
• A constructor code is executed once when a contract is created, and it is used to initialize contract state. Note: When the constructor does not explicitly set any state variables, they are set to zero
• After the constructor code is executed, the final code is deployed to blockchain. This code include public functions and code reachable through public functions. Note: Constructor code or any internal method used only by constructor are not included in final code
• A constructor is either public or internal
• A internal constructor marks the contract as abstract
• In case, no constructor is defined, a default constructor is present in the contract which initializes all values to zero

contract Inventory
{ uint public quantityInStock;
  constructor () public
  { quantityInStock = 0;
  } // End Inventory constructor
  function checkInventory() external view
    { if ( quantityInStock < 0 )
      { revert ( "quantityInStock must be greater than 0");
      } // End if
    } // End checkInventory
} // end Inventroy contract

contract Inventory
{ uint public quantityInStock;
  constructor ( uint _initialQuantity ) public
  { quantityInStock = _initialQuantity;
  } // End Inventory constructor
  function checkInventory() external view
    { if ( quantityInStock < 0 )
      { revert ( "quantityInStock must be greater than 0");
      } // End if
    } // End checkInventory
} // end Inventroy contract

Return to Top

Return to Top

Destructor is a special method called automatically during the destruction of an object. Actions executed in the destructor include the following:

• Recovering Heap space allocated during the lifetime of an object (see 2.3.4.5 Data Lifecycle Taxonomy)
• Releasing Shared or Network Resources such as printers, faxes, scanners or outside Voice over Internet Protocol (VOIP) resources
• Releasing Resource Lock, for example, Web Servers, banking systems read versus update, travel reservations, etc
• Closing connections such as database, file or service
• Other housekeeping tasks

• Note: Often the first use of the Destructor, Recovering Heap memory, is automated in many modern systems (i.e., Java, .NET, Python, JavaScript, etc.) but the remaining reasons for a destructor remain in place, and it is up to the architect to determine what resources need to be freed upon the end of a Data Object (see 2.3.4.5 Data Lifecycle Taxonomy).

Return to Top

Although the original intent of a DIDO is built around the concept of immutability of the data, why is there a need for destruction of the data (see 2.3.4.5 Data Lifecycle Taxonomy).

Since the software (i.e., Smart Contracts) are also stored on the DIDO and are self-executing, they too cannot be modified after they are deployed, not even by the creator of the contract. This is particularly true in Ethereum, which is a permission-less network of nodes meaning the software on the network (i.e., smart contracts) are executed by everyone who can access the network, which includes nefarious actors (i.e., attackers). In addition, the entire contents of the network including constants, state variables, transactions, the smart contract byte code are completely visible to the anyone having access to the DIDO making it an ideal target for “bad actors”.

In 2016, attackers utilized a vulnerability (reentrancy [40]) to attack a smart contract owned by an organization named DAO (Decentralized Autonomous Organization). This attack made the organization lose 3.6 million Ethers1. People usually call this attack a DAO attack [1]. Actually, the attack continued for several days and the organization even noticed that their contract had been attacked at that time. However, they could not stop the attack or transfer the Ethers because of the immutability feature of smart contracts.(

Jiachi Chen, Xin Xia, David Lo, John Grundy, Why Do Smart Contracts Self-Destruct? Investigating the Selfdestruct Function on Ethereum, May 2020, Accessed: 5 December 2021, https://www.researchgate.net/publication/341478354_Why_Do_Smart_Contracts_Self-Destruct_Investigating_the_Selfdestruct_Function_on_Ethereum ))

The 2016 attack known as the reentrancy attack or DAO attack drew the attention of both academia and industry as various schemes were introduced to prevent such attacks in the future. Part of the solution is to specify requirements, develop and test Smart Contracts rigorously before they are deployed. Although this is always best, it is not always possible to predict all the possible ways a Smart Contract is vulnerable, especially in the future. Therefore, another part of the solution is to add some mechanisms to stop the contracts and/or transfer the tokens when emergency situations arise (e.g., a contract is under attacked). The only option left for the owners of the Smart Contract is to reduce the impact of financial loss. In response, Ethereum's Solidity provides a Selfdestruct function which allows the Smart Contract to transfer all remaining tokens to a different Smart Contract and to remove the errant Smart Contract from the Ethereum network.

When a Data Object is destroyed in Ethereum²⁾, the following occurs:

• The remaining tokens are transferred to a new address
• The contract is destructed via the selfdestruct() method or the deprecated suicide() method

• Note: See https://www.tutorialspoint.com/solidity/solidity_constructors.htm