Polkadot-Blockchain-Academy · JoshOrndorff · Jan 11, 2024 · Jan 11, 2024 · Jan 11, 2024
@@ -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
 

@@ -6,47 +6,42 @@ title: Accounting Models & User Abstractions in Blockchains
 
 ---
 
-## Overview
+## Multi-User State Machines
 
-- Cryptography, Signatures, Hash functions, Hash based Data Structures
-  <!-- .element: class="fragment" data-fragment-index="2" -->
-- Economics/Game Theory
-  <!-- .element: class="fragment" data-fragment-index="3" -->
-- Blockchain structure
-  <!-- .element: class="fragment" data-fragment-index="4" -->
+* 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
-  <!-- .element: class="fragment" data-fragment-index="2" -->
-- Now, let's put them together into something cool..
-  <!-- .element: class="fragment" data-fragment-index="3" -->
+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?
-
-<pba-cols>
-<pba-col style="font-size:smaller">
+## 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
 
-</pba-col>
+Notes:
 
-<img rounded style="width: 400px; height 400px; float:right; margin-right:5px" src="./img/3.2-thinking-cartoon.png" />
+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
-
-<pba-flex center>
-
-- ID
-- Amount
-- Owner
-- Mask
-- All in a single<br/>
-  Pedersen commitment
-
-</pba-flex>
-
----
-
-## 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 👔
-
-> <https://github.com/Off-Narrative-Labs/Tuxedo>
-
----
-
-<!-- .slide: data-background-color="#4A2439" -->
-
-# Questions?
-Original file line number
+Diff line change
@@ Expand Up @@
     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
@@ Expand Down @@