ERIS enables robust availability of content by defining an encoding of content into uniformly sized blocks and a short identifier. Blocks can be replicated over various transport protocols. The original content can be decoded from the blocks and the short identifier.
ERIS is formally described in the specification:
Encoding for Robust Immutable Storage (ERIS)
ERIS defines an encoding of arbitrary content into a read-capability and a set of uniformly sized blocks. The original content can be reassembled (decoded) from the blocks and the read-capability.
The blocks are identified by the cryptographic hash of their content (content-addressing). This allows the integrity of the original content to be verified during decoding.
Blocks of ERIS encoded content are uniformly sized (either 1KiB or 32KiB) and can be transferred over protocols such as HTTP, FTP, IPFS, CoAP, GNUnet, BitTorrent, Named Data Networking or Sneakernets.
Furthermore, blocks are encrypted and the original encoded content can not be directly inferred from the blocks. In certain circumstances intermediary peers that store and transport without access to read-capabilities can claim that decrypting encoded content is infeasible for them (see Intermediary Peer Deniability).
By allowing content to be replicated and cached over many different protocols, ERIS allows a form of censorship resistance.
The short identifiers required to decode content are called read-capabilities. Read-capabilities can be encoded as URNs. This allows ERIS encoded content to be referenced from many existing applications and protocols.
An ERIS URN looks like this:
urn:eris:BIAD77QDJMFAKZYH2DXBUZYAP3MXZ3DJZVFYQ5DFWC6T65WSFCU5S2IT4YZGJ7AC4SYQMP2DM2ANS2ZTCP3DJJIRV733CRAAHOSWIYZM3M
We borrow the term from capability-based security because these URNs can (and should) be treated as permanent and unforgable data access tokens.
ERIS read-capabilities are generated by an algorithm that can create unique or convergent (deterministic) identifiers. Immutable data may be referred to by many unique identifiers or by a single convergent identifier that can be recreated by anyone using the same data. A read-capability can be used to securely verify the data it represents, regardless if it is unique or convergent.
ERIS capabilities are larger than hash digests, because a typical hash digest is 32 bytes whereas an ERIS capability is 66 bytes. Systems that use these capabilities internally therefore generate larger internal metadata. We believe this cost is offset by the benefit of identifiers that enable partial verification using hash trees and because a standardized URN representation enables data portability between applications.
Storing ERIS encoded data comes with the cost of storing a tree of metadata blocks describing data blocks as well as some data padding. The amount of overhead can vary, but the worst case scenario for storing a 1GiB file is 2MiB of tree blocks.
All data that is encoded for convergent capabilities has some implicit deduplication during storage, regardless of the storage medium.
Encodings similar to ERIS are already widely-used in applications and protocols such as GNUNet, BitTorrent, Freenet, IPFS and others. However, they all use slightly different encodings that are tied to the respective protocols and applications. ERIS defines an encoding independant of any specific protocol or application and decouples content from transport and storage layers. We hope to enable interoperability of content beyond protocols.
ERIS is inspired and based on the encoding used in the file-sharing application of GNUnet: Encoding for Censorship-Resistant Sharing (ECRS) (see also the relevant section in the specification).
We maintain further documentation describing usecases, extensions, recommendations and best-practices related to ERIS. For example this includes conventions on how to exchange ERIS blocks over CoAP, how to publish ERIS with HTTP, how to implement append-only sequences, how to cache content with ERIS or how to use Magnet URIs with ERIS.
The extensions and recommendations can be found here:
ERIS Extensions and Recommendations
| Language | License | Code | Documentation |
|---|---|---|---|
| Common Lisp | LGPL-3.0-or-later | eris-cl | |
| Go | BSD-3-Clause | codeberg.org/eris/eris-go | godocs.io/codeberg.org/eris/eris-go |
| Guile | GPL-3.0-or-later | guile-eris | eris.codeberg.page/guile-eris |
| Nim | Unlicense | nim-eris | eris.codeberg.page/nim-eris |
| OCaml | AGPL-3.0-or-later | ocaml-eris | eris.codeberg.page/ocaml-eris/eris/Eris |
| Python | AGPL-3.0-or-later.txt | python-eris | https://eris.codeberg.page/python-eris/ |
| Rust | AGPL-3.0 | eris-rs | |
| Smalltalk | ISC | ERIS |
Additional implementations are being developed (Wisp).
| System | Implementation | Interface | Documentation |
|---|---|---|---|
| Linux (Unix) | codeberg.org/eris/eris-go | FUSE | man 1 eris-go |
| 9FRONT (Plan 9) | codeberg.org/eris/eris-go | 9P2000 | man 1 eris-go |
For comments or questions please use the mailing list.
Ephemeral discussions take place in the #eris channel on the Libera IRC network.
Urgent and sensitive security issues may be addressed directly to the ERIS maintainers. See security.txt.
The drafting of the ERIS specification and the implementation of the initial software libraries was funded by the NGI Assure Fund, a fund established by NLnet with financial support from the European Commission's Next Generation Internet program.
Source for this page can be found on Codeberg.