You can see more at "Docker and AUFS in practice"

This diagram shows that each image layer, and the container layer, is represented in the Docker hosts filesystem as a directory under /var/lib/docker/.
The union mount point provides the unified view of all layers.

As of Docker 1.10, image layer IDs do not correspond to the names of the directories that contain their data.

As I mentioned before:

the V2 API does not deal in Image IDs. Rather, it uses digests to identify layers, which can be calculated as property of the layer and are independently verifiable.

See "Docker Registry HTTP API V2":

This API design is driven heavily by content addressability.
The core of this design is the concept of a content addressable identifier.

It uniquely identifies content by taking a collision-resistant hash of the bytes. Such an identifier can be independently calculated and verified by selection of a common algorithm.
If such an identifier can be communicated in a secure manner, one can retrieve the content from an insecure source, calculate it independently and be certain that the correct content was obtained.
Put simply, the identifier is a property of the content.

To disambiguate from other concepts, we call this identifier a digest.
A digest is a serialized hash result, consisting of a algorithm and hex portion. The algorithm identifies the methodology used to calculate the digest. The hex portion is the hex-encoded result of the hash.

We define a digest string to match the following grammar:

 digest := algorithm ":" hex algorithm := /[A-Fa-f0-9_+.-]+/ hex := /[A-Fa-f0-9]+/

Some examples of digests include the following:

digest  description
sha256:6c3c624b58dbbcd3c0dd82b4c53f04194d1247c6eebdaab7c610cf7d66709b3b     Common sha256 based digest

While the algorithm does allow one to implement a wide variety of algorithms, compliant implementations should use sha256