Remove immutable stamp field in the smart contract

[bcsorvasi]

The smart contract still exposes the legacy field/mechanism for marking a batch as immutable, even though the functionality has been disabled in Swarm for years. While it is still technically possible to purchase batches with this flag set, the flag has no practical effect: all batches are effectively mutable, with behavior determined by whether an existing index is stamped or not.

Bee does not document this legacy behavior, nor does it explain why the contract field still exists. This can mislead developers into thinking the immutable flag is still meaningful.

Determine whether the legacy field can be safely removed from the smart contract.

[Cafe137]

As I understand, the current immutable flag is only a local safeguard against overwriting filled slots, and it is not enforced for other chunks on the network.

Given that, it is probably safe to remove this flag from the smart contract. However, I believe Bee should retain this behavior locally through its database, as postage batch utilization is not intuitive, and overwrites could happen unexpectedly. For example, a postage batch may still have sufficient remaining theoretical capacity, but due to unlucky chunk distribution one of the buckets roll over during an upload and break prior data.

That said, I have mixed feelings about this direction. I'd support re-introducing the network-level functionality of the immutable flag, along with a flag that also locks the depth of a postage batch.

My problem statement is that no reliable assumptions can currently be made about data stored on the network.

1. Chunks can be overwritten, even when the immutable flag is set.
2. A postage batch's depth can be diluted to speed up expiry (24-48 hours).

As a result, there is currently no way to provide meaningful guarantees about third-party datasets or build storage services on top of Swarm. Postage batch owners cannot guarantee that either the postage batch or the associated chunks will remain available on the network for the duration implied by the amount in the postage batch.

[significance]

i think there is a lot of confusion here - we will have the same problem we are having with reuse of socs with reuse of stamps, the problems are analogous. i suggest the same solution here, i.e. do not support mutability, in fact choose arbitrarily - lowest stamp integer value of something deterministic is valid or disallow all stamps if double stamping is found

[acud]

lowest stamp integer value of something deterministic is valid or disallow all stamps if double stamping is found

does not hash. can you please rephrase and be a bit more specific?

[0xCardiE]

Ok to summarize this

immutableFlag is stored on-chain but never enforced anywhere int contract, redistribution, or network. It misleads integrators into thinking a guarantee exists when it doesn't.

1. Cleanup (now): Remove the legacy field from the smart contract (Batch.immutableFlag, _immutable on createBatch/copyBatch, batchImmutableFlag(), event field). PR here . Bee should keep its local overwrite protection that's independent of the contract.

2. Storage guarantees (later): Worth revisiting network-level immutability + depth-lock, but only as a full protocol change (Bee overwrite policy, conflict resolution, redistribution, RFC)

[0xCardiE]

As I understand, the current immutable flag is only a local safeguard against overwriting filled slots, and it is not enforced for other chunks on the network.

Given that, it is probably safe to remove this flag from the smart contract. However, I believe Bee should retain this behavior locally through its database, as postage batch utilization is not intuitive, and overwrites could happen unexpectedly. For example, a postage batch may still have sufficient remaining theoretical capacity, but due to unlucky chunk distribution one of the buckets roll over during an upload and break prior data.

That said, I have mixed feelings about this direction. I'd support re-introducing the network-level functionality of the immutable flag, along with a flag that also locks the depth of a postage batch.

My problem statement is that no reliable assumptions can currently be made about data stored on the network.

1. Chunks can be overwritten, even when the immutable flag is set.
2. A postage batch's depth can be diluted to speed up expiry (24-48 hours).

As a result, there is currently no way to provide meaningful guarantees about third-party datasets or build storage services on top of Swarm. Postage batch owners cannot guarantee that either the postage batch or the associated chunks will remain available on the network for the duration implied by the amount in the postage batch.

here is an issue on this where it will be tracked for no2, thnx for the overview that pointed us in right direction

ethersphere/bee#5538

[0xCardiE]

Technically done, but will need deployment which is part of migration of postagestamps.