2. Blockchain Primitives: Cryptography and Consensus

Instructor: Dan Boneh (Stanford Comp Sci Professor)

Personal Summary:

Key Learnings:

• Building dApps (decentralized) is harder than normal apps

• Consensus layer is well-understood
• Layer 1 is a public data structure (ledger) that provides; persistence, consensus, liveness and is open (some)
• How Blockchains work with a PoW (proof-of-work) consensus mechanism:
• Users have a secret key signifying ownership, users sign transactions, which are then sent to miners
• Consensus protocol chooses a leader among miners, who orders the transactions into a block, which get posted onto the blockchain
• The miners are compensated in tokens, and the other miners verify the block (if it’s invalid it doesn’t get added)
• However all miners need to verify the block (which is inefficient)
• The Leader decides the order of the transactions. Becoming the leader requires having the most CPU and compute power (resource-constrained)
• Blockchains aiming to move away from PoW (proof-of-work) to PoS (proof-of-stake) to be more energy efficient
• Layer 1.5 - the code is opensource, transparent, and publicly verifiable
• Layer 2 - How do you deploy applications on the Blockchain?
1. Write your code, create an application and write it in Solidity
2. Post your code onto the blockchain
3. Somebody sends a transaction to the application, which causes a state change to the application, and another state change etc
• Bitcoin is a limited computing environment
• Limited instruction set (no loops)
• Ethereum is a general programming environment (e.g. solidity, web3)
• Data put on the blockchain is really expensive, have to reduce the amount of storage on the blockchain
• Given the high cost, a lot of developer time is focused on either expiring data as quickly as possible from the Blockchain, or avoiding to write it on the chain itself
• Modern blockchains will have a richer developer toolkit to work with
• Layer 2 application layer is the most exciting layer
• If you make a bug in your application, it can be costly, so programming language chosen is important
• Very hard to write secure code with that languages
• MakerDAO as a beautiful idea, they took the US Fed policy and implemented it into an algorithm

Cryptographic Primitives

“Blockchains are a consumer of advanced cryptographic primitives.”

There are 3 primitive building blocks for cryptography:

1. Digital signatures + aggregation
2. Merkle commitments
3. Succinct zero-knowledge proof systems

Below, we’ll discuss the above primitives.

1. It’s difficult to replicate signing a physical check digitally, due to verification issues and easy replication. So how do you fix the digital signature problem? —> The idea is to make the signature itself a function of the data being signed (so you combine a signing algorithm with a private signing key)... and this produces a signature. Then you have a verification algorithm which uses a public verification key to verify the signature. Signature are used everywhere on the blockchain
• You can aggregate all the signatures and compress them all into one signature (an aggregate signature). This allows you to not store all the signatures on the blockchain, but have an aggregate instead
2. Commitments are like (real-world example) having a sealed envelope for an auction. You provide your price and send it to the auctioneer who selects the highest price. The envelope is sealed. In the Crypto world, this is exactly what happens. These commitments have security properties; being binding (can’t have multiple envelope openings) and hiding (nothing about the info inside the envelope is revealed).
1. This allows you to commit data to the Blockchain
2. “Merkle Trees” take a bunch of values, make a short proof, and commit the data onto a blockchain. They exist to reduce the storage space necessary on the Blockchain (remember you want to store less data, as storage is costly). Merkle Tree commitments can be used as proof that e.g. Alice paid Bob 2 Ethereum, because they have the proof.
1. Keeps entire database off the chain.
3. Zero-knowledge proof systems. What are they? If you have a prover and a verifier (where a prover is proving a fact to the verifier, using proof)... then a Zero-knowledge proof system is where the verifier learns nothing about the witness or the proof itself but can still confirm that the fact is indeed correct. The theorem says that anything that can’t be proved, can also be proved in zero-knowledge. If a certain fact has a short proof, I can convince you of that fact without telling you anything about what the proof is.
1. A proof system consists of a prover and a verifier (where the prover is trying to prove something is correct, to the verifier)
2. A proof system needs to be complete, succinct, have fast verification, have efficient proof generation
3. Security necessary: needs to be sound (can’t convince verifier of a false statement), and be zero-knowledge (verifier can’t learn anything about the witness)
4. A ‘SNARK’ is referred to as being succinct, having fast verification and efficient proof generation
1. Application: “Roll-ups”, which is a separate server that can host incoming transactions and verify all of them in a single proof, quickly. This means that miners don’t have to verify transactions, but can verify proofs instead, which is quicker. Roll-ups provide blockchain scalability.
2. It’s called a ‘Roll-Up’ because you also send a summary of the transactions onto the blockchain, so the actual data is transmitted onto the blockchain... But the miners don’t need to verify the data because the Roll-Ups have verified the proof which determines that the transaction is legitimate.
3. You can also provide zero-knowledge and zk Roll-Ups, which provides privacy as the miners won’t even know what the transactions are
4. Longer-term potential and project being worked on, which is not yet possible... You can have private data on a Public Blockchain. Rather than writing the app code in the clear, you can post a hiding commitment to the blockchain. You post a zero-knowledge proof that the state transition is valid. Bottleneck to achieving this is the time taken to generate proofs.
5. A ‘zkSNARK’ is referred to the above but also being zero-knowledge

• Blockchain is not a database. You shouldn’t use it as such. You should centralize when possible and use Blockchains when you need a decentralized system.
• Blockchains should be used when there is no single party trusted by everyone
• Professor believes that Blockchain architecture will converge and consolidate
• The Roll-Up server building the proofs is a centralized server, but it can be replicated. Fear is you might have censorship (it can refuse a transaction)... but you can have multiple roll-up servers that will pick it up.