-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Improve Eth JSON-RPC API handling of native messages #11355
Labels
Comments
2 tasks
So, an additional issue here is that we lookup addresses with an "empty tsk". That means we'll use whatever we consider to be our latest "head" instead of the state-tree after the message executed, and will fail (intermittently) on re-org. |
Stebalien
added a commit
that referenced
this issue
Nov 7, 2023
We need to always use the state-tree from the tipset _after_ the message executed. If we use any other state-tree, we might not find the address we're trying to resolve. This change also has some implication for pending messages: there's no guarantee we'll be able to generate a 0x-style address for a pending native message. So, instead of trying, I've removed support for pending native messages from the Eth API. Messages from EthAccounts will still work, and native messages will still show up in blocks/traces, they just won't show up as "pending". Which should affect exactly nobody. I'm also taking this opportunity to cleanup some edge-cases: 1. Pass contexts where appropriate. 2. Remove all state access from `ethTxHashFromSignedMessage`. Part of #11355
3 tasks
Stebalien
added a commit
that referenced
this issue
Nov 7, 2023
We need to always use the state-tree from the tipset _after_ the message executed. If we use any other state-tree, we might not find the address we're trying to resolve. This change also has some implication for pending messages: there's no guarantee we'll be able to generate a 0x-style address for a pending native message. So, instead of trying, I've removed support for pending native messages from the Eth API. Messages from EthAccounts will still work, and native messages will still show up in blocks/traces, they just won't show up as "pending". Which should affect exactly nobody. I'm also taking this opportunity to cleanup some edge-cases: 1. Pass contexts where appropriate. 2. Remove all state access from `ethTxHashFromSignedMessage`. Part of #11355
12 tasks
Stebalien
added a commit
that referenced
this issue
Nov 17, 2023
We need to always use the state-tree from the tipset _after_ the message executed. If we use any other state-tree, we might not find the address we're trying to resolve. This change also has some implication for pending messages: there's no guarantee we'll be able to generate a 0x-style address for a pending native message. So, instead of trying, I've removed support for pending native messages from the Eth API. Messages from EthAccounts will still work, and native messages will still show up in blocks/traces, they just won't show up as "pending". Which should affect exactly nobody. I'm also taking this opportunity to cleanup some edge-cases: 1. Pass contexts where appropriate. 2. Remove all state access from `ethTxHashFromSignedMessage`. Part of #11355
Stebalien
added a commit
that referenced
this issue
Nov 17, 2023
We need to always use the state-tree from the tipset _after_ the message executed. If we use any other state-tree, we might not find the address we're trying to resolve. This change also has some implication for pending messages: there's no guarantee we'll be able to generate a 0x-style address for a pending native message. So, instead of trying, I've removed support for pending native messages from the Eth API. Messages from EthAccounts will still work, and native messages will still show up in blocks/traces, they just won't show up as "pending". Which should affect exactly nobody. I'm also taking this opportunity to cleanup some edge-cases: 1. Pass contexts where appropriate. 2. Remove all state access from `ethTxHashFromSignedMessage`. Part of #11355
Stebalien
added a commit
that referenced
this issue
Nov 17, 2023
When translating "native" messages to Ethereum transactions, correctly handle parameters: 1. If the message looks like a valid "create external", treat it as a contract creation. 2. If it looks like a valid EVM invocation, decode it as such. 3. Otherwise, ABI-encode the parameters to make them look like a "handle_filecoin_method" call. This will help chain explorers recognize these messages. Part of #11355
8 tasks
8 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
E.g., code like
lotus/node/impl/full/eth_utils.go
Lines 483 to 499 in 6e22c08
Right now, we:
Instead, we need to:
lotus/node/impl/full/eth_trace.go
Lines 293 to 353 in 6e22c08
The text was updated successfully, but these errors were encountered: