-
Notifications
You must be signed in to change notification settings - Fork 138
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
JSON-RPC: Lower to call to a "send" if the target doesn't exist #1302
Comments
i feel like you might mean
|
Hows your walk. |
Not helpful (the walk, that is) |
I think we shouldn't replicate what we are doing in FEVM into FVM, and we should also not do what we are currently doing. It should be a user-space decision whether or not to do this auto method num translation at all. FVM as a system should really avoid transform messages as much as possible. Invoke with no params should either actually invoke the actor with params at the provided method or error, nothing else. This means that sends to things that don't exist will always fail with "no actor at address". Sends are explicit. I think this sort of behavior embedded in the system in general will cause edge cases to pop up later on. The complexity exists in EVM because it's an EVM complexity, but that should stay in tooling. |
This isn't about the FVM, but about the current MMVP account abstraction:
That's the kind of thing I'm trying to fix here, but I'm not sure if we can come up with a good fix. |
Ok, I'm voting to just drop this and keep the current logic. I.e., we don't support sending with parameters to a target contract that doesn't yet exist. cc @raulk |
@raulk @Stebalien Sooo...can we drop it? 🤞 |
Possible solution: Replace "placeholders". Currently, when sending to an f4 address, we automatically create a generic "placeholder" to store the funds. Instead, we could have the address manager register a code-cid that should be deployed on first send to an address.
Then, to deploy a contract and/or account, we'd "upgrade" said account into an EVM actor. The tricky parts here are:
|
An alternative is to reverse filecoin-project/FIPs#473 (comment) and make placeholders accept arbitrary methods (as in Ethereum). However, this has security implications around re-orgs. I.e.:
This is how Ethereum works but we'd rather not lock ourselves into the same bad design. There may be a middle-ground given that placeholders are only used by the EVM (for now), but it would be pretty hacky. |
This: 1. Always uses InvokeContract, never reducing to a method-0 value transfer. 2. Always encodes the parameters as a cbor byte array for simplicity. This removes _many_ edge cases and makes it possible to run contract logic with no parameters. Depends on filecoin-project/ref-fvm#1567 Fixes the issues outlined in filecoin-project/ref-fvm#1302
This: 1. Always uses InvokeContract, never reducing to a method-0 value transfer. 2. Always encodes the parameters as a cbor byte array for simplicity. This removes _many_ edge cases and makes it possible to run contract logic with no parameters. Depends on filecoin-project/ref-fvm#1567 Fixes the issues outlined in filecoin-project/ref-fvm#1302
We now always call with InvokeContract. |
Currently, we lower a call to send if the parameters are
non-empty. However:We should do what we're currently doing in FEVM and:
Or, at least, that's what we should do. Unfortunately, this impact signature validity, so I'm going to take a walk now and think about it.
The text was updated successfully, but these errors were encountered: