-
Notifications
You must be signed in to change notification settings - Fork 170
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
FIP-0049 (actor events): align with implementation. #581
Conversation
FIPS/fip-0049.md
Outdated
## Simple Summary | ||
|
||
This FIP adds the ability for actors to emit externally observable events during | ||
execution. Events are fire-and-forget, and can be thought of as a side effect | ||
from execution. The payloads of events are self-describing objects signalling | ||
that some important circumstance, action or transition has ocurred. Actor events | ||
that some relevant circumstance, action or transition has ocurred. Actor events |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that some relevant circumstance, action or transition has ocurred. Actor events | |
that some relevant state transition has occurred. Actor events |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you please explain your suggestion here, @jennijuju? (Generally, for all other comments, please explain your suggestion unless it's a typo).
We do not want to limit actor events to state transitions only. For example, a forbidden action could not result in a state transition, but still be recorded as an event (e.g. TokenTransferDenied
).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAIK, (in etherum), any actions that cause a failed message execution will lead to all state changes to be reverted, including the events. (quick google verification, here)
We do not want to limit actor events to state transitions only. For example, a forbidden action could not result in a state transition,
In this example, according to the definition below: When an actor exits abnormally (exit code > 0), events emitted from that invocation and its transitive callee are discarded. Could you please provide an example that a forbidden action in actors that will result in an exit code =0 (successful execution?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still seeking for an explanation.
FIPS/fip-0049.md
Outdated
|
||
## Specification | ||
|
||
### New chain types | ||
|
||
We introduce a DAG-CBOR encoded `Event` type to represent an actor event. | ||
We introduce a DAG-CBOR encoded `StampedEvent` type to represent an actor event | ||
as committed on chain. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as committed on chain. | |
as emitted on chain. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, that's incorrect.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
elaborate why please? what is an committed event and whats an emitted event?
FIPS/fip-0049.md
Outdated
@@ -236,37 +253,18 @@ dynamic costs: | |||
> TODO need to make syscall gas dynamic based on param length |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
❗ todo is needed before moving to last call
FIPS/fip-0049.md
Outdated
[`filecoin-project/ref-fvm`], and its first adoption is within the EVM runtime | ||
actor under [`filecoin-project/builtin-actors`]. | ||
|
||
### Client handling |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you link a impl for indexing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not on master yet, so unsafe to link. I will add a PR link, but generally not happy doing that.
FIPS/fip-0049.md
Outdated
@@ -304,28 +336,75 @@ break some of their code. | |||
|
|||
## Test Cases | |||
|
|||
TODO. | |||
Refer to events test cases in the [reference | |||
implementation](https://github.com/filecoin-project/ref-fvm/blob/master/testing/integration/tests/events_test.rs). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
implementation](https://github.com/filecoin-project/ref-fvm/blob/master/testing/integration/tests/events_test.rs). | |
implementation](https://github.com/filecoin-project/ref-fvm/blob/master/testing/integration/tests/events_test.rs). [permalink](https://github.com/filecoin-project/ref-fvm/blob/d8f5d86f28ecd03a9934240134dae83a9754f72e/testing/integration/tests/events_test.rs) |
bfba6a4
to
c6302d3
Compare
Event { | ||
emitter: 1234, | ||
entries: [ | ||
(0x03, "t1", <32-byte array>), // CBOR major type 2 | ||
(0x03, "t2", <32-byte array>), // CBOR major type 2 | ||
(0x03, "t3", <32-byte array>), // CBOR major type 2 | ||
(0x03, "t4", <32-byte array>), // CBOR major type 2 | ||
(0x03, "p", <32-byte array>), // CBOR major type 2 | ||
], | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These keys are more compact since we'll be charging for bytes indexed, which includes keys.
@kaitlin-beegle - I'd like either @anorth or @arajasek to review this FIP before we move this DRAFT to LAST CALL, thanks! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good except:
- Gas cost parameters are still TODO
(0x01, "receiver", <id address>), | ||
(0x01, "token_id", <identifier>), | ||
entries: [ | ||
(0x01, "transfer", null), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: why is this inconsistent with the fungible token transfer using ("type", "transfer")?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added this example with a different key-value style to demonstrate a usage of the "index by key" flag. Since user code will pay per byte, I expect devs will come up with ways to produce compact event representations without information loss. On an abstract level, this follows this pattern for a schema:
{ "transfer": { "sender": 1111, "receiver": 2222, "token_id": "0x12345678" } }
As opposed to:
{ "type": "transfer", "sender": 1111, "receiver": 2222, "token_id": "0x12345678" }
FIPS/fip-0049.md
Outdated
Note that because the FVM does not write receipts to the blockstore, neither | ||
does it write the events AMT themselves. Doing so would result in a dangling | ||
write. Clients are responsible for managing event data as they wish, just like | ||
they're responsible for managing receipts. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The correctness of this is dubious. The VM might not write, but the node probably does, or certainly could, in order to support subsequent queries. I think this paragraph could just be dropped without loss.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Which part is incorrect? The FVM certainly does not write receipts, so writing the event AMTs would lead to a dangling write since they would be unreferenced unless the client writes the receipt.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Basically what this is saying is: "look client, you're responsible for managing receipts, and that includes events."
I lifted my |
@raulk ping us when you've pushed any final edits and I can merge (overriding branch protection) or @jennijuju can approve (necessary to unblock merging). |
5e8b4bc
to
2733c85
Compare
Mostly aligns FIP with the final implementation, adds a table of contents, product considerations. Missing gas costs.