Blockchain as a Crypto-economic Protocol:
Vitalik Buterin defines blockchain protocols as a part of crypto-economic protocols, where cryptography and economic incentives are combined to guarantee information security properties.

Blockchain Building Blocks:
Cryptography: Used for proving properties about messages, such as signatures and hashes. Economic Incentives: Encouraged by the system to maintain certain properties.

Bitcoin as an Example:
Bitcoin is a peer-to-peer digital currency. It maintains a chain of blocks with transactions and state information. The Bitcoin blockchain maintains a clock with timestamps.

Properties of a Well-Performing Bitcoin Blockchain:
Convergence: Blocks are added to the chain without removal or reordering. Validity: Blocks are valid according to specific conditions, including proof-of-work, block links, and transaction validity. Clock: The blockchain clock should roughly increase and not go backward. Data Availability: The blockchain should be available for download by users. Availability for Users: Transactions with sufficiently high fees should be included in the blockchain.

Cryptographic Tools Used in Blockchain:
Proof-of-Work: Participants prove access to computing power for consensus. Signatures: Proof of sending a transaction. Hashes: Establish total ordering of the chain and enable limited white client protocols.

Economic Incentives in Bitcoin:
Miners receive 12.5 bitcoins per block and can extract economic rent from transaction inclusion. Rewards for block creation are marginally long run zero sum, which contributes to Bitcoin’s selfish mining vulnerabilities.

Cryptography: Powerful Tools for Data Integrity, Proof, and Privacy:
Cryptography offers a range of essential tools for blockchain security and operation, including hashes, signatures, zero-knowledge proofs, proof-of-work, erasure codes, timelock crypto, and holomorphic encryption. Hashes enable verification of topological order, while signatures prove the identity of message senders. Zero-knowledge proofs allow for verifying computable predicates without revealing the messages themselves.

Economic Incentives: Tokens, Privileges, and Security:
Economic incentives play a crucial role in blockchain design, with tokens and privileges being the two main types. Tokens incentivize actors through cryptocurrency units defined within the protocol, while privileges grant decision-making rights that can be used to extract rent. Transaction fees are a notable example of incentives in blockchain networks, where miners can be bribed to include specific transactions in blocks.

Crypto-Economic Security Margin and Proofs: Measuring Security in Dollars:
Crypto-economic security margin quantifies the amount of money needed to prove the validity of a protocol or guarantee, or the economic loss incurred by malicious actors if the guarantee fails. Crypto-economic proofs are messages signed by actors, certifying the truth of a claim or the occurrence of an economic loss if the claim is false. Proof-of-work and proof-of-stake are examples of crypto-economic proofs, with block rewards serving as the economic loss in proof-of-work and deposits in proof-of-stake.

Security Models: Defining Assumptions about Participants’ Behavior:
Security models describe the assumptions made about the behavior of participants in a blockchain network. Standard Byzantine fault tolerance assumes that two-thirds of participants are well-behaved, while traditional fault tolerance assumes that all participants are well-behaved but may experience server crashes. Economic models include the uncoordinated choice model, which assumes separate incentives and size limitations for participants, and the bribing attacker model, which introduces a bribing attacker capable of making conditional payments to influence actions.

Shellencoin: A Simple Example of Voting Protocol:
Shellencoin is a simple voting protocol that illustrates the application of cryptographic and economic tools in blockchain design. Participants vote for either A or B, and the majority answer is taken as the correct one.

Game Theory and the Schelling Coin Game:
In an honest majority model, the Schelling coin game functions correctly, encouraging truthful voting due to the incentive to align with the majority. In an uncoordinated choice model, the game also functions due to a recursive equilibrium, where participants are incentivized to vote truthfully based on the assumption that others will do the same. In a coordinated choice model, the incentive for truthful voting is neutral, as participants can gain equal rewards regardless of their choice. Introducing a bribing attacker, however, can disrupt the game’s equilibrium. The attacker can offer a higher reward to participants who vote against the majority, leading everyone to vote in favor of the attacker’s desired outcome.

Proof-of-Work and its Similarity to the Schelling Coin Game:
Proof-of-work operates similarly to the Schelling coin game, as it also rewards miners who align with the majority chain. Like the Schelling coin game, proof-of-work is susceptible to bribing attacks and exhibits similar behavior in uncoordinated and coordinated choice models.

Categorization of Faults:
Faults can be categorized at different levels, including faults of the protocol, individual actors within the protocol, and faults of the network. Protocol faults involve deviations from optimal behavior, such as a blockchain doubling back and discarding previously added blocks. Individual actor faults include node crashes, malicious behavior, bribing, and network faults involve latency, dropped messages, and partitions.

Categorization of Protocol Faults:
Invalidity: A node sends a message that is not the result of executing the protocol for any subset of messages it has seen. Equivocation: A node’s program forks, causing it to follow the protocol faithfully for one message, then pretend to unsee it and follow the protocol for another message. Ignoring and delaying inputs: A node consistently pretends that a message arrived later than it did or ignores it altogether. Not sending or delaying outputs: A node fails to send a message when it should or sends it later than it should. Using false values of X: A node uses incorrect values for auxiliary data, such as claiming a different winner in an election. Sending messages too early: A special case of using false values of X, where a node sends messages before it should.

Network Faults:
Network faults involve latency, where messages are delayed, and dropped messages, where messages are lost entirely.

Fault Identification:
In a blockchain, faults can be traced back to one of several scenarios, allowing for the identification of the responsible party.

Case 1: Block B Ignored Blocks C and D:
Miner B intentionally or due to technical issues ignores blocks C and D and builds on block A. Possible reasons include personal animosity, selfish mining attacks, or computer corruption. This fault arises from not receiving messages.

Case 2: Block C Ignored Block B:
Miner C ignores block B and builds on block A. Miner D chooses to build on block C instead of block B.

Case 3: Block C Did Not Send to Block B:
Miner C creates a block but intentionally or due to technical issues does not send it to other miners. Miner C might only send the block to friendly miners, causing a fault.

Case 4: Block B Did Not Send to Block C:
Miner B creates a block but does not send it to other miners. Miner C creates a block and miners D and N build on top of it.

Case 5: Network Faults:
Miners create blocks at nearly the same time, and due to network latency, they end up building on the same parent block.

Principles of Cryptoeconomic Penalty Assignment:
Fault categorization should be symmetrical, with both parties equally responsible for a fault if a definite conclusion cannot be reached. Punishment should be severe for proven faults, aiming to maximize crypto-economic security margin. Balancing act between crypto-economic security margin and griefing opportunities is crucial. Rewards should be tied to protocol quality, incentivizing performance.

Symmetrical Fault Categorization:
In the given case, parties B and C were equally blamed, while A and D were exonerated. This symmetrical fault categorization suggests that both B and C should be penalized equally.

Departure from Satoshi’s Approach:
Satoshi’s approach rewards only those who are part of the chain, while penalizing those who are not. The Cryptoeconomic Prince Puzzle Penalty Assignment departs from this approach, suggesting equal penalties for both B and C.

Benefits of the Cryptoeconomic Prince Puzzle Penalty Assignment:
It offers stronger incentive compatibility. It performs better under the coordinated choice model. It resolves the issue of selfish mining.

Crucial Principle:
Pay for performance is a crucial principle, directly related to the coordinated choice model’s performance.

Coordinated Choice Model:
In a coordinated choice model, a coalition of actors fully colludes to maximize their total revenues. This incentivizes the coalition to maintain high protocol quality, minimizing protocol faults. Proof-of-stake is an example of a coordinated choice model.

Benefits of Proof-of-Stake:
Punishing faulty actors is straightforward. Griefing factors and bounds can be analyzed and controlled. Selfish mining issues are easier to resolve.

Proof-of-Stake Mechanism:
Uses signatures from bonded validators instead of proof of work. Bonded validators have a deposit that cannot be withdrawn quickly. Faulty validators have their deposits slashed, disincentivizing misbehavior.

Desired Properties of Proof-of-Stake Algorithms:
Safety: Blocks are finalized and cannot be un-finalized. Liveness: Blocks are continuously produced and finalized. High Crypto-economic Security Margin: The cost of incentivizing validators is lower than the value of the deposits at stake. Auditable Safety: Safety can be verified through public audits.

Proof-of-Stake vs. Proof-of-Work:
Proof-of-work relies on rewards and privileges to incentivize miners, leading to a high crypto-economic security margin. Proof-of-stake uses penalties to disincentivize misbehavior, allowing for a higher crypto-economic security margin. Proof-of-stake validators can earn interest on their deposits and collect transaction fees, potentially eliminating the need for direct payments from the protocol.

Casper’s Auditable Safety Requirement:
To ensure auditable safety, the protocol requires that if it fails, at least a third of the participants must be malicious, and their identities must be known. Synchronous BFT protocols cannot unambiguously prove who is faulty, making auditable safety unattainable. Asynchronous algorithms can be converted to auditable safety by adding specific hashes and signatures, allowing for fault enumeration and unambiguous blame assignment.

Plausible Liveness:
Plausible liveness prevents the algorithm from getting stuck. Penalizing validators for malicious behavior should not lead to a situation where the protocol cannot finalize anything without validators voluntarily sacrificing their deposits. Plausible liveness ensures a path toward finalizing and agreeing on blocks, preventing stagnation.

Latest Thinking on Sharding:
The presentation moves on to discuss the latest thinking on sharding, but the specific details are not included in this segment of the transcript.

Introduction:
Vitalik Buterin explores the challenges of data availability in sharded blockchains. He emphasizes that in sharded blockchains, verifying data availability poses a significant problem since it’s impractical for individual nodes to download and validate all the data.

Defining the Data Availability Problem:
In a non-sharded blockchain, full nodes can download and validate entire blocks, ensuring data availability. In a sharded blockchain, the sheer volume of data makes it impossible for a single node to verify all of it.

Interactive Protocols for Proving Correctness:
Proving correctness, or validity properties, is feasible using interactive protocols when data is available. Techniques like interactive verification, crypto-economic binding research, and ZK-SNARKs can be employed to collectively verify data availability.

Challenges of Proving Data Unavailability:
Data unavailability isn’t a uniquely attributable fault. An attacker can make data unavailable and then suddenly make it available, resembling a denial-of-service attack. Existing mechanisms for addressing data unavailability either don’t work or are prone to denial-of-service exploitation.

Solutions for Ensuring Data Availability:
Honest Minority Assumption: Assume at least 15% of the network is honest. A randomly selected set of validators can prevent finalizing bad blocks. Issues: sustainability of the assumption, potential denial-of-service vulnerability. Erasure Coding with Spot Checks: Nodes randomly select and download a few branches of a block. If all branches are successfully downloaded, the block is considered legitimate. This approach uses random sampling to ensure data availability. Drawback: It doesn’t guarantee 100% data availability, which is crucial for certain contracts or applications.

Optimal Properties of Consensus Algorithms:
Designing consensus algorithms with enhanced security, reduced costs, and optimal performance under various economic models is a key challenge.

Censorship Resistance:
Detecting censorship in blockchain systems is difficult due to its covert nature. Tricking miners by sending high-fee transactions to make it appear that a transaction with a lower fee is being censored. Mandatory fees and burning a portion of them can help mitigate censorship issues.

Maximally Accurate Timestamping:
Achieving highly accurate timestamps is crucial for various applications, including payments and financial transactions. Exploring methods like sequential proof-of-work to enhance timestamp accuracy.

Scalable Validation:
Developing sharded blockchains with optimal data availability solutions is essential for scalability.

Cryptoeconomics:
Cryptoeconomics is a relatively new field that formalizes the foundation of incentive analysis in blockchain protocols. Ongoing efforts to establish a common understanding of concepts and methodologies.

Griefing Opportunities:
Protocols that punish faulty actors may create griefing opportunities, allowing individuals to cause financial losses to others at some cost to themselves. Designing protocols that minimize the profit incentives for malicious behavior is important.

Default Protocol Rules:
Nodes are expected to follow specific rules in blockchain protocols, such as building on top of the first block seen (Bitcoin) or choosing randomly (Ethereum). Deviating from the default rule can be considered a fault, but it may be difficult to attribute due to private randomness.

58% Honest Minority:
The choice of a 58% honest minority threshold for fault tolerance is intuitive rather than formulaic. Balancing the risk of malicious behavior by a small minority against the potential for blockchain stagnation is a key consideration.

Mobile Clients for Proof-of-Work Ethereum:
Clients like Leth and Status are already available for Proof-of-Work Ethereum, allowing users to interact with the network from mobile devices. Ongoing protocol improvements aim to enhance the security and efficiency of mobile clients.

Cryptoeconomics and Rationality:
Cryptoeconomic models assume rational behavior among participants. Hybrid approaches that combine crypto-economic incentives with honest majority assumptions are also explored. Real-world scenarios may involve honest majorities with limited honesty or crypto-economic bribery attacks.

Bribery Attacks in Coin Voting Systems:
Bribery can corrupt coin voting systems, which are designed for decentralized governance of blockchains. Bribery can be disguised as better interest rates or exchange services. Users essentially sell their voting power, compromising the public good of the system.

Nothing at Stake Attack in Proof-of-Stake:
Older proof-of-stake algorithms without penalties are vulnerable to the Nothing at Stake attack. This attack allows malicious actors to create blocks on multiple chains simultaneously, potentially reversing blocks and transactions. Bribing validators can exacerbate the attack, making it more effective.

Mitigation in Modern Proof-of-Stake Protocols:
Modern proof-of-stake protocols address the Nothing at Stake issue by implementing penalties. Penalties are imposed on validators who equivocate, or create contradictory messages. These penalties deter malicious behavior and maintain the integrity of the blockchain.