같은 tar 내용인데 압축 방식이 달라 layer digest가 달라질 수 있습니다. compressed digest와 uncompressed diffID의 역할을 구분하세요.

manifest descriptor의 digest와 config의 DiffID는 해시 대상이 다릅니다. 압축되지 않은 tar 바이트를 U, gzip 결과를 G1, 다른 gzip 설정 결과를 G2라 하면 sha256(U)=D, sha256(G1)=A, sha256(G2)=B에서 A와 B는 달라도 D는 같을 수 있습니다. descriptor digest는 registry로 전달되는 blob 바이트를 가리키므로 A 또는 B가 되고, rootfs.diff_ids의 D는 압축을 풀기 전 tar의 digest입니다. 압축 timestamp·level이 달라진 예에서만 이런 분리가 일어나는 것이 아니라 mediaType과 descriptor size까지 함께 달라질 수 있습니다.

다만 “같은 tar 내용”을 파일 목록이 같다는 뜻으로 느슨하게 말하면 안 됩니다. tar entry 순서, header의 mtime·uid·mode, pax 메타데이터, whiteout 이름이 바뀌면 압축을 풀어 얻는 tar 바이트 U가 달라져 DiffID도 달라질 수 있습니다. 반대로 U가 정말 byte-for-byte 같고 압축만 바뀐 경우에는 DiffID가 유지됩니다. 따라서 압축을 다시 만들 때 descriptor와 size를 갱신하고, config의 diff_ids와 layer 순서가 새 tar의 의미와 맞는지 따로 확인합니다.

diff_ids의 순서는 parent부터의 순서를 보존하며, 그 배열로 OCI 문서가 설명하는 누적 ChainID를 계산할 수 있습니다. 그러나 이것을 모든 OCI runtime이 반드시 계산하거나 저장 계층에서 사용한다는 뜻으로 확대하면 안 됩니다. 일부 image store나 snapshotter가 캐시·계보 키로 사용할 수 있고, 다른 구현은 자체 식별을 쓸 수 있습니다. config digest, manifest digest, layer descriptor digest, runtime snapshotter의 chain 사용은 각각 확인 대상입니다. 이 답변의 A/B/D는 설명용 기호 계산이지 실제 registry blob 생성 결과가 아닙니다.