Eight is great

[EndymionJkb]

Description

We reduced the maximum token count from 8 to 4 for v3, mainly because we thought we could optimize performance better this way, and because we didn't think there were many compelling use cases for more than 4 tokens. Even in v3, we expect the overwhelming majority of pools to be 2-token, but there have been enough inquiries from partners that we'd like to revisit this decision.

In earlier incarnations of the Vault, this would have been a lot harder. We've since refactored such that most data structures are mappings, and everything fits into single slots. At this point it was actually quite easy - actually trivial - to go up to 8 tokens; the only resizing was adding 16 bits to the pool config.

It's an open question whether we should extend our standard pools. I think there's a good case to raise stable pools to 5, as they were in v2 (this limit was imposed by the math), but we could either raise weighted pools to 8, or leave them at 4. (Custom pools could trivially add up to 4 more.)

Type of change

• [ ] Bug fix
• [X] New feature
• [ ] Breaking change
• [ ] Dependency changes
• [ ] Code refactor / cleanup
• [ ] Optimization: [ ] gas / [ ] bytecode
• [ ] Documentation or wording changes
• [ ] Other

Checklist:

• [X] The diff is legible and has no extraneous changes
• [ ] Complex code has been commented, including external interfaces
• [ ] Tests have 100% code coverage
• [X] The base branch is either main, or there's a description of how to merge

Issue Resolution

Closes #780

[danielmkm]

Great work @EndymionJkb, crazy how small the diff is here.

[EndymionJkb]

Great work @EndymionJkb, crazy how small the diff is here.

That was one of Nico's mantras: well-designed code should be easy to change.

If there are undocumented assumptions all over the place (which we want multiple reviews to check for), such that you need to make lots of unrelated changes, that's a sign of brittle code and fragile design.