PieceCIDv2 validation vs FRC-0069: oversized trees, heights 0/1, and the 0-byte vector

Abierto
  • ¿Algo no está bien?
#314 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
solidity
Área
backend-api-design

Línea de trabajo

Read FRC-0069 alongside Cids.validateCommPv2 and PDPVerifier.addPieces, then compare the listed vectors and results in report/REPORT.md and vectors/piececid-v2.json. Determine which behaviors should match the FRC, including oversized trees, heights 0 and 1, the 0-byte vector, and padding varints. Done means the intended rules are agreed and documented or implemented consistently.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Following up on the canonical-encoding point in #286. We ran 1,244 PieceCIDv2 vectors (generated from a reference model written from the FRC-0069 text) through Cids.validateCommPv2 and PDPVerifier.addPieces at 3d486ae, on both compact and legacy data sets. Both storage paths agree with each other on every vector. Three places differ from the FRC, and we'd like to know which are intended:

  1. Non-minimal trees are accepted. FRC-0069 makes the height the minimal one for the payload (padding < data, height 2 excepted). addPieces only checks that padding fits in the tree, so a 127-byte payload can be added as (padding 0, h 2), (127, h 3), (381, h 4), ... Each is a different CID with a different root, and each is accepted (33 vectors). So one payload has many valid on-chain identities (findPieceIdsByCid, CID-keyed accounting in FWSS), and the provider proves, and the client pays for, zero padding. Is the oversized form meant to be valid?
  2. Heights 0 and 1 are accepted (17 vectors). The FRC's minimum is height 2 (127 bytes). Some tests here use height-0 pieces, so this may be deliberate. If it is, would a note in the FRC or in Cids.sol help?
  3. The FRC's 0-byte vector is rejected. bafkzcibcp4bdomn3tgwgrh3g532zopskstnbrd2n3sxfqbze7rxt7vqn7veigmy (padding 127, h 2) fails isPaddingExcessive (128*127/127 >= 2^7). Rejecting empty pieces makes sense; the FRC currently says the opposite.

Minor: the library function validateCommPv2 on its own accepts 10-byte padding varints (2^63, 2^64), which addPieces then rejects only through the height cap.

Vectors, per-vector results and the reference model: https://github.com/let-the-dreamers-rise/pdp-conform (report/REPORT.md, vectors/piececid-v2.json). Happy to send a PR for whichever direction you prefer.

Generated by Claude Code

Lenguaje dominante
Solidity
Estrellas
20
Forks
18
Sin PR fusionados en 30 d

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de FilOzone/pdp

Todos los issues de FilOzone/pdp

Issues similares

Más issues de Backend & API Design

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.