Update the active_ranges in the DeciderProvingKey construction to avoid the two falling out of sync

[maramihali]

One situation in which this could happen is if we change where the lookup and databus table data are stored in the execution trace.

[maramihali]

This had to do with finding a way to avoid inconsistencies between how active ranges are constructed and updated in the execution trace tracker, given a set of DeciderProvingKey, potentially overflowing. More precisely, if one decides to change, say, where the lookup table data is stored, they will also have to potentially change something in the update() function in the tracker. It would be nice if this was obvious or we had a mechanism to warn if things were falling out of sync

[johnathan79717]

More precisely, if one decides to change, say, where the lookup table data is stored, they will also have to potentially change something in the update() function in the tracker. It would be nice if this was obvious or we had a mechanism to warn if things were falling out of sync

Both construct_lookup_table_polynomials and ExecutionTraceUsageTracker::update make use of ExecutionTraceBlock::trace_offset(). So if one changes where the lookup table data is stored, as long as they get the same trace_offset() results we should be fine? The same is for the other blocks, although both make the assumption that the databus starts from 0, which I guess we can synchronize?

[johnathan79717]

Closed by AztecProtocol/aztec-packages#16589