Skip to content

Checkpoint

Shuhei Hiya edited this page Mar 31, 2019 · 10 revisions

This is the description of plasma checkpoint. The definition of the segment in our Plasma is tokenId, coin start and coin end.

At first, I was implementing signature bitmaps for segments, but it was too big because the max segment size is 2^48. So we use challengeTooOldExit function instead of State Merkle Tree.

In this construction, operator requests segment and block number as checkpoint instead of state merkle tree. The latest tx before requesting block number will be oldest valid transaction after checkpoint is finalized. Users can challenge checkpoint their latest tx before requesting checkpoint, and operator can respond by spending tx or user's signatures for checkpoint.

challengeTooOldExit

  1. We have a checkpoint. I describe the process of determining checkpoint later. The structure of checkpoint is this.
struct Checkpoint:
  owner: address
  blkNum: uint256
  # 8bytes tokenId, 8 bytes start, 8bytes end
  segment: uint256
  isAvailable: bool
  finalizeAt: uint256
  challengeCount: uint256
  1. We should define the newest transaction before this checkpoint.

RootChain contract define "the newest transaction before this checkpoint" here. https://github.com/cryptoeconomicslab/chamber-packages/blob/master/packages/chamber-contracts/contracts/RootChain.vy#L683

  1. If all exits before "the newest transaction before this checkpoint" can be challenged by this transaction. Thus, we don't need the history of the segment before "the newest transaction before this checkpoint".

I describe the checkpointing process.

  1. The operator requests a checkpoint with Plasma block number and segment.

https://github.com/cryptoeconomicslab/chamber-packages/blob/master/packages/chamber-contracts/contracts/library/Checkpoint.vy

  1. To avoid "mass-exit" scenario, one owner in the segment at requesting checkpoint can challenge this checkpoint request. To prove that owners really has the segment, they should succeed to exit their segment. Not all owners need to exit their segment, only one owner can challenge checkpoint.

https://github.com/cryptoeconomicslab/chamber-packages/blob/master/packages/chamber-contracts/contracts/library/Checkpoint.vy#L159

  1. The operator can respond challenge by "checkpoint signature" of segment owners. "checkpoint signature" includes information of the checkpoint. It is the evidence that segment owners allowed this checkpoint. Segment owners should check history from the previous checkpoint.blkNum to new checkpoint.blkNum before sign new checkpoint.

https://github.com/cryptoeconomicslab/chamber-packages/blob/master/packages/chamber-contracts/contracts/library/Checkpoint.vy#L181

  1. The operator can finalize checkpoint after a period. This period is 3 times of exit period.

https://github.com/cryptoeconomicslab/chamber-packages/blob/master/packages/chamber-contracts/contracts/library/Checkpoint.vy#L196

Evaluation

Checkpoint period is depends on the exit period. Checkpoint period should be greater than 3 times of exit period.

Preconditions

  • 1000 tps

leaves are 2^10. proof size is 32 + 41 * 10 = 442 bytes

History in a week per UTXO is 442 * 60 * 24 * 7 = 4,455,360 bytes.

  • Checkpoint will be finalized after checkpoint period.
  • Operator requests next checkpoint soon after finalized
exit period checkpoint period max history size per UTXO
1 weeks 3 weeks 27.6 Mbyte
2 weeks 6 weeks 55.2 Mbyte
4 weeks 12 weeks 110.4 Mbyte
You can’t perform that action at this time.