I'm quite new to the blockchain technology and I would like to understand a few concepts for which I couldn't find an in-depth explanation online. All the resources I examined so far explain the subject in an extremely high-level way and there is no technical explanation of the process in which the system works, particularly Ethereum.
I will explain what I know about the system, then what I do not know. It could be that my question is a bit broad one, but I just can't split it into separate questions as the concepts are so tangled together!
In a simplified manner, this is how a blockchain looks like(I will have some ideas referencing this below):
Let's say we have a smart contract that stores a list of node addresses. Each time a node triggers the contract's iWasHere() function, the node's address gets to be added in a list and one can read the list of addresses by calling the whoWasHere() function.
I would like to have a more in-depth understanding on what exactly means for a smart contract to be ran on a blockchain and what happens exactly under-the-hood.
Here's what I do understand about the concept:
-
a smart contract can have the same capabilities a normal person has: can receive money, can send money, can listen to certain events and interact with other smart contracts.
-
a human person can interact with the smart contract through a frontend interface and so full-fledged applications can be built on top of that "backend" interface.
-
smart contracts are compiled into bytecode i.e. EVM assembly instructions that are ran on the EVM and each instruction consts Gas.
Here's what I do not understand about the concept:
-
what actually happens when one "deploys a smart contract on the blockchain"? Is it attached, to a block, on a newly mined block, e.g.
n + 17? How does one access that contract, then? You just scan the whole chain for smart contracts with a certain contract address? -
what happens, exactly, under-the-hood, when a random human person triggers a smart contract function, for example
iWasHere(). The EVM byte code corresponding to the code that needs to be executed by that function call gets added to a transaction and then recorded on the block? Who does the code execution per-se(i.e. what node will run the actual processor cycles needed to run the code on the actual hardware i.e. e.g. a human-ownd CPU), the node that calls the function or all the nodes in the network? If all the nodes in the network will run the code, how is this scalable? What happens when there are 10.000 applications running on blochcain simultaneously? Isn't the same as 10.000 application running on each node in the network?
Can someone explain or point me to some documentation that explains these concepts?
The web is full of high-level explanations on how does the system works, but couldn't find anything on the low technical level.
Best Answer
For starters let's not equate smart contracts with people, that's a very OOP idea and it just confuses the entire issue, in my opinion.
I definitely agree that technical documentation and teaching material like this are very lacking. You often get very surface level information.
A smart contract can not listen to events.
A smart contract is a passive static thing. You call it to do something and it will do the thing. It never does things on its own. It may respond differently depending how much time has passed or blockheight or similar. Or depending on the state of other smart contracts, which it may enquire, as part of your request.
Correct. Basically a blockchain is just a immutable database that lives "on the internet" decentralized with no single location. And in case of smart contract chains it can also have code.
Right.
It is! Everything is blocks, so everything on the chain is on the blocks. I think a contract might be split between blocks, technically, since there is a block size limited, not sure though.
Upon deployment, which is an EVM action performed with an existing ethereum address, which costs gas, you receive an address. That address is where you find the smart contract. Similar to a hashmap, access is very fast.
There are two types of function calls in solidity on ethereum "view" types and normal ones. a view type call, does not write anything to the chain and does not cost any gas. Normal ones do. The gas cost is equivalent to the amount and cost of EVM instructions needed to completely the entire call. So its only recorded for when you actually write to the chain, not when you just red out a variable, for instance.
Do note that for some view calls, some processing is still needed, like going through a loop lets say, and it does in fact not cost any gas to do this. This is relevant to the next point.
I think this is a very important question.
So first of all, the way these blockchains are designed is: you run a node yourself and you use it to communicate with the chain.
In reality most people use a third party, lets say metamask or infura or others. But these third parties just run nodes themselves and give you the answer you are looking for, they must still run a node like you can do yourself. These services usually cache all blockchain data in a faster and more convenient database.
(a lot of this seems like magic since we use convenient services like that, but really you just run a node, which collects all blocks and can communicate to the blockchain, which again is just a giant database)
When you make a VIEW call I assume you execute the EVM instructions yourself on your node, which is why it doesnt cost any gas.
When doing a call that writes, a miner has to actually mine it. Mine the block, attach your stuff to the block, execute code if there is any and write the result to block.
This is where it does get foggy for me: The consensus mechanism ensures data is correct and by more nodes picking up the blocks you produced, it becomes accepted. But it is only written once.
This goes into the territory of knowledge proofs for example if you want to look further into it.
But you do only write once, a miner does it. After that via consensus we determine, via consensus algorithm, that this write was correct and you didn't trick the system.