30 lines
2.4 KiB
Markdown
30 lines
2.4 KiB
Markdown
# Practical Client-side Replication: Weak Consistency Semantics for Insecure Settings
|
|
## Authors: van der Linde, Leitao, Preguica
|
|
|
|
## Definition
|
|
|
|
causal consistency: model enforcing clients to observe a state that respects the causal order of operations. (this is the case for decentralized and peer to peer systems)
|
|
|
|
Attacks on causal consistency:
|
|
|
|
- Tempering: a node submit an operation to anticipate a pending operation actually not yet executed by the system.
|
|
- Omitting dependencies: a node used only a subset of the operations in the dependency. He will be able to submit a concurrent task to the system.
|
|
- Unseen dependencies (also called add): a node submit an operation that depends on an operation that he didn't see. It can be usefull for the attacker to anticipate the operation. (This is different from tempering because in this case the operation does not exist yet).
|
|
- Combining omitting and unseen: a node can omit a dependency and submit an operation that depends on an operation that he didn't see.
|
|
- Sibbling generation: creating two differents operations with the same id. The attacker could create a permanent state divergence between the nodes.
|
|
|
|
## Summary
|
|
### Solutions used in the paper
|
|
#### Secure causal consistency
|
|
Autors defined the properties of a secure causal consistency: Immutable History, No Future Dependencies, Causal Executions, Limitted Omission, and Eventual Sibling Detection.
|
|
|
|
The algorithms they propose used the following solutions for each property:
|
|
|
|
- Immutable History: The nodes sign the operations and the dependencies. The nodes can't temper the history because they can't sign the operation.
|
|
- No Future Dependencies: Each operations includes a hash of all direct causal dependencies. The nodes can't omit dependencies because they can't sign the operation.
|
|
- Causal Executions: The nodes need to verify, before executing an operation, that all the dependencies are executed.
|
|
- Limitted Omission: It's by design impossible due to the metadata (hash of the dependencies).
|
|
- Eventual Sibling Detection: Many mechanism are used:
|
|
- a node is able to detect when two operations with the same id are send from differents paths.
|
|
- a node is able than the hash of the dependencies is different with the hash provide by the operation.
|
|
- the nodes are comparing the dependencies of the operation between them. If they are different, they are able to detect the sibbling generation. |