CIP: Shwap Protocol

Celestia Improvement Proposals (CIPs)
1

Post to discuss CIP for the upcoming Shwap Protocol.

3 Likes
2

Open Questions to continue discussion:

  1. CIP-19: Shwap by Wondertan · Pull Request #77 · celestiaorg/CIPs · GitHub
  2. CIP-19: Shwap by Wondertan · Pull Request #77 · celestiaorg/CIPs · GitHub
2 Likes
3

A few loose comments:

  1. “Proof: A Merkle inclusion proof of the data in the DataSquare.” Is this actually required by Shwap? Why not allow a generic proof, e.g. a KZG opening?

  2. “Identifiers are not collision-resistant and there MAY be different identifiers referencing the same container.” Could there be different containers for the same identifier?

  3. “SHOULD contain shares within a single DataSquare and MAY NOT be adjacent” it’s not clear that it’s the shares that may not be adjacent.

  4. “Share identifiers SHOULD be serialized by” shouldn’t these be MUSTs? If not serialized in that way, how would they be serialized?

  5. “Serialized identifiers SHOULD have constant and predetermined lengths in bytes.” seems to contradict “Serialized RowID MUST have a length of 10 bytes.”

  6. “It MUST be bigger than zero.” english, but should be “greater than” I think.

  7. “The 16 bit limit fits data squares up to 2TB. It MUST not exceed the number of Row roots in DAH.” If row indices are zero-indexed, then it must not exceed number of row roots minus one.

  8. “Its length MUST be equal to the number of Column roots in DAH divided by two.” “Its” here refers to the list of row shares, not the row shares themselves. So the spec as-is is saying the list of shares should always be for the whole block.

  9. “Namespace: A fixed-size 29 bytes array representing the Namespace of interest.” How about future namespace versions? They could break shwap the protocol. This spec is essentially adding a rule that namespace IDs must be 29 bytes, and that an app change that breaks this rule will also require a break to the DA protocol.

1 Like
4

Responses to each comment, with most of them being resolved in cip-19: adressing review from @adlerjohn by Wondertan · Pull Request #116 · celestiaorg/CIPs · GitHub

  1. Shwap requires proof. We can generalize the definition of a proof so KZGs are included. The protocol and Shwap only allow NMT Merkle proofs at present, but versioning for containers and IDs will allow new proofing systems. Do you think it makes sense to extend the definition already while keeping the protocol to NMT proof?
  2. No. Only one container is possible for the same identifier atm. This may change, though. If we support two proving systems, then the serialized containers would differ. It is worth clarifying in the spec.
  3. Agreed, worth clarifying.
  4. Agreed. I will update to MUST
  5. Agreed.
  6. Agreed. Good catch! Also, made me think of another such case.
  7. Yes. The RowHalf is always supposed to be for the whole block. I am not sure I understand your comment here entirely
  8. Yes. It will break the DA protocol, and that’s fine. The strategy is to produce new ID/Container versions(see versioning). We could make DataID with dynamic size and subsequently dynamic namespace size, but we are currently restricted to constant ID size due to a limitation in Bitswap. We found a way to avoid that limitation, which is invasive, and we decided against it for now. If anything, we can always fix it and make a new dynamic version of the ID
1 Like