mirror of
https://github.com/codex-storage/codex-research.git
synced 2025-02-10 01:33:26 +00:00
56 lines
2.7 KiB
Markdown
56 lines
2.7 KiB
Markdown
|
State Channel Disputes
|
||
|
|
======================
|
||
|
|
|
||
|
|
A problem with state channels is that participants have to remain "online"; they
|
||
|
|
need to keep an eye on latest state of the underlying blockchain and be able to
|
||
|
|
respond to any disputes about the final state of the state channel. Ironically
|
||
|
|
this problem stems from the mechanism that allows a state channel to be closed
|
||
|
|
when a participant goes offline. Closing a channel unilaterally is allowed, but
|
||
|
|
there is a period in which the other participant can dispute the final state of
|
||
|
|
the channel. Therefore participants should be monitoring the blockchain so that
|
||
|
|
they can respond during a dispute period.
|
||
|
|
|
||
|
|
### Pisa
|
||
|
|
|
||
|
|
https://www.cs.cornell.edu/~iddo/pisa.pdf
|
||
|
|
|
||
|
|
The PISA protocol enables a participant to outsource monitoring of the
|
||
|
|
underlying blockchain to an untrusted watchtower. The main idea is that a hash
|
||
|
|
of the latest state channel update is sent to the watchtower. The watchtower
|
||
|
|
responds with a signed promise to use this information to settle any disputes
|
||
|
|
that may arise. Should the watchtower fail to do so, then the signed promise can
|
||
|
|
be used as proof of negligence and it will lose its substantial collateral.
|
||
|
|
|
||
|
|
A potential problem with this scheme is that the collateral is shared among all
|
||
|
|
state channels that the watchtower is monitoring, which could lead to bribing
|
||
|
|
attacks.
|
||
|
|
|
||
|
|
### Brick
|
||
|
|
|
||
|
|
https://arxiv.org/pdf/1905.11360.pdf
|
||
|
|
|
||
|
|
The BRICK protocol provides an alternative to the dispute period based on
|
||
|
|
byzantine consistent broadcast. Participants in a state channel assign a
|
||
|
|
committee that is allowed to sign off on channel closing in case they are not
|
||
|
|
able to do so themselves. Instead of waiting for a period of time before
|
||
|
|
unilaterally closing the channel, with BRICK you wait for a threshold number of
|
||
|
|
committee members to confirm the latest state of the channel. This is much
|
||
|
|
faster.
|
||
|
|
|
||
|
|
Each state channel update contains a sequence number, which is signed by the
|
||
|
|
channel participants and sent to the committee members. For a channel to be
|
||
|
|
closed unilaterally, the BRICK smart contract requires a signed state update,
|
||
|
|
and signed sequence numbers provided by a majority of the committee. The highest
|
||
|
|
submitted sequence number should match the submitted state update. Committee
|
||
|
|
members that submit a lower sequence number lose the collateral that they
|
||
|
|
provided when the channel was opened.
|
||
|
|
|
||
|
|
A potential problem with the implementation of BRICK as outlined in the paper is
|
||
|
|
that the collateral scheme is vulnerable to sybil attacks; committee members can
|
||
|
|
attempt to steal their own collateral by providing proof of their own
|
||
|
|
wrongdoing.
|
||
|
|
|
||
|
|
Unilateral closing is also rather heavy on blockchain transactions; each
|
||
|
|
committee member has to separately perform a transaction on chain to supply
|
||
|
|
their sequence number.
|