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.
- 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
- 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
- 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.
- The operator requests a checkpoint with Plasma block number and segment.
- 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.
- 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.blkNumbefore sign new checkpoint.
- The operator can finalize checkpoint after a period. This period is 3 times of exit period.
Checkpoint period is depends on the exit period. Checkpoint period should be greater than 3 times of exit period.
- 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
- 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|