the tram architecture is optimistic, meaning we run our state update processes in parallel to block validation. If the block dumps out, the tram manager coordinates restarting the components, which 'rollback' any updates by opening the respective dbs at the previous chain head state.
given this optimistic assumption, we should support a fallback mode, to handle DOS attacks where we may be flooded with bad blocks. I'm wondering if we can selectively run some critical block validations (or maybe the full sensor suite) before passing the block to the conductor/engine in these cases...
Also worth investigating the limits of validator punishments- for example, will a validator be punished for producing multiple, valid blocks during a given timeslot? I don't think there is a punishment for this (might fall under validator 'effort' voting)
DOS vs Optimistic operating modes...
the tram architecture is optimistic, meaning we run our state update processes in parallel to block validation. If the block dumps out, the tram manager coordinates restarting the components, which 'rollback' any updates by opening the respective dbs at the previous chain head state.
given this optimistic assumption, we should support a fallback mode, to handle DOS attacks where we may be flooded with bad blocks. I'm wondering if we can selectively run some critical block validations (or maybe the full sensor suite) before passing the block to the conductor/engine in these cases...
Also worth investigating the limits of validator punishments- for example, will a validator be punished for producing multiple, valid blocks during a given timeslot? I don't think there is a punishment for this (might fall under validator 'effort' voting)
DOS vs Optimistic operating modes...