From 2663b4578cf5658db09488b593f9b5aaa3a39a2a Mon Sep 17 00:00:00 2001 From: Mark Spanbroek Date: Mon, 7 Dec 2020 13:54:22 +0100 Subject: [PATCH] Added evaluation of the Sia whitepaper --- evaluations/sia.md | 51 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 51 insertions(+) create mode 100644 evaluations/sia.md diff --git a/evaluations/sia.md b/evaluations/sia.md new file mode 100644 index 0000000..a430cdc --- /dev/null +++ b/evaluations/sia.md @@ -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).