From 1348aa3fd1948dde124dc7bd05a63cf4288ab5f5 Mon Sep 17 00:00:00 2001 From: Joshy Orndorff Date: Thu, 11 Jan 2024 22:25:29 +0800 Subject: [PATCH] Slight revisions to blockchain day 2 (#912) * tiny cleanup in blockchain structure slides * Accounts and UTXOs bruch up --- .../3-Blockchain_Structure_slides.md | 2 +- .../6-Accounts_and_UTXOs_slides.md | 176 +++--------------- 2 files changed, 27 insertions(+), 151 deletions(-) diff --git a/syllabus/3-Blockchain/3-Blockchain_Structure_slides.md b/syllabus/3-Blockchain/3-Blockchain_Structure_slides.md index ac2ac967c..24f237f63 100644 --- a/syllabus/3-Blockchain/3-Blockchain_Structure_slides.md +++ b/syllabus/3-Blockchain/3-Blockchain_Structure_slides.md @@ -37,7 +37,7 @@ This is a simplified blockchain. Each block has a pointer to the parent block as Notes: -The pointer is a cryptographic hash of the parent block. This ensures data integrity throughout the entire history of the chain. This is the simplest form that a blockchain could take and indeed it allows us to agree on a shared history. +The pointer is a cryptographic hash of the parent block. ---v diff --git a/syllabus/3-Blockchain/6-Accounts_and_UTXOs_slides.md b/syllabus/3-Blockchain/6-Accounts_and_UTXOs_slides.md index 8d4f33efd..32e60062d 100644 --- a/syllabus/3-Blockchain/6-Accounts_and_UTXOs_slides.md +++ b/syllabus/3-Blockchain/6-Accounts_and_UTXOs_slides.md @@ -6,47 +6,42 @@ title: Accounting Models & User Abstractions in Blockchains --- -## Overview +## Multi-User State Machines -- Cryptography, Signatures, Hash functions, Hash based Data Structures - -- Economics/Game Theory - -- Blockchain structure - +* We can model simple state machines. +* But now we want a multi-user state machine where users can interact. ---- -## Where do we go from here? +Notes: -- We have some base elements, ideas, and concepts - -- Now, let's put them together into something cool.. - +We have a lot of practice modeling simple state machines like a single audio amplifier +We can generalize this a little bit by giving every user their own machine. Their own amplifier. +But we can get even more rich, by having cross over effects between the amplifiers. +Imagine you plug the output of your amp into the input of my amp --- -## What are we talking about? - - - +## Multiple Models -- Now that we have this structured decentralized tamper proof state machine.. -- Let's think of ways we can formulate a state and a state transition in terms of representing users +* Unspent Transaction Output +* Accounts - +Notes: - +There are two popular methods for doing this in blockchain. +There amy very well be more viable way to do it as well. +For example I've heard of the actor model. +We will focus on these two because they are by far the most common. --- -## State User Model +## UTXO Model ![State User Model](img/utxo_state_1.svg) --- -## State User Model +## UTXO Model ![State User Model](img/utxo_state_2.svg) @@ -64,17 +59,22 @@ title: Accounting Models & User Abstractions in Blockchains --- -## How to send from Joshy to Andrew? What do you need? +## Addresses + +How to send from Joshy to Andrew? What do you need? ![Transfer](img/utxo_state_4.svg) Notes: -What would be catastrophic if we got wrong?? +We can use cryptographic identifiers. Perhaps a public key. +In practice it os often a hash of a public key. --- -## What if we want to spend this? +## Inputs + +What if we want to spend this? ![Spend](img/utxo_state_5.svg) @@ -229,127 +229,3 @@ Verify as opposed to determining the outcome. Not submitting output state in tra Notes: 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 👔 - -> - ---- - - - -# Questions?