Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrate sig hasher to vyper LLL #73

Open
djrtwo opened this issue Apr 5, 2018 · 5 comments
Open

Migrate sig hasher to vyper LLL #73

djrtwo opened this issue Apr 5, 2018 · 5 comments

Comments

@djrtwo
Copy link
Contributor

djrtwo commented Apr 5, 2018

Issue

Sig hasher is currently written in the deprecated Serpent. We should stop relying on Serpent compiler.

Proposed implementation

  • Migrate current sig hasher from serpent to vyper LLL
  • Port contract to this repo
  • Add sanity check testing to pytest build
  • Compile Purity Checker from source instead of using bytecode in the testing setup

Example Vyper LLL and compile techniques here https://github.com/ethereum/casper/blob/master/tests/utils/valcodes.py

@vbuterin vbuterin changed the title Migrate sig hasher to vyper Migrate sig hasher to vyper LLL Apr 8, 2018
@djrtwo
Copy link
Contributor Author

djrtwo commented Apr 19, 2018

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

@hrishikeshio
Copy link
Contributor

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

@djrtwo
Copy link
Contributor Author

djrtwo commented Apr 23, 2018

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

@ralexstokes
Copy link
Member

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

@ralexstokes
Copy link
Member

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants