This document describes GitKarma, a system for allowing users to vote for contributions on GitHub each day to prevent self-mining. It then discusses Merklux, a proposed framework combining Merkle trees and Flux patterns for building scalable blockchains. Merklux would allow deploying reducer smart contracts to handle state transitions and dispatching actions. Casper PEPoW is also proposed as a finality gadget using priority exponential proof of work to secure layer 2 solutions like plasma chains by rewarding validators. The document outlines some challenges around invalid transitions, data availability, and network failures that the system aims to address.

1. GitKarma
1 vote a day

6. Vote for any kind of contribution
activities on Github

7. To prevent self-mining
http://i.imgur.com/O40kROE.gif

8. To prevent self-mining
1 vote a day

9. To prevent self-mining
blooooooooomfilter

10. Layer 2!

11. Item structure
Activity ID (bytes32)
Bloom Filter (uint256) Token(uint32)
817,232
Owner(address: bytes20)
0xabcd1234abcd1234...
Value
56 bytes
Key
32 bytes

12. Merkle tree on plasma chain
root node

13. Merkle tree on plasma chain
node node
root node

14. Plasma chain
Finalization with Casper FFG
node node
root node
Main chain
checkpoint 1

15. Plasma chain
Merkle tree on plasma chain
node node
root node
Main chain
checkpoint 2checkpoint 1
Justified!

16. Plasma chain
Merkle tree on plasma chain
node node
root node
Main chain
checkpoint 3checkpoint 2checkpoint 1
Finalized!

17. Plasma chain
Merkle tree on plasma chain
node node
root node
Main chain
checkpoint 3checkpoint 2checkpoint 1
Finalized!

18. Plasma chain
Merkle tree on plasma chain
node node
root node
Main chain
checkpoint 3checkpoint 2checkpoint 1
Finalized!

19. Merklux & Casper PEPoW
https://github.com/wanseob/merklux
https://github.com/ethereum/EIPs/issues/1913
https://ethresear.ch/t/merklux-plasma-plant/4050/11

20. Future usage

23. but...

24. Flux pattern

25. Merkle tree + Flux pattern = Merklux

26. Reducer for Redux

27. Reducer for Merklux

28. Deploying of a reducer
Reducer’s source code
contract Transfer… {
...
}
Reducer’s bytecode
0x00000000000000011111111
1000001111111111111000000
0000000000011111111111111
Hash of the byte code
abc1230a...
Registry
Hash of the byte code Address of deployed reducer
Reducer map in Merkle tree
Action name Reducer Code
abc1230a... 123321..
TRANSFER abc1230a...

29. Deploying of a reducer
Reducer’s source code
contract SaveReducer.. {
...
}
Reducer’s bytecode
0x11111111110000000011111
1111101111111111100000000
01111111111111110000000...
Hash of the byte code
ddbccad1...
Registry
Hash of the byte code Address of deployed reducer
Reducer map in Merkle tree
Action name Reducer Code
SAVE ddbccad1...
ddbccad1... ac23bd..
abc1230a... 123321..
TRANSFER abc1230a...

30. Dispatching an action
Registry
Hash of the byte code Address of deployed reducer
Reducer map in Merkle tree
Action name Reducer Code
SAVE ddbccad1...
ddbccad1... ac23bd..
abc1230a... 123321..
TRANSFER abc1230a...
abc1230a... 123321..
TRANSFER abc1230a... 123321..
Transfer
Reducer
prev state
Action
name:
TRANSFER
params:
(amount)
100
(to)
0xabcd...
parameters
0x100abc..
next state
Action
name:
TRANSFER
params:
(amount)
100
(to)
0xabcd...

31. Plasma chain Root chain
Reproducing the state transitions on another chain
state 100
state 200
checkpoint 0 (state 100)
checkpoint 1 (state 200)

32. Root chain
Reproducing the state transitions on another chain
oint 0 (state 100)
oint 1 (state 200) ��
state 100
state 200?
Registry
Hash of the byte code
Address of deployed
reducer
Reducer map in Merkle tree
Action name Reducer Code
SAVE ddbccad1...
ddbccad1... a091f82..
abc1230a... 612cd2..
TRANSFER abc1230a...
Action
name:
TRANSFER
params:
(amount)
100
(to)
0xabcd...
Action
name:
TRANSFER
params:
(amount)
100
(to)
0xabcd...

33. Root chain
Reproducing the state transitions on another chain
state 100
state 200?

34. Cross-state items
Plasma state tree
(Plasma chain)
key1
val1 val1
key2 key3
val1 0x1a..
ANCHOR
Anchor state tree
(Root chain)
key1
val1 val1
key2 key3
val1 0xcd..
PLASMA
0xcd..0x1a..
Plasma cross-state
in the anchor contract
Anchor cross-state in the
plasma contract

35. Epoch 1
Plasma state tree
0 0 0 0x10..
ANCHOR
0xc1..
Epoch 2
Plasma state tree
1 1 2 0x10..
ANCHOR
0xc2..
Epoch 3
Plasma state tree
3 4 2 0x10..
ANCHOR
0xc3..
Epoch 4
Plasma state tree
1 3 4 0x13..
ANCHOR
0xc4..
Dynasty 1
Anchor state tree
0 0 0 0x00..
PLASMA
0x10..
0 0 1 0x00..
PLASMA
0x11..
Dynasty 1
Anchor state tree
0 0 2 0x00..
PLASMA
0x12..
Dynasty 2
Anchor state tree
0 1 2 0xc1..
PLASMA
0x13..
0xc1.. 0xc1..
0xc2..
0xc1..
0xc2..
justified
0xc3..
finalized
justified
submitted
submitted
submitted
Dynasty 3
Anchor state tree
0 2 3 0xc2..
PLASMA
0x17..
0xc1..
0xc2..
0xc3..
finalized
justified
Epoch 5
Plasma state tree
5 6 7 0x17..
ANCHOR
0xc5..
0x10..
Anchor checkpoint
0x10.. 0x10.. 0x13.. 0x17..
0xc4..
submitted
finalized
MerkluxAnchor(Root chain)
MerkluxPlasma(Child chain)Pulling anchor state
Merge request
Anchor checkpoint Anchor checkpoint Anchor checkpoint Anchor checkpoint
Dynasty 1
Anchor state tree
Plasma
checkpoints
Plasma
checkpoints
Plasma
checkpoints
Plasma
checkpoints

36. Casper PEPoW

37. Finality Gadget for Layer 2

38. Proposing rule:
Priority Exponential PoW

39. Fork choice rule:
Casper FFG

40. Gives the validation reward by minting token to the layer-2 validators
To provide the main-net level security to the 2nd layer, unlike the Casper FFG,
justified checkpoints can be reverted by the challenge system.
Checkpoint proposers are ordered dynamically and have their own difficulties to
propose a new checkpoint
Difficulty of Proof of Work to propose a new checkpoint is exponential to the
order of priority
Casper validation reward for a checkpoint is also exponential to its priority
Differences with the Casper FFG

44. 1. Makes PoW still be useful to mitigate forking and out of network problem.
2. Helps the network be more decentralized with only a small amount of hash
power
3. Mitigates data availability problem
Why Casper PEPoW matters

45. Root chain
Stream request
Stream function
finalized
checkpoint 1 (state 200)
3cadb129c...
checkpoint 2 (state 100)
finalized
checkpoint 0 (state 100)
merkle
proof
merkle
proof
Value
Key
?

46. Root chain
Stream request
Stream function
3cadb129c...
merkle
proof
merkle
proof
Value
Key
?

47. Challenges - 1. Invalid state transition
When Validators justify an invalid checkpoint
1. User can make a challenge with bond
2. Anyone who can be slashed can proceed own verification process for the
challenge
3. If anyone succeed to defend, the bond goes to the defender
4. Or all validators who voted and the proposer get slashed

48. If operators do not provide Merkle proof for a stream request
1. Users can request to execute a stream function with a bond
a. If no operator submits the merkle proof data for a given time, the request gets through the
process. And the validators and the proposer of the checkpoint, get slashed.
b. If any operator submits a valid merkle proof data for the key, which is different with the
requested value, the user loses the bond.
Challenges - 2. Data unavailability

49. Challenges - 3. Failure in duty
The plasma network can be stuck when the operators do not submit a checkpoint
or do not publish vote messages.
1. If no one submits a new checkpoint for a given period
a. Any user can submit a checkpoint
b. Then to finalize the submitted checkpoint, the user runs the verification process which
means reenacting the state transition by submitting all dispatch history and referred
key-value items for the epoch
c. If the user succeeds to verify the submission, all registered validators get slashed, and the
user gets the entire stakes as a reward.
2. When the latest epoch is not justified for a given time
a. Anyone can open the verification process and justify it.
b. If this case occurs, the unvoted validators are all slashed, and the volunteer gets their stakes.

50. [WIP]Implementation
Merklux:
https://github.com/wanseob/merklux
ERC: Casper PEPoW Token Standard for Layer 2 Solutions
https://github.com/wanseob/casper-pepow-token
https://github.com/ethereum/EIPs/issues/1913