Same trend as last week. We continued working on our course projects and we also had "crypto talks", this time we learned about front-end development tailored to the web3 needs, and some entrepreneurship talks.

As per the regular lectures, this week we learned how blockchain oracles work and some of the alternatives most broadly used in the industry.

The need for oracles

Blockchains are closed distributed systems. As we have previously seen, this means that each network node has to deterministically find the same output for a given input. Some of the most valuable blockchain properties that arise from these designs are its decentralization and mitigation of network downtime, the trustable consensus validation of transactions, and the prevention of double-spending.

Nevertheless, all these features have some tradeoffs. Since smart contracts are unable to perform calls to external APIs, the network cannot natively access external data. On top of that, it is impossible to generate on-chain cryptographically secure random numbers within smart contracts.

As you can imagine, oracles are the answer to these problems. Blockchain oracles are third-party services that bring real-world, off-chain information into the network by verifying and relaying the data. Since they bridge the on-chain and the off-chain world, they are known as blockchain middleware. Oracles solve this problem by posting the data on the blockchain. So any Ethereum node replaying the transaction will use the same immutable data that's posted for all to see. To do this, an oracle is typically made up of a smart contract and some off-chain components that can query APIs, then periodically send transactions to update the smart contract's data.

But fetching off-chain data is just the first part of the problem. Ideally, these oracles should be resistant to manipulation, provide accurate data, and be continuously updated with the latest information. As you can imagine, these properties cannot be ensured by a single (or centralized) oracle provider, since it could end up being hacked, outdated, or disconnected.

Anatomy of a decentralized oracle

High-level, a decentralized oracle is a network of independent nodes that provide on-chain data. Where the data of each individual node is aggregated and deterministically validated by the network.

To ensure data accuracy and try to prevent data manipulation, oracles networks should have a decentralized approach in each of its layers:

• Data source: An oracle is only as secure as its data sources. To ensure information accuracy, data is fetched from multiple, and independent, data sources. The key to having accurate price data (one of the most common applications for oracles) is to have full market coverage to prevent data manipulation or inefficiencies due to low volumes.

• Node operator: As explained before, any decentralized oracle network should have several independent nodes fetching data. If node operators source price data from multiple independent data sources, they can take statistically representative measures such as the median to mitigate outliers and API downtime.

• Oracle network: An oracle network defines how the collection of nodes works together to create a single on-chain reference data point. The most common form of aggregation is taking the median of the reported values once a minimum number of nodes have responded to the request.

Architecture

For the network to fetch data, the interested parties (clients) will have to trigger a data request to the oracle network. The chain of action usually works as follows:

1. A client calls the oracle smart contract to create a new data request.

2. The oracle contract emits a log with a new event request.

3. All the off-chain services that are subscribed to these logs (usually using something like the JSON-RPC eth_subscribe command) receive the event.

4. The off-chain services proceed to do some tasks as defined by the log.

5. The off-chain services respond with the data requested in a secondary transaction to the smart contract.

From an oracle-user point of view, the implementation of oracles into their contracts is extremely easy and convenient. In fact, the most challenging part is the risk assessment behind the oracle that the user decides to choose. The following code snipped showcases how to create a request to the Chainlink price feed smart contract.

TWAP Oracles

Despite the previous definition that we have seen for blockchain oracles, one can understand a price oracle as any tool used to fetch price information about a given asset. With this definition in mind, we can see another subset of oracles that fully leaves on-chain. We will call them on-chain oracles.

Time-Weighted Average Price (TWAP) Oracles were developed by Uniswap, and still are the most adopted form of on-chain oracles.

As we have previously before, an oracle needs to ensure the quality of the provided data and be manipulation resistant. In order to get the latest spot price of an asset, one could just use the liquidity of an AMM pool as a price oracle by simply dividing the number of tokens currently residing within each side of the pool to get an exchange rate. Despite this approach would give us the best data freshness, it can easily be manipulated with the usage of tools such as flash loans.

So instead of just using the latest price, one can sacrifice some accuracy to increase manipulation resistance by using several data points instead of just one.

Limitations of the TWAP

Despite TWAP oracles being useful and convenient, they have some limitations when compared to oracles that can fetch off-chain data such as Chainlink.

• Freshness/Accuracy: By design, a TWAP is a lagging indicator that provides an average price taken over a period of time. While this approach is fine in periods of short volatility, it can become a significant issue during times of considering volatility because the TWAP desynchronizes from the real price. As previously explained, this manipulation-resistant approach is inversely correlated with data freshness, meaning safety needs to be prioritized over accuracy.

• Market Coverage: Another critical issue of TWAP oracles is that they are restricted to a single DEX. Note that this lack of market coverage makes it easier (it is cheaper since the liquidity of a DEX is lower than the overall market liquidity) for malicious actors to tamper with the price of a pool.

• Feed Diversity: Finally, and related to the previous point, since TWAP oracles are limited to the pools of a DEX, they can only provide coverage for on-chain assets (that's why we called them on-chain oracles).

So it can be concluded that TWAP oracles are better suited for low volatility assets with high liquidity.

Resources

If you are interested in oracles and want to do a deep dive into how they work, I recommend going over the following resources:

• Implementing a blockchain oracle by Pedro Costa

• Demonstration of the dangers of poorly selected oracles by samczsun

• TWAP Oracles vs Chainlink Price feeds by SmartContent

On top of that, we also had several crypto talks with amazing guests where we learned about Zero-Knowledge Proofs, Foundry, or the Graph protocol. Yes, I know what you are thinking... I have a lot of interesting topics in my backlog and I should definitely produce more content!

So, now that you know what we have been up to, let's focus on digital signature verification and ecrecover.

First things first. Digital Signatures

Before figuring out what the hell ecrecover is, we need to master the basics. You have probably signed messages with your wallet, but have you ever stopped think about how does it actually work?

Digital signatures work similar to asymmetric cryptography encryption but in the opposite way.

In digital signatures, some data is signed by hashing the message with the sender’s private key (and obviously a hashing algorithm too). This produces a hash digest, that can only be recreated by using one of the keys in the key pair used by the sender. The recipient will then use the sender's public key to hash the message and assert that it matches the received hash digest. If that happens, then the receiver can be sure that the sender was the one who signed the message, and that the message wasn't altered.

Elliptic Curve Digital Signature Algorithm

If you ever hear about Elliptic Curve Digital Signature Algorithm (ECDSA), you should know that it is one of the more complex and efficient public key encryption algorithms. Keys are generated via elliptic curve cryptography, which are smaller than the average keys generated by digital signing algorithms. Yet they are able to offer the same level of security as any other digital signature algorithms.

ecrecover

Smart contracts on Ethereum have access to the built-in ECDSA signature verification algorithm via ecrecover. This system method verifies the integrity of any arbitrary signed data and recovers the address corresponding to the signer by using v, r, s and the signature hash.

Signatures are interesting because users can approve stuff without having to submit a transaction. This feature is useful because it can improve the UX and reduce user gas costs by using meta-transactions or ERC20-permit (more on this later).

Nevertheless, as usual, better UX and convenience generally comes at the expense of security. Because of that, it is important to follow the community-developed standards and best practices when dealing with digital signatures.

Digital Signature Standards

There are three main standards that can be used to sign data with an Ethereum key:

• Eth_sign: The simplest, most powerful, and most dangerous way to sign a message. This method is used to sign arbitrary data, so it can lead to users signing data that enables a future transaction without further confirmation. This feature is extremely dangerous because users may sign those types of "uncovered" transactions without knowing it. Because of that, the usage of eth_sign is discouraged.

• Personal_sign: EIP-191 introduced a format to sign data and ensure that it wasn't a valid transaction. To implement this method in geth, they prefixed any signed data with "\x19Ethereum Signed Message:\n" + len(message). Thus, making it impossible to use these signatures as valid transactions.

"0x19 [1 byte version] [versidon specific data] [data to sign]".

• signTypedData_v4: To help standardize signature usage in Ethereum, EIP-712 was introduced and is currently widely used and considered a standard that helps developers avoid most common security issues when dealing with signatures.

How to implement EIP-712

The main goal of this EIP was to ensure that users understood what they were signing. Providing explicit context of the contract address and network. Finally, this EIP also aimed to ensure that each signature could only be used by the intended contract.

These requirements are achieved by combining a Domain Separator hash and a Typed Structed Data hash, and using them inside ecrecover.

• Domain Separator Hash: The domain separator is a hash that is computed from the domain data and is used to prevent reusability of one signature in another dApp.

• Typed Structured Data: The data that needs to be signed is defined using structs and Solidity primary types.

Meta-transactions

A meta-transaction is a method for separating who pays for the gas of a transaction from who benefits from the transaction's execution.

A user signs the meta-transaction and then sends it to an operator (note that since there is no interaction with the blockchain, no gas is required to sign). The operator takes this signed meta-transaction and submits it to the blockchain, paying for the fees of the outer, regular transaction himself.

ERC20-Permit

The ERC20 standard requires two different transactions to transfer ERC20 tokens from an externally owned account (EOA) by using a third-party smartcontract:

• First, the EOA needs to perform an ERC20.approve() transaction to whitelist the third-party smartcontract.

• Then, the EOA needs to call the function from the third-party smartcontract that triggers the ERC20.transferFrom() to transfer the tokens.

With the implementation of EIP-2612, also known as ERC20-Permit, it is possible to simplify the process by using signature verification. With the use of ERC20-Permit, users can simply sign the allowance amount with their wallet, and the operator can take care of the rest.

Vulnerabilities and Best Practices

Signature Reply Attack: Unless some precautions are taken, the same signature can be used multiple times to execute a function. To prevent these types of exploits, the use of nonces is extremely encouraged (note that in the EIP-712 implementation above I have already used a nonce to prevent this vulnerability).

Signature Malleability: Due to the symmetric structure of elliptic curves, for every set of v, r, s there is another different set of v, r, s that also has the same relationship. This results in two valid signatures and allows malicious actors to compute a valid signature without the target user's private key. The easiest way to solve this vulnerability is by using ECDS OpenZeppelin library.

Resources

If you are not familiar with basic encryption, you should definitely check Artemis' public slides. Shoutout to the team for progressively sharing the content of the course and making it accessible to anyone interested!

If you want to see implementations of meta-transactions and erc20-permit, you can look into these articles by soliditydeveloper.com.

Finally, if you want to get a really in-depth understanding of digital signatures and, especially, their potential vulnerabilities, I highly encourage you to check this great article by Immunefi, one of the leading bug bounty platforms.

After 4 weeks of classes, we are already past half of the course. Looking back we can see that we have already absorbed plenty of new knowledge and that the basics are already consolidated.

We started the week by doing a deep-dive on how memory and storage work, answering questions such as How do the slots get filled? How does the pointer work? etc. If you want to get more knowledge regarding these topics, make sure to check out the recommended resources at the end of this post.

But that's not all, we also focused delegatecall, a powerful, but also dangerous, type of external call that can be leveraged to achieve contract upgradability. Before we look into it, let me share with you an easy-to-implement gas optimization tip that you should definitely take into account when developing smartcontracts.

Tips of the week

Sponsored by Gonçalo.

Slot Packing

Slot Packing is an optimization technique that allows us to save gas by using the SSTORE opcode fewer times, thanks to consolidating multiple variables in the same storage slot (32 bytes).

Since the solidity compiler will automatically combine several variables in the same storage slot, you should try to initialize them in such a way that you use the minimum amount of slots.

msg.sender vs tx.origin

Both tx.origin and msg.sender are global variables that refer to the caller of a contract. Nevertheless, there are some key distinctions that need to be made.

Weather tx.origin refers to the original externally owned account that started the transaction, msg.sender indicates the immediate account (ether an EOA or another contract account) that invoked that interacted with the contract.

In order to prevent security issues, tx.origin should not be used for authorization. Instead, you should use msg.sender.

Delegatecall

A delegatecall is a type of external call that will execute some code of another smartcontract in the context of the caller. Therefore, despite some external code will run, the upgraded state variables will be the ones from the caller.

Because of the described properties, when working with contracts that use delegatecall, rather than looking at the variable names, we should focus on the slot positions that the external contract will modify in the caller's state.

To help you better understand how delegatecall works, and to also showcase some of its dangers, let's look into Ethernaut's Level 16 challenge.

Note: Ethernaut is a set of security-focused challenges developed by OpenZeppelin, that help aspiring web3 developers understand all the intricacies of the EVM.

Ethernaut Level 16

In this challenge, our goal is to take over the ownership of the Persistence contract. To do so, we will exploit some vulnerabilities due to a poor understanding of the mechanics behind delegatecall and storage updates.

As you can see, when using delegatecall to execute the function setTime() from LibraryContract, we will be actually modifying slot0 of the Preservation contract (instead of the variable storedTime which points to slot4).

By properly encoding the attacker contract address into the delegatecall inputs, we can change slot0 so that timeZone1Library points to the attacker contract. Once we have managed to do so, we can execute any code we want to take ownership of the Preservation contract.

Now that we know what the attack will look like, we just need to implement the attacker contract.

Let me remark that to take ownership of the target contract, we need to properly initialize the slot pointers of the Attacker contract (unlike LibraryContract did). Then, it is just a matter of modifying the value of owner (slot3).

You can find the full implementation of this challenge in my Github repo.

Note: At the time of writing, I am still going over the Ethernaut challenges, so you may not find all the solutions there.

If I had to emphasize something about this post it would be the importance of a mindful slot storage initialization in your contracts, especially if you are dealing with delegatecall.

Recommended Resources

I highly encourage you to go over the Ethernaut challenges. You will be able to test your understanding of some basic solidity concepts while forcing yourself to code.

If you want to do a deep dive and better understand how storage works, I recommend checking this article by BetterProgramming. The article is really long, but you don’t need to read it all at once or completely.

Although in this post we didn’t go over contract upgradability, we introduced delegatecall, which is the opcode that enables contract upgradability. If you want to get a better understanding of how do upgradability implementations look like, I encourage you to look into the Universal Upgradable Proxy Standard (also known as just UUPS).

After getting started with solidity and learning the basics, the next step is to get as familiar as possible with the language. The best way to do so is clear: code as much as possible.

This week we did both active coding tasks, where we had to solve several challenges, and hands-on sessions where we would see the teachers code.

By following this approach, we covered ERC20 and ERC721 tokens (implementing the code ourselves, but also using the OpenZeppelin and Solmate libraries), we created a wETH token contract, a simple staking contract, the bare bones of an AMM, and even a basic voting system based on NFTs.

Since there is a lot of ground to cover, a simple post wouldn’t be enough to go through these implementations. Instead, I recommend checking the ERC20 and ERC721 contracts from OpenZeppelin, since it is an easy way to familiarize yourself with these token standards.

Note: Solmate is also great, but since they follow a minimalist design to optimize gas costs, it is less intuitive for someone new to solidity.

Because of that, this week we won’t be covering any exercises. Instead, we will do a deep dive on a typical security bug: reentrancy attacks.

Last week when going through the differences between send, transfer, and call functions, we saw that it is best to use call() in combination with Reentrancy Guard or the checks-effects-interactions pattern to protect your functions.

But, what is a reentrancy attack? What are these protection methods? Let’s dive into it.

The Reentrancy Attack

As a smart contract programmer, one of the first things that you should learn is that external calls to untrusted contracts can introduce several unexpected risks and errors. External calls may execute malicious code in your contracts (and also in any other contract that depends on yours), taking over the control flow, and modifying the data that your functions were expecting. As such, every external call should be treated as a potential security risk.

A classical exploit pattern that leverages external calls to drain a smart contract is the reentrancy attack. As described in the diagram below, this type of attack leverages a customized fallback() function to repeatedly call withdraw() before the user balance is updated. By doing so, the exploiter is able to effectively transfer all the deposited funds into the vulnerable contract to its own.

Note: If you perform an external static call, you will not have to worry about reentrancy attacks, since won’t be able to perform any status changes.

Check-Effects-Interaction Pattern

A best-practice programming pattern that prevents unexpected executions of a contract. This pattern ensures that the contract author controls all the state variables by following some design principles. The key idea behind the check-effects interaction pattern is that a contract should always check and modify the state variables before performing any external calls.

Let’s break down the design principles into 3 different steps.

• Checks: Validate whether the inputs are acceptable or not. Invalid inputs can return false and be manually handled, or fail hard and ensure that the transaction reverts. Note that if the transaction reverts, the world state won’t suffer any changes.

• Effects: Update the contract to a new valid state, assuming that the subsequent interactions will succeed. This step protects the contract from re-entrance and race conditions.

• Interactions: Lastly, the contract should invoke any external functions or perform the low-level function call(). On a general basis, you should generally limit interactions to "untrusted" contracts. You must always check the result of those interactions.

  If the called contract "hard fails" with require() or revert() then the whole transaction will revert. But, if the external call returns(bool success) then you need to check for the false condition and manually handle it.

To better understand the described principles, let’s look into some examples.

Example 1: Single-function vulnerability

Example 2: Multi-function vulnerability

Despite you may not be performing an external call directly in one of your functions, you may be doing so in an indirect manner by calling an internal function which, in its turn, performs the external call. Whenever you are facing this scenario, you should treat that internal function (the one which performs the external call) as an untrusted function. Therefore, you must stick to the check-effects-interaction pattern in both functions.

Reentrancy Guard

Another common practice is to use the Mutex pattern, also known as Reentrancy Guard. This method leverages the usage of modifiers (in combination with some checks) to lock the contract and ensure that a given function cannot be reentered until finishes its execution and the contract is unlocked.

Recommended Resources

In case you want to use OpenZeppelin’s implementation of the Reentrancy Guard in your contracts, you can check their GitHub repo.

You may have noticed the small warnings that appear vscode scripts whenever there is an external call. If you want to have them too ―despite being simple it can help you avoid mistakes―, install the Solidity Visual Developer extension that Consensys developed. It has plenty of interesting features.

After covering a lot of theoretical (but yet important) ground in the previous 2 weeks, we finally got into solidity. This week has been packed with basic concepts and plenty of exercises to get familiar with the language. We went through the different object types, functions, events, modifiers, inheritance, etc.

There are plenty of excellent online resources which are publically available. On top of that, they are in all sorts of formats, so you can check both written and video formats.

Because of that, instead of explaining all these basic concepts, I will try to explain a couple of interesting things worth sharing (i.e. security and gas optimization tips), and also go through my thought process when attempting to solve some exercises.

Tips of the week

Sponsored by Gonçalo.

send vs transfer vs call

Despite the 3 methods can be used to transfer ether, they have key distinctions that are worth knowing. send() and transfer() used to be recommended, because they would limit gas expenditure to 2300 gwei. With this amount of available gas, people were able to do minor fallback operations like emitting events or even updating storage, but it wasn't enough to reenter a contract. Nevertheless, this was never a good method to avoid reentrancy attacks, as gas costs can vary with protocol updates (i.e. the Istanbul fork increased the gas cost for the SLOD opcode).

Because of that, it is recommended to use the low-level function call(), which defaults to forward all the available gas. Then, you can use a Reentrancy Guard or the checks-effects-interactions pattern to protect your functions.

Note: For a more detailed explanation, read this article.

indexed event parameters vs non-indexed (regular)

Events with indexed parameters are easier to retrieve because they are specially indexed in the world state (in the logsBloom). Because of that, they are slightly more expensive than events with only regular parameters.

This explanation can be confirmed with this simple Foundry example:

Note: Logs are composed of Topics (up to 4) and Data. One topic is reserved for the event signature, so you can have a maximum of 3 indexed parameters.

In the Ethereum Yellow Paper, it can be asserted that each topic costs 375gwei, and each byte in data costs 8gwei * numberBytes.

Task. Creating a basic Crowdfunding Platform

Implement the backbone for a simple Crowdfunding platform with the following requirements:

• Anyone can create a campaign to acquire funding for their project.

• Each campaign must, at least, have:

  - A name.

  - An owner.

  - A campaign type (start-up or charity).

  - A funding goal.

  - A time limit to reach it, which can't be higher than 60 days.

• All of the above properties must be defined at campaign creation, and can't be updated.

• Until the time limit of a given campaign is reached, anyone can fund it by sending Ether. After the time limit is reached, it can't receive any more funds.

• The owner of a campaign can only withdraw the raised Eth after the time limit is reached.

• After the owner withdraws the funds, campaigns should be marked either as Fully-Funded (if raised >= funding goal) or Partially-Funded (if raised < funding goal).

• An owner must be able to cancel a campaign. If this happens that campaign can't receive any more Ether.

• Implement all the relevant events.

Solution Design

When having an idea, the first thing you need to figure out is the architectural design that your solution should have. In this case, the most reasonable thing to do, in my eyes, was to have an independent contract for each campaign, so owners could directly interact with it and have full ownership. Because of that, I decided to create a factory contract CampaignFactory and a campaign contract called Campaign.

Because of the explained architecture, I started by creating the Campaign contract, making sure that it was compliant with all the given requirements.

Note: you can find the full script in this GitHub gist.

First of all, we need to define the variables and any enum or structs that we may need.

Once we have set up all the variables, we can create the contract constructor. In this case, the constructor will use a require() to ensure that the deadline is less than 60 days.

Since in solidity timestamps are expressed in unix (a second-based system that starts on January 1st, 1970), the input variable _deadline used in the constructor will have a relative scope (see that the require clause states _deadline <= 3600*24*60 ). Nevertheless, the global variable deadline will have an absolute reference, so that we can compare it with any given timestamp.

After coding the contract constructed, I then created the relevant events and some modifiers that will help with the required validations that we will have to implement in the campaign functions.

Finally, we need to implement the contract functions. In this case, we only need 4 functions: fallback(), receive(), withdrawFunds(), cancelCampaign().

For both fallback() and receive() to be able to receive ether from other contracts and EOAs, we need to make them payable. On top of that, we will also add the liveCampaign modifier to ensure that no more donations are received after a campaign is closed.

Another topic worth mentioning is how to deal with withdrawals. As explained before in the tips of the week section, the low-level function call() is used.

With this, the campaign contract is finished. Now, we only need to create the crowdfunding factory contract.

In this case, the factory contract will only have a single function that will deploy a new instance of the campaign contract whenever it is called. On top of that, we will also add a couple of mappings to better deal with the deployed campaigns. These mappings will be tracking the deployed campaign contracts by owner (using an array), and the amount of deployed campaigns by each of them (to navigate the array).

Recommended Resources

If you want to get started with Solidity from the ground up, you should definitely check this youtube playlist by @SmartContractProgrammer.

If you prefer written content, you will also find plenty of resources on this webpage.

Second week of lectures at Artemis, where despite we kept covering the fundamentals behind the technology, we also started to get into more practical stuff.

This week we covered different topics around the Ethereum ecosystem: proof-of-stake, nodes, clients, and the EVM. Again, all of them are interesting topics and with plenty of side-quests that could be explored. Nevertheless, I will focus on the Data Storage Layer and the Ethereum Virtual Machine.

Personally, I plan to further familiarize myself with the opcodes in the upcoming weeks, since they can help provide a better understanding of the overall system and potentially help with gas optimization and even security.

Data Storage Layer

To fully comprehend Ethereum it is key to first learn how its data storage layer works. To do so, the following topics should be understood.

Merkle Patricia Trie

A trie is an easy-to-implement and small-memory data structure that is extremely fast at finding common prefixes. As Ethereum uses a Merkle Tree to efficiently store hashes in blocks, the development of a new data structure called “Modified Merkel Patricia Trie” became the core of data storage. Because of that, the world state trie, the Account State, the Receipt trie, and the Transaction trie are implementations of a Merkle Patricia Trie.

World State

The world state trie keeps a mapping between addresses (EOAs and contract accounts) and their account states. It can be seen as a global state that is constantly updated by transaction executions.

It is important to note that despite the world state trie can be used to retrieve all the accounts’ state information from a root hash (storage root), the actual information is stored in the Account State trie.

Finally, it is also important to take into account that all this information is not stored on the blockchain. Instead, a single root hash (state root) representing the latest state, is stored in each block. The state root is enough for light nodes and full nodes to request world state data to full nodes and archival nodes respectively.

Note: If you are not familiar with it yet, you can check the characteristics of the different node types here.

Transactions

Transactions are cryptographically signed instructions initiated by accounts. Transactions are the reason behind changes in the world state, and can result in message calls or the creation of new contracts.

Similar to the world state trie, each block has its own separate transaction trie. This trie stores both the transaction-related information and the transaction order decided by the miner who assembled the block.

Blocks

A block is composed of two different parts: the header and the body.

• Block header: Actual “block-chain” part of Ethereum. Contains the hash of its predecessor, ensuring an untampered chain.

• Block body: Contains a list of transactions that have been included in the block and a list of uncle/ommer block headers.

All the exposed information can be summarized in the following diagram:

EVM Basics

The EVM is a virtual, stack-based computation engine that powers the Ethereum Blockchain by enabling it to run and deploy smart contracts.

One can think of EVM as the execution environment for the Ethereum blockchain. As such, the EVM consists of opcodes (operation codes), which can be conceptualized as a set of instructions with associated gas costs.

Since the EVM is deterministic, Ethereum can be described as a network with a state transition function where, given a state and a set of transactions, the network will transition towards a new valid state.

High-level Language → Byte Code → Opcode

Smart contracts are compiled into bytecode, which is then executed by the EVM as a set of opcodes that perform specific tasks. In combination with enough resources, these opcodes allow the EVM to compute almost anything, grating it Turing-completeness.

EVM Architecture

The EVM execution is controlled by a 1024-item-deep stack, where each item is a 256-bit word. During execution, the EVM maintains a volatile memory that works as a word-addressed byte array, and which does not persist between transactions. Contracts, however, can use storage tries (as addressable key-value pairs), associated with the network accounts to access persistent data.

EVM State transition

As explained before, to move into a new state, the EVM needs to have an initial state to transition from, and a set of transactions in charge of the state changes.

If these requirements are fulfilled, every new transaction will either perform a message call or deploy a new contract. Regardless of the transaction nature, the stack will be populated with the corresponding opcodes and data, to effectively compute some operations and transition into a new state.

Recommended Resources

If you feel like a quant today, you should definitely check the Ethereum Yellow Paper.

If you want to have a more in-depth view of how the Ethereum Virtual Machine works, check this article.

You can find all the different opcodes, their explanation, and their minimum gas consumption here.

If you want to fully understand opcodes and their correlation with stack, memory, and storage, I highly encourage you to play around with this awesome tool.

Finally, I would like to give credit to Gonçalo for explaining all these complex topics in such a comprehensive manner.

This industry grows fast, and there is plenty of information to be aware of if you want to be a successful developer. Because of that, Artemis offers an 8-week course that covers the very basics of blockchain development (to set a solid foundation), and which will finally go into more advanced stuff (to give students the required tools to keep improving on their own).

The course will not only focus on development but will also have complimentary weekly talks regarding different interesting topics that will help students get a clearer picture of the industry. Despite these talks will be really insightful and given by reputable industry personalities, I won't cover them in this dev journal because I want it to be focused on technical stuff. Instead, I will most likely write about some of them in my main blog (check it out if you haven't already).

Let's begin. Artemis Week-1

First things first. Introduction week, where we went through the history of money, the history of blockchains, we did some basic cryptography (asymmetric keys, hash functions, etc.) and also went through consensus mechanisms. Despite all of the topics being really interesting, today we will focus on distributed systems and consensus mechanisms.

Distributed Systems

A distributed system contains multiple nodes that are physically separated but connected using a network. All the nodes in the system communicate and coordinate with each other to reach an agreement on a variety of topics (single data values, new transactions, the state of the network, etc.).

On top of that, it is necessary to not only coordinate but also maintain system reliability even in the presence of faulty processes. Distributed systems are especially useful because of their ability to not have a single point of failure.

The Byzantine Generals’ Problem

Distributed systems must be able to handle downtime/failure of their components, and must also be resistant to malicious operators who attempt to alter the state of the network.

In 1982, Leslie Lamport, Robert Shostak, and Pease Marshall created an abstraction of this problem and presented it in a paper called The Byzantine Generals Problem. One of the hardest problems in distributed computing systems, and which was thought to be unsolvable for many years.

The generals face several challenges such as:

• Finding out whether the content of a message is true (sent by an honest general) or not (sent by a traitor).

• Being certain that the information in a message hasn’t been tempered.

The only way for the generals to succeed is if they stick to an algorithm that gives them an action plan that helps them move from a deterministic problem to a probabilistic one.

Byzantine Fault Tolerance

A Byzantine Fault Tolerance (BFT) system is able to overcome the Byzantine Generals problem, and therefore successfully operate even if some nodes fail or act maliciously.

With the release of the Bitcoin whitepaper, Satoshi Nakamoto was able to design a BFT system on a peer-to-peer network. This achievement was possible thanks to the combination of cryptography security, and the development of a consensus mechanism called proof-of-work (PoW).

Cryptographic Security

Satoshi used cryptographic hash functions and public-key encryption to prevent data tampering and to verify the identity of networks.

Cryptographic hash functions are algorithms that take an arbitrary amount of data as an input and produce a fixed-size output of enciphered text called a hash.

Hash functions are especially useful for security purposes due to their properties:

• Non-reversible. Hash functions are unidirectional, they make it very hard to reconstruct the original input from the hash.

• Avalanche effect / Non-predictable. A change in just one bit of the original input results in a completely different hash.

• Determinism. A given input always generates the same hash value.

• Collision resistance. Different inputs shouldn’t produce the same hash.

With the usage of cryptographic hash functions, transactions can be secured in a block that connects to other blocks by its hash value. All hashes can be traced back to an initial block that is the root of all hashes. Note that by ensuring that each block stores the hash of the prior block, we can be certain that previous data hasn’t been altered. This hash structure is known as a Merkle Tree, and it is used to verify hashes that originate from the genesis block.

Proof-of-Work

PoW is a consensus mechanism that established a set of rules to validate and add new blocks into the network, and, therefore, solve the Byzantine generals’ problem.

According to Satoshi, the generals must agree on a difficulty metric. Let’s say that this metric states that the final hashed value must start with three 0s. The generals will then create a message and hash it until the output sticks to the agreed difficulty condition.

Note that if someone (the messenger or other generals) tries to tamper with the message, the final hash will change drastically and it won’t be taken as valid because it won’t stick to the pre-agreed rules. The only option for traitors is to find another nonce that will result in a final hash that sticks to the difficulty condition. Since we already know that this is a resource-intensive process, the traitors won’t easily be able to find a new hash.

When the message is received, it can easily be validated by hashing the nonce and the message and checking it against the provided hash.

Recommended Resources

If you want to visually understand everything that is being discussed in this piece, would highly encourage you to check this video by Austin Griffith.

If you prefer a more academic description of the topic, I also encourage you to go through the resources of Distributed Systems course at the University of Cambridge.