DEV Community: SK Sabiruddin

Solidity Gas Optimization Techniques

SK Sabiruddin — Wed, 07 Feb 2024 05:09:29 +0000

Gas Units:

Making transactions on Ethereum or any other Ethereum backed blockchain will cost you a gas fee. The total gas fee consists of two parts: Gas Units x Gas Price
Gas units are a number that depends on the amount of computation required for a transaction. E.g. If you send some Ether (Ethereum’s native cryptocurrency) to someone, it requires 21,000 gas units. It’s the minimum number of units required for any transaction.
The number of required gas units increases as the complexity of the transaction increases. E.g. Sending an ERC-20 token might cost around 60,000 gas units. Minting an NFT might cost around 120,000 gas units, and so on.
It all depends on how many computations need to be made while processing the transaction.

Gas Price:

Gas price is determined by the demand for making transactions. The more the traffic, the higher the price.
It’s usually expressed in Gwei which is a billionth part of an Ether. If the gas price is 100 Gwei, it means 1 gas unit currently costs 100 Gwei as per the demand. The gas price will vary throughout the day depending on the total traffic.

Let’s combine these two now. If you need to send some Ether to someone at a time when gas price for 1 gas unit is 100 Gwei, you’ll have to pay a total of: 21,000 gas units x 100 Gwei = 2,100,000 Gwei.
Since Gwei is 1/1bn of Ether, you’ll pay 0.0021 Ether.
To find the amount in dollars, multiply it with the current price of ether i.e. 1200 USD. Hence 0.0021 Ether x 1200 USD = 2.52 USD total gas fee. To summarise, the gas fee depends on:
- Complexity of transaction (gas unit)
- Demand for making transactions (gas price)
- Price of Ether (to calculate dollar value)

Where does my gas fee go?

So, we know that we need to pay a gas fee when making a transaction. But where does it go now? Is it burnt? Or is it given to the validator?
Actually, it’s both, after the EIP-1559 (an upgrade to Ethereum that happened in September 2022).
Total gas fee is made up of:
- Base Fee (fixed for every transaction of a block) – which gets burnt entirely.
- Max Priority Fee (decided by the user) – which goes to the validator partially or entirely depending on the Max Total Fee which is again decided by the user.
Let’s run through an example:
- Suppose a user wants to pay a Max Total Fee of 100 Gwei per gas unit consumed for the transaction. It’s inclusive of the Base Fee (burnt) and Max Priority Fee (for validator).
- While making the transaction, the user doesn’t know what the exact Base Fee will be for the transaction/block.
- During peak time, a lot of people will be trying to make a transaction, thus congesting the network. This will cause your transaction to take a long time before going through. In order to prioritise his/her transaction, a user may want to pay some (extra) fee to the block validator. This fee is called the Max Priority Fee. Suppose the user wants it to be 30 Gwei per gas unit.
- Hence, the user enters the values of 100 Gwei and 30 Gwei respectively.
- When the block is confirmed, there are 2 possibilities depending on what is the final value of Base Fee:

Case 1: Base Fee + Max Priority Fee <= Max Total Fee
    example:
    Base Fee = 60, Max Priority Fee = 30, Max Total Fee = 100
    Hence,
        - 60 Gwei is burnt, (per gas unit)
        - 30 Gwei goes to the validator, (per gas unit)
        - The remaining 10 Gwei is refunded to the user (per gas unit)

Case 2: Base Fee + Max Priority Fee > Max Total Fee
    example:
    Base Fee = 80, Max Priority Fee = 30, Max Total Fee = 100
    Hence,
        - 80 Gwei is burnt, (per gas unit)
        - Only 20 Gwei goes to the validator (per gas unit), since Max Total Fee is 100 Gwei
        - 0 refund for the user since the max limit is consumed.

Note: Base Fee can’t be >= Max Total Fee. Your Metamask wallet will let you know if the Max Total Fee entered by you is not sufficient as per the network conditions.

How to save Gas Cost:

Important: This document contains useful information to optimize your Gas Cost in Ethereum Blockchain. The following document contains 90% of the gas optimization techniques in Ethereum.

We will see which method is useful and which method is useless. (or event harmful)
We will see how much gas you can save by using each method.
We will rank all the methods by using a tier list. (A = excellent, D= useless/harmful)

1. Deployment optimization vs Call optimization:

At first, you need to know that there are 2 ways to optimize gas on a Decentralized Application.

A). Optimizing Deployment costs:

You can optimize the cost to deploy a smart contract.
The cost = 21000 gas (for creating transaction) + 32000 gas (for creating a contract) + CONSTRUCTOR EXECUTION + BYTES DEPLOYED * 78.125
So, for deploying a smart contract, you will spend at least 53000 gas.
To minimize gas costs you need to minimize the size of a smart contract and the cost of the constructor.

B). Optimize every function call:

You can also optimize the cost of calling every function in your smart contract.
The cost is equal to21000 gas (for creating transaction) + the function execution cost).
So, the objective will be to reduce the function execution cost.

Note that these 2 means of optimization are not the same!!

A lot of times, you may deploy a larger solidity code (so with higher deployment gas cost) but more optimized for every function call. (So with a smaller calling gas cost)
If you need to choose which type of optimization, you need to use it wisely.
I strongly advise you to optimize every function call as the deployment is made only one time and the user experience will be enhanced. (unless your smart contract size exceeds the limit of 24Kb)

2. Ranking Gas optimization methods:

We will rank all the gas optimization methods by using a tier list. (Because there is a difference between saving 2 gas on a transaction of 21000 gas and saving 10000 gas.)
- Tier A: If you don’t know these rules, you’re not a TRUE solidity developer.
- Tier B: Essential, should be known by all the developers.
- Tier C: may be useful sometime, should be known by developers too.
- Tier D: Useless/harmful, don’t use them (unless you know what you are doing). You may lose, either your time or the security of the smart contract.

Tier A:

A1 : Knowing how much each EVM opcodes cost:

Here is the 6 of the most costly gas opcodes (among the most used is smart contracts):
- CREATE/CREATE2 -> Deploys a smart contract. (32,000 gas)
- SSTORE -> Stores a value in storage. (20,000 gas if the slot hasn’t been accessed, 2900otherwise.)
- EXTCODESIZE -> Get the size in bytes of a smart contract code. (2600 if not accessed before, 100 gas otherwise)
- BALANCE (address(this).balance), same as EXTCODESIZE.
- SLOAD -> Access a value in storage. (2100 gas if not accessed before 100 gas otherwise)
- LOG4 -> Create an event with 4 topics. (1875 gas)
(This is in fact an estimation. Some of them may vary depending on the situation.)
The best website which describes how much each opcode is https://www.evm.codes/, it’s very well explained.
If you know that, you’ll better understand solidity and you’ll get a “better” intuition of how much each line of code costs you.

A2: Use view the modifier:

      function getBalance() external view {
                return balance;
        }

You can easily cut your gas costs to 0 when you call the smart contract if you don’t write to the storage. (moreover, you don’t need to wait 5–20 seconds the response)

A3: Understand the solidity programming language & A4: Become good at computer science/algorithms.

Tier B:

These tips and tricks can save you a good amount of gas and should be implemented as much as possible. IMPORTANT NOTE BEFORE STARTING:

As the not_optimized() function is situated before optimized() function in the byte code, Calling optimized() costs more than not_optimized() with the same code (22 more gas), so I will subtract 22 gas on each call tooptimized() function.

B1: Batching operations (Saved gas: 21000 gas * batched transactions):

Submitting a transaction alone on the blockchain costs a lot of gas (21,000 gas to be precise), so if you can find a way to batch transactions for your users, it can save you a good amount of gas.

B2: change orders of storage slot (20,000 gas saved at deployment):

Ethereum storage is composed of slots of 32 bytes, the problem is that writing is expensive. (Up to 20,000 gas using “cold” writing)
Let’s say you have 3 variables:


    // These vars use 3 different storage slots
         unit128 a; // slot 0(16 bytes)
         unit256 b; // slot 1(32 bytes)
         unit128 c; // slot 2(16 bytes)

    // These var use 2 different storage slots
         unit256 b; // slot 0(32 bytes)
         unit128 a; // slot 1(16 bytes)
         unit128 c; // slot 1(16 bytes)

But if we align the 3 slots well, we can economize 1 slot. (a and c variable will be in the same slot)
Therefore, there are 1 less used slot at the deployment. (So 20,000 gas saved)
Moreover, if you want to access the c variable, but the b variable is already accessed. It will count as a warm access (accessing a storage slot already accessed) so it will cost you 1000instead of 2900 gas which is pretty significant.
If you don’t understand the storage, the documentation may help you: https://docs.soliditylang.org/en/v0.8.13/internals/layout_in_storage.html

B3: Use the optimizer (Saved gas: 10–50% on deployment & call):

You can use the solidity built-in optimizer.
This is a very simple way to save a lot of gas without learning any new concepts. You need to check the “enable optimization” checkbox under Advance configuration section.
A value near to 1 will optimize gas cost, but a value near to the max (2³²-1) will optimize calls to the function. In most of the cases you can use the default value (200)

B4: use mapping instead of array (5000 gas saved per value):

Mappings are usually less expensive than arrays, but you can’t iterate over them.

      mapping(unit => unit) map;
      unit[] map2;

      function not_optimized() external{
          map2.push(10);
      }

      function optimized() external{
          map[1] = 10;
      }

not_optimised() function gas usage: 48,409 gas
optimised() function gas usage: 43,400 gas

B5: Use require instead of assert:

Assert should NOT be used by other means than testing purposes. (because when the assertion fails, gas is NOT refunded contrary to require)

B6: Use self-destruct (save up to 24,000 gas):

selfdestruct() function destroys the smart contract and refunds 24,000 gas.
In a more complex transaction like deploying another smart contract, you can call selfdestruct() on the smart contract to economize some gas.

B7: Make fewer external calls (amount saved: variable):

Make a call to another contract only when you’re obligated to do so.

B8: Look for dead code (saves a variable amount of gas on deployment):

Sometimes, developers forget to remove useless code like:

      require(a == 0)
      if (a == 0) {
         return true;
      } else {
          return false
      }

This is a dump example because it shows you that some devs can forget to remove useless parts.

B9: use immutable variables (saves 15,000 gas on deployment)":

Use immutable storage variables whenever it’s possible.

       contract not_optimised{
           unit256 public a;
           constructor(unit256 _a) public {
             a = _a;
         } 
      }

       contract optimised{
          unit256 public immutable a;
          constructor(unit256 _a) public{
            a = _a;
         } 
       }

not_optimisedcontract gas usage: 11,6800 gas
optimised contract gas usage: 10,1013 gas

B10: Storing data in events (up to 20,000 gas saved on function call):

If you don’t need to access the data on-chain in solidity, you can store it using events.

          address store;
          event Store(uint256 indexed key, 
                      address indexed data);

          function not_optimized() external{
              store = 0xaaC532..;
           }

          function optimized() external{
              emit Store(1, 0xaaC532..);
           }

not_optimised() function gas usage: 43,353 gas
optimised() function gas usage: 22,747 gas

Tier C:
These tips can save you a fair amount of gas and cost you nothing.

C1: Use static size type in solidity (about 50 gas saved):

Static size types (like bool, uint256, bytes5) are cheaper than dynamic size type (like string or bytes).

         function not_optimized() external{
              bytes4 memory str = "abcd";
          }

          function optimized() external{
              bytes4 str = 0x61626364;
          }

not_optimised() function gas usage: 21,255 gas
optimised() function gas usage: 21,227 gas

C2: Cold access vs warm access (70 saved gas):

Don’t access the same storage variable twice.

            uint256 a = 100;

            function not_optimized() external{
                uint b   =  a;
                uint c   =  a;
            }
            function optimized() external{
                uint tmp =  a;
                uint b   =  tmp;
                uint c   =  tmp;
           }

not_optimised() function gas usage: 23,412 gas
optimised() function gas usage: 23,347 gas

C3: Using calldata instead of memory (450 saved gas per call):

        string str;

        function not_optimized(string memory _str) external{
            //code ...
          }

        function optimized(string calldata _str) external{
            // code...
         }

not_optimised() function gas usage: 22,442 gas
optimised() function gas usage: 21,994 gas

C4: Use Indexed events (62 gas saved on function call per topic):

You can mark each event as indexed as bellow:
Indexed events allow events to be searched more easily.

       event Test1(address a, address b);
       event Test2(address indexed a, address indexed b);

       function optimized(string calldata _str) external{
          // code ...
        }

       function not_optimized() external {
            emit Test1(0x..,0x..)
        }

       function optimized() external {
            emit Test2(0x..,0x..)
        }

Here the function optimised() uses 135 less gas than not_optimised().

C5: Changing the order of calls (20–2000 saved gas per call):

We can call every smart contract, you supply in msg.data the signature of the function. (the first 4 bytes of the function keccak256 hash).
Firstly, the EVM will do a “switch” of this signature, to see which function to execute.

      switch(msg.data[0:4]) { // compare to signature
        case 0x01234567: go to functionA;

        // cost 22 more gas..
        case 0x11111111: go to functionB;

        // cost 22+22 more gas... 
        case 0x4913aaaa: go to functionC; 
              ...
      }

As comparing to signature computation use a bit of gas (22 gas), you need to place the most called function in the first place of the switch() by assuring that the signature is in the first place (by changing its name)
You can learn more about this par is my reversing EVM articles: https://trustchain.medium.com/reversing-and-debugging-evm-smart-contracts-392fdadef32d

C6: Use ++i instead of i = i+1 (62 gas saved on each call):

This sounds like a joke, but it seems to work.:

        function not_optimized() external{
             uint i = 10;
             i = i + 1;
         }

         function optimized() external{
              uint i = 10;
              ++i;
         }

not_optimised() function gas usage: 21,401 gas
optimised() function gas usage: 21,339 gas

C7: Use uint256 instead of uintXX on storage (55 gas saved per call):

To write/access data on storage, the EVM uses 32 bytes (= 256 bits slots), by using smaller types than uint256, the EVM needs to perform additional operations to assure the conversion. So better to use uint256 instead of uint8 for storing data.

         uint256 balance;
         uint8 balance2;
         function not_optimized() external{
                balance2 = 10;
          }

         function optimized() external{
                balance = 10;
         }

not_optimised() function gas usage: 43,353 gas
optimised() function gas usage: 43,298 gas

C8: Create a custom error (24 gas saved per call):

You can create a custom error on solidity and revert with it like below:

          error err(string test);
          function not_optimized() external{
                revert("test");
           }

          function optimized() external{
                revert err("test");
           }

not_optimised() function gas usage: 21,476 gas
optimised() function gas usage: 21,474 gas

C9: Exchanging 2 variables by using a tuple (a, b) = (b, a) (saves 5 gas on every call):

          function not_optimized() external{
               uint i = 10 ;
               uint j = 20 ;
               uint temp = i ;
               i = j ;
               j = temp;
           }

           function optimized() external{
               uint i = 10;
               uint j = 20 ;
               (i,j) = (j,i);
           }

not_optimised() function gas usage: 21,241 gas
optimised() function gas usage: 21,236 gas
We put it on the C tier because the notation is way more readable.

C10: Use Calldata instead of Memory in function arguments in case of not changing the passed data:

Using calldata in a summing function that loops over an input array can save about 1829 gas (or 3.5%) on average.

      function not_optimised(uint[] memory nums) external {
        for (uint i = 0; i < nums.length; ++i){
         // code ...
        }
      }

     function optimised(uint[] calldata nums) external {
        for (uint i = 0; i < nums.length; ++i){
       // code ...
         }
      }

not_optimised() function gas usage: 50,992 gas
optimised() function gas usage: 49,163 gas

Tier D: (Useless/harmful)

These optimizing gas tips are useless, don’t lose your time for saving a low amount of gas it will be shadowed anyway by the 21,000gas transaction.

D1: using unchecked (gas saved: 150/operation):

Since solidity 0.8.0, operations like + * / — are checked every time if there is an overflow/underflow.
But it cost a little bit of gas to verify if there is an overflow/underflow.
Unless you are doing a lot of operations in a single function call (like in for loops), you should NOT use unchecked{}.

         function not_optimized() external{
              uint i = 10 ;
              uint j = 20 ;
              uint add;
              add = a + b;
          }

          function optimized() external{
               uint i = 10 ;
               uint j = 20 ;
               uint add;
               unchecked {c = a + b};
           }

not_optimised() function gas usage: 21,419 gas
optimised() function gas usage: 21253 gas

D2: changing and optimizing the bytecode yourself:

Don’t do this unless you have a good reason to do so, some of the functions may end up with undefined behavior and security issues.
Use the optimizer instead or implement a very strict testing policy.

D3: Delete Errors string messages (about 78.125 gas saved on deployment cost per characters):

Don’t do it, the code may be harder to debug for you and for users. Use the custom errpr instead.
For example, someone can replace:

         require(account != address(0), 
           "ERC20: mint to the zero address");
    To:-
         require(account != address(0))

D4: using low level assembly (gas saved: variable):

If you don't know what you’re doing, DON’T do solidity assembly. You will end up having a lot more chances to have a security hole on your contract for a marginal saved gas amount.

D5: Use external instead of public:

Surprisingly they are not any difference between external and public functions,

       function not_optimized() public returns (uint){
                 return 777;
             }
       function optimized() external returns(uint){
                return 777;
           }

not_optimised() function gas usage: 21,401 gas
optimised() function gas usage: 21,379 gas (22)

D6: Use left shift instead of multiplication >> (150 saved gas):

Shifting binary data n times to the left results in multiplying the data by 2^n. Here is an example:

      00000001 = 1 dec
      00000010 = 2 dec
      00000100 = 4 dec
      00001000 = 8 dec

     function not_optimized()  external returns (uint){
                   uint a = 5;
                   uint b = a * 1024;
                   return b;
              }

     function optimized() external returns(uint){
                   uint a = 5;
                   uint b = a >> 10;
                   return b;
              }

not_optimised() function gas usage: 21,615 gas
optimised() function gas usage: 21,436 gas
Gains are not bad, but the >> operator doesn't check for an overflow.

D7: Delete metadata hash (3000–5000 gas on deployment):

On every smart contract byte code a “hash” is appended in the end.
This is the hash of all the metadata of the smart contract. (Including abi, comments, code…)
As the metadata hash is 32 bytes in length, it can save you a bunch of gas.
But this is quite hard to do, because you have to do it by hand.
So it may be dangerous if executed badly.

D8: Add payable to every function (24 gas saved per call):

Adding payable to a function, removes the verification on msg.value. Therefore, some gas is saved.

          function not_optimized() external{
              // code ...
          }

          function optimized() external payable{
               // code ...
           }

not_optimised() function gas usage: 21,186 gas
optimised() function gas usage: 21,184 gas

D9: Doing the important work offchain:

Be careful about the work you’re doing off-chain (Like in JS).
For example, you can’t do security verification off-chain in the website front end, this is very dangerous as anyone may be able to change the JS code in the browser and send bad input to the smart contract.
ALWAYS DO THE SECURITY VERIFICATION ON-CHAIN.!!!

Some other gas saving techniques: -

    - Loading state variable to memory
    - Replace for loop i++ with ++i
    - Caching array elements
    - Short circuit

Some more details: (Credit - CodeEater)

Internals of Solidity Compiler:

About Nonce:

Why Gas Cost 21000:

How's The Transaction Fee Calculated:

How's The Transaction Fee Calculated with Input Data:

How's The Transaction Fee Calculated For Functions:

How's The Transaction Fee Calculated For Arrays:

Mastering Ethereum Notes

SK Sabiruddin — Tue, 06 Feb 2024 04:39:29 +0000

The components of an open, public blockchain are:

A peer-to-peer (P2P) network connecting participants and propagating transactions and blocks of verified transactions, based on a standardized "gossip" protocol.
Messages, in the form of transactions, representing state transitions.
A set of consensus rules, governing what constitutes a transaction and what makes for a valid state transition.
A state machine those processes transactions according to the consensus rules.
A chain of cryptographically secured blocks that acts as a journal of all the verified and accepted state transitions.
A consensus algorithm that decentralizes control over the blockchain, by forcing participants to cooperate in the enforcement of the consensus rules.
A game-theoretically sound incentivization scheme (e.g., proof-of-work costs plus block rewards) to economically secure the state machine in an open environment.
One or more open-source software implementations of the above ("clients").

About Ethereum:

Ethereum is often described as the world computer. From a more practical perspective, Ethereum is an open source, globally decentralized computing infrastructure that executes programs called smart contracts. It uses a blockchain to synchronize and store the system’s state changes, along with a cryptocurrency called ether to meter and constrain execution resource costs.
The Ethereum platform enables developers to build powerful decentralized applications with built-in economic functions, while providing high availability, auditability, transparency, and neutrality, it also reduces or eliminates censorship and reduces certain counterparty risks.
Many people will come to Ethereum with some prior experience of cryptocurrencies, specifically Bitcoin.
Ethereum shares many common elements with other open blockchains: a peer-to-peer network connecting participants, a Byzantine fault–tolerant consensus algorithm for synchronization of state updates (a proof-of-work blockchain), the use of cryptographic primitives such as digital signatures and hashes, and a digital currency (ether).
Ethereum’s development was planned over four distinct stages, with major changes occurring at each stage.
A stage may include sub releases, known as "hard forks," that change functionality in a way that is not backward compatible.
The four main development stages are codenamed Frontier, Homestead, Metropolis, and Serenity.
The intermediate hard forks that have occurred to date are codenamed Ice Age, DAO, Tangerine Whistle, Spurious Dragon, Byzantium, Constantinople/St, Petersburg, Istanbul and Muir Glacier.
Both the development stages and the intermediate hard forks are shown on the following timeline, which is "dated" by block number:
- Block #0: _Frontier_ — The initial stage of Ethereum, lasting from July 30, 2015, to March 2016.
- Block #200,000: Ice Age — A hard fork to introduce an exponential difficulty increase, to motivate a transition to PoS when ready.
- Block #1,150,000: Homestead — The second stage of Ethereum, launched in March 2016.
- Block #1,192,000: DAO — A hard fork that reimbursed victims of the hacked DAO contract and caused Ethereum and Ethereum Classic to split into two competing systems.
- Block #2,463,000: Tangerine Whistle — A hard fork to change the gas calculation for certain I/O-heavy operations and to clear the accumulated state from a denial-of-service (DoS) attack that exploited the low gas cost of those operations.
- Block #2,675,000: Spurious Dragon — A hard fork to address more DoS attack vectors, and another state clearing. Also, a replay attack protection mechanism.
- Block #4,370,000: Metropolis Byzantium — Metropolis is the third stage of Ethereum. Launched in October 2017, Byzantium is the first part of Metropolis, adding low-level functionalities and adjusting the block reward and difficulty.
- Block #7,280,000: Constantinople / St. Petersburg — Constantinople was planned to be the second part of Metropolis with similar improvements. A few hours before its activation, a critical bug was discovered. The hard fork was therefore postponed and renamed St. Petersburg.
- Block #9,069,000: Istanbul — An additional hard fork with the same approach, and naming convention, as for the prior two.
- Block #9,200,000: Muir Glacier — A hard fork whose sole purpose was to adjust the difficulty again due to the exponential increase introduced by Ice Age.
Two hard forks, Berlin and London, have also been announced, and we are now in the final stage of Ethereum development, codenamed Serenity. Serenity involves a profound reorganization of the infrastructure that will make Ethereum more scalable, more secure, and more sustainable. It is presented as the second version of Ethereum, "Ethereum 2.0".
The original blockchain, namely Bitcoin’s blockchain, tracks the state of units of bitcoin and their ownership. You can think of Bitcoin as a distributed consensus state machine, where transactions cause a global state transition, altering the ownership of coins.
The state transitions are constrained by the rules of consensus, allowing all participants to (eventually) converge on a common (consensus) state of the system, after several blocks are mined.
Ethereum is also a distributed state machine. But instead of tracking only the state of currency ownership, Ethereum tracks the state transitions of a general-purpose data store, i.e., a store that can hold any data expressible as a key–value tuple. A key–value data store holds arbitrary values, each referenced by some key.
In some ways, this serves the same purpose as the data storage model of Random Access Memory (RAM) used by most general-purpose computers. Ethereum has memory that stores both code and data, and it uses the Ethereum blockchain to track how this memory changes over time. Like a general-purpose stored-program computer, Ethereum can load code into its state machine and run that code, storing the resulting state changes in its blockchain.
Two of the critical differences from most general-purpose computers are that Ethereum state changes are governed by the rules of consensus and the state is distributed globally.
Ethereum answers the question: "What if we could track any arbitrary state and program the state machine to create a world-wide computer operating under consensus?"
Ethereum has two different types of accounts: externally owned accounts (EOAs) and contracts. Ownership of ether by EOAs is established through digital private keys, Ethereum addresses, and digital signatures. The private keys are at the heart of all user interaction with Ethereum. In fact, account addresses are derived directly from private keys: a private key uniquely determines a single Ethereum address, also known as an account.
That is to say that private keys should remain private and never appear in messages passed to the network, nor should they be stored on-chain; only account addresses and digital signatures are ever transmitted and stored on the Ethereum system.
Access and control of funds is achieved with digital signatures, which are also created using the private key. Ethereum transactions require a valid digital signature to be included in the blockchain. Anyone with a copy of a private key has control of the corresponding account and any ether it holds. Assuming a user keeps their private key safe, the digital signatures in Ethereum transactions prove the true owner of the funds, because they prove ownership of the private key.
In the payment portion of an Ethereum transaction, the intended recipient is represented by an Ethereum address, which is used in the same way as the beneficiary account details of a bank transfer. As we will see in more detail shortly, an Ethereum address for an EOA is generated from the public key portion of a key pair. However, not all Ethereum addresses represent public–private key pairs; they can also represent contracts, are not backed by private keys.
Public key cryptography (also called "asymmetric cryptography") is a core part of modern-day information security. Public key cryptography uses unique keys to secure information. These keys are based on mathematical functions that have a special property: it is easy to calculate them, but hard to calculate their inverse. Based on these functions, cryptography enables the creation of digital secrets and unforgeable digital signatures, which are secured by the laws of mathematics.
A more advanced category of mathematical functions that is useful in cryptography is based on arithmetic operations on an elliptic curve. In elliptic curve arithmetic, multiplication modulo a prime is simple but division (the inverse) is practically impossible. This is called the discrete logarithm problem and there are currently no known trapdoors. Elliptic curve cryptography is used extensively in modern computer systems and is the basis of Ethereum’s (and other cryptocurrencies') use of private keys and digital signatures.
A digital signature can be created to sign any message. For Ethereum transactions, the details of the transaction itself are used as the message. The mathematics of cryptography—in this case, elliptic curve cryptography—provides a way for the message (i.e., the transaction details) to be combined with the private key to create a code that can only be produced with knowledge of the private key. That code is called the digital signature.
When a transaction is sent to the Ethereum network in order to move funds or interact with smart contracts, it needs to be sent with a digital signature created with the private key corresponding to the Ethereum address in question. Elliptic curve mathematics means that anyone can verify that a transaction is valid, by checking that the digital signature matches the transaction details and the Ethereum address to which access is being requested. The verification doesn’t involve the private key at all; that remains private. However, the verification process determines beyond doubt that the transaction could have only come from someone with the private key that corresponds to the public key behind the Ethereum address. This is the "magic" of public key cryptography.
There is no encryption as part of the Ethereum protocol—all messages that are sent as part of the operation of the Ethereum network can (necessarily) be read by everyone. As such, private keys are only used to create digital signatures for transaction authentication.

Ethereum’s Components:

P2P network: Ethereum runs on the Ethereum main network, which is addressable on TCP port 30303, and runs a protocol called ÐΞVp2p.
Consensus rules: Ethereum’s consensus rules are defined in the reference specification, the Yellow Paper.
Transactions: Ethereum transactions are network messages that include (among other things) a sender, recipient, value, and data payload.
State machine: Ethereum state transitions are processed by the Ethereum Virtual Machine (EVM), a stack-based virtual machine that executes bytecode (machine-language instructions). EVM programs, called "smart contracts," are written in high-level languages (e.g., Solidity) and compiled to bytecode for execution on the EVM.
Data structures: Ethereum’s state is stored locally on each node as a database (usually Google’s LevelDB), which contains the transactions and system state in a serialized hashed data structure called a Merkle Patricia Tree.
Consensus algorithm: Ethereum uses Bitcoin’s consensus model, Nakamoto Consensus, which uses sequential single-signature blocks, weighted in importance by PoS to determine the longest chain and therefore the current state.
Economic security: Ethereum currently uses a PoS algorithm.
Clients: Ethereum has several interoperable implementations of the client software, the most prominent of which are Go-Ethereum (Geth) and Parity.

EVM Architecture:

The EVM uses a stack-based architecture and a word size of 256 bits. The 256-bit word size allows the EVM to facilitate native hashing and elliptic curve operations that ensure funds can be spent only by their rightful owners. The EVM supports various programming languages such as Vyper and Solidity, with Solidity being the most popular programming language for smart contract source code. These programming languages are used to write smart contracts, which are converted into the bytecode needed to be utilized by the EVM.
When an Ethereum transaction executes a smart contract, an EVM is loaded with the information for the transaction being processed. For example, one variable needed for a smart contract execution is the gas supply, which is set to the amount of gas paid by the sender. The gas supply is reduced as the transaction progresses, and if, at any point, the gas supply reaches zero, the transaction is abandoned. Although abandoned transactions don’t result in changes to the Ethereum state and are not considered valid transactions, the block’s beneficiary is paid for providing resources up to the halting point.
The bytecode stored on-chain, known as the runtime bytecode, is then converted into an opcode that the EVM computation engine interprets to carry out those actions.
Smart contracts can initiate transactions and call other contracts on their own. In this case, each call results in another EVM being loaded with specific information for the new transaction. This new information is initialized from the EVM one level above. If there isn’t enough gas to complete the execution, the state is discarded, and the transaction execution is reset to the EVM one level above.
The Ethereum protocol uses two distinct data types – permanent data and ephemeral data. _Permanent data_, such as a transaction, is recorded in Ethereum’s tree-like data structure and will never be altered. _Ephemeral data_, such as a wallet’s balance, is recorded and changed in response to new transactions.
EVM’s opcodes use contract memory to retrieve data. Contract state memory is stored at the contract address and is not persistent. A variable’s position in a smart contract’s storage array is determined by its order in the code. If a given variable is 256 bits or less, the EVM will try to fit multiple variables in the space. When a contract inherits another contract, the storage variables of the base contract are stored in the first slots in the order of inheritance.
Whereas contract memory is impermanent, contract storage is stored indefinitely. Contract storage is like a public database where values can be read externally without the need to send a transaction. Still, contract storage is expensive compared to contract state memory.
Once the Smart contract is compiled, it'll generate ABI and Bytecode.
Ethereum’s EVM has allowed the project to achieve its goal of “decentralizing everything.”
Alan Turing further defined a system to be Turing complete if it can be used to simulate any Turing machine. Such a system is called a Universal Turing machine (UTM).
Ethereum’s ability to execute a stored program, in a state machine called the Ethereum Virtual Machine, while reading and writing data to memory makes it a Turing-complete system and therefore a UTM. Ethereum can compute any algorithm that can be computed by any Turing machine, given the limitations of finite memory.
Turing proved that you cannot predict whether a program will terminate by simulating it on a computer. In simple terms, we cannot predict the path of a program without running it. Turing-complete systems can run in "infinite loops," a term used (in oversimplification) to describe a program that does not terminate. It is trivial to create a program that runs a loop that never ends. But unintended never-ending loops can arise without warning, due to complex interactions between the starting conditions and the code.
To answer this challenge, Ethereum introduces a metering mechanism called gas. As the EVM executes a smart contract, it carefully accounts for every instruction (computation, data access, etc.). Each instruction has a predetermined cost in units of gas. When a transaction triggers the execution of a smart contract, it must include an amount of gas that sets the upper limit of what can be consumed running the smart contract.
The EVM will terminate execution if the amount of gas consumed by computation exceeds the gas available in the transaction. Gas is the mechanism Ethereum uses to allow Turing-complete computation while limiting the resources that any program can consume.
The next question is, 'how does one get gas to pay for computation on the Ethereum world computer?' You won’t find gas on any exchanges.It can only be purchased as part of a transaction and can only be bought with ether. Ether needs to be sent along with a transaction and it needs to be explicitly earmarked for the purchase of gas, along with an acceptable gas price. Just like at the pump, the price of gas is not fixed. Gas is purchased for the transaction, the computation is executed, and any unused gas is refunded back to the sender of the transaction.

Ether denominations and unit names:

Currently, there are six main implementations of the Ethereum protocol, written in six different languages:
- Parity, written in Rust
- Geth, written in Go
- cpp-ethereum, written in C++
- pyethereum, written in Python
- Mantis, written in Scala
- Harmony, written in Java

Full Node Advantages and Disadvantages:

Choosing to run a full node helps with the operation of the networks you connect it to, but also incurs some mild to moderate costs for you. Let’s look at some of the advantages and disadvantages.

Advantages:

Supports the resilience and censorship resistance of Ethereum-based networks
Authoritatively validates all transactions
Can interact with any contract on the public blockchain without an intermediary
Can directly deploy contracts into the public blockchain without an intermediary
Can query (read-only) the blockchain status (accounts, contracts, etc.) offline
Can query the blockchain without letting a third party know the information you’re reading

Disadvantages:

Requires significant and growing hardware and bandwidth resources
May require several days to fully sync when first started
Must be maintained, upgraded, and kept online to remain synced

Types of Keys in Ethereum:

There are 2 kind of keys present in Ethereum.

Private Key
Public Key

Private Keys:

A private key is simply a number, picked at random. Ownership and control of the private key is the root of user control over all funds associated with the corresponding Ethereum address, as well as access to contracts that authorize that address.
The private key is used to create signatures required to spend ether by proving ownership of funds used in a transaction. The private key must remain secret at all times, because revealing it to third parties is equivalent to giving them control over the ether and contracts secured by that private key.
The private key must also be backed up and protected from accidental loss. If it’s lost, it cannot be recovered, and the funds secured by it are lost forever too.
The Ethereum private key is just a number. One way to pick your private keys randomly is to simply use a coin, pencil, and paper: toss a coin 256 times and you have the binary digits of a random private key you can use in an Ethereum wallet (probably—see the next section). The public key and address can then be generated from the private key.

Generating a Private Key from a Random Number:

The first and most important step in generating keys is to find a secure source of entropy, or randomness. Creating an Ethereum private key essentially involves picking a number between 1 and 2^256. The exact method you use to pick that number does not matter as long as it is not predictable or deterministic. Ethereum software uses the underlying operating system’s random number generator to produce 256 random bits.
More precisely, a private key can be any nonzero number up to a very large number slightly less than 2^256—a huge 78-digit number, roughly 1.158 * 10^77. The exact number shares the first 38 digits with 2256 and is defined as the order of the elliptic curve used in Ethereum.
To create a private key, we randomly pick a 256-bit number and check that it is within the valid range. In programming terms, this is usually achieved by feeding an evenlarger string of random bits (collected from a cryptographically secure source of randomness) into a 256-bit hash algorithm such as Keccak-256 or SHA-256, both of which will conveniently produce a 256-bit number. If the result is within the valid range, we have a suitable private key. Otherwise, we simply try again with another random number.
2^256—the size of Ethereum’s private key space—is an unfathomably large number. It is approximately 10^77 in decimal; that is, a number with 77 digits. For comparison, the visible universe is estimated to contain between 10^77 and 10^80 atoms. Therefore, at the lower range there are enough private keys to give every atom in the universe an Ethereum account. If you pick a private key randomly, there is no conceivable way anyone will ever guess it or pick it themselves.
Note that the private key generation process is an offline one; it does not require any communication with the Ethereum network, or indeed any communication with anyone at all. As such, in order to pick a number that no one else will ever pick, it needs to be truly random. If you choose the number yourself, the chance that someone else will try it (and then run off with your ether) is too high.
The following is a randomly generated private key shown in hexadecimal format (256 bits shown as 64 hexadecimal digits, each 4 bits): f8f8a2f43c8376ccb0871305060d7b27b0554d2cc72bccf41b2705608452f315

Public Keys:

An Ethereum public key is a point on an elliptic curve, meaning it is a set of x and y coordinates that satisfy the elliptic curve equation.
In simpler terms, an Ethereum public key is two numbers, joined together. These numbers are produced from the private key by a calculation that can only go one way. That means that it is trivial to calculate a public key if you have the private key, but you cannot calculate the private key from the public key.
The public key is calculated from the private key using elliptic curve multiplication, which is practically irreversible: K = k * G, where k is the private key, G is a constant point called the generator point, K is the resulting public key, and * is the special elliptic curve "multiplication" operator. Note that elliptic curve multiplication is not like normal multiplication. It shares functional attributes with normal multiplication, but that is about it.
In simpler terms: arithmetic on the elliptic curve is different from "regular" integer arithmetic. A point (G) can be multiplied by an integer (k) to produce another point (K). But there is no such thing as division, so it is not possible to simply "divide" the public key K by the point G to calculate the private key k. This is the one-way mathematical function described in Public Key Cryptography and Cryptocurrency.

Elliptic curve multiplication is a type of function that cryptographers call a "one-way" function: it is easy to do in one direction (multiplication) and impossible to do in the reverse direction (division). The owner of the private key can easily create the public key and then share it with the world, knowing that no one can reverse the function and calculate the private key from the public key. This mathematical trick becomes the basis for unforgeable and secure digital signatures that prove ownership of Ethereum funds and control of contracts.
Elliptic curve cryptography is a type of asymmetric or public key cryptography based on the discrete logarithm problem as expressed by addition and multiplication on the points of an elliptic curve.
Ethereum uses the exact same elliptic curve, called secp256k1, as Bitcoin. That makes it possible to reuse many of the elliptic curve libraries and tools from Bitcoin.

Serialized EC public key prefixes:

Ethereum only uses uncompressed public keys; therefore, the only prefix that is relevant is (hex) 04. The serialization concatenates the x and y coordinates of the public key:

04 + x-coordinate (32 bytes/64 hex) + y-coordinate (32 bytes/64 hex)

Therefore, the public key we calculated earlier is serialized as:

046e145ccef1033dea239875dd00dfb4fee6e3348b84985c92f103444683bae07b83b5c38e5e2b0 \ c8529d7fa3f64d46daa1ece2d9ac14cab9477d042c84c32ccd0

A hash function is “any function that can be used to map data of arbitrary size to data of fixed size.”
A cryptographic hash function is a one-way hash function that maps data of arbitrary size to a fixed-size string of bits. The "one-way" nature means that it is computationally infeasible to recreate the input data if one only knows the output hash. The only way to determine a possible input is to conduct a brute-force search, checking each candidate for a matching output; given that the search space is virtually infinite, it is easy to understand the practical impossibility of the task.
Let’s take a closer look at the main properties of cryptographic hash functions. These include:
- Determinism: A given input message always produces the same hash output.
- Verifiability: Computing the hash of a message is efficient (linear complexity).
- Noncorrelation: A small change to the message (e.g., a 1-bit change) should change the hash output so extensively that it cannot be correlated to the hash of the original message.
- Irreversibility: Computing the message from its hash is infeasible, equivalent to a brute-force search through all possible messages.
- Collision protection: It should be infeasible to calculate two different messages that produce the same hash output.
Resistance to hash collisions is particularly important for avoiding digital signature forgery in Ethereum.
The combination of these properties makes cryptographic hash functions useful for a broad range of security applications, including:
• Data fingerprinting

• Message integrity (error detection)

• Proof of work

• Authentication (password hashing and key stretching)

• Pseudorandom number generators

• Message commitment (commit–reveal mechanisms)

• Unique identifiers
Ethereum uses the Keccak-256 cryptographic hash function in many places. Keccak-256 was designed as a candidate for the SHA-3 Cryptographic Hash Function Competition held in 2007 by the National Institute of Standards and Technology. Keccak was the winning algorithm, which became standardized as Federal Information Processing Standard (FIPS) 202 in 2015.
Ethereum Addresses: Ethereum addresses are unique identifiers that are derived from public keys or contracts using the Keccak-256 one-way hash function. Ethereum addresses are hexadecimal numbers, identifiers derived from the last 20 bytes of the Keccak-256 hash of the public key.

Wallets:

The word "wallet" is used to describe a few different things in Ethereum.
At a high level, a wallet is a software application that serves as the primary user interface to Ethereum. The wallet controls access to a user’s money, managing keys and addresses, tracking the balance, and creating and signing transactions. In addition, some Ethereum wallets can also interact with contracts, such as ERC20 tokens.
The word wallet refers to the system used to store and manage a user’s keys. Every wallet has a key-management component. For some wallets, that’s all there is. Other wallets are part of a much broader category, that of browsers, which are interfaces to Ethereum-based decentralized applications, or DApps.
Ethereum wallets contain keys, not ether or tokens. Wallets are like keychains containing pairs of private and public keys. Users sign transactions with the private keys, thereby proving they own the ether. The ether is stored on the blockchain.
There are two primary types of wallets, distinguished by whether the keys they contain are related to each other or not.
The first type is a Nondeterministic wallet, where each key is independently generated from a different random number. The keys are not related to each other. This type of wallet is also known as a JBOK wallet, from the phrase "Just a Bunch of Keys.”
The second type of wallet is a Deterministic wallet, where all the keys are derived from a single master key, known as the seed. All the keys in this type of wallet are related to each other and can be generated again if one has the original seed. There are a number of different key derivation methods used in deterministic wallets. The most commonly used derivation method uses a tree-like structure, as described in Hierarchical Deterministic Wallets (BIP-32/BIP-44).
To make deterministic wallets slightly more secure against data-loss accidents, such as having your phone stolen or dropping it in the toilet, the seeds are often encoded as a list of words (in English or another language) for you to write down and use in the event of an accident. These are known as the wallet’s mnemonic code words.
Deterministic or "seeded" wallets are wallets that contain private keys that are all derived from a single master key, or seed. The seed is a randomly generated number that is combined with other data, such as an index number or "chain code" (see Extended public and private keys), to derive any number of private keys.
In a deterministic wallet, the seed is sufficient to recover all the derived keys, and therefore a single backup, at creation time, is sufficient to secure all the funds and smart contracts in the wallet. The seed is also sufficient for a wallet export or import, allowing for easy migration of all the keys between different wallet implementations.
Deterministic wallets were developed to make it easy to derive many keys from a single seed. Currently, the most advanced form of deterministic wallet is the hierarchical deterministic (HD) wallet defined by Bitcoin’s BIP-32 standard.
HD wallets contain keys derived in a tree structure, such that a parent key can derive a sequence of child keys, each of which can derive a sequence of grandchild keys, and so on. This tree structure is illustrated in HD wallet: a tree of keys generated from a single seed.
HD wallets offer a few key advantages over simpler deterministic wallets. First, the tree structure can be used to express additional organizational meaning, such as when a specific branch of subkeys is used to receive incoming payments and a different branch is used to receive change from outgoing payments. Branches of keys can also be used in corporate settings, allocating different branches to departments, subsidiaries, specific functions, or accounting categories.
The second advantage of HD wallets is that users can create a sequence of public keys without having access to the corresponding private keys. This allows HD wallets to be used on an insecure server or in a watch-only or receive-only capacity, where the wallet doesn’t have the private keys that can spend the funds.
There are many ways to encode a private key for secure backup and retrieval. The currently preferred method is using a sequence of words that, when taken together in the correct order, can uniquely recreate the private key. This is sometimes known as a mnemonic, and the approach has been standardized by BIP-39. Today, many Ethereum wallets (as well as wallets for other cryptocurrencies) use this standard and can import and export seeds for backup and recovery using interoperable mnemonics.
Some examples of software wallets supporting these standards include (listed alphabetically) Jaxx, MetaMask, MyCrypto, and MyEtherWallet (MEW). Examples of hardware wallets supporting these standards include Keepkey, Ledger, and Trezor.

Generating Mnemonic words 128 bit / 12 words:

Transactions are signed messages originated by an externally owned account (EOA), transmitted by the Ethereum network, and recorded on the Ethereum blockchain.
This basic definition conceals a lot of surprising and fascinating details.
Another way to look at transactions is that they are the only things that can trigger a change of state or cause a contract to execute in the EVM.
Ethereum is a global singleton state machine, and transactions are what make that state machine "tick," changing its state. Contracts don’t run on their own. Ethereum doesn’t run autonomously. Everything starts with a transaction.

The Structure of a Transaction:

First let’s take a look at the basic structure of a transaction, as it is serialized and transmitted on the Ethereum network. Each client and application that receives a serialized transaction will store it in-memory using its own internal data structure, perhaps embellished with metadata that doesn’t exist in the network serialized transaction itself. The network-serialization is the only standard form of a transaction.
A transaction is a serialized binary message that contains the following data:
- Nonce: A sequence number, issued by the originating EOA, used to prevent message replay
- Gas price: The amount of ether (in wei) that the originator is willing to pay for each unit of gas
- Gas limit: The maximum amount of gas the originator is willing to buy for this transaction
- Recipient: The destination Ethereum address
- Value: The amount of ether (in wei) to send to the destination.
- Data: The variable-length binary data payload
- v,r,s: The three components of an ECDSA digital signature of the originating EOA

Chain identifiers:

Oracles:

Oracles are systems that can provide external data sources to Ethereum smart contracts. The term "oracle" comes from Greek mythology, where it referred to a person in communication with the gods who could see visions of the future. In the context of blockchains, an oracle is a system that can answer questions that are external to Ethereum. Ideally oracles are systems that are trustless, meaning that they do not need to be trusted because they operate on decentralized principles.
Oracles, ideally, provide a trustless (or at least near-trustless) way of getting extrinsic (i.e., "real-world" or off-chain) information, such as the results of football games, the price of gold, or truly random numbers, onto the Ethereum platform for smart contracts to use. They can also be used to relay data securely to DApp frontends directly. Oracles can therefore be thought of as a mechanism for bridging the gap between the off-chain world and smart contracts. Allowing smart contracts to enforce contractual relationships based on real-world events and data broadens their scope dramatically.
Some more examples of data that might be provided by oracles include:
- Random numbers/entropy from physical sources such as quantum/thermal processes: e.g., to fairly select a winner in a lottery smart contract
- Parametric triggers indexed to natural hazards: e.g., triggering of catastrophe bond smart contracts, such as Richter scale measurements for an earthquake bond
- Exchange rate data: e.g., for accurate pegging of cryptocurrencies to fiat currency
- Capital markets data: e.g., pricing baskets of tokenized assets/securities
- Benchmark reference data: e.g., incorporating interest rates into smart financial derivatives
- Static/pseudostatic data: security identifiers, country codes, currency codes, etc.
- Time and interval data: for event triggers grounded in precise time measurements
- Weather data: e.g., insurance premium calculations based on weather forecasts
- Political events: for prediction market resolution
- Sporting events: for prediction market resolution and fantasy sports contracts
- Geolocation data: e.g., as used in supply chain tracking
- Damage verification: for insurance contracts
- Events occurring on other blockchains: interoperability functions
- Ether market price: e.g., for fiat gas price oracles
- Flight statistics: e.g., as used by groups and clubs for flight ticket pooling
All oracles provide a few key functions, by definition. These include the ability to:
- Collect data from an off-chain source.
- Transfer the data on-chain with a signed message.
- Make the data available by putting it in a smart contract’s storage.
Once the data is available in a smart contract’s storage, it can be accessed by other smart contracts via message calls that invoke a "retrieve" function of the oracle’s smart contract; it can also be accessed by Ethereum nodes or network-enabled clients directly by "looking into” the oracle’s storage. The three main ways to set up an oracle can be categorized as request–response, publish-subscribe, and immediate-read.

The steps for a request–response oracle may be summarized as follows:

Receive a query from a DApp.
Parse the query.
Check that payment and data access permissions are provided.
Retrieve relevant data from an off-chain source (and encrypt it if necessary).
Sign the transaction(s) with the data included.
Broadcast the transaction(s) to the network.
Schedule any further necessary transactions, such as notifications, etc.
- A range of other schemes are also possible; for example, data can be requested from and returned directly by an EOA, removing the need for an oracle smart contract. Similarly, the request and response could be made to and from an Internet of Things–enabled hardware sensor. Therefore, oracles can be human, software, or hardware.
- The request–response pattern described here is commonly seen in client–server architectures. While this is a useful messaging pattern that allows applications to have a two-way conversation, it is perhaps inappropriate under certain conditions. For example, a smart bond requiring an interest rate from an oracle might have to request the data on a daily basis under a request–response pattern in order to ensure the rate is always correct. Given that interest rates change infrequently, a publish–subscribe pattern may be more appropriate here—especially when taking into consideration Ethereum’s limited bandwidth.
- Publish–subscribe is a pattern where publishers (in this context, oracles) do not send messages directly to receivers, but instead categorize published messages into distinct classes. Subscribers are able to express an interest in one or more classes and retrieve only those messages that are of interest. Under such a pattern, an oracle might write the interest rate to its own internal storage each time it changes. Multiple subscribed DApps can simply read it from the oracle contract, thereby reducing the impact on network bandwidth while minimizing storage costs.
- ChainLink has proposed a decentralized oracle network consisting of three key smart contracts—a reputation contract, an order-matching contract, and an aggregation contract—and an off-chain registry of data providers.
- The reputation contract is used to keep track of data providers' performance. Scores in the reputation contract are used to populate the off-chain registry. The order-matching contract selects bids from oracles using the reputation contract. It then finalizes a service-level agreement, which includes query parameters and the number of oracles required.
- This means that the purchaser needn’t transact with the individual oracles directly. The aggregation contract collects responses (submitted using a commit–reveal scheme) from multiple oracles, calculates the final collective result of the query, and finally feeds the results back into the reputation contract.

 // query params are (delay in seconds, datasource type,
 // datasource argument)
 // specifies JSONPath, to fetch specific portion of JSON API result
   oraclize_query(60 * 10, "URL", 
"json(https://min-api.cryptocompare.com/data/price?\
      fsym=ETH&tsyms=USD,EUR,GBP).USD");

What Is a DApp?

A DApp is an application that is mostly or entirely decentralized. Consider all the possible aspects of an application that may be decentralized:
- Backend software (application logic)
- Frontend software
- Data storage
- Message communications
- Name resolution
Each of these can be somewhat centralized or somewhat decentralized. For example, a frontend can be developed as a web app that runs on a centralized server, or as a mobile app that runs on your device. The backend and storage can be on private servers and proprietary databases, or you can use a smart contract and P2P storage.
There are many advantages to creating a DApp that a typical centralized architecture cannot provide:
- Resiliency: Because the business logic is controlled by a smart contract, a DApp backend will be fully distributed and managed on a blockchain platform. Unlike an application deployed on a centralized server, a DApp will have no downtime and will continue to be available as long as the platform is still operating.
- Transparency: The on-chain nature of a DApp allows everyone to inspect the code and be more sure about its function. Any interaction with the DApp will be stored forever in the blockchain.
- Censorship resistance: As long as a user has access to an Ethereum node (running one if necessary), the user will always be able to interact with a DApp without interference from any centralized control. No service provider, or even the owner of the smart contract, can alter the code once it is deployed on the network.

Mastering ₿itcoin Notes

SK Sabiruddin — Sat, 03 Feb 2024 17:59:22 +0000

Bitcoin:

The name of the currency unit (the coin), the network and the software. Bitcoin is a collection of concepts and technologies that form the basis of a digital money ecosystem. Units of currency called bitcoins are used to store and transmit value among participants in the bitcoin network.

Bitcoin users communicate with each other using the bitcoin protocol primarily via the Internet, although other transport networks can also be used. The bitcoin protocol stack, available as open-source software, can be run on a wide range of computing devices, including laptops and smartphones, making the technology easily accessible.

Address (aka public key):

A bitcoin address looks like 1DSrfJdB2AnWaFNgSbv3MZC2m74996JafV - they consist of a string of letters and numbers starting with a “1” (number one). Just like you ask others to send an email to your email address, you would ask others to send you bitcoin to your bitcoin address.

BIP:

Bitcoin Improvement Proposals. A set of proposals that members of the bitcoin community have submitted to improve bitcoin. For example BIP0021 is a proposal to improve the bitcoin URI scheme.

Block:

A grouping of transactions, marked with a timestamp, and a fingerprint of the previous block. The block header is hashed to find a proof-of-work, thereby validating the transactions. Valid blocks are added to the main blockchain by network consensus.

Blockchain:

A list of validated blocks, each linking to its predecessor all the way to the genesis block.

Confirmations:

Once a transaction is included in a block, it has one confirmation. As soon as another block is mined on the same blockchain, the transaction has two confirmations etc. Six or more confirmations is considered sufficient proof that a transaction cannot be reversed.

Difficulty:

A network-wide setting that controls how much computation is required to find a proof-of-work.

Difficulty target:

A difficulty at which all the computation in the network will find blocks approximately every 10 minutes.

Difficulty re-targeting:

A network-wide re-calculation of the difficulty which occurs once every 2106 blocks and considers the hashing power of the previous 2106 blocks.

Fees:

The sender of a transaction often includes a fee to the network for processing their requested transaction. Most transactions require a minimum fee of 0.5mBTC.

Hash:

A digital fingerprint of some binary input.

Genesis block:

The first block in the blockchain, used to initialize the crypto-currency.

Miner:

A network node that finds valid proof-of-work for new blocks, by repeated hashing.

Network:

A peer-to-peer network that propagates transactions and blocks to every bitcoin node on the network.

Proof-of-work:

A piece of data that requires significant computation to find. In bitcoin, miners must find a numeric solution to the SHA256 algorithm that meets a network wide target, the difficulty target.

Reward:

An amount included in each new block as a reward by the network to the miner who found the proof-of-work solution. It is currently 6.25BTC per block.

Secret key (aka private key):

The secret number that unlocks bitcoins sent to the corresponding address. A secret key looks like 5J76sF8L5jTtzE96r66Sf8cka9y44wdpJjMwCxR3tzLh3ibVPxh.

Transaction:

In simple terms, a transfer of bitcoins from one address to another. More precisely, a transaction is a signed data structure expressing a transfer of value. Transactions are transmitted over the bitcoin network, collected by miners and included into blocks, made permanent on the blockchain.

Wallet:

Software that holds all your bitcoin addresses and secret keys. Use it to send, receive and store your bitcoin.

Transaction Locktime:

Locktime defines the earliest time that a transaction can be added to the blockchain. It is set to zero in most transactions to indicate immediate execution. If locktime is nonzero and below 500 million, it is interpreted as a block height, meaning the transaction is not included in the blockchain prior to the specified block height. If it is above 500 million, it is interpreted as a Unix Epoch timestamp (seconds since Jan-1-1970) and the
transaction is not included in the blockchain prior to the specified time. The use of locktime is equivalent to post-dating a paper cheque.

Transaction Outputs and Inputs : (UTXO)

The fundamental building block of a bitcoin transaction is an unspent transaction output or UTXO. UTXO are indivisible chunks of bitcoin currency locked to a specific owner, recorded on the blockchain, and recognized as currency units by the entire network.
The bitcoin network tracks all available (unspent) UTXO currently numbering in the millions.
Whenever a user receives bitcoin, that amount is recorded within the blockchain as a UTXO. Thus, a user’s bitcoin may be scattered as UTXO amongst hundreds of transactions and hundreds of blocks.
In effect, there is no such thing as a stored balance of a bitcoin address or account; there are only scattered UTXO, locked to specific owners.
The concept of a user’s bitcoin balance is a derived construct created by the wallet application. The wallet calculates the user’s balance.
There are no accounts or balances in bitcoin, there are only unspent transaction outputs (UTXO) scattered in the blockchain.
UTXO are tracked by every full node bitcoin client in a database held in memory, called the UTXO set or UTXO pool. New transactions consume (spend) one or more of these outputs from the UTXO set. Transaction outputs consist of two parts:
- An amount of bitcoin, denominated in Satoshi, the smallest bitcoin unit.
- A locking script, also known as an encumbrance that locks this amount by specifying the conditions that must be met to spend the output.
if you consume a 20 bitcoin UTXO to make a 1 bitcoin payment, you must include a 19 bitcoin change output back to your wallet. Otherwise, the 19 bitcoin “leftover” will be counted as a transaction fee and will be collected by the miner who mines your transaction in a block. While you will receive priority processing and make a miner very happy, this is probably not what you intended.

Transaction Pools:

Almost every node on the bitcoin network maintains a temporary list of unconfirmed transactions called the memory pool or transaction pool.
Nodes use this pool to keep track of transactions that are known to the network but are not yet included in the blockchain. For example, a node that holds a user’s wallet will use the transaction pool to track incoming payments to the user’s wallet that have been received on the network but are not yet confirmed.
As transactions are received and verified, they are added to the transaction pool and relayed to the neighboring nodes to propagate on the network.

About Bitcoin:

Bitcoin is a fully distributed, peer-to-peer system. As such there is no “central” server or point of control. Bitcoins are created through a process called “mining”, which involves looking for a solution to a difficult problem.
Any participant in the bitcoin network (i.e., any device running the full bitcoin protocol stack) may operate as a miner, 1 using their computer’s processing power to attempt to find solutions to this problem.
Every 10 minutes on average, a new solution is found by someone who then is able to validate the transactions of the past 10 minutes and is rewarded with brand new bitcoins.
The bitcoin protocol includes built-in algorithms that regulate the mining function across the network. The difficulty of the problem that miners must solve is adjusted dynamically so that, on average, someone finds a correct answer every 10 minutes regardless of how many miners (and CPUs) are working on the problem at any moment.
The protocol also halves the rate at which new bitcoins are created every 4 years and limits the total number of bitcoins that will be created to a fixed total of 21 million coins.
The result is that the number of bitcoins in circulation closely follows an easily predictable curve that reaches 21 million by the year 2140.
Bitcoin represents the culmination of decades of research in cryptography and distributed systems and includes four key innovations brought together in a unique and powerful combination. Bitcoin consists of:
- A de-centralized peer-to-peer network (the bitcoin protocol);
- A public transaction ledger (the blockchain);
- A de-centralized mathematical and deterministic currency issuance distributed mining, and.
- A de-centralized transaction verification system (transaction script).
Byzantine Generals’ Problem: Briefly, the problem consists of trying to agree on a course of action by exchanging information over an unreliable and potentially compromised network.
The three primary forms of bitcoin clients are:
- Full Client: A full client, or “full node” is a client that stores the entire history of bitcoin transactions (every transaction by every user, ever), manages the user’s wallets and can initiate transactions directly on the bitcoin network. This is similar to a standalone email server; in that it handles all aspects of the protocol without relying on any other servers or third-party services.
- Light Client: A lightweight client stores the user’s wallet but relies on third-party owned servers for access to the bitcoin transactions and network. The light client does not store a full copy of all transactions and therefore must trust the third-party servers for transaction validation. This is similar to a standalone email client that connects to a mail server for access to a mailbox, in that it relies on a third party for interactions with the network.
- Web Client: Web-clients are accessed through a web browser and store the user’s wallet on a server owned by a third party. This is similar to webmail in that it relies entirely on a third-party server.
The bitcoin system of trust is based on computation. Transactions are bundled into blocks, which require an enormous amount of computation to prove, but only a small amount of computation to verify as proven. This process is called mining and serves two purposes in bitcoin:
- Mining creates new bitcoins in each block, almost like a central bank printing new money. The amount of bitcoin created per block is fixed and diminishes with time.
- Mining creates trust by ensuring that transactions are only confirmed if enough computational power was devoted to the block that contains them. More blocks mean more computation which means more trust.
The algorithm for “Proof-of-Work” involves repeatedly hashing the header of the block and a random number with the SHA256 cryptographic algorithm until a solution matching a pre-determined pattern emerges. The first miner to find such a solution wins the round of competition and publishes that block into the blockchain.
A transaction transmitted across the network is not verified until it becomes part of the global distributed ledger, the blockchain.
Every 10 minutes on average, miners generate a new block that contains all the transactions since the last block.
New transactions are constantly flowing into the network from user wallets and other applications. As these are seen by the bitcoin network nodes, they get added to a temporary pool of unverified transactions maintained by each node.
As miners build a new block, they add unverified transactions from this pool to a new block and then attempt to solve a very hard problem (aka Proof-of-Work) to prove the validity of that new block.
Each miner starts the process of mining a new block of transactions as soon as they receive the previous block from the network, knowing they have lost that previous round of competition.
They immediately create a new block, fill it with transactions and the fingerprint of the previous block and start calculating the Proof-of-Work for the new block.
Each miner includes a special transaction in their block, one that pays their own bitcoin address a reward of newly created bitcoins (currently 6.25 BTC per block).
If they find a solution that makes that block valid, they win this reward because their successful block is added to the global blockchain and the reward transaction they included becomes spendable.
In most wallet implementations, the private and public keys are stored together as a key pair for convenience. However, the public key can be calculated from the private key, so storing only the private key is also possible.
In most wallet implementations, the private and public keys are stored together as a key pair for convenience. However, the public key can be calculated from the private key, so storing only the private key is also possible.
A bitcoin wallet contains a collection of key pairs, each consisting of a private key and a public key. The private key (k) is a number, usually picked at random.
From the private key, we use elliptic curve multiplication, a one-way cryptographic function, to generate a public key (K). From the public key (K), we use a one-way cryptographic hash function to generate a bitcoin address (A).
A private key is simply a number, picked at random. Ownership and control over the private key is the root of user control over all funds associated with the corresponding bitcoin address.
The private key is used to create signatures that are required to spend bitcoins by proving ownership of funds used in a transaction.
Algorithm used: Secure Hash Algorithm (SHA) and the RACE Integrity Primitives Evaluation Message Digest (RIPEMD).
Starting with the public key K, we compute the SHA256 hash and then compute the RIPEMD160 hash of the result, producing a 160-bit (20 byte) number:

A = RIPEMD160(SHA256(K)) // bitcoin address
whereK is the public key and A is the resulting bitcoin address. eg : 1DSrfJdB2AnWaFNgSbv3MZC2m74996JafV
Bitcoin addresses are almost always presented to users in an encoding called Base58Check.

Generating Bitcoin address from private key:

Even more compact, Base-64 representation uses 26 lower case letters, 26 capital letters, 10 numerals and 2 more characters such as “+” and “/”to transmit binary data over text-based media such as email.
Base-64 is most commonly used to add binary attachments to email. Base-58 is a text-based binary encoding format developed for use in bitcoin and used in many other crypto-currencies.
It offers a balance between compact representation, readability and error detection and prevention. Base-58 is a subset of Base-64, using the uppercase and lowercase letters and numbers but omitting some characters that are frequently mistaken for one another and can appear identical when displayed in certain fonts. Specifically, Base-58 is Base-64 without the 0 (number zero), O (capital o), l (lower L), I (capital i) and the symbols “\ +” and “/”. Or, more simply, it is a set of lower and capital letters and numbers without the four (0, O, l, I)mentioned above. Bitcoin’s Base-58 Alphabet: 123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz

Base58Check Encoding:

Base58Check Version Prefix and Encoded Result Examples:

Wallets contain keys, not coins. The coins are stored on the blockchain in the form of transaction-outputs (often noted as vout or txout).
Each user has a wallet containing keys. Wallets are really keychains containing pairs of private/public keys.
Users sign transactions with the keys, thereby proving they own the transaction outputs (their coins).

Hierarchical Deterministic Wallets (BIP0032/BIP0044):

Deterministic wallets were developed to make it easy to derive many keys from a single seed.
The most advanced form of deterministic wallets is the _Hierarchical Deterministic Wallet or HD Wallet_ defined by the BIP0032 standard.
Hierarchical deterministic wallets contain keys derived in a tree structure, such that a parent key can derive a sequence of children keys, each of which can derive a sequence of grandchildren keys and so on to an infinite depth.
HD wallets offer two major advantages over random (non-deterministic) keys.
- First, the tree structure can be used to express additional organizational meaning, such as when a specific branch of sub-keys is used to receive incoming payments and a different branch is used to receive change from outgoing payments. Branches of keys can also be used in a corporate setting, allocating different branches to departments, subsidiaries, specific functions or accounting categories.
- The second advantage of HD wallets is that users can create a sequence of public keys without having access to the corresponding private keys. This allows HD wallets to be used on an insecure server or in a receive-only capacity, issuing a different public key for each transaction. The public keys do not need to be pre-loaded or derived in advance, yet the server doesn’t have the private keys that can spend the funds.
HD wallets are created from a single root seed, which is a 128-, 256- or 512-bit random number.
Everything else in the HD wallet is deterministically derived from this root seed, which makes it possible to re-create the entire HD wallet from that seed in any compatible HD wallet.
This makes it easy to backup, restore, export and import HD wallets containing thousands or even millions of keys by simply transferring only the root seed.
The root seed is most often represented by a mnemonic word sequence, as described in the previous section “Mnemonic Code Words”, to make it easier for people to transcribe and store it.
Hierarchical Deterministic wallets use a child key derivation (CKD) function to derive children keys from parent keys. The child key derivation functions are based on one-way hash functions that combines:
- A parent private or public key (ECDSA uncompressed key) -A seed called a chain code (256 bits)
- An index number (32 bits)
A child private key, the corresponding public key and the bitcoin address are all indistinguishable from keys and addresses created randomly. The fact that they are part of a sequence is not visible, outside of the HD wallet function that created them. Once created, they operate exactly as “normal” keys.
When a transaction is added to the transaction pool, the orphan pool is checked for any orphans that reference this transaction’s outputs (its children). Any matching orphans are then validated. If valid, they are removed from the orphan pool and added to the transaction pool, completing the chain that started with the parent transaction.
In light of the newly added transaction, which is no longer an orphan, the process is repeated recursively looking for any further descendants, until no more descendants are found.
Through this process, the arrival of a parent transaction triggers a cascade reconstruction of an entire chain of interdependent transactions by re-uniting the orphans with their parents all the way down the chain.
Both the transaction pool and orphan pool (where implemented) are stored in local memory and are not saved on persistent storage, rather they are dynamically populated from incoming network messages. When a node starts, both pools are empty and are gradually populated with new transactions received on the network.
The blockchain data structure is an ordered back-linked list of blocks of transactions. The blockchain can be stored as a flat file, or in a simple database. The bitcoin core client stores the blockchain metadata using Google’s LevelDB database. Blocks are linked “back”, each referring to the previous block in the chain. The blockchain is often visualized as a vertical stack, with blocks layered on top of each other and the first block ever serving as the foundation of the stack. The visualization of blocks stacked on top of each other results in the use of terms like “height” to refer to the distance from the first block, and “top” or “tip” to refer to the most recently added block.
One way to think about the blockchain is like layers in a geological formation, or glacier core sample. The surface layers may change with the seasons, or even be blown away before they have time to settle. But once you go a few inches deep, geological layers become more and more stable.
By the time you look a few hundred feet down, you are looking at a snapshot of the past that has remained undisturbed for millennia or millions of years.
In the blockchain, the most recent few blocks may be revised if there is a chain recalculation due to a fork. The top six blocks are like a few inches of topsoil. But once you go deeper into the blockchain, beyond 6 blocks, blocks are less and less likely to change.
After 100 blocks back there is so much stability that the “coinbase” transaction, the transaction containing newly-mined bitcoins, can be spent. A few thousand blocks back (a month) and the blockchain is settled history. It will never change.
A block is a container data structure that aggregates transactions for inclusion in the public ledger, the blockchain.
The block is made of a header, containing metadata, followed by a long list of transactions that make up the bulk of its size. The block header is 80 bytes, whereas the average transaction is at least 250 bytes and the average block contains more than 500 transactions.
A complete block, with all transactions, is therefore 1000 times larger than the block header.
- 4 bytes: Block Size: The size of the block, in bytes, following this field.
- 80 bytes: Block Header: Several fields form the block header.
- 1-9 bytes (VarInt): Transaction Counter: How many transactions follow

Block Header:

A Block Header contains:
- Block Number
- Version
- Timestamp
- Previous Hash
- Merkle Root
- Nonce
The block header consists of three sets of block metadata. First, there is a reference to a previous block hash, which connects this block to the previous block in the blockchain.
The second set of metadata, namely the difficulty, timestamp and nonce, relate to the mining competition.
The third piece of metadata is the Merkle Tree root, a data structure used to efficiently summarize all the transactions in the block. `
Unlike the block hash, the block height is not a unique identifier. While a single block will always have a specific and invariant block height, the reverse is not true - the block height does not always identify a single block.
Two or more blocks may have the same block height, competing for the same position in the blockchain. Each node dynamically identifies a block’s position (height) in the blockchain when it is received from the bitcoin network. The block height may also be stored as metadata in an indexed database table for faster retrieval.

Sample block:

Merkle Trees:

Each block in the bitcoin blockchain contains a summary of all the transactions in the block, using a Merkle Tree.
A Merkle Tree, also known as a Binary Hash Tree is a data structure used for efficiently summarizing and verifying the integrity of large sets of data.
Merkle Trees are binary trees containing cryptographic hashes. The term “tree” is used in computer science to describe a branching data structure, but these trees are usually displayed upside down with the “root” at the top and the “leaves” at the bottom of a diagram.
Merkle trees are used in bitcoin to summarize all the transactions in a block, producing an overall digital fingerprint of the entire set of transactions, providing a very efficient process to verify if a transaction is included in a block. A merkle tree is constructed by recursively hashing pairs of nodes until there is only one hash, called the root, or merkle root.
The cryptographic hash algorithm used in bitcoin’s merkle trees is SHA256 applied twice, also known as double-SHA256.
When N data elements are hashed and summarized in a Merkle Tree, you can check to see if any one data element is included in the tree with at most 2*log2(N) calculations, making this a very efficient data structure.
The merkle tree is constructed bottom-up. The transactions are not stored in the merkle tree, rather their data is hashed and the resulting hash is stored in each leaf node:

Eg: HA = SHA256(SHA256(Transaction A))
Consecutive pairs of leaf nodes are then summarized in a parent node, by concatenating the two hashes and hashing them together. For example, to construct the parent node HAB, the two 32-byte hashes of the children are concatenated to create a 64-byte string. That string is then double-hashed to produce the parent node’s hash:

Eg: HAB = SHA256(SHA256(HA + HB)
The process continues until there is only one node at the top, the node known as the Merkle Root. That 32-byte hash is stored in the block header and summarizes all the data in all four transactions.
Since the merkle tree is a binary tree, it needs an even number of leaf nodes. If there is an odd number of transactions to summarize, the last transaction hash will be duplicated to create an even number of leaf nodes, also known as a balanced tree.
To prove that a specific transaction is included in a block, a node only needs to produce log2(N) 32-byte hashes, constituting an authentication path or merkle path connecting the specific transaction to the root of the tree.
This is especially important as the number of transactions increases, because the base-2 logarithm of the number of transactions increases much more slowly.
This allows bitcoin nodes to efficiently produce paths of
ten or twelve hashes (320-384 bytes) which can provide proof of a single transaction out of more than a thousand transactions in a megabyte sized block.

Cryptography:

Cryptography is a key technology that underpins the security of blockchain systems. It is used to secure the transactions and data on the blockchain, ensuring that they cannot be tampered with or modified without being detected.
In a blockchain, cryptography is used in several different ways, including the following:
1. Hashing: Hashing is the process of generating a fixed-size, unique output from an input of any size. In a blockchain, hashing is used to generate a unique "fingerprint" for each block of transactions, known as a block hash. This allows the blockchain to efficiently store and verify the integrity of the transactions.
2. Digital signatures: Digital signatures are a cryptographic technique that allows the sender of a message to prove that they are the true owner of the message. In a blockchain, digital signatures are used to sign transactions, proving that they are authorized by the owner of the associated cryptocurrency.
3. Public-key cryptography: Public-key cryptography is a cryptographic technique that uses a pair of keys, one public and one private, to secure communications. In a blockchain, public-key cryptography is used to generate addresses for users and to enable them to securely receive and send transactions.
These are just a few examples of the ways that cryptography is used in blockchain technology. Cryptography is a complex and constantly evolving field, and it is essential for the security and functionality of blockchain systems.

Types of Cryptography:

Symmetric Cryptography:

With symmetric cryptography (or symmetric-key encryption), the same key is used for both encryption and decryption.
Alex wants to send some confidential message to Blake. In symmetric cryptography both of them will have a common key, let's call it K1. Alex encrypts the message using the key (K1) and then Bob decrypts the message using the same key (K1). The problem with this method is, if the key is compromised anyone can read the message.

Asymmetric cryptography or Public Key Cryptography:

In this method, each node has two keys, one is a public key and the other one is a private key.
The most commonly used implementations of public key cryptography (also known as public-key encryption and asymmetric encryption) are based on algorithms presented by Rivest-Shamir-Adelman (RSA) Data Security.
Public key cryptography involves a pair of keys known as a public key and a private key (a public key pair), which are associated with an entity that needs to authenticate its identity electronically or to sign or encrypt data.
Each public key is published and the corresponding private key is kept secret. Data that is encrypted with the public key can be decrypted only with the corresponding private key.
RSA public key pairs can be any size. Typical sizes today are 1024 and 2048 bits.
In the above case, Alex and Blake both will have two keys each. Whenever there's a link between them, they'll share their public keys to each other. The encryption-decryption happens as follows. KA - Key of A, KB -Key of B, 1- Private Key, 2- Public Key.
1. When Alex sends a message to Blake, It's first encrypted using his private key (KA1)
2. Proceeded by Blake's Public Key (KB2)
3. Then, Blake decrypts the first layer of encryption using his private key (KB1).
4. Blake gets the original message when it's decrypted using A's public key (KA2) in the last step.
Properties of Asymmetric Cryptography:
- It is not possible to guess the Private key from the Public Key.
- However, they are mathematically linked in such a way that anything encrypted using either a Public or Private key can only be decrypted using only these two keys.
- Two layers of encryption ensure authenticity of the message. In the last step Blake is sure that the message was from Alex as it could be decrypted using Alex public key only.
- End-to-End encryption in WhatsApp works the same way.

Mining:

Mining is all about finding a Nounce value which will generate a hash value below a certain target threshold set by bitcoin network.
It is the process by which new bitcoin is added to the money supply.
Mining also serves to secure the bitcoin system against fraudulent transactions or transactions spending the same amount of bitcoin more than once, known as a double-spend.
Miners provide processing power to the bitcoin network in exchange for the opportunity to be rewarded bitcoin.
Miners validate new transactions and record them on the global ledger.
A new block, containing transactions that occurred since the last block, is “mined” every 10 minutes, thereby adding those transactions to the blockchain.
Transactions that become part of a block and added to the blockchain are considered “confirmed”, which allows the new owners of bitcoin to spend the bitcoin they received in those transactions.
Miners receive two types of reward for mining: new coins created with each new block and transaction fees from all the transactions included in the block.
To earn this reward, the miners compete to solve a difficult mathematical problem based on a cryptographic hash algorithm. The solution to the problem, called the Proof-of-Work, is included in the new block and acts as proof that the miner expended significant computing effort.
The competition to solve the Proof-of-Work algorithm to earn reward and the right to record transactions on the blockchain is the basis for bitcoin’s security model.
The process of new coin generation is called mining, because the reward is designed to simulate diminishing returns, just like mining for precious metals.
Bitcoin’s money supply is created through mining, similar to how a central bank issues new money by printing bank notes.
The amount of newly created bitcoin a miner can add to a block decreases approximately every four years (or precisely every 210,000 blocks). It started at 50 bitcoin per block in January of 2009 and halved to 25 bitcoin per block in November of 2012. It got halved again to 12.5 bitcoin per block in 2016.
Based on this formula, bitcoin mining rewards decrease exponentially until approximately the year 2140 when all bitcoin (20.99999998 million) will have been issued. After 2140, no new bitcoins will be issued.
Bitcoin miners also earn fees from transactions. Every transaction may include a transaction fee, in the form of a surplus of bitcoin between the transaction’s inputs and outputs.
The winning bitcoin miner gets to “keep the change” on the transactions included in the winning block.
Today, the fees represent 0.5% or less of a bitcoin miner’s income, the vast majority coming from the newly minted bitcoins.
However, as the reward decreases over time and the number of transactions per block increases, a greater proportion of bitcoin mining earnings will come from fees. After 2140, all bitcoin miner earnings will be in the form of transaction fees.

How Node verifies transactions:

Each node verifies every transaction against a long checklist of criteria as follows:
• The transaction’s syntax and data structure must be correct.

• Neither lists of inputs or outputs are empty.

• The transaction size in bytes is less than MAX_BLOCK_SIZE.

• Each output value, as well as the total, must be within the allowed range of values(less than 21m coins, more than 0).

• None of the inputs have hash=0, N=-1 (coinbase transactions should not be relayed).

• nLockTime is less than or equal to INT_MAX.

• The transaction size in bytes is greater than or equal to 100.

• The number of signature operations contained in the transaction is less than the signature operation limit.

• The unlocking script (scriptSig) can only push numbers on the stack, and the locking script (scriptPubkey) must match isStandard forms (this rejects “nonstandard” transactions)

• A matching transaction in the pool, or in a block in the main branch, must exist.

• For each input, if the referenced output exists in any other transaction in the pool, reject this transaction.

• For each input, look in the main branch and the transaction pool to find the referenced output transaction. If the output transaction is missing for any input, this will be an orphan transaction. Add to the orphan transactions pool, if a matching transaction is not already in the pool.

• For each input, if the referenced output transaction is a coinbase output, it must have at least COINBASE_MATURITY (100) confirmations.

• For each input, the referenced output must exist and cannot already be spent.

• Using the referenced output transactions to get input values, check that each input value, as well as the sum, are in the allowed range of values (less than 21m coins, more than 0)

• Reject if the sum of input values < sum of output values.

• Reject if transaction fee would be too low to get into an empty block.

• The unlocking scripts for each input must validate against the corresponding output locking scripts.
By independently verifying each transaction as it is received and before propagating it, every node builds a pool of valid new transactions (the transaction pool), roughly in the same order.
After validating transactions, a bitcoin node will add them to the memory pool, or transaction pool, where transactions await until they can be included (mined) into a block.
To construct the candidate block Jing’s bitcoin node selects transactions from the memory pool, by applying a priority metric to each transaction and adding the highest priority transactions first.
Transactions are prioritized based on the “age” of the UTXO that is being spent in their inputs, allowing for old and high-value inputs to be prioritized over newer and smaller inputs.
Prioritized transactions can be sent without any fees, if there is enough space in the block. The priority of a transaction is calculated as the sum of the value and age of the inputs divided by the total size of the transaction:

Priority = Sum (Value of input * Input Age) / Transaction Size

Forking Of Blockchain:

A “fork” occurs whenever there are two candidate blocks competing to form the longest blockchain.
This occurs under normal conditions whenever two miners solve the Proof-of-Work algorithm within a short period of time from each other.
As both miners discover a solution for their respective candidate blocks, they immediately broadcast their own “winning” block to their immediate neighbors who begin propagating the block across the network.
Each node that receives a valid block will incorporate it into their blockchain, extending the blockchain by one block.
If that node later sees another candidate block extending the same parent, they connect the second candidate on a secondary chain.
As a result, some nodes will “see” one candidate block first, while other nodes will see the other candidate block and two competing versions of the blockchain will emerge.
Forks are almost always resolved within one block. As part of the network’s hashing power is dedicated to building on top of “red” as the parent, another part of the hashing power is focused on building on top of “green”.
Even if the hashing power is almost evenly split, it is likely that one set of miners will find a solution and propagate it before the other set of miners have found any solutions.
Let’s say for example that the miners building on top of “green” find a new block “pink” that extends the chain (e.g. bluegreen-pink). They immediately propagate this new block and the entire network sees it as a valid solution.

How Polygon Blockchain works...

SK Sabiruddin — Sat, 03 Feb 2024 08:17:58 +0000

About:

Polygon is a blockchain platform which aims to create a multi-chain blockchain system compatible with Ethereum. As with Ethereum, it uses a proof-of-stake consensus mechanism for processing transactions on-chain. Polygon's native token is named MATIC. Matic is an ERC-20 token, allowing for compatibility with other Ethereum cryptocurrencies.
Polygon uses a modified proof of stake consensus mechanism that enables a consensus to be achieved with every block. Achieving consensus using traditional proof of stake requires processing many blocks to achieve consensus.
The proof of stake method requires network participants to stake—agree to not trade or sell—their MATIC tokens, in exchange for the right to validate Polygon network transactions. Successful validators in the Polygon network are rewarded with MATIC tokens.
The Polygon network aims to address problems within the Ethereum platform, namely high transaction fees and slow processing speeds.
Layer 2 solution. Off Chian computation. It's Decentralised.
Scalability issues solved. High throughput (High TPS). Enhance the capability of Ethereum.
Can achieve 10000 TPS.
Provide SDK. Mobile apps can build using this.
Matic js : to build Polygon apps using JS.
It has Polygon mainnet and mumbai testnet.

Architecture of Polygon:

Polygon network is divided into 3 Parts/Layers:
- 1) Ethereum Mainnet. / BeaconChain. It has: (All the SC that polygon is using i.e. Staking Contract , checkpoint contract and Reward Contract etc. ⮃
- 2)Heimdall (POS for Polygon): <- (Polygon consensus layer).It contains POS mechanism. (2/3 voting)⮃
- 3) BOR layer. For adding new Blocks. (MATIC Chain = Native token for Polygon.)
The Heimdall node is responsible for aggregating or rolling up blocks produced by the Bor node into a Merkle tree and publishing the Merkle root onto the Ethereum blockchain in periodic intervals called checkpoints.
Checkpointing provides finality on the Ethereum network which is used in the withdrawal of assets from Polygon to Ethereum through Proof of Burn proofs.
The Bor node, a Geth fork, is the execution layer of Polygon. It’s responsible for processing transactions into blocks and passing those blocks to Heimdall for validation.
Polygon network blocks are by default proposed in the BOR layer, after which they are forwarded to the Ethereum layer after consensus is reached via the POS mechanism in the Heimdall layer.
There are various checkpoints available in Polygon POS. One block is minted in every 2 seconds in the BOR chain.
Each block will have its own blockhash. One block has between 100 and 200 TXN.
For example, five blocks with various TXNs connected to a POS polygon checkpoint. The merkel root hash for all block hashes was then represented by combining the block hashes of the individual blocks. The ethereum mainnet will receive that single merkle root hash.
Thus, 1 hash will be used to represent 600 transactions on the mainnet. Block will be put to the Ethereum blockchain after the Merkel root and TXN have been verified. Only the final polygon transaction, not the individual blocks, will be able to alter the Ethereum State.
Make sure a specific transaction is real or not by using the Merkel root.
At checkpoints, the BOR layer continuously generates new blocks and adds them to the Heimdall layer.
In every 10-20 minutes, checkpointing and snapshots of every block (Merkel Root) are taken i.e., all suggested blocks are added to the Heimdall layer on the checkpoint every 20 minutes.
These blocks from BOR networkswere added by randomly selected validators from the POS polygon.
In order to avoid doing transactions on the Ethereum blockchain, Polygon must execute the majority of its Transactions or operations in the offchain. Just To confirm the transactions, it uses Ethereum.

Heimdall Chain: (POS network , acting like BeaconChain)

It is the POS verification layer of polygon.it does the Checkpointing of BOR blocks/ Plasma blocks representation.
Transferring the Merkel root to the Ethereum blockchain from a checkpoint. And all the logic to validate this three-layer architecture is contained in the Polygon Smart Contract that was implemented on Ethereum.
The Ethereum mainnet is where the staking contract is deployed. It includes all the logic for proposing new blocks, allocating voting rights to various validators, selecting a random validator, and overseeing checkpoints.
On the Ethereum blockchain, Heimdall is able to perform function calls to the staking smart contracts. Polygon uses the Ethereum Mainnet for all it's security.
Aggregation of blocks produced by BORat the checkpoints. Then, verify the block signature and hashs of the Individual blocks. It merged the blocks to create the root hash after it was validated.
After successful validation, the blocks are merged to create the root hash and then it will be sent to Ethereum mainnet as final transaction.
Tendermint software need to install in order to become a validator.
Every new block, one valiadtor will perform the following duties:
- Validate all blocks since the last checkpoint.
- Creates a merkel tree of block hashes.
- Final hash can be checkpointed and send to the mainnet.
- polygon will do 1-1 mapping with the mainnet.
Checkpoint importance/Task:
- Providing finality on the root chain.
- Providing proof of burn in the withdrawal assets.
- How transfer of token happens in both chain (zkEVM)

`ERC20 polygon <-> Mainnet ETH`. Tokens that are mapped to equivalent amounts, that should be added to the mainnet, will be `burned on polygon` before being `transferred to the mainnet and vice versa`.

Blockchain Consensus Mechanism

SK Sabiruddin — Fri, 02 Feb 2024 16:50:25 +0000

Consensus mechanism:

A consensus mechanism is a algorithm or protocol used by nodes in a distributed system to reach agreement on the state of the system.
In a blockchain, the consensus mechanism is used to determine which transactions will be included in the next block of the ledger and to prevent conflicting transactions from being included.
A consensus protocol is a process used to achieve agreement between participants of a distributed network.

Proof Of Work (PoW):

Yes, it means what it sounds like, showing the proof that you have done the work. As we know mining is basically solving a complex mathematical problem that requires high computational power.

At a time when many miners compete to mine a block, the node that wins the race has a proof of work of spending energy and resources and hence it’s rewarded when the block is verified and added to the chain.
If the node tries to perform malicious activity, the block will not be verified by other nodes in the network and the miner doesn’t get the reward, which is a total waste of its resources and time.
Bitcoin works on PoW, while Ethereum is using Proof of Stake. Proof Of Work requires a lot of power as many miners try to compete to mine a block, Proof Of Stake is a better alternative.

Facts about PoW:

Bitcoin has around 2700 transactions in a block after 10 minuteswhich is around 4/5 TPS. (7–19 minutes to create a block, i.e., an average of 10 minutes).
There is a 14-day maximum hold period for transactions in the mempool. Higher transaction fees are used in the mempool to replace lower transaction fees. You'll need to resend the transaction again after that because it will be removed from the mempool.
Once a transaction is added to the blockchain, it will wait for 6 more blocks to be added to the same blockchain for confirmation and to become irreversible.
In every 2 weeks, the bitcoin blockchain checks the average time for the last two weeks. Based on this, the difficulty level was adjusted to make the average mining time per block 10 minutes.
The bitcoin blockchain looks up the average time spent in mining a block over from previous two weeks. To make the average mining time per block 10 minutes, the difficulty level was adjusted in light of this.
In 10 minutes, 1 block mined => In 2 weeks = 2016 mined blocks. So, the difficulty level for miners is adjusted after every 2016 blocks (after 2 weeks).
After 210000 blocks, or every 4 years, Coinbase awards will be divided in half. In 2013, 50 bitcoins were given to miners for successfully mining a block then after 4 years it was 25 then 12.5 and now it's 6.26. This is known as halving. 4-year halving cycle.
Since miners get fewer rewards, the price of bitcoin will increase. Miners control the circulation of bitcoin price.They'll sell the bitcoin at a higher price to get the benefit.
The price of bitcoin will rise since miners receive smaller rewards. The price of bitcoins is determined by miners. To earn profit, they will sell the bitcoin for more money. Miners control the circulation of bitcoin price.
Reward: Coinbase/Mining Reward (6.25 BTC) + Transaction Fee (1-2 lakh) Reward points will be distributed to miners; however, they won't be able to use it for another 16 or 17 hours, or until the next 100 blocks are created. (also known as Maturity of Coinbase)
Original Bitcoin network, commonly known as bitcoin cash, was forked in order to extend the block size from 1 MB to 4 MB, allowing for the addition of more transactions. Each Block size: 1 MB, after forking: 4 MB
Bitcoin uses/follows the longest chain in operation.
wallet = public key + private key. Hierarchical deterministic wallet: HD wallet (uses different keys for each transaction)
Bitcoin address = SHA256(public key)
Transaction hash: To determine the final transaction hash, find the hash of each transaction and apply the merle tree. The block hash will be determined as follows: block no + nonce + transaction hash + timestamp.

Drawbacks of PoW:

There is only one blockchain i.e. no sharding concept available.
Too much energy consumption: Bitcoin annual mining = Argentina's electricity
Network Congestion (NC): When the network consumption is high, the dynamic gas price kicks in and vice versa, resulting in the extended block confirmation time. Also, it takes longer time to add transactions from Dapps with significant network consumption in the blockchain.

Proof of Stake (PoS):

Ethereum 2.0: POS: POS based Ethereum blockchain (Also known Serenity or Beacon Chain). Has PoS consensus & Shard chains.
In POS, there are no miners. They are referred as validators rather than miners. In order to be a validator on the Ethereum network, one must stake 32 ETH.
Groups of people can invest money in liquidity pools, also known as staking pools, until they reach 32 ETH and become validators.
32 ETH will be locked in for a brief period of time, and the blockchain software will serve those as a validator. Liquidity pools can be found in Dapps. A liquidity pool can be a Dapp.
Geth: GO implementation of the ETH, store private/public key.
These three types of software must be installed. (Part of GETH): (POS architecture)
- Execution client
- Consensus client (consensus: voting and reaching agreement)
- Validator Client
Once 32 ETH are deposited (blockchain software will be activated), a validator joins a queue where others are waiting to be validators.

Adding new blocks in PoS: (How blocks added in POS)

Beacon chains have slots and epochs.
There is a data structure that has 32 partitions. Each partition is called a Slots. The combination of 32 slots is called an Epoch.
All of the slots are capable of taking transactions. They are representations of proposed blocks. Slots are the intermediate state of a block.
A transaction can be proposed in any slot by the validator who wishes to add a block to the Ethereum blockchain. To add these blocks, individuals or validators are selected at random.
In POW, the miner with the best hardware mines the transaction. On the other hand, POS uses random selection. When a block is inserted, only one validator will be selected at a time to validate that.
The amount of ETH staked, was chosen as a validator, based on probability. The more, one stake the ETH, has greater chance of becoming a validator.

PoS committees: (128 committee members/attester)

There will be at least 128 committee members (who are also randomly selected as validators) and 1 proposer, or validator, who will be picked at random to add blocks or transactions to the blockchain, for each slot. Each of them also staked at least 32 ethers.
Committee members' responsibility is to verify if a transaction or block added by the proposer or validator is malicious or legitimate. In this case, the majority needed to confirm a certain slot is 2/3 = 66%(committee members).
Therefore, each time a validator is selected at random from that queue, 128 other validators are selected at random for every slot so that committee members can validate one transaction or add one block. For all 32 slots in a single epoch, the same event occurs for every slot.
There will be 12 seconds for each slot. The duration of the entire epoch is 6.4 minutes. No vacant slots are uploaded to the blockchain.
If the proposer is unable to add a transaction to the slot, Beacon Chain will penalize them. A portion of the Ethereum staked will be burnt. The procedure will use up some of the 32 ethers.
It will burn some of the stake if it commits fraud. (1% Stake).
The Ethereum blockchain has a list of active validators. If any malicious activity found by a validator, Ethereum will remove it from the blockchain network.
The checkpoint will reverse any newly added slots or blocks to the blockchain in the event that any fraudulent transactions are found.
The first slot in each epoch serves as a checkpoint. It will function as the approved or finished version of the blockchain. The last accepted state of the first slot is based on the voting of committee members, that will roll back to the last checkpoint in case of fraud transactions.
Genesis Block = Slot 0 + Epoch 0. Every epoch is meant to reach finality. A maximum of<=32 slots can be present in an epoch. Epoch's function is to strengthen the blockchain's security by introducing checkpointing.
Batches of 32 blocks are uploaded to the blockchain. One slot equals one block, and every block contains a unique collection of transactions.
Each epoch's validator task is as follows:-> (for 1 slot)
- Randomly selected to propose a new block.
- In order to approve the transaction, a committee member was arbitrarily selected to vote.
- To confirm the signature of the transaction, i.e., the public key and private key, committee members will run the transaction through the slots once more. They'll cast their vote when they've checked the signature. Verify the signature by comparing it with the proposer's signature.

`Notes: 1 Epoch = 32 Slots = 32 blocks uploaded to bockchain = slots can store transactions. 128 Committee members/attester for 1 proposer/validator. 128 other validators to propose transaction for each slot. 12 seconds for each slot. epoch is 6.4 minutes long.`

Reward for Mining a block in PoS:

Base reward = validator effective balance * 2^6 / SQRT(Effective Bal. of all active validators).
Reward for POS: % of total staked Ethereum. Rewards will be given for each slot.
One can be an attester or a proposer at any point in time in one epoch. 1 task per epoch. Interest on the entire amount of ether staked will be given to you.
There is no mining in POS. The portion of ether that you get in return will be added to the overall amount of ether in circulation.
You can withdraw the staked ether only after a period of 1.5 years.

Sharding in POS (also known as horizontal sharding): (Parallel blockchain: 15% faster transactions)

There are 64 shard chains and 1 beacon chain.
64 shard chains will each have a portion of the tasks.
Every shard chain will make reference to the beacon chain.
Every single shard chain's data can be read by the beacon chain.
Hashing will be used in beacon chains to store the distinctive characteristics of shard chains.
The beacon chain is assigning tasks to the shard chains.

Drawbacks of Ethereum:

Gas prices are high due to heavy network congestion.
Scalability issues i.e. 13-15 TPS.

Solution:

Layer 2 scaling solution. It uses POS Consensus. A certain gas price changes each time a state is altered. Has some network throughput as well. (TPS).
Layer 2 blockchain: They are of ERC20 type token. EVM compatible. E.g.: Polygon

Ethereum Blockchain 101

SK Sabiruddin — Fri, 02 Feb 2024 10:25:34 +0000

About:

Ethereum is a decentralized, open-source blockchain platform that runs smart contracts, applications that run exactly as programmed without any possibility of downtime, censorship, fraud or third-party interference.
These applications are run on a custom-built blockchain, which is a decentralized database that runs on a network of computers.
Ethereum is the second-largest blockchain platform by market capitalization, after Bitcoin. It was developed by Vitalik Buterin in 2013 and has since become a popular platform for creating and running decentralized applications.

Smart Contracts:

Smart contracts are self-executing contracts with the terms of the agreement between buyer and seller being directly written into lines of code.
The agreements and the code are spread via a decentralized, distributed blockchain network.
By automating digital contracts, smart contracts have the power to completely transform the way that business is conducted and documented, opening the door to entirely new types of ventures while also enhancing the effectiveness and safety of current systems.

Blockchain Layers:

Layer 0: It’s the underlying infrastructure layer that forms the basic blockchain network consisting of distributed nodes forming the peer-to-peer architecture. Layer 0 enables interoperability (cross-chain communication) blockchain protocols that are built on the same layer 0, can easily transfer tokens and data.

Example: PolkaDot, Avalanche, Cosmos etc
Layer 1: L1 blockchains, also known as "layer 1" blockchains, are the foundational layer of a blockchain platform. They are the underlying infrastructure that supports the platform and enables it to function.
- L1 blockchains typically consist of a network of nodes that maintain a shared, decentralized ledger of transactions and a consensus mechanism to ensure the integrity and security of the ledger.
- L1 blockchains are often the first layer of a multi-layer blockchain platform, with additional layers built on top to provide additional features and functionality. Examples of L1 blockchains include the Bitcoin and Ethereum networks.
- Prominent blockchains like Bitcoin. Ethereum, Solana, Near, etc are the layer 1 chains. These are the execution protocols that provide the environment for transactions, handling cryptographic algorithms, data, consensus and tokenomics. Native tokens of the chain are the medium to interact with smart contracts, access resources, and mint NFT.
- As I mentioned earlier, some examples of L1 blockchains include the Bitcoin and Ethereum networks. Both of these networks are decentralized, open-source platforms that run on a network of nodes and use a consensus mechanism to maintain a shared ledger of transactions.
- Other examples of L1 blockchains include Litecoin, which is based on the Bitcoin network and provides faster transaction processing times, and Ripple, which is a payment network for financial institutions. These are just a few examples of L1 blockchains; there are many others that are in use today.
Example : Solana, Ethereum, Bitcoin, Tezos, Near
Layer 2: An L2 blockchain, or "layer 2 blockchain," is a blockchain that is built on top of another blockchain, known as the "layer 1" or "base" blockchain.
- L2 blockchains are designed to improve the scalability, performance, and security of the underlying blockchain by offloading some of the workload to the L2 blockchain.
- This can help to reduce transaction fees, increase transaction throughput, and improve the user experience.
- Some examples of L2 blockchains include the Lightning Network on top of the Bitcoin blockchain, and the Plasma framework on top of the Ethereum blockchain.
- Built on top of layer 1 chains, L2 solves the scalability problem of the blockchain trilemma by improvising on transaction speed (faster finality) & throughputs (higher transactions per second).
- Layer 1 handles security, data & consensus while Layer 2 handles transactions and regularly communicates with layer1.
- It takes away the transaction burden from layer 1 while taking the advantages of layer1’s security and decentralization.
Example : Polygon Matic L2 on Ethereum
Layer 3: This is the utility layer where all the decentralized applications are built like DeFi, games & wallets. It gives abstraction where the user is only use the applications.

Sharding:

Sharding is a technique used to improve the scalability and performance of a blockchain. In a sharded blockchain, the network is divided into multiple "shards," or partitions, where each shard processes a subset of the transactions and maintains its own portion of the ledger. This allows the network to process multiple transactions in parallel, which can increase the overall transaction throughput and reduce transaction fees.
Here is an example of the steps to build a blockchain with sharding:

Determine the number of shards and the shard size. The number of shards should be determined based on the desired level of scalability and performance, while the shard size should be determined based on the desired level of decentralization and security.
Implement the sharding mechanism. This involves designing and implementing the algorithms and data structures for dividing the network into shards, assigning transactions to shards, and maintaining the consistency and integrity of the ledger across all shards.
Implement the consensus mechanism. In a sharded blockchain, the consensus mechanism must be designed to ensure that the transactions within each shard are processed and validated in a decentralized and secure manner, and that the ledgers across all shards remain consistent.
Implement the transaction processing and validation logic. This involves designing and implementing the algorithms and data structures for processing and validating transactions within each shard, as well as the mechanisms for communicating and coordinating with other shards.
Implement the APIs and interfaces for interacting with the blockchain. This includes designing and implementing the APIs and interfaces for submitting transactions, querying the ledger, and accessing the data and functionality of the blockchain.

Consensus mechanism:

A consensus mechanism is a algorithm or protocol used by nodes in a distributed system to reach agreement on the state of the system. In a blockchain, the consensus mechanism is used to determine which transactions will be included in the next block of the ledger and to prevent conflicting transactions from being included.
A consensus protocol is a process used to achieve agreement between participants of a distributed network.
Basically, that’s how a consensus protocol works in blockchain. Different blockchain’s have different consensus protocol. Types of Consensus Protocol:

Proof Of Work (PoW):
Yes, it means what it sounds like, showing the proof that you have done the work. As we know mining is basically solving a complex mathematical problem that requires high computational power.
- At a time when many miners compete to mine a block, the node that wins the race has a proof of work of spending energy and resources and hence it’s rewarded when the block is verified and added to the chain.
- If the node tries to perform malicious activity, the block will not be verified by other nodes in the network and the miner doesn’t get the reward, which is a total waste of its resources and time.
- Bitcoin works on PoW, while Ethereum is using Proof of Stake. Proof Of Work requires a lot of power as many miners try to compete to mine a block, Proof Of Stake is a better alternative.
Proof of Stake (PoS):
In Proof of Stake, instead of miners competing in a race to mine a block, they are asked to stake (deposit) some minimum tokens (32 ETH) of that blockchain to become validators (Miners in PoS are called as Validators).
- The validators are chosen randomly taking into consideration how many tokens they have staked or for how long they have been staking.
- If a validator performs any malicious activity he’s penalized from the stake.
- It is a more energy efficient protocol as not all the validators compete against each other which lowers transaction cost and increases throughput.
- This is one of the primary reasons for Ethereum to migrate to PoS.
Proof of History (PoH):
Proof of History is an extension of Proof of Stake, developed by Solana. And it’s one of the primary reasons why Solana is very fast, having the block time of 400 millisecond compared to Ethereum (1Sec) & BTC (10Mins).
- PoH introduces a variable of time in the block, it’s showing the proof that a historical event had occurred.
- In other consensus protocols the validators need to talk to each other to agree on when a block was added and how much time has passed. Whereas in Solana it has its own clock coded in a SHA256 algorithm, the validators keep mining blocks and they are sequentially added to the chain.

Blockchain Basics

SK Sabiruddin — Fri, 02 Feb 2024 06:49:02 +0000

Blockchain Overview:

Blockchain is a type of digital ledger technology that makes it possible to build decentralized, transparent, and safe networks. A blockchain is a distributed database that is not controlled by a single entity but rather by a network of computers called nodes. A copy of the database, which holds a history of every transaction made on the blockchain, is kept on every node in the network.
Numerous nodes inside the network use complex cryptographic methods to verify and confirm every transaction on the blockchain. A new block is added to the blockchain when a transaction is approved and verified, completing the chain. All nodes inside the network get this block and update their respective copies of the blockchain accordingly.
The reason the blockchain is regarded as safe is that each block in the chain is connected to the one before it, forming an unbreakable transaction chain. A block is a tamper-proof record of every transaction that has ever taken place on the blockchain since once it is added, it cannot be removed or changed.
Applications for blockchain technology are numerous and include voting systems, healthcare, supply chain management, finance, and more. Its potential is found in its capacity to foster security, trust, and openness across a range of industries, do away with the need for middlemen, and open the door to new business models.

Why do we need blockchain?

Decentralization: Establishing decentralized systems is one of the main goals of employing blockchain technology. A decentralized network is more transparent, safe, and resistant to censorship and corruption since it lacks a central authority or middleman to exert control over it.
Security: Cryptographic algorithms are used by blockchain technology to protect data and transactions. Multiple parties validate and verify each transaction on the blockchain, making it more difficult for an unauthorized person to change the data or steal information.
Transparency: By generating an immutable ledger of every transaction, blockchain technology promotes transparency. As a result, trust and accountability are encouraged because every member of the network can view every transaction that has occurred and confirm its legitimacy.
Efficiency: Through the removal of middlemen and the automation of procedures, blockchain technology can lower transaction costs and boost efficiency. Businesses can cut expenses and boost revenues by expediting and streamlining transactions by doing away with middlemen.

Types of Blockchain:

There are generally three types of blockchain: public, private, and hybrid.

Public Blockchain: Anyone can access and participate in a public blockchain, which is a decentralized blockchain network. Anyone can read and write data on the network and join it. The public blockchains of Ethereum, Litecoin, and Bitcoin are examples.
Private Blockchain: A permissioned blockchain network is one in which only individuals with permission are able to access and engage with the network. Private blockchains are usually utilized by businesses or by a select group of reliable and well-known individuals. The Quorum, Corda, and Hyperledger Fabric private blockchains are a few examples.
Hybrid Blockchain: A hybrid blockchain is made up of elements from both private and public blockchains. Because it enables authorized users to access and engage with both the public blockchain network and the private network, it provides the best of both worlds. Aion, Dragonchain and other hybrid blockchains are examples of it.

Apart from the aforementioned trio of blockchain styles, there exist additional varieties or adjustments to the three main types of blockchains. A type of private blockchain known as a consortium blockchain, for instance, is one in which a number of businesses band together to cooperatively run and maintain the network.

Blockchain Applications:

Blockchain technology has a wide range of applications across various industries. Here are four examples of how blockchain is being used:

Cryptocurrencies: The development and utilization of cryptocurrencies such as Bitcoin, Ethereum, and Litecoin is the most well-known application of blockchain technology. These digital currencies employ blockchain technology to enable safe, peer-to-peer transactions. They are decentralized, which means they are not governed by any financial organization or government.
Supply Chain Management: By generating a safe, transparent record of each transaction that takes place in the supply chain, blockchain technology is being utilized to enhance supply chain management. This promotes efficiency, lowers fraud, and strengthens confidence between all supply chain participants.
Identity Verification: People can establish safe, immutable digital identities for themselves using blockchain technology. This can lessen fraud and identity theft and make it simpler for people to authenticate themselves in a range of situations.
Smart Contracts: Smart contracts are self-executing agreements that automatically carry out their terms by utilizing blockchain technology. This can improve contract execution efficiency and speed while also lessening the need for middlemen like banks and lawyers. Financial services, insurance, and real estate are just a few of the businesses using smart contracts.

Ethereum Vs Bitcoin:

Ethereum and Bitcoin are both decentralized blockchain platforms that have some similarities but also some
important differences. Here are some key differences between Ethereum and Bitcoin:

Ethereum was intended to serve as a platform for smart contracts and decentralized applications (Dapps), whereas Bitcoin was intended to serve as a decentralized digital currency.
Bitcoin uses a Proof of Work (PoW) mining method, which, in order to validate transactions and add new blocks to the blockchain, consumes a significant amount of processing power and energy. Nowadays, Ethereum employs the more energy-efficient PoS algorithm.
While Bitcoin has a limited scripting language for transactions, Ethereum allows developers to create custom smart contracts and decentralized applications using a variety of programming languages, such as Solidity, Vyper , and Rust.
The processing speed of Ethereum transactions (15-20 tps) is generally faster than that of Bitcoin (7/8 tps), with an average block time of approximately 15 seconds, as opposed to 10 minutes for Bitcoin. This is achieved through scalability. The network congestion that causes high fees and delayed transaction times during peak demand is one of Ethereum's scalability problems.
Ethereum does not have a fixed supply; instead, new Ethereum tokens are created through mining and transaction fees. Bitcoin has a finite quantity of 21 million coins.
In Bitcon, miners will get 6.25BTC(halving in every 4 years) and in Ethereum, they will get 2 ETH.

Cryptocurrency VS Token:

Cryptocurrency is native to a Blockchain network. A Blockchain can have only one cryptocurrency but a million tokens. For example, Ethereum has its native currency, ether, but regulates multiple tokens such as USDC, AVAX, UNI, USDT, etc.
Tokens are backed by a smart contract and can contain various functionalities depending upon different use cases. For example, security tokens, utility tokens, etc.
Tokens can represent any asset on a blockchain network. For example, art, equity, insurance, identity, tickets, etc.

Broadly, there are three basic token standards and more will be added over time. Let’s understand them one by one.

ERC20 :

This standard is used to implement the functionality behind Fungible tokens. Fungible Tokens of a type are all alike and can be exchanged for the same value. For example, USDC, UNI, AVAX, DAI, etc.

Ex: When you ride a metro/subway train, the ticket you buy is the same as everyone else for the same destination. Even if you exchange the ticket with someone, it would still work for you as there’s no differentiator between those tickets. Such items are called ‘fungible’, meaning that they can be mutually exchanged. Other examples of fungible items are currency notes, shares of a company etc.

ERC721 :

This standard is for Non-Fungible Tokens (NFTs). Tokens of this type are meant to be unique and cannot be exchanged for the same value given that none of them are alike. For example, Bored Apes, CryptoKitties, etc. we usually call the image itself as an NFT and ultimately this is the thing that we bought it for. But technically, an NFT is a serial ID on the blockchain i.e. 1, 2, 3 etc. Against this serial ID, there’s a wallet address, and this mapping of address against the serial ID proves that a particular serial ID is owned by a particular address. In IPFS/Pinata, you can upload the images and metadata for your NFT that can then be connected to your ERC-721 smart contract. With this, we’ll now have two mappings on the blockchain:
Token ID –> User Address
Token ID –> Token URI (This mapping is actually done through a function that returns a URI for each token ID as we’ll see later in this lesson) i.e. one mapping will contain which user address owns a particular token ID. The second mapping maps the token URI to each token ID. The token URI is the hash of metadata stored on IPFS that contains the details and properties of the image associated with the token ID.

Thus, we establish the ownership of NFTs on the blockchain by storing the token IDs, wallet addresses and token URI function. Whereas the images and their details & properties are stored on the IPFS and connected to the smart contract via token URI.

Ex: When you take a flight, you can’t exchange your boarding pass with another person even if you both are going to the same destination. That’s because your boarding pass has your name and your seat number, both of which are unique. Hence each boarding pass is different from others. Such items are called ‘non-fungible’, meaning they can’t be exchanged with other items. Other examples of non-fungible items are your driving licence, your college degree, a piece of art etc.

ERC1155 :

This standard is used to implement functionalities of both fungible and non-fungible tokens. It can also be called a standard for semi-fungible tokens. For example, multiple editions of a song or photographs.

Ex: When you attend a concert, you can buy a General pass, VIP pass, Multi-day pass and so on. If you hold a general pass, you can exchange your pass with someone holding a general pass but not with someone holding a VIP pass. Hence, such items are a mixture of fungible and non-fungible. Different categories of passes are non-fungible, but the passes within the same category are fungible. Other examples being shares of different companies, metro tickets for different destinations etc.

DEV Community: SK Sabiruddin

Solidity Gas Optimization Techniques

Gas Units:

Gas Price:

Where does my gas fee go?

How to save Gas Cost:

Some other gas saving techniques: -

Some more details: (Credit - CodeEater)

Other Useful links:

Mastering Ethereum Notes

The components of an open, public blockchain are:

About Ethereum:

Ethereum’s Components:

EVM Architecture:

Ether denominations and unit names:

Full Node Advantages and Disadvantages:

Advantages:

Disadvantages:

Types of Keys in Ethereum:

Private Keys:

Public Keys:

Serialized EC public key prefixes:

Wallets:

Generating Mnemonic words 128 bit / 12 words:

The Structure of a Transaction:

Chain identifiers:

Oracles:

The steps for a request–response oracle may be summarized as follows:

What Is a DApp?

Mastering ₿itcoin Notes

Bitcoin:

Address (aka public key):

BIP:

Block:

Blockchain:

Confirmations:

Difficulty:

Difficulty target:

Difficulty re-targeting:

Fees:

Hash:

Genesis block:

Miner:

Network:

Proof-of-work:

Reward:

Secret key (aka private key):

Transaction:

Wallet:

Transaction Locktime:

Transaction Outputs and Inputs : (UTXO)

Transaction Pools:

About Bitcoin:

Generating Bitcoin address from private key:

Base58Check Encoding:

Base58Check Version Prefix and Encoded Result Examples:

Hierarchical Deterministic Wallets (BIP0032/BIP0044):

Block Header:

Merkle Trees:

Cryptography:

Types of Cryptography:

Symmetric Cryptography:

Asymmetric cryptography or Public Key Cryptography:

Mining:

How Node verifies transactions:

Forking Of Blockchain:

How Polygon Blockchain works...

About:

Architecture of Polygon:

Heimdall Chain: (POS network , acting like BeaconChain)

ERC20 polygon <-> Mainnet ETH. Tokens that are mapped to equivalent amounts, that should be added to the mainnet, will be burned on polygon before being transferred to the mainnet and vice versa.

Blockchain Consensus Mechanism

Consensus mechanism:

Proof Of Work (PoW):

Facts about PoW:

Drawbacks of PoW:

Proof of Stake (PoS):

Adding new blocks in PoS: (How blocks added in POS)

PoS committees: (128 committee members/attester)

Notes: 1 Epoch = 32 Slots = 32 blocks uploaded to bockchain = slots can store transactions. 128 Committee members/attester for 1 proposer/validator. 128 other validators to propose transaction for each slot. 12 seconds for each slot. epoch is 6.4 minutes long.

`ERC20 polygon <-> Mainnet ETH`. Tokens that are mapped to equivalent amounts, that should be added to the mainnet, will be `burned on polygon` before being `transferred to the mainnet and vice versa`.

`Notes: 1 Epoch = 32 Slots = 32 blocks uploaded to bockchain = slots can store transactions. 128 Committee members/attester for 1 proposer/validator. 128 other validators to propose transaction for each slot. 12 seconds for each slot. epoch is 6.4 minutes long.`