Broken-Invariant-Evidence Tx

[rigelrozanski]

Rather than running all invariants on-chain (which will likely end up being quite computationally expensive), we could develop a simple tool for a full-node to run invariant checks and further submit evidence of a broken invariant to the chain, which would at that point force-halt the system.

• we could even provide an incentive for finding a broken invariant (however I don't think this requires an incentive, enough systems will just want to be running this no matter what)

[rigelrozanski]

CC @cwgoes

[cwgoes]

I think it might require an incentive, since the gas cost will be quite high, but given one this seems incentive-compatible, saves computation time, and could be safely kept around for a long time.

Great idea! I think we should strongly consider this pre-transfers.

[cwgoes]

cc @ValarDragon, also @gamarin2 - I think this might address much the same goals as the circuit breaker proposal, and is much simpler.

[cwgoes]

Only concern is if the invariants exceeded the block gas limit.

[rigelrozanski]

Yeah the block gas limit would have to be priced accordingly - otherwise it could potentially be a special type of authenticated transaction... for instance we could require something to be at stake to submit this transaction for which you would get slashed if it ended up not being an invariant.

[ValarDragon]

This is an awesome idea! I'm totally for this. At minimum we should refund the gas cost if an invariant was broken, but I think rewards on top are good.

These invariants should be itemized, i.e. it shouldn't be one "run all invariants" message, but instead a sub-listing of which invariant to run. (This can be implemented as a "run invariant" message type, followed by an invariant index) That just reduces gas cost.

I am opposed to increasing the block gas limit to accomodate this though. We should only do this for invariants that fit within the gas limit, and defer to the circuit breaker otherwise. (I am opposed to opening us up to attacks that slow down consensus despite paying the fair gas amount for that computation. (e.g. bogus long invariants))

I think the circuit breaker is still good, that is a more general solution. There would be no need for the circuit breaker if the invariants covered the space of all possible faults, but that just seems unlikely to ever be the case.

[ValarDragon]

Actually on second thought, I don't think this should ever halt, but should only defer to going into the circuit breaker state. The issue with halting is that the conditions for coming back online is always going to be a hard fork. (And therefore we either have to create a new genesis, which is massive and foregoes proofs of upgrade procedure due to IAVL, or create an upgrade script which directly modifies state, again a bit ... sketchy) We still get our social consensus tally on chain in the circuit breaker, which is quite nice.

[rigelrozanski]

hmm are you suggesting some kind of a pause state - which doesn't allow sends but governance is still active?

[ValarDragon]

Yeah! Thats essentially what the state in circuit breaker mode is AFAIU. Its not clear to me if fees should / block rewards should be enabled during this paused state. (I think thats a great name for it :))

[rigelrozanski]

cool! Yeah I'm really into the pause state - we could have the allowed functionality during the pause state be configurable at genesis

[jackzampolin]

cc @cwgoes Circut breaker?

[cwgoes]

Yes, this is quite excellent, we should implement it post-launch pre-transfers.

[rigelrozanski]

As a first instance of this implementation we could still have a halt state - once circuit breaker is implemented we can integrate the two together

[cwgoes]

As a first instance of this implementation we could still have a halt state - once circuit breaker is implemented we can integrate the two together

At the moment I think it is fine if the broken-invariant-tx just halts the chain (i.e. panics) if the invariants are broken.