It's remarkable (if not surprising) that this comment exists in the Monero source, about caching the same kind of verification:
nostr:nevent1qqs8dxhek3h98d086mdzyz6lxerpz2vwctqkl63e5seq6xxpe4t530q...
A comment by Luke Parker (guy who's the main author of FCMP stuff) struck me on a PR to introduce such a verification cache:
"We could just serialize key images, and fix that issue. I suggested in #8707. The problem is how it's been pointed out there's yet another field with this behavior. I don't want to play cat and mouse forever. The TX's entire networked value, and the mix ring (via do_serialize and as tested by @jeffro256 ) is complete. **Considering this code disables almost every single line of meaningful TX validation code**, I'm not willing to settle for less anymore."
(emphasis mine).
"We could just serialize key images, and fix that issue. I suggested in #8707. The problem is how it's been pointed out there's yet another field with this behavior. I don't want to play cat and mouse forever. The TX's entire networked value, and the mix ring (via do_serialize and as tested by @jeffro256 ) is complete. **Considering this code disables almost every single line of meaningful TX validation code**, I'm not willing to settle for less anymore."
(emphasis mine).
1
