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 QGB is currently designed around having the ability to slash individual validators on celestia, not unlike the normal non-quantum gravity module. This is not needed, and dramatically changes how the orchestrator and relayer should be designed. We should flesh out this design in an ADR that can be written in parallel with an implementation.
Currently, the orchestrator and relayer are piggybacking on the state required for slashing individual validators. The thinking was that since the state already had to exist for slashing, that the orchestrator would create that state by submitting their signed commitment transactions to Celestia, and then the relayer would relay that state directly to the evm chain of choice.
This is a very reasonable design, assuming that the state has to be there for slashing. However, the state does not have to be there for slashing, as we can rely entirely on hardforking, as it takes ⅔ of the voting power to update the contracts in the first place. If a malicious update occurs, then all the evidence needed for fraud proofs is posted on that evm chain. The one thing that we cannot slash using this model is downtime. If validators choose not to sign or send their txs to a relayer, then we have no way of punishing them other than shaming them twitter. This is not a bad thing imho, as shaming validators has proven effective in the past for other PoS networks, and it puts a lot less strain on the validators ensuring that every signature is perfect. If for some reason they accidentally sign the wrong commitment or double sign, then they don't get slashed.
The good news is that while we will have to ditch a bit of work done for the app-integration, most of the orchestrator and relayer code can be reused.
The new functionality will be in how the relayer and orchestrators communicate. This will have to be done in some p2p fashion, for the 0.1.0 (or whatever release), we can simply have the orchestrators send their signed commitents to some set of relayers via rpc. In the future, we could get fancier.
The text was updated successfully, but these errors were encountered:
evan-forbes
changed the title
Write ADR for QGB 1.0
Write ADR for QGB Relayer and Orchestrator 1.0
Apr 1, 2022
To update this, after two synchronous calls, we decided that we did actually want to slash individual validators for not signing, mainly to add to the liveness guarantees of the bridge. This requires the additional state that is introduced in the qgb-integration branch, mainly that signatures are posted on celestia. This means that we will not need an additional p2p network.
@sweexordious came up with the great idea of removing most, if not all, additional state after the unbonding period, as the signatures are not useful after that period of time.
The QGB is currently designed around having the ability to slash individual validators on celestia, not unlike the normal non-quantum gravity module. This is not needed, and dramatically changes how the orchestrator and relayer should be designed. We should flesh out this design in an ADR that can be written in parallel with an implementation.
Currently, the orchestrator and relayer are piggybacking on the state required for slashing individual validators. The thinking was that since the state already had to exist for slashing, that the orchestrator would create that state by submitting their signed commitment transactions to Celestia, and then the relayer would relay that state directly to the evm chain of choice.
This is a very reasonable design, assuming that the state has to be there for slashing. However, the state does not have to be there for slashing, as we can rely entirely on hardforking, as it takes ⅔ of the voting power to update the contracts in the first place. If a malicious update occurs, then all the evidence needed for fraud proofs is posted on that evm chain. The one thing that we cannot slash using this model is downtime. If validators choose not to sign or send their txs to a relayer, then we have no way of punishing them other than shaming them twitter. This is not a bad thing imho, as shaming validators has proven effective in the past for other PoS networks, and it puts a lot less strain on the validators ensuring that every signature is perfect. If for some reason they accidentally sign the wrong commitment or double sign, then they don't get slashed.
The good news is that while we will have to ditch a bit of work done for the app-integration, most of the orchestrator and relayer code can be reused.
The new functionality will be in how the relayer and orchestrators communicate. This will have to be done in some p2p fashion, for the 0.1.0 (or whatever release), we can simply have the orchestrators send their signed commitents to some set of relayers via rpc. In the future, we could get fancier.
The text was updated successfully, but these errors were encountered: