SM2 is a set of cryptographic algorithms based on elliptic curve cryptography, including a digital signature, public key encryption and key exchange scheme.
The ISCC is similarity preserving identifier for digital content. An ISCC is derived algorithmically from the digital content itself, just like cryptographic hashes. However, instead of using a single cryptographic hash function to identify data only, the ISCC uses a variety of algorithms to create a composite identifier that exhibits similarity-preserving properties (softhash). For an implementation of code `0xcc01` see: https://iscc-core.iscc.codes/#quick-start
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
