Blockchain Protocols Flashcards

1
Q

Define a synchronously safe protocol.

A

If it’s safety is guaranteed by an assumption about timing or about how the race conditions are resolved.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Define an asynchronous consensus protocol.

A

If it’s safety is guaranteed WITHOUT assumption about timing or about how the race conditions are resolved (as long as everyone eventually gets the message).

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Traditionally which two properties do consensus protocol have?

A

1) Safety

2) Liveness

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Define “Safety” as a consensus property

A

It is not possible for nodes to make inconsistent decisions

Safety means that the results produced by the system should be correct

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Define “Liveness” as a consensus protocol property

A

Node eventually/inevitably make decisions

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Fault tolerant consensus protocols have ………….. and/or …………… despite some number of faults.

A

Safety

Liveness

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Faulty behaviour is either considered to be …………… ……………… or ……………….

A

Crash faulty

Byzantine

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Define crash tolerate behaviour

A

Nodes are faulty by virtue of not sending messages

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Define Byzantine Fault behaviour

A

Where a node fails but there is not agreement between the other nodes about whether it has failed because the fault detection results are inconsistent.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

What does the FLP Possibility show?

A

Can’t have
-deterministic consensus protocol
that is SAFE and LIVE
In an ASYNCHRONOUS system

IF
There is even one crash fault.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

List the two “Liveness” faults:

A

Crash fault - failing to SEND a message when expected

Omission fault - failing to RECEIVE a message when expected

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

List the two “Safety” faults

A

Invalid message fault

Equivocation fault

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Define an Invalid message fault

A

Producing messages that cannot be produced by a protocol following node.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Define an Equivocation fault

A

Producing valid message in a way that could not have been produced by a single execution of the protocol

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Liveness faults are indistinguishable from ……………. ……………….

A

Network latency

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Network latency (and therefore …………… ……………….) cannot cause protocol following ………….. to make inconsistent decisions in an asynchronous safe consensus protocol.

A

Liveness faults

Nodes

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

What does CBC stand for?

A

Correct by construction

18
Q

What is a Byzantine fault?

A

When components may fail but appear to some on the network as failed and others as fine.

19
Q

Under what conditions are Byzantine faults a problem?

A

When the network requires consensus on whether there is a fault on the problem component

20
Q

What is a consequence of a Byzantine fault?

A

The faulty component is NOT shut out of the network

Because consensus can’t be reached about whether it is faulty as there is inconsistency about its state

21
Q

What is Byzantine fault tolerance?

A

The ability of the network to continue operating even if some of the nodes fail or are acting maliciously

22
Q

What does BFT stand for?

A

Byzantine fault tolerance

23
Q

What are the requirements in the Byzantine generals problem?

A

Each general has to decide: attack or retreat (yes or no)

After the decision is made, it cannot be changed

All generals have to agree on the same decision

Have to execute in a synchronized manner

24
Q

How does the Byzantine generals problem translate to blockchain?

A

The MAJORITY of participants within a distributed network have to :

AGREE and EXECUTE the same action in order to avoid complete failure.

Works based on majority so even if there are MALICIOUS or FAULTY nodes it won’t be a problem (unless they gain 51% of the network)

25
Q

What is the consensus problem?

A

Agreement among a number of nodes for a single data value is required.

Some of the nodes may fail or be unreliable in other ways, so consensus protocols must be fault tolerant or resilient.

The nodes must put forth their candidate values, communicate with one another, and agree on a single value.

26
Q

What is the difference between a crash failure and a Byzantine failure?

A

A crash failure occurs when a process abruptly stops and does not resume.

A Byzantine failure may send contradictory or conflicting data to other nodes, or it may sleep and then resume activity after a lengthy delay.

27
Q

What is FLP?

A

It has been proved that consensus is impossible

  • In a fully asynchronous message-passing distributed system
  • Where even one node has a crash failure
28
Q

Once every node has agreed on consensus with one another, ………….. is guaranteed.

A

Liveness

29
Q

Safety should guarantee that ……………..

A

A bad thing never happens

30
Q

Liveness should guarantee that …………….

A

Something good eventually happens

31
Q

Why would nodes want mine on every fork in POS system? (are nothing at stake problem)

A

No cost to mine all forks

Guarantees that you will collect a transaction fee as one of the forks will win

32
Q

What is the problem when nodes start mining on every fork in a POS system? (re nothing at stake problem)

A

Leaves the network vulnerable to double spending attacks

33
Q

What is the Nothing at Stake problem?

A

A theoretical security hole in POS systems.

The problem can occur anytime there is a fork in the blockchain, either because of a malicious action or accidentally when two honest validators propose blocks simultaneously.

34
Q

Why is a Nothing at Stake problem unlikely in reality?

A

Assumes that:

Every validator will seek profit
- even at the detriment of network security and quality

No validators will act altruistically

Validators modified or used modified software (as mining on multiple forks is not part of standard software)

35
Q

How does the Casper protocol seek to deter Nothing at Stake problem?

A

By requiring funds that can be lost to be staked

In other system just having money in your wallet that would not be at risk was all that was required

36
Q

Casper is a……………….. based economic consensus protocol.

A

security-deposit

37
Q

What happens in a security-deposit based protocol?

A

Nodes who wish to validate transactions must place a security deposit in order to do so.

If a validator produces anything invalid

  • A portion or all of their deposit is forfeited
  • Their ability to continue participating in consensus is forfeited
38
Q

How does Casper tackle the Nothing at Stake problem?

A

The security-deposit attaches a cost to being dishonest

makes it in the best economic interest of all of the miners to behave honestly

39
Q

Safety also means……………., a transaction that got recorded in the ledger at some position shouldn’t change position.

Once the system or the ledger outputs some kind of ……………., this should be the same for all nodes or for all participants in the system.

A

persistence

ordering

40
Q

………….. means that if a transaction is sent, it should appear in the ledgers of all nodes (or at least, the honest nodes that follow the protocol)

A

Liveness

41
Q

Safety = ………..

Liveness = ……….

A

Correctness (that everyone will agree on the same thing)

Agreement (that agreement across nodes will be reached)

42
Q

Name 4 types of fault on Tendermint (Cosmos) network

A

Liveness - network halts
Safety - blockchain forks
Censorship - data withholding
Hard fork failure - invalid state transition