Bitcoin Consensus Mechanism——SYSU SSE Blockchain 5th lecture(English Version)

目录

Part 1: What is Consensus?

Definition

Distributed Consensus

Consensus in Bitcoin

CAP Theorem

Definitions

Trade-offs ("Pick Two" Dilemma)

Part 2: Why Bitcoin needs Consensus

Types of Consensus Mechanisms

Why Bitcoin Needs Consensus

Byzantine Generals Problem

Sybil Attack

Bitcoin's Consensus Mechanism: Proof of Work (PoW)

What is Proof of Work?

PoW Mining Principle

Longest Chain Rule & 51% Attack

Summary of PoW Features

Review

Transaction model

UTXO Model

对于第一个问题：

对于第二个问题：

---

Part 1: What is Consensus?

Definition

• Consensus: A process of agreement between distrusted nodes on the final state of specified data.

Distributed Consensus

• Objective: To attain a common state/value among multiple nodes despite the presence of some failing nodes.

Consensus in Bitcoin

• Bitcoin aims to reach an agreement on the state of its blockchain, which includes transaction history, account balances, etc.

---

CAP Theorem

Definitions

• Consistency: All changes are seen by all nodes at the same time.
• Availability: Systems return a response within an acceptable time frame.
• Partition Tolerance: The system continues to function when network segments fail to communicate. Systems can be partitioned into sub-networks that continue to function independently.

Trade-offs ("Pick Two" Dilemma)

• Availability ≠ Correctness: You can only achieve two out of the three CAP properties in a distributed system.

• CA/P: Focuses on consistency and availability but lacks partition tolerance.

  • Implementation: All data is stored on a single node, and other nodes read from this main node.
  • Note: Not considered a distributed system.

• CP/A: Focuses on consistency and partition tolerance at the cost of availability.

  • Implementation: Each node stores data, with the primary focus on ensuring consistency.

• AP/C: Focuses on availability and partition tolerance at the cost of consistency.

  • Implementation: Each node stores data, with the primary focus on ensuring availability.

Note: Since distributed systems must have Partition Tolerance (P), they must choose between Consistency (C) and Availability (A).

Part 2: Why Bitcoin needs Consensus

Types of Consensus Mechanisms

1. BFT-based (Byzantine Fault Tolerance)

   • Feature: Low computational requirements
   • Participants: Permissioned, limited trust
   • Applicability: Alliance/Private Chains

2. Leader Election-based

   • Example: Proof of Work (PoW)
   • Feature: Computationally intense
   • Participants: Permissionless, anonymous, no trust
   • Applicability: Public Chains

Why Bitcoin Needs Consensus

Byzantine Generals Problem

• Problem: Uncertain transmission of information due to possible traitors
• Goal: To maintain consistency in a distributed system
• Solution:
  • Simplified to a Generals and Lieutenants model
  • Loyal Lieutenants follow the same command, traitors may disrupt
• Fault Tolerance: Malicious nodes must be less than 1/3 of the total nodes

Sybil Attack

• Consequence: Makes Byzantine Fault Tolerance unsuitable for Bitcoin
• Method: Creating multiple identities to cast multiple votes
• Why Feasible:
  • Bitcoin is a decentralized, anonymous service
  • Low cost to create multiple identities
• Example: Double-spending attack
• Defense: Resource-based voting through Proof of Work (PoW)

Bitcoin's Consensus Mechanism: Proof of Work (PoW)

What is Proof of Work?

• Goal: To solve the Byzantine Generals Problem
• Voting Eligibility: Granted through computational work

PoW Mining Principle

• Mining Process: Combines previous block's hash, Merkle root of new transactions, a nonce, and a timestamp.
• Success Criterion: SHA(Merkle Root + Previous Block Hash + Timestamp + Nonce) < target
  • Number of leading zeros indicates difficulty level

Longest Chain Rule & 51% Attack

• 51% Attack: Control over more than half of the computational power can result in a fake chain being accepted.
• Prevention: Wait for 6 block confirmations before proceeding with transactions.

Summary of PoW Features

• Challenging: Difficult to solve but easy to verify
• Fairness: No shortcuts
• Randomness: Ensures a decentralized and unpredictable process
• Stability: Enables the stable operation of the blockchain with multiple-party participation

Review

Transaction model

每一个交易都省略了剩下自己的那一部分，比如第二个区块中应该还有A给自己剩下的3.5BTC。

每一个转出方的Hash Pointer都指向之前所有的收入来源，这样做可以避免双花攻击。

每一个转出方都要对这笔交易进行签名。

UTXO Model

1. Alice 转给bob ，第一个PubkeyHash是谁的？
2. 第二个,PubkeyHash是谁的?
3. 中的内容是什么？

在比特币中，一个比较常见的脚本模式用于标准的“支付到公钥哈希”（Pay-to-PubkeyHash，或P2PKH）交易是如下的：

1. 锁定脚本（ScriptPubKey）：OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG

2. 解锁脚本（ScriptSig）：

这里的 和 、 是不同脚本中的占位符，它们在实际的交易中会被实际的数据替换。

对于第一个问题：

在 OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG 中的 是Bob的公钥哈希。Alice想要将比特币发送给Bob，所以这个脚本锁住了属于Bob的输出。

对于第二个问题：

在解锁脚本 中：

• 是Bob用他的私钥对此交易进行签名的结果。
• 是Bob的公钥。
• 仍然是Bob的公钥哈希。

这样，当这两个脚本合并和执行时，它们会首先用 计算一个公钥哈希，然后检查这个计算出来的公钥哈希是否与锁定脚本中的 相等。如果相等，并且 是一个有效的对于该交易的签名，那么这个输出就被认为是有效的，从而被解锁，可以被花费。