feat: types: apply a max length when decoding events

[arajasek]

Related Issues

A security report pointed out the unbounded allocation here, which could be problematic. In practice, this is not a problem, since we can trust the FVM not too return dangerously large data, which can in turn trust gas costs to not allow several GiBs of events.

Proposed Changes

Despite that, we might as well apply some limit here. I settled on 6 million, since it seems like a good theoretical limit, given that a single message can't use more than 10 Billion gas (block gas limit), and a single event must cost at least 1750 gas, leading to a theoretical max of 5.7 Million entries.

I'm happy to use something bigger or smaller, this number is only consensus critical for folks actually decoding events, which Lotus doesn't do by default.

Additional Info

Checklist

Before you mark the PR ready for review, please make sure that:

• Commits have a clear commit message.
• PR title is in the form of of <PR type>: <area>: <change being made>
  • example: fix: mempool: Introduce a cache for valid signatures
  • PR type: fix, feat, build, chore, ci, docs, perf, refactor, revert, style, test
  • area, e.g. api, chain, state, market, mempool, multisig, networking, paych, proving, sealing, wallet, deps
• New features have usage guidelines and / or documentation updates in
  • Lotus Documentation
  • Discussion Tutorials
• Tests exist for new functionality or change in behavior
• CI is green

[Stebalien]

Ok, so, this is the maximum number of events as emitted by the FVM when encoded as an array.

• The minimum gas is more like 14000 gas because that's the base cost of a syscall.
• However, the max gas we care about here is tipset gas which... doesn't theoretically have a max limit.

6M events per epoch is probably safe, but I'm inclined to simply move DecodeEvents into chain/vm/fvm.go and make it private. It's not designed external use, it's designed for passing data from the FVM to lotus.

[Kubuxu]

Another option would be to not pre-allocate a slice larger than N. If someone passes an enormous blob into there and gets, let's say, 30x expansion, it is bad but not as bad as passing a couple hundred bytes and OOMing.

[jennijuju]

Seems missing tests

[arajasek]

• However, the max gas we care about here is tipset gas which... doesn't theoretically have a max limit.

Wait, no it's not? These are the events emitted by a single message, which is bounded by block gas limit?

6M events per epoch is probably safe, but I'm inclined to simply move DecodeEvents into chain/vm/fvm.go and make it private. It's not designed external use, it's designed for passing data from the FVM to lotus.

Seems reasonable, gonna do that, that definitely derisks this from future danger. Okay if I keep the max limit anyway?

[arajasek]

Seems missing tests

fevm_events_test covers relevant cases, I think?

[Stebalien]

Wait, no it's not? These are the events emitted by a single message, which is bounded by block gas limit?

Uh, yes, nvm. You're right.

[Stebalien]

Okay if I keep the max limit anyway?

Only if we end up logging and dropping in that case, but even then I don't think it matters. Returning an error here will make nodes recording events halt.