Casper

Contract Discussion

1. Inconsistent between target_hash and target_epoch

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

2. 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.

3. Bug caused by Vyper implicit conversion

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

4. 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

Vyper compiler Discussion

1. Support for integer division

https://github.com/ethereum/vyper/issues/716

2. Improvement in shift function.

shift is compiled to the following code:

   ['if', ['sle', '_s', 0], 
          ['div', '_v', ['exp', 2, ['sub', 0, '_s']]], 
          ['mul', '_v', ['exp', 2, '_s']]]]],

When _s == 0, ['div', '_v', ['exp', 2, ['sub', 0, '_s']]] and ['mul', '_v', ['exp', 2, '_s']]]] are the same. But in the div branch, it need to execute sub which potentially costs more gas. Suggest using slt instead of sle. On the other hand, EIP145 proposes supporting shift opcode directly in EVM. Not sure when it will happen.

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 .