Closed ZenGround0 closed 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
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.
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
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.