Open kacperzuk-neti opened 3 weeks ago
Hey, any comments on this? I'm happy to implement one of the alternatives if go-eth
is considered too unpopular.
Please feel free to submit a PR. I would suggest going with bindings and abi like https://github.com/filecoin-project/curio/pull/175/files#diff-61b9bc7f68d7a7b1b7e877b73f9e790e80e6884ffc438356bfee467e72a5c7dc to avoid too many dependencies.
Checklist
Ideas
.Boost component
What is the motivation behind this feature request? Is your feature request related to a problem? Please describe.
FIDL is working on smart contracts that would enforce some rules on how clients can use their datacap (for example, restrict to selected storage providers). This is implemented as EVM contracts that act as a Verified Client (contracts receive the DataCap) and the actual client has to call them to create DDO allocations. We expect that these contracts will become widely used.
Describe the solution you'd like
As we expect these contracts to be widely used, having support for them in boost will make clients' lives easier.
My proposal is to add a new option to
boost allocate
command:--evm-client-contract
. When the option is provided, instead of calling transfer method on datacap actor directly, it should invoke transfer method on the provided EVM contract. While parameters to the EVM contract are semantically the same, EVM contracts require different encoding.I plan on implementing this and submitting a PR to boost. Before I do that though, I'd like to get a green light for:
Describe alternatives you've considered
Instead of using
go-eth
for encoding, I've considered:geth
: https://geth.ethereum.org/docs/developers/dapp-developer/native-bindings#generating-bindings . That seems like an overkill for just 1 method in 1 contract.Additional context
Current implementation of the client contract: https://github.com/fidlabs/contract-metaallocator/blob/main/src/Client.sol#L59