fix: api: Length check the array sent to RPC.

[parthshah1]

Related Issues

When calling eth_feeHistory, it takes input a rewardPercentile array. Currently, there isn't any restriction on the length of the array, can result in high computation and potentially leading to OOM issues in RPC nodes. The fix is to set a hard limit of the array to 100.

Proposed Changes

Changing the length of RewardPercentiles Array to upto 100.

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
• If the PR affects users (e.g., new feature, bug fix, system requirements change), update the CHANGELOG.md and add details to the UNRELEASED section.
• 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

[rvagg]

Seems reasonable, except that I don't know what a reasonable limit on this would be; geth doesn't appear to have one, at least when you get this deep: https://github.com/ethereum/go-ethereum/blob/c41105ce80f12f60ec4bf6c65c4c59c6bf4a86e7/eth/gasprice/feehistory.go#L200 and it event does an 8*len allocation at one point. Maybe there's a total params limit size, which I guess would be appropriate for us too if we don't have one.

[parthshah1]

@rvagg. I had a discussion about the limits with @Stebalien, that maybe 100 would be reasonable number since one would not need more than that to calculate the eth_feehistory. It also aims to solve computation issues this might cause with huge arrays.

it event does an 8*len allocation at one point. Maybe there's a total params limit size, which I guess would be appropriate for us too if we don't have one.

I was not aware of such a case in geth. I am not too expert in this area and how often, how much data it is expected to compute. I will agree to what you think should be right. Though, imo keeping the hard fix on the length won't harm.

[rvagg]

this seems fine to me, we can bump it up if there's a genuine request for more

[Stebalien]

Nits, but this looks correct.

[Stebalien]

Thank you! Sorry for all the nits.

One final thing: it looks like some of the lints are unhappy. I think you just need to run go fmt and fix some spelling.