The smart contract leverages the immutable recording and trust model of the blockchain.

The smart contract leverages the immutable recording and trust model of the blockchain.
Since a smart contract is deployed in the blockchain, it is an immutable piece of code, and once deployed, it cannot be changed. We will have to redeploy the code as a new smart contract, or somehow redirect the calls from a old contract to the new one.
Smart contract can store variables in it called state variables.
Contract in the Ethereum blockchain has pragma directive, name of the contract, data or the state variable that define the state of the contract, collection of function to carry out the intent of a smart contract.

State

The state and the state hash in a black header. These are those states.
Initial state is state one, is updated by the message set and the state changes to state two.
Next, the execution of increment message results in state three and the decrement message or function execution will transition to the next state and so on.

If there is no explicit constructor but a constructor is automatically by default created for the smart contract.

Smart contract creation

A smart contract can be created, on behalf of an externally owned account, by:

• Application programmatically from the command-line interface
• By a script of commands from high level applications
• User interface or UI
• From inside a smart contract

Smart contract address

The smart contract requires an address for itself so that transaction can target it for invocation of its function.
The contract address is generated by hashing the sender’s account address and its nonce.
A unique target account is reserved for smart contract creation and deployment.

Target account zero.
If a target’s address is zero or null, it is meant for creating a new smart contract using its payload feed.
The payload of a transaction contains the bytecode for the smart contract.
This code is executed as a part of the transaction execution to instantiate the bytecode for the actual smart contract.

Smart contract compile process artifacts

Here are some of the artifacts generated by the Remix smart contract compile process and their use:

• ABI, Application Binary Interface, the interface schema for a transaction to invoke functions on the smart contract instance bytecode.
• Contract bytecode, this is the bytecode that is executed for instantiating a smart contract on the EVM. Think of it like executing a constructor of a smart contract to create an object.
• WebDeploy script, this as two items:
  • JSON script to web application to invoke smart contract function
  • Script for programmatically deploying a smart contract from a web application
• Gas estimates, this provides a gas estimates for deploying the smart contract and for the function invocation.
• Function hashes, first four byte of the function signatures to facilitate function invocation by a transaction.
• Instance bytecode, the bytecode of the smart contract instance.

Deploying Smart Contracts

Similar to how a constructor creates an object, the execution of a smart contract creation transaction results in the deployment of this smart contract code on the EVM.
It is permanently stored in the EVM for future invocation.
This transaction goes through all the regular verification and validation specified in the etherium blockchain protocol. Block creation, transaction confirmation by the full nodes deploys a the same contract on all the nodes.
This provides consistent execution when the regular transaction with function messages are invoked on the smart contract.

Other approaches for deploying smart contract:

• Remix IDE.
  • You enter the smart contract code in the Remix IDE and compile. Remix generates several artifacts. For the ease of deployment, Remix provides us with the Web3 deployment script which contains a bytecode. Application Binary Interface, ABI, and account detail.
  • To deploy the smart contract, we could just execute the script.
  • Once the deployment is done, the address is generated by hashing creator’s account number and nonce.
  • To interact with the smart contract, we’ll use the smart contract address, ABI definition, and the function hashes.

Structure of smart contract

Function

Function definitions are similar to functions in any other high level language.
Function header, followed by the code, within curly brackets.
Function header can be as simple as an anonymous noname function to a complex function header loaded with a lot of details.
Function code contains the local data and statements to process the data and return the results of processing.

function header { function code }

function nameOfFunction (parameters)
visibilityModifier accessModifiers returns
(returnParameters)
Function is a keyword at the beginning of all functions.
Parameters are any number of pairs type identifier, example, UInt count. returnParameters, return values can be specified as pair type identifier or just type.
When only type is specified, it has to be explicitly returned using a return statement.
If type and identifier are specified in the return statement, any statechain that happens to the identifier within the function is automatically returned.
Any number of values can be returned, unlike common programming languages that allow only one return value.
var (age, gender) = getAgeGender();

A constant function is included to enable the client applications to call to obtain the result.
The constant modifier of the function prevents it from changing any state of the smart contract.
More importantly, this call comes directly to the smart contract not via a transaction, so it is not recorded in the blockchain.

Data Structures

Address

Mapping
Mapping is a very versatile data structure that is similar to a key value store, it also can be thought of as a hash table.
The key is typically a secure hash of a simple Solidity data type such as address and the value in key-value pair can be any arbitrary type.

Message

Solidity Events: Logs events and pushes data to an application level listener

Struct
Struct is a composite data type of a group of related data that can be referenced by a single, meaningful, collective name. Individual elements of the struct can be accessed using the dot notation.

Array

Enum
Enum or enumerator data type, allows for user defined data types with limited set of meaningful values.
It is mostly used for internal use and are not supported currently at the ABI level of solidity.
However, it serves an important purpose of defining states or phases of a smart contract.

Time Units
The time is used in timestamping the block time. When a block is added to the blockchain, all the transaction confirmed by the block also have the same block time as their confirmation time.
A variable called “Now” defined by solidity, returns the block timestamp. This variable is often used for evaluating time related conditions.
In other words, now variable in a function is not the time at which function transaction was initiated, but it is the time when it was confirmed.

(Smart contracts often require control over who are what can execute the function, at what time a function needs to be executed, what are the precondition to be met before getting access to the function?
It’s a good practice to validate input values to the function to avoid unnecessary execution and waste of gas.
If there are any errors found during the input validation, these have to be handled appropriately.
At the end of the function execution, you may want to assert that certain conditions are met to ensure the integrity of the smart contract.)

Modifier
Modifiers can change the behavior of a function. That’s why this feature is referred to as a modifier.
It is also known as a function modifier since it is specified at the entry to a function and executed before the execution of the function begins.

You can think of a modifier as a gatekeeper protecting a function.

A modifier typically checks a condition using a require and if the condition failed, the transaction that call the function can be reverted using the revert function. This will completely reject the transaction and revert all its state changes. There’ll be no recording on the blockchain.

Function modifiers along with state reverting functions of revert, required, and assert, collectively supported robust error handling-approach for a smart contract.

Events

The application can listen to the events pushed, using a listener code, to track transactions, to receive results through parameters of the event, initiate a pull request to receive information from the smart contract.

Best Practices

Design the state variables for the smart contract to be efficient storage for the on-chain data. Leave the off-chain data to be managed by higher level applications.