Smart Contract Development
  • Introduction
    • What is a Transaction
    • Accounts and Signing
    • What is a smart contract
  • Learning Solidity
    • Introduction
    • Module 1
      • Variable Types
      • Variable Scope: State & Local variables
      • Global variables
      • Functions
        • View and Pure
        • Shadowing in Fuctions
      • Mapping
      • Require
      • Events
    • Project #1: Simple Registry
    • Module 2
      • Constructor
      • Data Location: Value & Reference
      • Interface
      • Import
        • Importing in Foundry
      • Inheritance
      • ERC-20
      • Checks-effect-interaction pattern
    • Project #2: Basic Vault
    • Module 3
      • Payable
      • Receive
      • Fallback
      • Returns
    • Project #3: ERC20+ETH Wrapper
    • Module 4
      • Immutable and Constant
      • Fixed-point Math
      • Abstract contracts
      • ERC-4626
      • Modifier + Inheritance +Ownable
      • Type
    • Project #4: Fractional Wrapper
    • Module 5
      • If-else
      • Libraries
        • TransferHelper
      • Chainlink Oracle
    • Project #5: Collateralized Vault
  • Compendium
    • Solidity Basics
      • Variable Types
      • Value Types
        • address
        • enum
      • Reference Types
        • strings
        • mappings
        • struct
        • Arrays
        • Multi-Dimensional arrays
      • Global Objects
      • Functions
        • Function types
        • Constructor Function
        • Transaction vs Call
        • Require, Revert, Assert
      • Function signature + selectors
      • Payable
        • Payable + withdraw
        • msg.value & payable functions
      • Receive
      • Fallback function (sol v 0.8)
        • Fallback function (sol v 0.6)
      • call, staticcall, delegatecall
    • Return & Events
    • Control Variable Visibility
    • Local Variables (Storage v Memory)
    • Data Location and Assignment Behaviors
    • Modifiers & Inheritance & Import
      • import styles
    • Interface & Abstract Contracts
    • ABI & Debugging
    • Libraries
    • Conditional(ternary) operators
    • Smart Contract Life-cycle
      • Pausing Smart Contracts
      • Destroying Smart Contracts
    • Merkle Trie and MPT
    • Merkle Tree Airdrop
  • Try & catch
  • Ethereum Signatures
  • EVM, Storage, Opcodes
    • EVM
    • Wei, Ether, Gas
    • Storage
    • ByteCode and Opcodes
    • Transaction costs & Execution costs
  • Reading txn input data
  • Data Representation
  • Yul
    • Yul
      • Intro
      • Basic operations
      • Storage Slots
      • Storage of Arrays and Mappings
      • Memory Operations
      • Memory: how solidity uses memory
      • Memory: Return, Require, Tuples and Keccak256
      • Memory: Logs and Events
      • Inter-contract calls
      • calldata
      • free memory pointer
    • Yul Exercises
      • read state variable
      • read mapping
      • iterate Array, Return Sum
    • memory-safe
  • Upgradable Contracts
    • Upgradability & Proxies
    • UUPS Example
    • Minimal Proxy Example
    • TPP Example
    • 🚧Diamond
      • On Storage
  • Gas Opt
    • Block Limit
    • gasLimit & min cost
    • Solidity Optimiser
    • Memory v calldata
    • Memory caching vs direct storage vs pointers
    • < vs <=
    • reverting early
    • X && Y, ||
    • constant and immutable
    • caching sload into mload
    • Syntactic Sugar
    • using unchecked w/o require
    • Compact Strings
    • Calling a view function
    • Custom errors over require
    • usage of this.
      • multiple address(this)
  • ERCs & EIPs
    • ERC-20.sol
      • Core functions
      • transfer()
      • transferFrom()
      • TLDR transfer vs transferFrom
    • Landing
      • ERC721.sol
      • EIP-721
        • LooksRare
        • Page 1
      • ERC-1271
      • EIP-2981
      • ERC-165
      • EIP-1167: Minimal Proxy Contract
    • VRFConsumerBase
    • UniswapV2Library
  • Yield Mentorship 2022
    • Projects
      • #1 Simple Registry
      • #2 Basic Vault
      • #3 ERC20+ETH Wrapper
        • setFailTransferTrue
      • #4 Fractional Wrapper
      • #5 Collateralized Vault
        • Process
        • Vault.sol
        • Testing
        • Chainlink Oracles
        • Pricing + Decimal scaling
        • Refactor for Simplicity
      • #9 Flash Loan Vault
        • Implementing ERC3156
        • Full code for lender
        • Ex-rate calculation
    • State Inheritance Testing
    • Testing w/ Mocks
    • Yield Style Guide
    • Github Actions
    • TransferHelper.sol
    • math logic + internal fn
    • Interfaces: IERC20
  • Foundry
    • Overview
    • Importing Contracts
    • Testing
      • stdError.arithmeticError
      • assume vs bound
      • Traces
      • label & console2
      • std-storage
  • Smart Contract Security
    • Damn Vulnerable Defi
      • 1. Unstoppable
      • 2. Naive receiver
      • 3. Truster
      • 4. Side Entrance
      • 5. The Rewarder
      • 6. Selfie
      • 7. Compromised
      • 8. Puppet
      • 9. Puppet V2
      • 10 - Free Rider
    • Merkle Tree: shortened proof attack
  • Fixed-Point Math
    • AMM Math
  • Solidity Patterns
    • checks-effects-interactions pattern
    • Router // batch
    • claimDelegate: stack unique owners
    • claimDelegate: cache previous user
  • Array: dup/ascending check
  • Deployment
    • Behind the Scenes
    • Interacting with External Contracts
    • Logging, Events, Solidity, Bloom Filter
  • Misc
    • Mnemonic Phrases
    • Bidul Ideas
  • Archive
    • Brownie Framework
      • Brownie basics
        • storing wallets in .env
        • Deployment to ganache
        • Interacting with contract
        • Unit Testing
        • Testnet deployment
        • Interacting w/ deployed contract
        • Brownie console
      • Brownie Advanced
        • Dependencies: import contracts
        • helpful_scripts.py
        • verify and publish
        • Forking and Mocking
        • Mocking
        • Forking
      • Testing
      • Scripts Framework
        • deploy.py
        • get_accounts
        • deploy_mocks()
        • fund_with_<token>()
      • Brownie Networks
    • Brownie Projects
      • SharedWallet
        • Multiple Beneficiaries
        • Common Code Contract
        • Adding Events
        • Renounce Ownership
        • Separate Files
      • Supply Chain
        • ItemManager()
        • Adding Events
        • Adding unique address to each item
      • Lottery
      • Aave - Lending and Borrowing
        • Approve & Deposit
        • Borrow
      • NFT
      • Advanced Collectible
        • adv_deploy() + Testing
        • Create Metadata
        • Setting the TokenURI
    • node npm
    • Ganache
    • Truffle
    • Remix
    • Installing Env
Powered by GitBook
On this page
  • Ethereum
  • Transaction
  • Accounts and Signing
  1. Introduction

What is a Transaction

PreviousIntroductionNextAccounts and Signing

Last updated 2 years ago

Ethereum

  • Each node can contain a full copy of the Blockchain.

  • Anyone can run a node.

  • Each node is a machine running an Ethereum client.

  • Networks are formed by multiple nodes.

  • There are many different Ethereum networks. (Ropsen, etc)

  • Ethereum networks are used to transfer money and store data

Transaction

  • nonce -> (index) if this is the 101st transaction sent by sender, transaction will have nonce of 101.

    • to avoid prevent replay attacks.

  • Transactions are signed with the private key, generating v,r,s components.

Accounts and Signing

How does the blockchain know that the transaction sent is not forged?

Transactions are signed and can be verified to be authentic, like so:

For a transaction signature to be created, access to the account and its private key is required. Which is why, we need to unlock our MM, and sign before committing a transaction.

Private Key: 32 bytes (64 hex characters)

Public Key

The public key is generated from a private key, using ECDSA. This is a one-way function, the only way is to brute-force it.

Ethereum Account (Wallet Address)

An Ethereum account is the Keccak Hash of the last 20 bytes (40 hex char) of the public key.

Can go from Private -> Public -> Account. No reverse.

Signing & Verification

The transaction gets signed with the private key, creating additional fields of v,r,s. The signature is the r and s.

You cannot reverse engineer the private key from the signature.

With the r & s, you can run them through an ECRECOVER function, and it will output the Public Key and Wallet Address (Eth account).

This authenticates the transaction.

What is the difference between EOA and Contract Accounts?

  • Externally-owned account (EOA) – controlled by anyone with the private keys, can initiate transactions

  • Contract account – a smart contract deployed to the network, controlled by code initiated from an external EOA or another contract

What does an Ethereum Account contain?

  • nonce – a counter that increments with every transaction sent from the account. This ensures transactions are only processed once. For contract accounts, it the number of contracts created by the account.

  • balance – amount of wei owned by the address

  • codeHash – the hash of the code of an account on the EVM. Contract accounts contain code fragments that can perform different operations. This code gets executed if the account receives a message call. It cannot be changed, unlike the other account fields. For EOAs, the codeHash field is the hash of an empty string.

  • storageRoot – keccak256 hash of the root node of a Merkle Patricia trie that encodes the storage contents of the account. empty by default.

What information does a transaction contain?

A submitted transaction includes the following information:

  • recipient – the receiving address (if an EOA, the transaction will transfer value. If a contract account, the transaction will execute the contract code)

  • signature – the identifier of the sender. This is generated when the sender's private key signs the transaction and confirms the sender has authorized this transaction

  • nonce - a sequencially incrementing counter which indicates the transaction number from the account

  • value – amount of ETH (in wei) to transfer from sender to recipient

  • data – optional field to include arbitrary data

  • gasLimit – the maximum amount of gas units that can be consumed by the transaction

  • maxPriorityFeePerGas - the maximum amount of gas to be included as a tip to the validator

  • maxFeePerGas - the maximum amount of gas willing to be paid for the transaction (inclusive of baseFeePerGas and maxPriorityFeePerGas)

What is the life cycle of a transaction from when the user signs to when it is included in the blockchain?

  1. Once you send a transaction, cryptography generates a transaction hash from the signed transaction (transaction fields and v,r,s)

  2. The transaction is then broadcast to the network and included in a pool with lots of other transactions.

  3. A validator must pick your transaction and include it in a block in order to verify the transaction and consider it "successful".

  4. As time passes the block containing your transaction will be upgraded to "justified" then "finalized". Protocol upgrades make it much more certain that your transaction was successful and will never be altered. Once a block is "finalized" it could only ever be changed by an attack that would cost many billions of dollars.

How does the current Proof of Stake consensus mechanism in Ethereum work?

  • Validating nodes have to stake 32 ETH into a deposit contract as collateral against bad behavior. This helps protect the network because dishonest activity leads to partial or full slashing.

  • In every slot (spaced twelve seconds apart) a validator is randomly selected to be the block proposer. They bundle transactions together, execute them and determine a new 'state'. They wrap this information into a block and pass it around to other validators.

  • Other validators who hear about a new block re-execute the transactions to ensure they agree with the proposed change to the global state. Assuming the block is valid they add it to their own database.

  • If a validator hears about two conflicting blocks for the same slot, they will pick the one supported by the most staked ETH.

  • When the network performs optimally and honestly, there is only ever one new block at the head of the chain, and all validators attest to it. However, it is possible for validators to have different views of the head of the chain due to network latency or because a block proposer has equivocated.

Therefore, consensus clients require an algorithm to decide which one to favor. The algorithm used in proof-of-stake Ethereum is called , and it works by identifying the fork that has the greatest weight of attestations in its history.

LMD-GHOST