Replies: 4 comments
-
@lrettig do you mean regular logs that are printed to stdout or something more sophisticated? The programs can already write to stdout by using the WRITE syscall with the stdout file descriptor. E.g, |
Beta Was this translation helpful? Give feedback.
-
No, something more sophisticated. I know the name "log" is misleading, but I'm envisioning something more like how logs/events work in EVM: https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378 EVM has opcodes for emitting logs, and they're actual data committed to the blockchain and that all nodes achieve consensus on. They're stored in a log trie that's part of the account state trie. We don't have to do the exact same thing, but at the very least we definitely want to support some kind of events that both user-facing applications, as well as backend infrastructure (e.g., explorers, data indexers) can subscribe to. |
Beta Was this translation helpful? Give feedback.
-
OK, so it's more like events. Are events specific to a program (e.g. every program can define a new kind of event only understandable by it)? We could support it by:
|
Beta Was this translation helpful? Give feedback.
-
yes, they're specific to a program, but we also want standards (like ERC-20) so, e.g., all token programs use the same log messages to make indexing easy. The more interesting question here isn't the opcode we use but how these data are surfaced to the application layer (which we probably need to handle on the go-sm side, e.g., via API changes) |
Beta Was this translation helpful? Give feedback.
-
We need EVM-style logs, i.e., a running program needs a way to log the fact that a particular event occurred (coins sent, program spawned, etc.).
Beta Was this translation helpful? Give feedback.
All reactions