The paper waits until page 2 to mention that their scheme would not help standard WebAssembly implementations at all: those implementations already eliminate all bounds checks using a virtual memory trick, so reducing the number of required bounds checks makes no difference.<p>However, it would help implementations that can't use the virtual memory trick, such as if they need to support a 64-bit WebAssembly address space, or run on a 32-bit host, or have a huge number of WebAssembly VMs in the same host process.<p>And if I understand their (extremely hard to read) graph correctly, the scheme reduces the bounds checking overhead in that case quite close to zero, which is pretty impressive.<p>On the other hand, any approach based on software bounds checking is ripe for speculative-execution attacks. Maybe that doesn't matter because in the browser it's a lost cause already?