See
https://docs.softwareheritage.org/devel/swh-model/persistent-identifiers.html
for the technical details of that spec.
Software Heritage has done a superb job promoting content addressing in
general, and their identifier scheme (SWHIDs, for short) in particular.
By supporting them in CIDs / IPLD, I hope the IPFS ecosystem can align
itself with that effort.
Per the linked documentation, SWHIDs have their own nested grammar and
versioning scheme. I begun by taking the version 1 core identifier
grammar, unrolled it, and replaced `:` with `-` per the guidelines on
separators, with the result being these 5 rows.
There is overlap between the remaining for and git-raw, so this just
adds SWHID snapshots for now.
Add eth-receipt-logand eth-receipt-log-trie types
Also:
* Clarify ETH "block" terminology, as it is actually only the header that is hash referenced by "block" hash and the header in turn contains all the roots to the tx, rct, state (and thereby storage) tries.
* Changed "RLP" to MarshalBinary in the description for tx and rct, because after EIP-2718 tx envelopers were introduced the consensus encoding of a tx or rct is only the pure RLP encoding for the legacy types.
These describe roots & nodes of a merkle tree, not the underlying
data. In the case of CommP and CommD they are binary merkle trees
using sha2-256-trunc2. For CommR they are novel structure merkle
trees using poseidon-bls12_381-a2-fc1.
All nodes of the respective merkle trees could also be described
using this codec if required, all the way to base data. It is
anticipated that the primary use will be restricted to the roots.
Ref: https://github.com/multiformats/multicodec/pull/161Closes: #161Closes: #167
Reserving the 0xb400 range for Poseidon variants, allowing FIL to
iterate on the `fcX` extension of the name where they stay with
BLS12-381 and arity=2. High security variant is for extra circuits
that are usable in case new attacks arise from the standard variant.
Ref: https://github.com/multiformats/multicodec/pull/161
Ref: https://eprint.iacr.org/2019/458.pdf
* Renamed from blake3-256 to blake3. We only need a single code because shorter hashes are just prefixes of longer hashes.
* Changed the code to 0x0202. This will turn into a two byte code, the previous code was 3 bytes when encoded. The other blake algorithms are in the 3 byte range because we needed _many_ codes.
