A standard interface of tokens for layer 2 solutions which are minted by Casper PEPoW algorithm.
Abstract
The following standard is an extended version of ERC20 token for layer-2 solutions using Casper PEPoW. This token is minted by checkpoint proposing and validation to mitigate the data availability problem and provide economic incentives for the operators.
Casper PEPoW uses priority exponential proof of work for its checkpoint proposing rule and Casper FFG for its fork choice rule. In Casper PEPoW, checkpoint proposers are ordered dynamically and have their own difficulties in proposing a new checkpoint. Also, the difficulty of Proof of Work to propose a new checkpoint is exponential to the order of priority. Lastly, the Casper validation reward for a checkpoint is also exponential to its priority.
Moreover, to provide the main-net level security to the 2nd layer, unlike the vanilla Casper FFG, justified checkpoints can be reverted by the challenge system. Any checkpoint, which is justified, but not finalized yet, can get a challenge. If the challenge reverts the justified checkpoint, validators who voted to the checkpoint are all slashed. It makes the conflicting fork being able to be justified. Lastly, to finalize a checkpoint, all of its ancestor checkpoints should not be in dispute.
Motivation
When we run a layer 2 solution, the data availability problem is always a hot potato. Furthermore, the operators spend Ether for the gas costs to update the data from the 2nd layer to the 1st layer. To solve these problems, we need to make the operator set more decentralized to mitigate the data availability issue and also need to mint tokens to reward the decentralized operators.
Specification
pragma solidity>=0.4.21<0.6.0;
interfaceIERC1XXX /* isIERC20 */{
/** * @dev Push the message sender into the waiting list for the *d+2* dynasty * if the sender sends more than the designated minimum amount of ETH. * Later, it should allow ERC20 tokens instead of ETH. */function deposit() externalpayable;
/** * @dev Register the message sender to the exit queue for the *d+2* dynasty * if the validator set includes the message sender. */function requestWithdraw() external;
/** * @dev If there was no slash during its withdrawal delay period, * the message sender can withdraw the staked ETH. */function withdraw() external;
/** * @dev An operator can submit a checkpoint with proof of work. The difficulty of the * proof of work is exponential to the message sender's priority * which is decided by the parent checkpoint. */function propose(
bytes32_parent,
bytes32_state,
uint256_epochNum,
uint256_nonce
) external ;
/** * @dev Anyone can apply published vote messages by the validators. * The message is a byte array which length is 193 and it contains source hash, * target hash, source epoch number, target epoch number, and the signature. * kIt mints token as many as the checkpoint's priority and transfer them to the * voter. */function vote(bytescalldata_msg) external;
/** * @dev Several vote messages can be applied at once. */function batchVote(bytescalldata_msgArr) external;
/** * @dev Anyone can raise a challenge process staking a designated amount of bond. */function challenge(bytes32_checkpointHash) externalpayable;
/** * @dev Anyone can change the state of a checkpoint from submitted to justified * if it secures more than two third of the total stake. * The message sender gets rewarded with newly minted token. */function justify(bytes32_checkpointHash) external;
/** * @dev If a validator published double votes or surrond votes, * anyone can punish the validator and get rewards */function slash(bytescalldata_vote1, bytescalldata_vote2) external;
/** * @dev Returns whether the `validatorAddress` is validator or not */function isValidator(address_validatorAddress) externalviewreturns (bool);
/** * @dev Returns whether the validator with the address can withdraw its stake or not. * It returns true if the validator is never slashed and out of withdrawal delay * period. */function isWithdrawable(address_validatorAddress) externalviewreturns (bool);
/** * @dev Returns the difficulty of proposing a new child checkpoint for the `_parent` * value. * It differs by the proposer and the parent hash. */function difficultyOf(
bytes32_parent,
address_proposer
) externalviewreturns (uint256);
/** * @dev Returns the amount of reward for validation. It is exponentially proportional * to the priority of the checkpoint proposer. */function rewardFor(
bytes32_parent,
address_proposer
) externalviewreturns (uint256);
/** * @dev Returns the priority to propose a new checkpoint agaisnt the parent * checkpoint. */function priorityOf(bytes32_parent, address_proposer) externalviewreturns (uint8);
/** * @dev Returns whether the nonce value for the priority exponential proof of work is * correct or not. */function proofOfWork(
address_proposer,
bytes32_parent,
bytes32_state,
uint256_epochNum,
uint256_nonce
) externalviewreturns (bool);
event Deposit(
addressindexed_from,
uint256_startDynasty,
uint256_amount
); // amount: weievent Vote(
addressindexed_from,
bytes32indexed_targetHash,
uint256_targetEpoch,
uint256_sourceEpoch
);
event Logout(
addressindexed_from,
uint256_endDynasty
);
event Withdraw(
addressindexed_to,
uint256_amount
); // amount: weievent Slash(
addressindexed_from,
addressindexed_offender,
uint256indexed_offenderIndex,
uint256_bounty
); // bounty: wei event Epoch(
uint256indexed_number,
bytes32indexed_checkpointHash,
bool_isJustified,
bool_isChallenged,
bool_isFinalized
);
event Dynasty(
uint256indexed_number,
bytes32indexed_checkpointHash
);
}
The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (go-ethereum, parity, cpp-ethereum, ethereumj, ethereumjs, and others).
Rationale
First, applying a mechanism like Casper FFG to the layer 2 solutions is a good way to offer operators an economic incentive to participate in. And it makes the network more decentralized and resistant to the data unavailability. If we apply Casper FFG to the layer 2 solutions, anyone participates in the operator set without permission and gets rewarded for checkpoint proposing or validation. And if someone submits a checkpoint that does not provide enough data to others, the validators may choose another checkpoint.
Secondly, it is important to use the PEPoW algorithm to make the network more decentralized. PEPoW lets PoW still be useful to mitigate forking and back up the out of network problem with the only small amount of hash power. For example, even if a checkpoint proposer cut in the line by using an extra hash power, the checkpoint may not be chosen by the validators since it does not offer the best reward. As a result, it makes having an obsessive hash power pointless for users to operate a node. Therefore, many users can easily participate as an operator and naturally run their nodes with the standard amount of hash power.
Mechanism
Fig 1)
The first checkpoint is justified and finalized
c2-1 is the first submitted checkpoint, because of its low difficulty.
c2-1 is justified by the validators because it offers the highest reward, for isntance 64 tokens, while c2-2 offers only 16 tokens.
Fig 2)
The checkpoint 3-1 is not available. Soon after another proposer submitted the checkpoint c3-2 due to the unavailability.
Validators vote to c3-2 even it is the second priority.
As c3-2 is justified, Casper finalizes c2-1 and the dynasty becomes 2.
Fig 3)
c4-1 is submitted and justified, but its state transition is invalid.
Fig 4)
One of the operators challenges c4-1 due to the invalid state transition
Because c4-1 is justified, c4-2 is not able to be justified due to it is on the conflicting fork.
Fig 5)
The challenge succeeds and the justification for c4-1 is reverted.
As Casper reverts the justification, proposer and validators who voted to c4-1 gets slashed.
As the malicious operators are slashed, c4-2 becomes able to be justified.
Fig 6)
Any checkpoint can get challenged if it is not finalized.
Fig 7)
Even validators justify the direct child of a justified checkpoint, if there's an ancestor checkpoint in dispute, it does not finalize the parent checkpoint.
If c5-2 was not in dispute, c6-1 should be finalized.
Fig 8)
Defending a challenge does not affect the finalization of already submitted checkpoints.
Fig 9)
The checkpoint c7-2 is finalized by the justification of c8-1.
Postponed finalizations occur at once, so the dynasty becomes 7.
Backwards Compatibility
This standard does not include backward incompatibility. This is compatible with ERC20.
The text was updated successfully, but these errors were encountered:
wanseob
changed the title
ERC: Casper PEPoW Token Standard for Layer 2 Solutions
ERC-1913: Casper PEPoW Token Standard for Layer 2 Solutions
Apr 5, 2019
wanseob
changed the title
ERC-1913: Casper PEPoW Token Standard for Layer 2 Solutions
ERC: Casper PEPoW Token Standard for Layer 2 Solutions
Apr 5, 2019
There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.
This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.
eip: 1913
title: Casper PEPoW token for layer 2 solutions
author: Wanseob Lim (@wanseob)
discussions-to: #1913
status: Draft
type: Standards Track
category: ERC
created: 2019-04-05
Simple Summary
A standard interface of tokens for layer 2 solutions which are minted by Casper PEPoW algorithm.
Abstract
The following standard is an extended version of ERC20 token for layer-2 solutions using Casper PEPoW. This token is minted by checkpoint proposing and validation to mitigate the data availability problem and provide economic incentives for the operators.
Casper PEPoW uses priority exponential proof of work for its checkpoint proposing rule and Casper FFG for its fork choice rule. In Casper PEPoW, checkpoint proposers are ordered dynamically and have their own difficulties in proposing a new checkpoint. Also, the difficulty of Proof of Work to propose a new checkpoint is exponential to the order of priority. Lastly, the Casper validation reward for a checkpoint is also exponential to its priority.
Moreover, to provide the main-net level security to the 2nd layer, unlike the vanilla Casper FFG, justified checkpoints can be reverted by the challenge system. Any checkpoint, which is justified, but not finalized yet, can get a challenge. If the challenge reverts the justified checkpoint, validators who voted to the checkpoint are all slashed. It makes the conflicting fork being able to be justified. Lastly, to finalize a checkpoint, all of its ancestor checkpoints should not be in dispute.
Motivation
When we run a layer 2 solution, the data availability problem is always a hot potato. Furthermore, the operators spend Ether for the gas costs to update the data from the 2nd layer to the 1st layer. To solve these problems, we need to make the operator set more decentralized to mitigate the data availability issue and also need to mint tokens to reward the decentralized operators.
Specification
The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (go-ethereum, parity, cpp-ethereum, ethereumj, ethereumjs, and others).
Rationale
First, applying a mechanism like Casper FFG to the layer 2 solutions is a good way to offer operators an economic incentive to participate in. And it makes the network more decentralized and resistant to the data unavailability. If we apply Casper FFG to the layer 2 solutions, anyone participates in the operator set without permission and gets rewarded for checkpoint proposing or validation. And if someone submits a checkpoint that does not provide enough data to others, the validators may choose another checkpoint.
Secondly, it is important to use the PEPoW algorithm to make the network more decentralized. PEPoW lets PoW still be useful to mitigate forking and back up the out of network problem with the only small amount of hash power. For example, even if a checkpoint proposer cut in the line by using an extra hash power, the checkpoint may not be chosen by the validators since it does not offer the best reward. As a result, it makes having an obsessive hash power pointless for users to operate a node. Therefore, many users can easily participate as an operator and naturally run their nodes with the standard amount of hash power.
Mechanism
Fig 7)
Fig 8)
Fig 9)
Backwards Compatibility
This standard does not include backward incompatibility. This is compatible with ERC20.
Test Cases
[WIP]https://github.com/wanseob/casper-pepow-token/blob/master/test/CasperToken.test.js
Implementation
[WIP]https://github.com/wanseob/casper-pepow-token
Copyright
Copyright and related rights waived via CC0.
References
Related works
The text was updated successfully, but these errors were encountered: