ZenGround0 / onramp-contracts

Prototyping smart contracts piping data to the filecoin network
2 stars 5 forks source link

Use foundry cast for token constructions in deploy script #5

Closed ZenGround0 closed 4 months ago

ZenGround0 commented 4 months ago

lotus evm is not powerful enough to construct a contract with calldata OR call from delegated address since wallet isn't imported in a way for lotus to easily see, so simple ERC20s can't be set up right which blocks testing client.

To solve either problem we should just use foundry cast in deploy script against lotus rpc api and a keystore.

This also solves the problem of deploy scripts working on arbitrary eth api chains.

ZenGround0 commented 4 months ago

This is now sending raw tx to lotus but its not returning the created contract address like it should.

Getting these in lotus log which seems related:

    WARN    chainstore  store/messages.go:49    GetCMessage: unexpected error getting unsigned message: cbor input had wrong number of fields
    WARN    chainstore  store/messages.go:49    GetCMessage: unexpected error getting unsigned message: cbor input had wrong number of fields
ZenGround0 commented 4 months ago

Tracing this further:

I run cast send --create this is the standard way to create a contract with foundry tools afaik. Internally this uses alloy which is what has become of the rust ethers project. It sends a raw tx to lotus eth rpc api. The tx is addresses to 0x0000000000000000000000000000000000000000 which afaik is a correct thing to do for contract creation. Lotus however requires the To field to be nil to recognize a send to the eth zero address and tries to pass along the message as a filecoin invokeContract instead of as a createExternal . Lotus makes no attempt to parse 0x000… and turn it into nil. When I try to patch lotus to do this I get a signature validation error because the bytes being signed are different than those from packing nothing in the To field.

Looks like something lotus should just handle internally, checking sig against both nil and 0x000... options and being happy if one of them works.

ZenGround0 commented 4 months ago

The main issue appears to have been an out of date foundry setup. This now works which gets us a lot closer to #6 to as an added bonus