SWIP 049 - Fixed set of stamps for stamp sampling phase#98
SWIP 049 - Fixed set of stamps for stamp sampling phase#98lat-murmeldjur wants to merge 1 commit into
Conversation
lat-murmeldjur
changed the title
zelig
left a comment
zelig
left a comment
There was a problem hiding this comment.
I have read through it and commented thoroughly, but
there is a major flaw here https://github.com/ethersphere/SWIPs/pull/98/changes#r3485677904
and I am not sure of the motivation for increased complexity.
What we do need is a delay in dilution and (maybe require a long effective ttl after)
This is a short and Sweet SWIP of its own, not worth mixing in othr stuff
https://github.com/ethersphere/SWIPs/pull/98/changes#r3484124428
|
|
||
| ## Abstract | ||
|
|
||
| Phase 5 adds a postage-stamp sample beside the existing chunk-data sample. For each distinct stamp identity, Bee calculates `hash(batchId, fullStampIndex, roundAnchor)` and keeps the required lowest values. One purchased index can therefore contribute only one transformed value in a round, so overreporting storage depth requires a correspondingly large number of real stamp indexes. The separate chunk sample remains necessary to show that participants also store the same chunk data. |
There was a problem hiding this comment.
the "transformed hash" is using the roundAnchor as a prefix, so it is hash( roundAnchor, batchId, index) to be the same as the phase 4 transformed hash.
| - 38 reveal blocks; and | ||
| - 76 claim blocks. | ||
|
|
||
| For target round `r`, sampling begins at the first reveal block of round `r - 1`. This is the first scheduled block in which a successful reveal can produce the anchor used by target round `r`. If the preceding reveal phase has no successful reveal, the existing skipped-round seed derivation is used and the target round remains playable. The sampling boundary does not move. |
There was a problem hiding this comment.
For target round
r, sampling begins at the first reveal block of roundr - 1.
this is not true, but as you say:
This is the first scheduled block in which a successful reveal can produce the anchor used by target round
r.
I suggest a dofferent wording:
The anchor target round r is set by the first successful reveal transaction of the previous round. Since the earliest block this can happen is at the first reveal block of the previous round, we can set that as the "starting block" for sampling.
|
|
||
| The state used by the round is the state after the preceding block has been processed. A batch creation or dilution included before `samplingStartBlock` may therefore affect the target round. An operation included in `samplingStartBlock` or later is too late for that round. | ||
|
|
||
| Counting the sampling-start block and the final target-round claim block, the round's sampling-to-claim window spans 266 blocks. During that window, later postage operations must not change: |
| 4. The batch is still present and live when the target claim verifies the stamp. | ||
| 5. The existing signature, bucket-alignment, inclusion-proof, and other postage checks pass. | ||
|
|
||
| The target claim can be submitted as late as the end of the 266-block window. Requiring 456 blocks of balance at sampling start leaves 190 starting-price blocks of headroom over that claim window. This headroom is used to tolerate the price increase that the preceding round's claim may apply while target-round sampling is already in progress. |
There was a problem hiding this comment.
how do you know that this length tolerates the potential price increase of the previous round's claim. This must be calculated.
|
|
||
| A deployment may require a larger minimum, but it must not permit less than 912 blocks. | ||
|
|
||
| These rules remove the need for per-batch balance history. A top-up cannot rescue a nearly expired batch into an already open round, because the batch must already have six rounds of balance before it can be topped up. A dilution cannot remove a batch from an already open round, because the diluted batch must still have six rounds of balance afterward. |
There was a problem hiding this comment.
why 6? how do you make sure that the degree of the change of price has these properties?
|
|
||
| Bee may reconstruct this state locally from events. The PostageStamp read functions defined by this SWIP are the canonical contract reference. Later creation, top-up, dilution, expiry, or price updates do not change an already constructed target-round sample. | ||
|
|
||
| ### Batch ID reuse |
There was a problem hiding this comment.
This is a totally unrelated issue that is kind of hidden here. Consider reifing it as a separate SWIP
|
|
||
| After 756 skipped rounds, the remaining balance represents approximately 227.871 blocks at the increased price, so survival through the complete conservative window is no longer guaranteed. Integer division in the oracle can only reduce the realised increase, so 755 skipped rounds is a conservative guaranteed tolerance under the current constants. | ||
|
|
||
| This number is a safety analysis, not an on-chain limit. If a larger catch-up causes a selected batch to expire before proof verification, the target claim rejects that batch normally. No expired-batch data is retained for redistribution. |
There was a problem hiding this comment.
I do not understand these two sentences
| 1.832897789 | ||
| ``` | ||
|
|
||
| This is an increase of approximately **83.2898%**. The remaining 418 starting-price block units then represent approximately: |
There was a problem hiding this comment.
'represent' is a funny word to use here. I think it is better to say 'covers the storage rent for a shorter period with the higher price.
| 1049417 / 1048576 | ||
| ``` | ||
|
|
||
| After 755 skipped rounds, the combined maximum price factor is approximately: |
There was a problem hiding this comment.
No no no. You seem to be compounding a multiplicative factor. But it is actually just the price itself.
No matter how many skipped rounds happened. the rate of change is capped at a maximum of the above ratio. which means that the price change is minuscule during a
|
|
||
| ```text | ||
| 418 / 1.832897789 = 228.054 blocks | ||
| ``` | ||
|
|
||
| Using the conservative 266-block window, 228 blocks remain after the earliest possible price update. The batch therefore remains live through the latest target-round claim. | ||
|
|
||
| After 756 skipped rounds, the remaining balance represents approximately 227.871 blocks at the increased price, so survival through the complete conservative window is no longer guaranteed. Integer division in the oracle can only reduce the realised increase, so 755 skipped rounds is a conservative guaranteed tolerance under the current constants. | ||
|
|
||
| This number is a safety analysis, not an on-chain limit. If a larger catch-up causes a selected batch to expire before proof verification, the target claim rejects that batch normally. No expired-batch data is retained for redistribution. | ||
|
|
||
| ### Bee behaviour |
There was a problem hiding this comment.
lets not call it bee but node client changes instead. There are a lot of alternative clients
2 participants
Bee and the Redistribution contract must use the same set of batches and indexes. This SWIP fixes that set when sampling begins and keeps it fixed through the last claim block. A batch may be used only if it already existed, had at least 456 blocks of balance at the price in force when sampling began, and already contained the proved index at that time. New batches and newly created indexes remain usable for uploads immediately, but they cannot be used by an already open redistribution round.
Furthermore, the suggestion is for the PostageStamp contract to keep one previous price and two previous batch depths. The Redistribution contract can use that history to reconstruct the price and index range that applied when sampling began at claim. A top-up is allowed only while the batch still has at least six rounds of balance, and a dilution must leave at least six rounds of balance. The claim verifies that the batch is still present and live, verifies all postage proofs, including that the index existed at the start of sampling, and only then allows the price to change.