Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Submit feedback
Contribute to GitLab
Sign in
Toggle navigation
N
nebula
Project
Project
Details
Activity
Releases
Cycle Analytics
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Charts
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Charts
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Charts
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
exchain
nebula
Commits
b31146ac
Commit
b31146ac
authored
Apr 05, 2023
by
clabby
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Add `dispute-game.md` to this PR
parent
cc0e020c
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
73 additions
and
0 deletions
+73
-0
dispute-game.md
specs/dispute-game.md
+73
-0
No files found.
specs/dispute-game.md
0 → 100644
View file @
b31146ac
# Dispute Game
<!-- START doctoc generated TOC please keep comment here to allow auto update -->
<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
**Table of Contents**
-
[
Attestation Dispute Game
](
#attestation-dispute-game
)
-
[
Smart Contract Implementation
](
#smart-contract-implementation
)
-
[
Attestation Structure
](
#attestation-structure
)
-
[
Why EIP-712
](
#why-eip-712
)
-
[
Offchain Actor
](
#offchain-actor
)
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
## Attestation Dispute Game
The attestation based dispute game is meant to be a dispute game based on social consensus that
can progressively decentralize over time with larger participant sets. When submitting an output
proposal is permissionless, a social quorum can be used to revert "invalid" output proposals.
A set of attestors is maintained and
[
EIP-712
](
https://eips.ethereum.org/EIPS/eip-712
)
signatures
over canonical output roots can be used as attestations.
### Smart Contract Implementation
The
`AttestationDisputeGame`
should implement the dispute game interface and also be able to call
out to the disputable interface. It is expected that a contract that implements the disputable
interface will have permissions such that the
`AttestationDisputeGame`
has rights to alter its state.
The
`AttestationDisputeGame`
should be configured with a quorum ratio at deploy time. It should also
maintain a set of attestor accounts. The ability to add and remove attestor accounts should be
enabled by a single immutable account. It should be impossible to remove accounts such that quorum
is not able to be reached. It is ok to allow accounts to be added or removed in the middle of an
open challenge.
A challenge is opened when an EIP-712 based attestation is presented to the contract and the signer
is in the set of attestors. Multiple challenges should be able to run in parallel.
For simplicity, the
`AttestationDisputeGame`
does not need to track what output proposals are
committed to as part of the attestations, it only needs to check that the attested value is
different than the proposed value. If this is not checked, then it will be possible to remove
outputs that are in agreement with the attestations and create a griefing vector.
#### Attestation Structure
The EIP-712
[
typeHash
](
https://eips.ethereum.org/EIPS/eip-712#rationale-for-typehash
)
should be
defined as the following:
```
solidity
TYPE_HASH = keccak256("Dispute(bytes32 outputRoot,uint256 l2BlockNumber)");
```
### Why EIP-712
It is important to use EIP-712 to decouple the originator of the transaction and the attestor. This
will allow a decentralized network of attestors that serve attestations to bots that are responsible
for ensuring that all output proposals submitted to the network will not allow for malicious withdrawals
from the bridge.
It is important to have replay protection to ensure that attestations cannot be used more than once.
### Offchain Actor
The offchain actor should be able to custody an attestation key as well as a transaction signing key.
The offchain actor is expected to watch for each output proposal that is submitted to the
`L2OutputOracle`
and then check the value against the value returned from a trusted RPC endpoint.
If the trusted value does not match what was submitted to the chain, the actor is expected to submit
an EIP-712 signature to the
`AttestationDisputeGame`
contract. After a quorum of signatures are sent
to the contract, the
`AttestationDisputeGame`
will call the
`L2OutputOracle`
and remove the
malicious output proposal.
Longer term, the actor should be capible of calling out to an "Attestation API", so that it will no
longer be responsible for custodying the attestation key itself and instead can rely on public
infrastructure to get attestations.
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment