Continuing from where I left off in my previous article, What Is DeFi and Why Should You Know It as a Software Developer, we are going to dive into writing a Smart Contract with the objective of making an investment in the DeFi Space. However, since that will be a really complicated one, we are going, to begin with, writing some really base Smart Contracts and then grow from there.
Friends to bookmark
The following two sources are like the most important when you are writing out a Smart Contract (let’s call this SC):
While the first one needs no introduction, there is something really critical that you must note: the language Solidity that we are going to use for writing SCs is under continuous development and hence, there is no better place to find out the latest state of the language than the official documentation. Thus, whenever, and I repeat, whenever, you are writing an SC you have to make sure that you have taken into account the latest changes in the language. This is not only to make sure that your SC works as you want it to, but it is also to make sure that your money (and this is real money that we are talking about) is put exactly as we want it too. Trust me, mistakes in this part of the world have cost a lot of people a lot of money.
The second one is where your SCs usually take their first breath (yes, each mature and complex SC then goes on to more battle-tested IDEs for development).
So, let’s do it in our old Q&A fashion.
so what is Remix?
Remix is an IDE for SC development. It has the ability to compile the SC as per the official compilers, deploy the SC in a fake browser-based Blockchain or local machine-based fake Blockchains or actual Blockchains out there.
Wait! Did you just say Fake Blockchains and Actual Blockchains? what is that?
I am sure you are aware of the term, test environments, that is what a fake Blockchain is. That is to say,
- those Blockchains can lose their state (i.e. the entire Blockchain at any given point in time), and
- Transactions on these chains have no monetary value. There are quite a few fake Blockchains (i.e. TestNets as they are known to Google). Ropsten, Kovan, and Rinkeby are currently the three most popular Ethereum TestNets.
In contrast to the TestNets – obviously, there is only one Blockchain for each protocol and Ethereum is one such Blockchain protocol.
Cool! So I am in Remix and I have selected Solidity. What’s next?
There are various things that we need to learn in just Remix alone. But as of now, let’s start writing the simplest and naive contract and then let’s break it down.
To begin with, please click on + logo that you see here in Remix:
You will be asked to give your contract a name. You can give any name that you may like.
Subsequent to that, I will request you to code out this SC:
For obvious reasons, I do not want to give you this code through GitHub or Gist.
Ok, I think I understand the code, but obviously each of the words above has some relevance, let’s talk about those.
That is correct. So let us look into it bit by bit:
pragma solidity ^0.5.0
This statement informs our compiler which version of Solidity to use. As I mentioned earlier, the state of Solidity is in continuous development, hence, our compiler needs to know which version of Solidity are you using to develop your Smart Contract so that it can appropriately compile it down to bytecode. It is the bytecode that gets deployed onto the Blockchain (more on that in a bit).
contract XXXXXX {
}
This is setting the name of our contract. So as you will notice in just a bit, the name of the file and the name of the contract can be completely different.
All our contract code will go within the curly braces that our defined with our contract declaration.
function () external payable {…. }
The no-name function is known as the fallback function in the case of an SC. It is not necessary that each of your SCs should have a fallback function, but it is advisable.
So what is a fallback function?
I am glad you asked. Every SC is something similar to “if this, then, do that” situation. Also, each SC can accept ETH. So, a fallback function is the function that will be invoked should anyone randomly send any ETH to your SC, without invoking any specific function (i.e. reason of why the ETH is being sent to the SC).
Why is it required?
Well, first it is a security measure, secondly you want to kind of do something when someone just randomly sends ETH to your SC. I have seen a fair share of SCs that return the ETH to the sender in such situations.
What is msg.sender, msg.value?
Easy to guess. Msg.sender is the ETH address sending the ETH while Msg.value is the number of ETH that is being sent in the transaction.
Ok done, I think, I understand what this code does.
That is great. Yes, the code is simple and holds no secret. It will send you the ETH back. Or, to put it simply, it is just a wall from which all ETH will just bounce back. But is it so simple or are we missing out any detail?
Is it!?! What?
For this, I will let you google a bit (ok, only until my next article). I will leave you with the breadcrumbs external and payable as the keywords over here.
