Migrate sig hasher to vyper LLL about casper HOT 5 OPEN

Note, this was previously pointing to the wrong contract. The link has been updated to the correct contract.

from casper.

Since vyper does not support inline assembly, how can the assembly code like mstore be implemented in the vyper implementation?

from casper.

@hrishikeshio Vyper LLL rather than high level Vyper. LLL is an intermediary between vyper and bytecode.

from casper.

I'm going to follow up the purity checker migration with this migration -- anyone else working on it already?

from casper.

After looking at the options I'm thinking we do the following, taking into consideration that we want to stay w/in the domain of Vyper as much as possible...

Vyper already has a RLPDecode built-in which you can see in the example below. There is no RLPEncode but I'm electing to submit a PR for that to the Vyper repo in lieu of just porting MSG_HASHER here. This way we can drop msg_hash.se.py completely and just use the Vyper functions.

This is an example usage for the validate_vote_signature method in simple_casper.v.py.

Note, some of the syntax or function names may ultimately change -- this is just illustrative:

def validate_vote_signature(vote_msg: bytes[1024]) -> bool:
    # Decode RLP list
    values: tuple(uint256, bytes32, uint256, uint256, bytes) = RLPList(vote_msg, [uint256, bytes32, uint256, uint256, bytes])
    msg: tuple(uint256, bytes32, uint256, uint256)
    msg, _ = values
    new_msg: bytes = RLPEncode(msg, [uint256, bytes32, uint256, uint256])
    
    msg_hash: bytes32 = sha3(new_msg)
    validator_index: uint256 = values[0]
    sig: bytes[1024] = values[4]

    return self.validate_signature(msg_hash, sig, validator_index)

There are two caveats I can think of:

1. Waiting on integration and release of a new Vyper version w/ the required builtins will take some time, blocking this issue (and others that depend on it)

2. As long as the input data represented an RLP list, msg_hash.se.py allowed for any arbitrary RLP list elements by just walking the length data (if present) for each element. This approach will be less flexible as the required message format will have to be specified for the Vyper builtins to work. The Casper contract already commits to a specific message format so it doesn't seem like a problem but figured it was worth mentioning to consider before pursuing this approach.

Thoughts anyone?

from casper.