From 8afe7c0635bcb5bcf1463c35de150e65e368e430 Mon Sep 17 00:00:00 2001 From: Joshy Orndorff Date: Thu, 21 Dec 2023 14:33:18 -0500 Subject: [PATCH] renumber remaining slides to match new outline --- .../1-Overview_of_Blockchains_slides.md | 9 + .../3-Blockchain/12-UTXO-privacy-slides.md | 115 ------ ...g_slides.md => 2-P2P_Networking_slides.md} | 0 ...es.md => 3-Blockchain_Structure_slides.md} | 0 ...des.md => 4-Consensus-Authoring-slides.md} | 0 ...n_and_Game_Theory_in_Blockchain_slides.md} | 0 ...ides.md => 6-Accounts_and_UTXOs_slides.md} | 112 ++++++ ...esource_Allocation_Fees_Ordering_slides.md | 368 ------------------ .../{13-Forks_slides.md => 7-Forks_slides.md} | 0 ...ides.md => 9-Consensus_Finality_slides.md} | 0 10 files changed, 121 insertions(+), 483 deletions(-) delete mode 100644 syllabus/3-Blockchain/12-UTXO-privacy-slides.md rename syllabus/3-Blockchain/{7-P2P_Networking_slides.md => 2-P2P_Networking_slides.md} (100%) rename syllabus/3-Blockchain/{2-Blockchain_Structure_slides.md => 3-Blockchain_Structure_slides.md} (100%) rename syllabus/3-Blockchain/{3-Consensus-Authoring-slides.md => 4-Consensus-Authoring-slides.md} (100%) rename syllabus/3-Blockchain/{9-Econ_and_Game_Theory_in_Blockchain_slides.md => 5-Econ_and_Game_Theory_in_Blockchain_slides.md} (100%) rename syllabus/3-Blockchain/{4-Accounts_and_UTXOs_slides.md => 6-Accounts_and_UTXOs_slides.md} (54%) delete mode 100644 syllabus/3-Blockchain/6-Resource_Allocation_Fees_Ordering_slides.md rename syllabus/3-Blockchain/{13-Forks_slides.md => 7-Forks_slides.md} (100%) rename syllabus/3-Blockchain/{5-Consensus_Finality_slides.md => 9-Consensus_Finality_slides.md} (100%) diff --git a/syllabus/3-Blockchain/1-Overview_of_Blockchains_slides.md b/syllabus/3-Blockchain/1-Overview_of_Blockchains_slides.md index f0e88988d..7f44c7f54 100644 --- a/syllabus/3-Blockchain/1-Overview_of_Blockchains_slides.md +++ b/syllabus/3-Blockchain/1-Overview_of_Blockchains_slides.md @@ -6,6 +6,15 @@ duration: 30 - 45 minutes # Overview of Blockchains +TODO Joshy + +Braindump for the structure of this lesson for HK: + +- Shared Story Telling +- Digital Services +- Broad def of smart contract +- State Machines + --- ## Upholding Expectations diff --git a/syllabus/3-Blockchain/12-UTXO-privacy-slides.md b/syllabus/3-Blockchain/12-UTXO-privacy-slides.md deleted file mode 100644 index 4238781d1..000000000 --- a/syllabus/3-Blockchain/12-UTXO-privacy-slides.md +++ /dev/null @@ -1,115 +0,0 @@ ---- -title: Adding Privacy to the UTXO model -description: Explore some techniques for adding privacy to the UTXO model -duration: 30min ---- - -# Adding Privacy - ---- - -## Input/Output-based Cryptocurrencies - -- Transactions have a list of unspent transaction outputs (UTXOs) as its inputs -- Each input is signed -- The transaction is allowed to spend as much funds as the sum of its inputs -- The transaction spends funds by creating outputs and by paying a fee - ---- - -## Input/Output-based Cryptocurrencies - -- Inputs must only refer to actually existing outputs (membership) -- The output spent must not be prior spent (linkability) -- The output's owner must consent to this transaction (ownership) -- The transaction's inputs and outputs must be balanced (sum check) - ---- - -## Bitcoin - -- Bitcoin specifies the spent output. This satisfies membership and linkability -- Each Bitcoin output has a small, non-Turing complete program (Script) specifying how it can be spent -- Each input has a `scriptSig` which proves the script is satisfied and this is an authorized spend (ownership) -- The outputs cannot exceed the inputs, and the remainder becomes the fee (sum check) - ---- - -## ZK Proofs - -- ZK-SNARKs - A small proof that's fast to verify (<= $O(\sqrt{n})$) -- ZK-sNARKs - A small proof that's not fast to verify (>= $O(n)$, frequently $O(n log n)$) -- ZK-STARKs - A small proof that's fast to verify, based on hash functions -- All of these can prove the execution of an arbitrary program (via an arithmetic circuit) -- None of these reveal anything about the arguments to the program - ---- - -## Merkle Proofs - -- Merkle proofs support logarithmically proving an item exists in a tree -- For 2\*\*20 items, the proof only requires 20 steps -- Even if a ZK proof is superlinear, it's a superlinear encoding of a logarithmic solution - ---- - -## Private Membership - -- When an output is created on-chain, add it to the Merkle tree -- When an input specifies an output, it directly includes the output it's spending -- It also includes a Merkle proof the output exists _somewhere_ on chain, embedded in a ZK proof - ---- - -## Pedersen Commitments - -- A Pedersen commitment has a value (some number) and a mask (also some number) -- There's as many masks as there private keys, hiding the contained value -- Pedersen commitments can be extended to support multiple values - ---- - -## A New Output Definition - - - -- ID -- Amount -- Owner -- Mask -- All in a single
- Pedersen commitment - - - ---- - -## Private Membership - -- We don't prove the included output exists on chain -- We prove an output with identical fields exists on chain _yet with a different mask_ -- This allows spending a specific output without revealing which it is - ---- - -## Ownership and linkability - -- A ZK proof can take the output ID and apply some transformation -- For every output ID, the transformation should output a single, unique ID -- Not just anyone should be able to perform this transformation -- This provides linkability, and if only the owner can perform the transformation, ownership - ---- - -## Sum check - -- One final ZK proof can demonstrate the sum of inputs - the sum of outputs = fee -- There are much more efficient ways to prove this - ---- - -# Summary - -- This hides the output being spent and the amounts transacted -- Combined with a stealth address protocol, which replaces addresses with one time keys, it hides who you're sending to as well -- This builds a currency which is private w.r.t. its on-chain transactions diff --git a/syllabus/3-Blockchain/7-P2P_Networking_slides.md b/syllabus/3-Blockchain/2-P2P_Networking_slides.md similarity index 100% rename from syllabus/3-Blockchain/7-P2P_Networking_slides.md rename to syllabus/3-Blockchain/2-P2P_Networking_slides.md diff --git a/syllabus/3-Blockchain/2-Blockchain_Structure_slides.md b/syllabus/3-Blockchain/3-Blockchain_Structure_slides.md similarity index 100% rename from syllabus/3-Blockchain/2-Blockchain_Structure_slides.md rename to syllabus/3-Blockchain/3-Blockchain_Structure_slides.md diff --git a/syllabus/3-Blockchain/3-Consensus-Authoring-slides.md b/syllabus/3-Blockchain/4-Consensus-Authoring-slides.md similarity index 100% rename from syllabus/3-Blockchain/3-Consensus-Authoring-slides.md rename to syllabus/3-Blockchain/4-Consensus-Authoring-slides.md diff --git a/syllabus/3-Blockchain/9-Econ_and_Game_Theory_in_Blockchain_slides.md b/syllabus/3-Blockchain/5-Econ_and_Game_Theory_in_Blockchain_slides.md similarity index 100% rename from syllabus/3-Blockchain/9-Econ_and_Game_Theory_in_Blockchain_slides.md rename to syllabus/3-Blockchain/5-Econ_and_Game_Theory_in_Blockchain_slides.md diff --git a/syllabus/3-Blockchain/4-Accounts_and_UTXOs_slides.md b/syllabus/3-Blockchain/6-Accounts_and_UTXOs_slides.md similarity index 54% rename from syllabus/3-Blockchain/4-Accounts_and_UTXOs_slides.md rename to syllabus/3-Blockchain/6-Accounts_and_UTXOs_slides.md index 33479b864..8d4f33efd 100644 --- a/syllabus/3-Blockchain/4-Accounts_and_UTXOs_slides.md +++ b/syllabus/3-Blockchain/6-Accounts_and_UTXOs_slides.md @@ -232,6 +232,118 @@ Parallelization? Storage space, privacy solutions? --- +# Adding Privacy + +--- + +## Input/Output-based Cryptocurrencies + +- Transactions have a list of unspent transaction outputs (UTXOs) as its inputs +- Each input is signed +- The transaction is allowed to spend as much funds as the sum of its inputs +- The transaction spends funds by creating outputs and by paying a fee + +--- + +## Input/Output-based Cryptocurrencies + +- Inputs must only refer to actually existing outputs (membership) +- The output spent must not be prior spent (linkability) +- The output's owner must consent to this transaction (ownership) +- The transaction's inputs and outputs must be balanced (sum check) + +--- + +## Bitcoin + +- Bitcoin specifies the spent output. This satisfies membership and linkability +- Each Bitcoin output has a small, non-Turing complete program (Script) specifying how it can be spent +- Each input has a `scriptSig` which proves the script is satisfied and this is an authorized spend (ownership) +- The outputs cannot exceed the inputs, and the remainder becomes the fee (sum check) + +--- + +## ZK Proofs + +- ZK-SNARKs - A small proof that's fast to verify (<= $O(\sqrt{n})$) +- ZK-sNARKs - A small proof that's not fast to verify (>= $O(n)$, frequently $O(n log n)$) +- ZK-STARKs - A small proof that's fast to verify, based on hash functions +- All of these can prove the execution of an arbitrary program (via an arithmetic circuit) +- None of these reveal anything about the arguments to the program + +--- + +## Merkle Proofs + +- Merkle proofs support logarithmically proving an item exists in a tree +- For 2\*\*20 items, the proof only requires 20 steps +- Even if a ZK proof is superlinear, it's a superlinear encoding of a logarithmic solution + +--- + +## Private Membership + +- When an output is created on-chain, add it to the Merkle tree +- When an input specifies an output, it directly includes the output it's spending +- It also includes a Merkle proof the output exists _somewhere_ on chain, embedded in a ZK proof + +--- + +## Pedersen Commitments + +- A Pedersen commitment has a value (some number) and a mask (also some number) +- There's as many masks as there private keys, hiding the contained value +- Pedersen commitments can be extended to support multiple values + +--- + +## A New Output Definition + + + +- ID +- Amount +- Owner +- Mask +- All in a single
+ Pedersen commitment + + + +--- + +## Private Membership + +- We don't prove the included output exists on chain +- We prove an output with identical fields exists on chain _yet with a different mask_ +- This allows spending a specific output without revealing which it is + +--- + +## Ownership and linkability + +- A ZK proof can take the output ID and apply some transformation +- For every output ID, the transformation should output a single, unique ID +- Not just anyone should be able to perform this transformation +- This provides linkability, and if only the owner can perform the transformation, ownership + +--- + +## Sum check + +- One final ZK proof can demonstrate the sum of inputs - the sum of outputs = fee +- There are much more efficient ways to prove this + +--- + +# Summary + +- This hides the output being spent and the amounts transacted +- Combined with a stealth address protocol, which replaces addresses with one time keys, it hides who you're sending to as well +- This builds a currency which is private w.r.t. its on-chain transactions + +--- + ## Small shill... Tuxedo 👔 > diff --git a/syllabus/3-Blockchain/6-Resource_Allocation_Fees_Ordering_slides.md b/syllabus/3-Blockchain/6-Resource_Allocation_Fees_Ordering_slides.md deleted file mode 100644 index 373ccebeb..000000000 --- a/syllabus/3-Blockchain/6-Resource_Allocation_Fees_Ordering_slides.md +++ /dev/null @@ -1,368 +0,0 @@ ---- -title: Fees, Ordering -description: Fees and ordering in blockchains -duration: 1 hour ---- - -# Fees, Ordering - ---- - -## Overview - - - -1. [Fees and ordering](#fees--ordering) -1. [Execution models](#execution-models) - - - -Notes: - -- This lecture is a bit all over the place. -- A bunch of stuff worth covering, but not all directly related. - ---- - -# Fees & Ordering - ---- - -## Fees & Ordering - -Blockchains are open, shared systems. -They are unrestricted in access. - -But restricted in resources. - ---- - -## Permissionless Access - -Free _ability_ to access does not mean free _cost_ to access. - ---- - -## Threads - -A blockchain runtime is single-threaded. - -(For now) - ---- - -## Time - -A block must terminate in some amount of time. - ---- - -## Network - -Besides execution time, blocks need to propagate throughout the network. - ---- - -## Demand - -Many people may want to use the system concurrently. - -But the system needs to decide: - -- Which state transition calls to include in a block, and -- How to order them. - ---- - -## Brief Interruption #1 - -> The block body contains an ordered set of _extrinsics_: Packets from the outside world with _zero_ or more signatures attached. - -Notes: - -Recall from Lecture 1. - ---- - -## Brief Interruption #1 (cont.) - -These packets include: - -- A call to the system's state transition function -- Some contextual information (e.g. a spec version) -- Perhaps some additional information that would help block authors prioritise - ---- - -## No-Longer Brief Interruption #1 (cont.) - -Consider packets with: - -- zero signatures attached as "inherents" or "unsigned extrinsics" -- one or more signatures attached as "transactions" - -This will be pretty straightforward until it's not. - ---- - -## Fee Models - -Different blockchains have different fee models. - -For this lecture, we will look at three: - -- Size (Bitcoin) -- Step Metering (Ethereum) -- Time (Polkadot)\* - -\* (and coming soon, space) - ---- - -## Size - -Bitcoin has a very simple STF: Namely verifying signatures and reassigning UTXOs. - -Its block size is limited, and each transaction has some byte-length (instruction, signature, etc.) - -Block authors will normally choose the set of transactions that would yield the highest gross fee. - ---- - -## Bitcoin Fee Market - - - -Notes: - -- Fee market evolves based on demand - -[Source: Y Charts](https://ycharts.com/indicators/bitcoin_average_transaction_fee_btc) -(Couldn't find the chart I really wanted (per-byte rate), but can discuss) - ---- - -## Metering - -Ethereum has a more complex STF than Bitcoin, namely one that is quasi-Turing-complete. - -Users could submit transactions with an unknown number of steps to terminate. - -The system uses "gas metering" to halt execution of a transaction and continue to the next. - ---- - -## Metering - -Ethereum's STF defines a VM with instruction set, where each instruction costs some "gas". - -Users specify: - -- Max amount of gas to use -- Cost, in ETH, per unit of gas they are willing to pay - ---- - -## Metering - -Each time an instruction is executed, the system deducts its cost from the max gas. - -If the program terminates, it only charges for the gas used. - -If it runs out of gas, it terminates the program. - ---- - -## Gas Rates - - - -Notes: - -[Source: Etherscan](https://etherscan.io/chart/gasprice) - ---- - -## Weight - -Instead of metering during runtime, meter ahead of time. - -Charge a fixed\* fee for dispatching some call. - ---- - -## \*Fixed - -```rust -#[pallet::weight(100_000_000)] -fn my_variable_weight_call(input: u8) -> Refund { - let mut refund: Refund = 0; - if input > 127 { - let _ = do_some_heavy_computation(); - } else { - let _ = do_some_light_computation(); - refund = 80_000_000; - } - refund -} -``` - ---- - -## Time - -Weight is picoseconds of execution time (`10E-12`). - -Calls are benchmarked on some "standard hardware". - -(There are some changes in the works about making two-dimensional weight.) - ---- - -## Weight - -Using weight reduced the overhead of runtime metering, but requires some more care from developers. - -- It must be possible to meter before runtime -- So, users should not be able to deploy untrusted code -- There is no safety net on execution -- Some computation is OK, but should be possible from call inspection - -Notes: - -Examples: - -- User-supplied length of a list that will be iterated over -- Number of calls within a batch - ---- - -## Brief Interruption #2 - -Some of the gas and weight systems are evolving. - -- Ethereum recently added EIP1559, which uses a fee + tip mechanism -- Parity and Web3 Foundation are discussing some changes to the weights model - ---- - -## Fee Strategies - -Block authors can include transactions using several strategies: - -- Just take those with the highest fee -- Take those with the highest fee to {length, gas, weight} ratio - ---- - -## Fee Burning - -Not all the fees must go to the block author (depends on system design). - -In fact, this is often a bad design. Block authors will want fees to go up, so may indulge in no-op transactions to boost fees. - ---- - -## Fee Burning Examples - -- Polkadot only gives 20% of fees to block authors (80% goes to an on-chain Treasury) -- Since EIP1559, Ethereum burns some of its fees (its "base") from each transaction - -In both systems, users can add "tips" to increase the priority of their transaction with authors. - ---- - -## Filling a Block - -Depending on the limiting factor, systems can have different limits to call a block full. - -- Bitcoin: Size (in bytes) -- Ethereum: Gas limit (sum of all gas limits of transactions) -- Polkadot: Weight (sum of all max expected weights) - ---- - -## Ordering - -We've selected some transactions, but the runtime is single-threaded. - -Block authors must order them. - ---- - -## Priority Basis - -The naive solution is to maintain an order of pending transactions by some "priority". - -And just include the top `N` transactions that fit in a block. - ---- - -## More Advanced - -But, many small transactions might result in a higher fee for greedy block authors. - -So there could exist a set of transactions that is more profitable than just the top `N`. - -Even some that could be considered attacks. - ---- - -# Execution Models - ---- - -## Transactional Execution - -Most blockchains have a "transactional" execution model. - -That is, they need to be woken up. - -A smart contract, for example, won't execute any code unless someone submits a signed, fee-paying transaction to the system. - ---- - -## Brief Interruption #3 - -All of the "packets from the outside world" in these systems are signed. - -Some key holder signs an instruction that authorises a call and is willing to pay for its execution. - -Now is the time to enter the world of unsigned packets. - ---- - -## Free Execution - -State machines can have autonomous functions in their state transition function. - -System designers can make these functions execute as part of the STF. - -In this model, block authors _must_ execute some logic. - ---- - -## Free Execution - -These added function calls are powerful, but some care must be taken: - -- They still consume execution resources (e.g., weight) -- They need some method of verification (other nodes should be able to accept/reject them) - ---- - -## Hooks - -The Substrate lectures will get into these, but for now just a look at some APIs: - -```rust -pub trait Hooks { - fn on_finalize(_n: BlockNumber) {} - fn on_initialize(_n: BlockNumber) -> Weight {} - fn on_idle(_n: BlockNumber, _remaining_weight: Weight) -> Weight {} - fn on_runtime_upgrade() -> Weight {} - fn offchain_worker(_n: BlockNumber) {} -} -``` - -[Source: `/frame/support/src/traits/hooks.rs`](https://github.com/paritytech/substrate/blob/33c518e/frame/support/src/traits/hooks.rs) diff --git a/syllabus/3-Blockchain/13-Forks_slides.md b/syllabus/3-Blockchain/7-Forks_slides.md similarity index 100% rename from syllabus/3-Blockchain/13-Forks_slides.md rename to syllabus/3-Blockchain/7-Forks_slides.md diff --git a/syllabus/3-Blockchain/5-Consensus_Finality_slides.md b/syllabus/3-Blockchain/9-Consensus_Finality_slides.md similarity index 100% rename from syllabus/3-Blockchain/5-Consensus_Finality_slides.md rename to syllabus/3-Blockchain/9-Consensus_Finality_slides.md