I’d like to start a discussion on RSKIP-491 draft, which proposes reducing the target difficulty by 30% to lower Rootstock’s average block time from 14s to 10s. The goal is to improve transaction finality while maintaining network security and stability.
Key points of this proposal:
Mining pools have already optimized block template refresh times, reducing block time from 30s to ~24s.
A 10s block time is now feasible without compromising network security and stability.
This change requires modifying the difficulty adjustment calculation in RSKj, specifically in the Constants class for mainnet and here for testnet.
The change will require a hard fork, meaning all full nodes must update.
Open Questions for Discussion:
What potential risks do you see in reducing the block time to 10s?
Apps/protocols that depends on block time?
What would be the best approach for rolling out this update?
Would love to hear your thoughts and feedback on how to move forward with this!
Some protocols rely on the average block time (and the block number) to measure passed time as “avg block time * numberOfBlocks” . Most of them measure relatively large time windows where the resolution in seconds is not really that important, so using the block timestamp (which it is expected not to deviate more than 5min from the bitcoin header timestamp and, more importantly, it can’t be more than X seconds in the future according to the RSK node’s clock, where X by default is 60 seconds on mainnet) is a much better alternative in those cases. So this change will impact these contracts relying on an outdated average block time, especially when the time difference accumulates in time windows composed of a large number of blocks (in those scenarios the time difference can be important)
We need to identify these contracts and if they can be upgraded move to a timestamp solution to keep track of these time windows. The ones that cannot be upgraded are a problem, but I don’t think that’s a reason not to pursue this change.
In the case of Flyover, the amount of confirmations required for a quote to be confirmed is defined off-chain, therefore, if the RSK target difficulty is reduced, it would be needed that all the liquidity providers increase accordingly the number of confirmations they’re asking for pegout quotes. The server has a UI to make this kind of changes without restarting it so it shouldn’t be a big deal. Besides of this, I don’t see any other consideration to have regarding this topic.
All the usage of the block timestamp and block number is to compare against a particular quote and since the quotes have a relatively short lifecycle this reduction shouldn’t be a problem. Taking this into account, maybe it would be good that the LPs did this adjustment before the reduction, to prevent any risk with the quotes whose lifecycle coincides with both pre and post difficulty reduction blocks.
That was regarding the quote pegin and pegout processes. There is only one variable of the Liquidity Bridge Contract that contains a number of blocks required in the protocol which is the resignDelayInBlocks. This is the difference that need to pass between a LP resignation and the block where it is able to withdraw its collateral. This variable would need to be adjusted as well, but I don’t see any logic modifications required (source).
One comment regarding the purpose: " The goal is to improve transaction finality while maintaining network security and stability"
If we reduce the target difficulty and as a consequence reduce the avg block time, we are not improving transaction finality (we need more blocks now for the same cumulative work) , we’re improving transaction settlement.
I might be missing something so I’m reading your research here , in case it explains how finality does in fact get improved by this change.
You’re right that we aren’t improving the time/finality relationship, as it depends on the cumulative work, as you mentioned. However, we do reduce the time a user waits for the first confirmation block, which provides lighter finality with less cumulative work compared to before. By the way, I’ve never heard the term ‘transaction settlement.’ Where is that terminology used?
I can check if it’s used as standard terminology in some texts, but what I meant with that terminology is: the transaction has been recorded on the Blockchain, so whatever outcome is expected from executing that transaction is now in the blockchain (global state if you want), although probably not irreversible yet. So it is the first confirmation block that you mentioned.
Example: If you had 1 block every 30 seconds avg with blockGasLimit=X you could record Y transactions (settle them) every 30 seconds, on average assuming a controlled test. Now if the block time is every 15 seconds avg, with the same gas limit, you can settle Y transactions every 15 seconds, so it’s the double of transactions (and their outcome in the blockchain) recorded/settled in the same time window, on average . As you also described, the outcome of a transaction appears faster on the Blockchain as it settles faster now.
But in this example the finality time didn’t change (the time to consider them probably irreversible), as you decreased the block time by reducing the difficulty while maintaining the hash-rate unchanged (the effort to mine 2 blocks with the new lowered difficulty for the 15-second block should be very similar to the effort to mine 1 block for the 30-second block scenario)
Exactly the time relation time/finality didn’t change, If previously you had to wait 6 blocks or 3 minutes to be considered finalized, after this change, you will still need to wait the same 3 minutes, but it will involve more than 6 blocks.
I believe the correct terminology is “confirmation” and “finality.” Confirmed refers to when a transaction is first included in a block, but it remains reversible with a high probability. Finalized, on the other hand, means that the chances of reversion are negligible.