mirror of
https://github.com/codex-storage/codex-research.git
synced 2025-01-24 09:32:04 +00:00
Added evaluation of the Sia whitepaper
This commit is contained in:
parent
5b5bae2af0
commit
2663b4578c
51
evaluations/sia.md
Normal file
51
evaluations/sia.md
Normal file
@ -0,0 +1,51 @@
|
|||||||
|
An evaluation of the Sia whitepaper
|
||||||
|
===================================
|
||||||
|
|
||||||
|
2020-12-07 Mark Spanbroek
|
||||||
|
|
||||||
|
https://sia.tech/sia.pdf
|
||||||
|
|
||||||
|
Goal of this evaluation is to find things to adopt or avoid while designing
|
||||||
|
Dagger. It is not meant to be a criticism of Sia.
|
||||||
|
|
||||||
|
#### Pros:
|
||||||
|
|
||||||
|
+ Clients do not need to actively monitor hosts (§1). Once a contract has been
|
||||||
|
agreed upon, the host earns/loses coins based on proofs of storage that the
|
||||||
|
network can check.
|
||||||
|
+ Denial of service attacks can be mitigated by burning funds associated with
|
||||||
|
missed proofs (§4).
|
||||||
|
+ Proof of storage is simple; provide a random piece of the file, and the
|
||||||
|
corresponding Merkle proof (§5.1).
|
||||||
|
+ Promotes erasure codes to safeguard against data loss (§7.2).
|
||||||
|
+ Suggests to use payment channels for micro-payments (§7.3).
|
||||||
|
+ The basic reputation system is protected against Sybil attacks (§7.4).
|
||||||
|
|
||||||
|
#### Cons:
|
||||||
|
|
||||||
|
- Sia has its own blockchain (§1), which makes some attacks more likely
|
||||||
|
(§5.2, §5.3). This can be mitigated by adopting a widely used, general purpose
|
||||||
|
blockchain such as Ethereum.
|
||||||
|
- Requires a multi-signature scheme (§2).
|
||||||
|
- The proof-of-storage algorithm requires that hosts store the entire file (§4),
|
||||||
|
instead of a few chunks.
|
||||||
|
- Contracts can be edited (§4). This feels like an unnecessary complication of
|
||||||
|
the protocol.
|
||||||
|
- Randomness for the storage proofs comes from the latest block hash (§5.1).
|
||||||
|
This can be manipulated, especially when using a specialized blockchain for
|
||||||
|
storage.
|
||||||
|
- There is an arbitrary data field that might be used for advertisements in a
|
||||||
|
storage marketplace (§6). This feels like a very restrictive environment for a
|
||||||
|
marketplace, and an unnecessary complication for the underlying blockchain.
|
||||||
|
- It is suggested that clients use erasure coding before encryption (§7.2). If
|
||||||
|
this were reversed (first encryption, then erase coding) then this would open
|
||||||
|
up scenario's for caching and re-hosting by those who do not possess the
|
||||||
|
decryption key.
|
||||||
|
- Consecutive micropayments are presented as a solution for the trust problems
|
||||||
|
while downloading (§7.3). This assumes that the whole file, or a large part of
|
||||||
|
it, is stored on a single host. It also doesn't entirely mitigate withholding
|
||||||
|
attacks.
|
||||||
|
- The basic reputation system favors hosts that have already earned or bought
|
||||||
|
coins (§7.4). It is also unclear how the reputation system discourages abuse.
|
||||||
|
- Governance seems fairly centralized, with most funds and proceeds going to a
|
||||||
|
single company (§8).
|
Loading…
x
Reference in New Issue
Block a user