mirror of
https://github.com/jackyzha0/quartz.git
synced 2025-12-27 14:54:05 -06:00
vault backup: 2022-11-14 10:33:32
This commit is contained in:
parent
e378a1692d
commit
220b32ec55
@ -27,4 +27,46 @@ fallible machines
|
||||
- ram corruption, fade or malfunction of storage media, software issues (fs bugs, compression bugs, etc)
|
||||
- solution
|
||||
- estimate probability of failures, determine how many trials to achieve a certain level of confidence
|
||||
-
|
||||
- aside: mahcines are designed to fail frequently
|
||||
- reliability tradeoff with increases in speed/power consuption (e.g., overclocking)
|
||||
|
||||
distributed consensus
|
||||
- e.g., Master/master relational database
|
||||
- NoSQL gossip protocols, and eventual consistency
|
||||
- network instrastructure e.g., routers as hot spares
|
||||
- consensus gathering systems
|
||||
- apache zookeeper distributed synchronisation
|
||||
- etcd (used in kubernetes)
|
||||
|
||||
dist cons algorithms
|
||||
- fischer lynch paterson impossibility result
|
||||
- paxos - fault tolerant consensus over distributed nodes (use din apache zoo)
|
||||
- raft - alternative to paxos used in etcd
|
||||
- easier than paxos to understand and implement
|
||||
- sub problems: leader election, log (data) replication by leader to followers
|
||||
- EPaxos - more compex and efficient that paxos
|
||||
|
||||
all used when all servers are trusted. when there are malicious parties the consensus set size must grow. you need a majority of votes from the asumed-benign server set.
|
||||
|
||||
permissionless blockchain - do not control the server set, safety presumed if 50% of nodes are benign
|
||||
|
||||
fault tolerance
|
||||
- CFT - when a node dissapears
|
||||
- BFT - nodes acting maliciously
|
||||
- raft and paxos only CFT, variants of Paxos are BFT
|
||||
|
||||
building a cryptocurrency
|
||||
- how to make a 'coin'
|
||||
- how to id coin owners
|
||||
- how to protect from forgery
|
||||
- how to record ownership and transfer of ownership
|
||||
- how are coins single-use
|
||||
|
||||
distributed consensus in bitcoin
|
||||
- track who has what (in normal currency done by banks)
|
||||
- bitcion has all validating nodes store the whole ledger - indicates order of transactions
|
||||
- collectively agreeing its content avoid double spending
|
||||
- a wallet is a hash of a public key a client generates
|
||||
|
||||
proof of work
|
||||
-
|
||||
@ -12,7 +12,12 @@ tags:
|
||||
# Notes
|
||||
- [412-lectures](notes/412-lectures.md)
|
||||
|
||||
-
|
||||
# Log
|
||||
- 14/11
|
||||
- starting today
|
||||
- reviewing 412 lectures 7 and 9
|
||||
- reading https://101blockchains.com/blockchain-governance/
|
||||
|
||||
# Abstract
|
||||
Blockchain technology falls into two distinct classes: open (permissionless) blockchains such as those underlying bitcoin, Ethereum and Cardano; and closed (permissioned) blockchains such as implemented in the Hyperledger Fabric project. To motivate decentralised participation, open blockchains (presently) require an associated cryptocurrency, which can be a risky distraction. However, closed blockchains are considered by some to be insufficiently decentralised.This summer project aims to prototype a compromise: a closed blockchain system that encodes voting rules about self-governance, so that closed blockchain technology can be used in a more open manner. Experience in programming blockchain systems is not assumed. Depending on the student involved, the project will balance work between design and modelling of the blockchain governance rules, and implementation of such a rule set over an existing closed blockchain system.
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user