You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The settlement hub will require single round fraud proofs, which should eventually be implemented by making some modifications to the block production and EVM to allow for calculation and insertion of ISRs every N distinct state accesses.
For an initial implementation however it's possible to simulate this functionality, given a known set of deployed contracts, by limiting the block gas limit such that no single tx can exceed the N dynamic state accesses limit (contract calls not included given that they are fixed state in the hub).
The block gas limit should therefore be changed to be a hardcoded value that doesn't change other than by an update of the software itself, rather than being chosen by the block producers. Light clients and third party software should reject any tx or any block that attempts to use gas beyond this value.
To know what the value is, the settlement contracts need to be completed and (exhaustive-path) benchmarked first, so this issue is in part blocked by that effort, although the scaffolding to change the limit to versioned config rather than by block producer vote is orthogonal and can be worked on in paralle.
The text was updated successfully, but these errors were encountered:
The settlement hub will require single round fraud proofs, which should eventually be implemented by making some modifications to the block production and EVM to allow for calculation and insertion of ISRs every N distinct state accesses.
For an initial implementation however it's possible to simulate this functionality, given a known set of deployed contracts, by limiting the block gas limit such that no single tx can exceed the N dynamic state accesses limit (contract calls not included given that they are fixed state in the hub).
The block gas limit should therefore be changed to be a hardcoded value that doesn't change other than by an update of the software itself, rather than being chosen by the block producers. Light clients and third party software should reject any tx or any block that attempts to use gas beyond this value.
To know what the value is, the settlement contracts need to be completed and (exhaustive-path) benchmarked first, so this issue is in part blocked by that effort, although the scaffolding to change the limit to versioned config rather than by block producer vote is orthogonal and can be worked on in paralle.
The text was updated successfully, but these errors were encountered: