It’s about 2 years since I don’t code a dapp and it’s time to recapitulate about the whole concept. Here are some notes and thoughts about Solidity.

Solidity itself is a simple language as a programming language

Solidity is a high-level language for ETH contracts. It makes it much easier for human to code, understand and then compile the code into the EVM so the ETH network can read it in a way the computer can understand. It’s a purposefully slimmed down, loosely typed language with a syntax similar to ECMAScript (JS).

Compilers such as Solidity is a compiler code into IBM code which is uploaded into the BC in the form of a transaction. Then anyone can execute it later on ETH BC.

Some basic ideas

– A OO Programming Language to Generate Smart Contracts.
– It helps developers in writing smart contracts which gets converted into byte code, which further gets executed in Ethereum Blockchain.
– Initially proposed in August 2014 by Gavin Wood.
– It has similarities to JavaScript and C (check the functions below)
– Program language of ETH BC and other competing platforms.
– Solidity is first converted into byte code and then gets executed in the EVM
– With Solidity developers can develop self enforcement applications.
– Solidity supports inheritance, libraries and a complex user-defined type which make it possible to create contracts for voting, crowdfunding, blind options, multisize wallets and many more.
– Runs in ETH BC and other BCs.
– Dapps: application that implement SELF ENFORCING business logic in the smart contracts.

Solidity to build smart contracts on top of Ethereum

Once the contract code is in the EVM (ETH Virtual Machine, the network) it needs people to interact with reality because there are no connections, otherwise its isolated. The reason is that anything that executes in the EVM needs to be deterministic. You can’t generate random numbers easily inside the EVM: it requires an outside interaction.

The contract object is the highest level we have in Solidity (class). Contracts expose some number of functions.

Functions and the issue with  security

Contracts are easy to WRITE. But difficult to write SECURELY. Specially when you are dealing with funds. Many functions let someone to hack it and manipulate it circularly which makes them unsafe.

Public functions are callable by anybody e.g. want anybody who has X coin to check how many of them do they have in their wallet. Anyone can call it!.

=> Public functions are sort of the exposed API, exposed to the world. Things that you allow outside actors to interact with your contract.

Internal functions: only callable from inside the program so you only let other functions and not outsiders to use them.