Shutterized Optimism: Performance Evaluation
High performance is one of the most critical features of modern rollups. Potential performance impacts are therefore one of the most common concerns when adopting new features. This includes threshold cryptography-based encrypted mempools such as Shutter, which promise to make rollups more fair, secure, and user-friendly.
In this report, we present measurements of a variety of performance metrics of Shutter’s key generation process. On this basis, we evaluate the impact Shutter might have on Optimism’s block production process. We hope that this provides a solid data basis, to aid in the decision-making process regarding whether a Shutter-based encrypted mempool should be adopted.
Threshold-Encrypted Mempools
For context and to simplify understanding of the following sections, we review how a Shutter-based encrypted mempool implemented on Optimism would work at a high level. In such a system, users would be able to encrypt their transactions and send them to the sequencer, presumed to be a centralized entity. The sequencer then commits to a transaction order, e.g., by sealing a block.
Upon observing the sealed block, a decentralized set of nodes, which we call the keyper network (typically consisting of between around five to fifty keypers), is tasked with generating the corresponding decryption keys. Participation of only a subset of nodes is required (the eponymous threshold, typically two-thirds of the total size), making the protocol resilient against individual failures. Nodes participate by first generating decryption key shares, which can then be aggregated to produce the decryption keys. With these keys, the block can finally be decrypted and executed.
Key Performance Metrics
The key performance metrics of interest that we analyze in this report are as follows.
-
Latency: The time that passes between a decryption key being requested and it being generated. The latency should be short because it determines how quickly a block can be executed and therefore when the next block can be built, limiting the maximum block interval.
-
Keyper failure rates: How often do keypers fail to participate in time, e.g., due to latency spikes? This rate should be low to ensure a high uptime and reliability of the chain.
-
Encryption and decryption speed: How long does it take to encrypt or decrypt transactions? This should be fast to guarantee strong usability, high synchronization speed, and low gas overhead.
-
Network load: How much additional traffic is generated? Decryption keys and shares constitute additional data that needs to be exchanged, in particular between keypers and the sequencer. This should be low to
Methodology
To measure the above-mentioned metrics, we employ two separate, complementary methods:
-
Laboratory benchmarks performed on consumer hardware (2021 MacBook Pro with an Apple M1 Pro chip and 32 GB RAM)
-
Observation of network traffic in the keyper network of Shutterized Gnosis chain
The latter represents a live production environment very similar to one that would be required for Shutterized Optimism. Where there are relevant differences (e.g. in regard to keyper set size and threshold), we extrapolate from the data.
Results
Figure 1: Cumulative Histogram of Key Arrival Times
Figure 1 shows the cumulative histogram of key arrival times measured in the Shutterized Gnosis Chain keyper network. It reveals that the majority of decryption keys are generated just over one second after the triggering event, with nearly all keys available within three seconds. The curve’s characteristic bump just before the 2-second mark is caused by suboptimal peer-to-peer message forwarding strategies. This suggests that adopting a more centralized or star-like network topology, which Optimism’s architecture would allow, could significantly reduce latency.
Additionally, in the Gnosis setup, keypers only begin releasing their keys once the corresponding block is observed, which itself must propagate through the network. This sequential dependency contributes further to latency. In contrast, an Optimism deployment, with its centralized sequencer, would reduce this additional delay. Moreover, for simplicity, key generation in Gnosis involves two broadcasting rounds (first for key shares, then for the aggregated key), whereas an Optimism-based system could aggregate directly at the sequencer. Combining these optimizations, we estimate that overall latency could be reduced by more than a factor of two in a Shutterized Optimism environment.
Figure 2: Benchmarks of Cryptographic Operations
Figure 2 sheds light on the cause of key generation latency. It shows laboratory benchmarks of the relevant cryptographic functions. The results indicate that key share generation, key share verification, and key verification each take less than 2 ms, rendering their contribution to overall latency negligible compared to typical network delays, which range from tens to hundreds of milliseconds. Key aggregation, which would be performed by the sequencer, requires slightly more time but still remains below 10 ms and is thus similarly insignificant in practice (note that this scales linearly with the size of the keyper set).
Encryption, carried out by users when preparing a transaction, takes roughly 1.5 ms, while decryption during block execution completes in under 1 ms. Although these values are notably higher than standard signature generation and verification times (typically 50–200 µs), they are still far from posing a significant bottleneck for users or block execution. Furthermore, decryption can be efficiently parallelized across transactions, and gas costs are primarily driven by state access and storage operations rather than CPU-bound computation in typical systems.
Figure 3: Key Sizes
Figure 3 shows sizes of encryption keys, decryption keys, and decryption key shares, which have to be propagated through the network. They are very small (48 bytes for decryption key and share, 96 bytes for encryption key), so they do not constitute a relevant infrastructure cost. Note that the diagram omits peer-to-peer message metadata such as sender and receiver information or contextual information such as block numbers, but this is only a constant overhead.
Figure 4: Estimated Key Generation Failure Rate by Keyper Set Size
Figure 5: Estimated Key Generation Failure Rate by Arrival Time Cutoff
Building on the key generation and propagation latencies presented above, Figures 4 and 5 extrapolate to larger keyper set sizes to evaluate the resilience of the system, expressed as the probability that a key fails to be generated before a specified cutoff time. At a constant threshold ratio of one-third, increasing the keyper set size decreases the failure rate, as keyper failures are assumed to be independent for this analysis. Even moderate keyper set sizes can reduce this probabilistic failure rate to a negligible level. A cutoff time of approximately 2 seconds yields a failure rate of about 1 in 100,000, while a 2.5-second cutoff reduces it further to around 1 in 10 million. Note also that, as discussed in Figure 1, overall latency is expected to be lower in an Optimism deployment than in the Gnosis deployment.
Conclusion
This report examined key performance metrics of Shutter’s key generation mechanism. We performed both laboratory benchmarks and real-world measurements in a production environment to estimate the potential performance cost of adopting it in Optimism. Overall, the findings suggest that the technology is suitable for adoption, particularly with Optimism-specific modifications such as a custom network topology.