Skip to content

Casper

Jump to bottom
Daejun Park edited this page Apr 26, 2018 · 13 revisions

Contract Discussion

  1. Inconsistent between target_hash and target_epoch

https://github.com/ethereum/casper/issues/57

  1. validator_index or validators' signature checkers maybe different on different chains

It is OK because a validator has to wait two dynasties (two finalized blocks) to join a validator set, then the case in which he has two different identities for the same ether deposit would mean that there were two different finalized blocks (competing forks) and some previous validators were slashed. In such a case, the community is expected to either choose a chain to rally behind or simply both chains continue to exist (like eth/eth-classic) in which the people not at fault continue to have funds on both.

  1. Bug caused by Vyper implicit conversion

https://github.com/ethereum/casper/issues/67

  1. Validation code

Q. Is it possible to run the validation code inside the casper contract? The validation code seems to be straightforward (essentially calling the precompiled ECDSA recovery contract), and I think we can add the code (parameterized by the validator's address) inside the casper contract. If so, we don't need to worry about the integrity of the validation code (no purity_checker etc). What have I missed here? https://github.com/karlfloersch/pyethereum/blob/develop/ethereum/hybrid_casper/casper_utils.py#L57-L60

['calldatacopy', 0, 0, 128],
['call', 3000, 1, 0, 0, 128, 0, 32],
['mstore', 0, ['eq', ['mload', 0], utils.bytes_to_int(address)]],
['return', 0, 32]

A. The external validation code is inevitable to allow various different signature schemes to be used by different validators. So, there is a trade-off between security vs flexibility.

https://runtimeverification.slack.com/archives/C8GDD1K5Y/p1522868989000127

https://runtimeverification.slack.com/archives/C8GDD1K5Y/p1522870343000111

https://runtimeverification.slack.com/archives/C8GDD1K5Y/p1522871403000427

https://github.com/ethereum/casper/issues/74

https://github.com/ethereum/casper/issues/75

Daejun Park @danny.ryan You may already know this, but just in case. The epoch_length must be less than 256. Otherwise, recommended_target_hash will always throw, since the BLOCKHASH opcode returns 0 for a block number behind more than 256. You may want to add an assertion for that in __init__.

Danny Ryan ah, indeed. will add the assertion and a test case.

Issued and fixed: https://github.com/ethereum/casper/issues/83 https://github.com/ethereum/casper/pull/114

Vyper compiler Discussion

  1. https://github.com/ethereum/vyper/issues/775

  2. https://github.com/ethereum/vyper/issues/768

  3. https://github.com/ethereum/vyper/issues/767

Protocol Discussion

  1. accountable safety can be violated after many epochs without finalization (the "split network" case)

  2. plausible liveness can be violated when validators use a signature scheme where the private key is computable from three different signatures.

    • add a reasonalbe assumption
    • "no new signed message can be forged"
[2:55 PM] Yoichi Hirai (pirapira): I think plausible liveness requires some additional assumptions about the validators' signature scheme.  Let's say they use a weird signature scheme, where the private key is easily computable from three different signatures.  Then after 2/3 validators sign twice, they cannot make any progress without getting slashed.
[2:56 PM] Yoichi Hirai (pirapira): but assuming a specific signature scheme is too restrictive.
[2:58 PM] vbuterin: yeah, it does assume that the signature scheme satisfies standard security definitions and is otherwise not weird

To Do

  1. Checking no reentrance exploit .
Clone this wiki locally