Table of Contents

Bitcoin: A Peer-to-Peer Electronic Cash System

1. "Distributed Consensus"

Part of the bitcoin experiment is the underlying blockchain technology as a tool of distributed consensus.

2. "Smart Contracts"

Smart contracts are self-executing contracts with the terms of the agreement between buyer and seller directly written into lines of code. They run on the blockchain and are immutable, which means once deployed, their code and the agreements they represent cannot be changed. They are "smart" in the sense that they can automatically enforce and execute the terms of a contract when certain conditions are met, without the need for a middleman.

The Ethereum blockchain stores the state of smart contracts, which includes both the code of the contract and its current data (e.g., balances, whether a condition is met, etc.). Every time a smart contract receives a transaction, the EVM executes its code and updates the state on the blockchain according to the rules defined by the contract.

3. "Ethereum"

"What Ethereum intends to provide is a blockchain with a built-in fully fledged Turing-complete programming language that can be used to create "contracts" that can be used to encode arbitrary state transition functions, allowing users to create any of the systems described above (smart contracts), as well as many others that we have not yet imagined, simply by writing up the logic in a few lines of code."

Ethereum provides a decentralized platform where smart contracts are run exactly as programmed without any possibility of downtime, fraud, or third-party interference. This is because the code is executed by the Ethereum Virtual Machine (EVM) across thousands of nodes in the Ethereum network, ensuring resilience and redundancy.

The Ethereum blockchain is an immutable ledger, which means once a smart contract is deployed to the blockchain, the code cannot be changed. This immutability gives users confidence that the contract will execute as written, without the possibility of later alterations by any party, including its original author.

4. "State Transition System"

From a technical standpoint, the ledger of a cryptocurrency such as Bitcoin can be thought of as a state transition system. Where there is "state" consisting of the ownership status of all existing bitcoins and "state transition function" that takes a state and a transaction and outputs a new state which is the result.

The "state" in Bitcoin is the collection of all coins (technically, "unspent transaction outputs" or UTXO) that have been minted and not yet spent. A transaction contains one or more inputs, with each input containing a reference to an existing UTXO and a cryptographic signature produced by the private key associated with the owner's address, and one or more outputs, with each output containing a new UTXO to be added to the state.

5. "Blockchain"

If we had access to a trustworthy centralized service, this system would be trivial to implement; it could simply be coded exactly as described, using a centralized server's hard drive to keep track of the state.

However, with Bitcoin we are trying to build a decentralized currency system, so we will need to combine the state transaction system with a consensus system in order to ensure that everyone agrees on the order of transactions (prevent double-spend, etc).

To achieve this, Blockchain systems like Bitcoin's decentralized consensus process requires nodes in the network to continuously attempt to produce packages of transactions called "blocks". Each "block" containing a timestamp, a reference to (ie. hash of) the previous "block" and a list of all the transactions that have taken place since the previous "block". -> (ref: When we are say a "hash of the previous block", we are referring to a hash of that block's header, not the entire block or the individual transaction themselves. However, the header includes the Merkle root, which is directly dependent on all the transactions in the block.)

Over time, this creates a persistent, ever-growing, "blockchain" that constantly updates to represent the latest state of the Bitcoin ledger.

The algorithm for checking if a block is valid, is as follows:

5.1. 1. Check if the previous block referenced by the block exists and is valid.

5.2. 2. Check that the timestamp of the block is greater than that of the previous block and less than 2 hours into the future.

5.3. 3. Check that the proof-of-work on the block is valid.

5.4. 4. Let S[0] be the state at the end of the previous block.

Suppose TX is the block's transaction list with n transactions. For all i in 0…n-1, set S[i+1] = APPLY(S[i],TX[i]). If any application returns an error, exit and return false. This means that if at any point a transaction cannot be applied to the state (perhaps because it's invalid, the sender doesn't have enough funds, etc.), the entire block is invalid. The system stops processing the rest of the transactions in the block, and the block is not added to the blockchain. (order matters)

5.5. 5. Return true, and register S[n] as the state at the end of this block.

Essentially, each transaction in the block must provide a valid state transition from what was the canonical state before the transaction was executed to some new state. "Note that the state is not encoded in the block in any way; it is purely an abstraction to be remembered by the validating node and can only be (securely) computed for any block by starting from the genesis state and sequentially applying every transaction in every block".

6. "51% Attack"

Since Bitcoin's underlying cryptography is known to be secure (the cryptographic principles and algorithms on which Bitcoin is built, which have been widely studied, tested, and validated over the years.)

6.1. Such as the SHA-256 cryptographic hash function

among other things, link blocks together in the blockchain and to create a summary of the data contained in each block (the Merkle root). Hash functions are designed to be one-way functions that produce a fixed-size output (the hash) which appears random and changes dramatically with even a small change to the input. SHA-256 is considered secure because it is computationally infeasible to reverse the function (derive the input from the output) or to find two different inputs that produce the same output (a collision). The cryptographic problem in PoW involves finding a hash below a certain target. The SHA-256 hash function used in Bitcoin is designed such that outputs are unpredictable and uniformly distributed. Miners must perform many hash operations with different inputs to find a suitable hash, which translates into a significant time and energy investment.

6.2. Such as the Digital Signatures

Bitcoin uses the Elliptic Curve Digital Signature Algorithm (ECDSA) to allow users to prove ownership of bitcoins. It is used to sign transactions, allowing Bitcoin to ensure that bitcoins can only be spent by their rightful owners. ECDSA is deemed secure under the assumption that the elliptic curve discrete logarithm problem is hard to solve, which is the case with current technology and for the foreseeable future

the attacker will target the one part of the Bitcoin system that is not protected by cryptography directly: the order of transactions. The attacker's strategy is simple:

6.3. 1. Send 100 BTC to a merchant in exchange for some product (preferably a rapid-delivery digital good)

6.4. 2. Wait for the delivery of the product

6.5. 3. Produce another transaction sending the same 100 BTC from him to another address that he controls.

6.6. 4. Try to convince the network that his transaction to himself was the one that came first.

Once step (1) has taken place, after a few minutes some miner will include the transaction in a block, say block number 270000. After about one hour, five more blocks will have been added to the chain after that block, with each of those blocks indirectly pointing to the transaction and thus "confirming" it. At this point, the merchant will accept the payment as finalized and deliver the product; since we are assuming this is a digital good, delivery is instant. Now, the attacker creates another transaction sending the 100 BTC to himself (another address controled by himself).

If the attacker simply releases it into the wild, the transaction will not be processed, miners will attempt to run APPLY(S,TX) and notice that TX consumes a UTXO which is no longer in the state. So instead, the attacker creates a "fork" of the blockchain, starting by mining another version of block 270000 pointing to the same block 269999 as a parent but with the new transaction in place of the old one. Because the block data is different, this requires redoing the proof-of-work. Furthermore, the attacker's new version of block 270000 has a different hash, so the original blocks 270001 to 270005 do not "point" to it; thus, the original chain and the attacker's new chain are completely separate. The rule is that in a fork the longest blockchain is taken to be the truth, and so legitimate miners will work on the 270005 chain while the attacker alone is working on the 270000 chain.

In order for the attacker to make his blockchain the longest, he would need to have more computational power than the rest of the network combined in order to catch up.

7. "Merkle Trees"

Merkle tree is a fundamental component of blockchain technology used in Bitcoin to efficiently summarize all the transactions in a block.

A Merkle tree is a type of binary tree, composed of a set of nodes with a large number of leaf nodes at the bottom of the tree containing the underlying data, a set of intermediate nodes where each node is the hash of its two children, and finally a single root node, also formed from the hash of its two children, representing the "top" of the tree. In the Bitcoin block, each transaction hashes are the leaf nodes of the Merkle tree.

Suppose we have 4 transactions in a block, labeled Tx1, Tx2, Tx3 and Tx4. 

Step 1: Individual transaction hashes
Tx1 -> hash1
Tx2 -> hash2
Tx3 -> hash3
Tx4 -> hash4

Step 2: Create parent nodes by combining child nodes
hash1 + hash2 -> hash12
hash3 + hash4 -> hash34

Step 3: Combine parent hashes to form the Merkle root
hash12 + hash34 -> MerkleRoot

When a node receives a new block, the node will:

7.1. Verify the block by recalculating the Merkle root from the transactions in the block and checking that it matches the Merkle root in the block header.

7.2. Check that the previous block referenced by its hash in the block header is indeed the last block in the node's current version of the blockchain.

7.3. Validate each transaction according to the consensus rules of the network.

7.4. Confirm that the proof of work for the block is valid and meets the required difficulty level of the network at that time.

A blockchain with a built-in Turing-complete programming language. "Smart Contracts" in ethereum is like "autonomous agents" that live inside of the Ethereum execution environment "Always executing a specific piece of code when 'poked' by a message or transaction, and having direct control over their own ether balance and their own key/value store to keep track of persistent variables".

In Ethereum, the state is made up of objects called "accounts". There are two types of accounts:

8. 1. Externally Owned Accounts (EOAs):

EOAs cannot initiate transactions automatically, they must manually initiate a transaction. This can be anything from sending Ether, interacting with a smart contract, or executing a function in a smart contract.

9. 2. Contract Account:

A Contract Account can automatically perform actions based on its code when it receives a transaction from EOAs.

In summary. The EOA, controlled by a user and lacking any code, initiates transactions. The Contract Account, governed by its code, responds to incoming transactions by executing its smart contract, which can include reading/writing to its storage and communicating with other accounts.

"Transactions" refers to a signed data package that contains a message sent from an externally owned account (EOA) to either another externally owned account or a contract account.

10. 1. EOA to EOA Transactions:

These are the simplest form of transactions in Ethereum. They usually involve transferring ETH from one externally owned account to another.

11. 2. EOA to Contract Account Transactions:

These transactions are more complex. They occur when an externally owned account interacts with a contract account (a smart contract). The contract, upon receiving the transaction, executes its code based on the rules defined within it. This could lead to a variety of state changes within the Ethereum blockchain, including transferring ETH or tokens, changing data stored in the contract, or even creating new contracts.

A transaction usually involved:

11.1. The recipient of the message

11.2. A signature identifying the sender

11.3. The amount of ether to transfer from the sender to the recipient

11.4. An optional data field

11.5. A STARTGAS value

Representing the maximum number of computational steps the transaction execution is allowed to take. It's a cap to ensure that transactions don't run indefinitely (due to bugs or malicious intent) and to signal to miners the upper limit of computation and state changes the sender is prepared to fund.

11.6. A GASPRICE value

Representing the fee the sender pays per computational step. Which can fluctuate significantly based on network congestion Users can choose to set higher gas prices for faster transaction processing or lower prices if they are willing to wait longer.

Contract Accounts have the ability to send "messages" to other contracts.

"Messages are virtual objects that are never serialized and exist only in the Ethereum execution environment(EVM)."

In Ethereum, messages are considered virtual objects, meaning they are conceptual entities used within the Ethereum Virtual Machine (EVM) during the execution of smart contracts. They are not tangible in the same way that transactions are, which can be seen as discrete packages of data existing on the blockchain.

Somehow, we can consider messages as a part of the overall process of Ethereum transactions.

12. Message Initialization

Messages can only be initiated by smart contracts, not by externally owned accounts (EOAs). When a smart contract is executing its code, it may generate messages as a part of that execution. These messages are used to interact with other contracts or to perform specific actions within the Ethereum Virtual Machine (EVM). Like a transaction, a message leads to the recipient account running its code. Thus, contracts can have relationships with other contracts in exactly the same way that external actors can.

13. "Never Serialized"

13.1. Serialization refers to the process of converting an object into a format that can be easily stored or transmitted, and later reconstructed.

Transactions in Ethereum are serialized; they are transformed into a standardized format that can be broadcast to the network, included in blocks, and stored on the blockchain. Messages, however, are never serialized in this way. They do not have a standardized external representation because they are not transmitted across the network nor stored on the blockchain as independent entities. Instead, they exist only during the execution of smart contract code.

14. STARTGAS in Messages:

When a contract sends a message to another contract, it specifies a gas amount (similar to the concept of STARTGAS) that it is willing to allocate to the execution of that message. This gas is deducted from the gas remaining in the transaction that initiated the contract execution. If a message runs out of gas during execution (i.e., the computational work exceeds the allocated gas), the execution of that message fails, and the state changes made by that message are reverted, similar to how an entire transaction reverts if it runs out of gas.

Created: 2024-10-28 Mon 19:27

Validate