From 635fffba6e5fb7eb8e41593f2986ee3444d74df7 Mon Sep 17 00:00:00 2001 From: Mark Spanbroek Date: Tue, 26 Sep 2023 13:49:11 +0200 Subject: [PATCH] FastECC decoder is availabe, just not released --- design/proof-erasure-coding.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/design/proof-erasure-coding.md b/design/proof-erasure-coding.md index ebbc412..18082d3 100644 --- a/design/proof-erasure-coding.md +++ b/design/proof-erasure-coding.md @@ -225,13 +225,14 @@ size 2^24, we could support slot sizes up to 1TB: We are however unaware of any implementations of reed solomon that use a field size larger than 2^16 and still be efficient O(N log(N)). [FastECC][2] uses a -prime field of 20 bits, but it lacks a decoder and a byte encoding scheme. The -paper ["An Efficient (n,k) Information Dispersal Algorithm Based on Fermat -Number Transforms"][3] describes a scheme that uses Proth fields of 2^30, but -lacks an implementation. +prime field of 20 bits, but its decoder isn't released yet, and it is unclear +whether its byte encoding scheme allows for a systematic erasure code. The paper +["An Efficient (n,k) Information Dispersal Algorithm Based on Fermat Number +Transforms"][3] describes a scheme that uses Proth fields of 2^30, but lacks an +implementation, and has the same encoding challenges that FastECC has. If we were to adopt an erasure coding scheme with a large field, it is likely -that we'll have implement one. +that we'll either have to modify Leopard or FastECC, or implement one ourselves. Conclusion ----------