add swip-26: strictly typed chunk system #67
Conversation
There was a problem hiding this comment.
The chunk address always available before chunk type assertion which kind of implies its type; if it cannot be a SOC it is a CAC based on its address.
Though the proposal has valid points and straightforward logic to solve chunk types, I don't see the urge to incorporate this new type indicator for chunks because there is no new chunk type that needs it.
|
|
||
| 1. **Ambiguous Processing**: Without explicit type information, chunk processing depends on implicit detection methods, leading to potential security vulnerabilities. | ||
|
|
||
| 2. **Limited Extensibility**: Adding new chunk types requires changes to core validation logic, making it difficult to evolve the system. |
There was a problem hiding this comment.
there is no new chunk type proposed at the moment.
There was a problem hiding this comment.
Replica chunks come to mind as a natural new chunk type, instead of slicing this into the SOC chunks. By not communicating the type of a chunk on the wire-level, this makes execution non-deterministic which leaves open potential issues surrounding resource starvation (e.g. a concerted actor can send chunks that are always SOC chunks, and, on the assumption that most chunks are CAC chunks, lead to a double-spike in resource consumption as all chunks must first go through the CAC check first.
|
|
||
| 1. **Type Ambiguity**: By explicitly encoding chunk types in the header, we eliminate ambiguity in chunk processing, enhancing security and reliability. | ||
|
|
||
| 2. **Extensibility**: The formal specifications allow for future chunk types to be added in a standardised way without modifying core validation logic. |
There was a problem hiding this comment.
those new chunk types address calculation functions should be implemented in our smart contracts as well that still makes it difficult to integrate new types
|
|
||
| 1. Preserving existing chunk address calculation methods for current chunk types | ||
| 2. Supporting current chunk formats with version 0 of each type | ||
| 3. Allowing for gradual adoption of the type system |
There was a problem hiding this comment.
for me, first, it seems like it needs a breaking change in the base protocol to handle type headers.
There was a problem hiding this comment.
A localstore migration can be used in order to both assign type, and version numbers to chunks contained within the localstore, assigning version 0 to the respective chunk types.
While there is no new chunk type planned (yet), this is work that would have to be achieved prior to this. Examples that come to mind would be system chunks (whereby postage snapshots can be distributed with some other proof mechanism attached instead of stamps). In the meantime, the system benefits from clear typing and well-defined binary marshaling of chunks. |
zelig
changed the title
|
|
||
| 1. **Ambiguous Processing**: Without explicit type information, chunk processing depends on implicit detection methods, leading to potential security vulnerabilities. | ||
|
|
||
| 2. **Limited Extensibility**: Adding new chunk types requires changes to core validation logic, making it difficult to evolve the system. |
There was a problem hiding this comment.
not sure i agree with this (core validation logic) but yes standardising the chunk type types will make it easier moving forward and we should use SWIPs to define these
|
suggested some changes, otherwise happy to merge. more SWIPs should follow which define the two current chunk types and use these as a stage to establish prescriptive examples of a formal chunktype type structure with which future chunktypes shall be defined |
Co-authored-by: significance <[email protected]>
3 participants
This PR introduces a draft SWIP for a standardised framework for defining chunk types in Swarm, improving security and interoperability through consistent type identification and validation.