Test - Sofia 01

NEAR Chain Signatures enables signing and executing transactions across multiple blockchain protocols. The technology relies heavily on threshold cryptography, using signature schemes such as ECDSA and EdDSA. This blog post explores how newly integrated schemes can help scale our systems, demonstrating their impact through practical benchmarking techniques and results.

Threshold signing allows multiple parties, each holding a secret key share, to jointly compute a signature over a specific message. Such a technology guarantees cryptographically the possibility of generating valid signatures if and only if at least 𝑡 participants actively take part in the signing process, where 𝑡 is the system’s threshold parameter. In other words, any 𝑡 −1 malicious parties would fail to generate a valid signature without the inclusion of one honest signer.

Our system maintains a pool of eight signers. For each protocol instance, a subset of five signers is selected to participate, and operations require approval from all five participants (i.e., a 5-of-5 configuration). As we scale, we plan to increase the total number of available signers while preserving strong security guarantees and high performance.

A preliminary performance assessment revealed that the primary bottlenecks stem from the complexity of our deployed ECDSA scheme (based on Cait-Sith implementation), which we refer to as OT-Based ECDSA. This protocol requires more than eleven computation-heavy communication rounds and exhibits quadratic communication overhead with respect to the number of active participants. We split this scheme (as well as all other schemes) into two phases: an offline phase and an online phase. The offline phase is a precomputation stage that occurs before the message is known to the protocol participants. During this phase, participants collaboratively generate cryptographic assets that will be needed in the online phase. Once the message becomes known to the signers, the online phase begins, and signatures can be produced and delivered with minimal delay, since all necessary computations have already been performed in advance. In this blog post, all the schemes mentioned require a presigning protocol (Presign), which is part of the offline phase, and a signing protocol (Sign), which belongs to the online phase. Additionally, the OT-Based ECDSA scheme requires a Two Triple Generation protocol during the offline phase, which must be executed before the presigning protocol.

To address the OT-Based ECDSA performance limitations, we implemented and evaluated a more efficient ECDSA construction based on [DJNPO20], which we refer to as Robust ECDSA. To quantify the expected improvements, we developed a dedicated benchmarking methodology.

This blog post presents our approach, assumptions, and findings and shows results for the OT-Based ECDSA, Robust ECDSA and (for completeness) our EdDSA implementation based on FROST [KG20].

Benchmarking

Prior to this work, we had multiple threshold signature schemes implemented, but no systematic way to compare their practical performance. A key challenge in this setting is that these protocols are inherently distributed, yet benchmarking them on multiple machines is costly and difficult to control. As a result, our goal was to design benchmarking methodologies that run on a single machine while still providing results that are representative of real-world deployments.

To address this gap, we designed two benchmarking approaches based on Rust’s Criterion framework to measure computation time. To ensure a fair comparison between the implemented schemes, we evaluated them under a shared invariant: the security level, defined as the maximum number of malicious parties tolerated.

Importantly, for a fixed maximum number of malicious parties, different schemes may require different numbers of active participants. Our methodology accounts for this distinction, enabling an apples-to-apples comparison at an equivalent security level. Naturally, derandomizing our algorithms was a necessary precondition for producing consistent results, thereby improving the reliability of our benchmarks by eliminating protocol-induced randomness.

Our first approach measures the end-to-end execution time of each scheme by running all participants on a single machine. We refer to this as the naive technique. While straightforward and fast to implement, this method does not fully reflect realistic deployment conditions and may therefore produce results that are only partially representative. In the following section, we describe how this technique operates in practice and explain why we classify it as “naive.”

We then designed and implemented a more representative, advanced technique. This approach captures a snapshot of the communication during protocol execution and subsequently replays the protocol from the perspective of a single participant using the recorded data. By doing so, we are able to isolate and measure the per-participant computational cost, while still accounting for network latency and communication volume. The advantage of this approach is that it provides a more accurate approximation of real-world performance without requiring a fully distributed deployment for each benchmark run.

All benchmarks were executed on a laptop equipped with an AMD Ryzen 7 7730U processor with Radeon Graphics and 16 GB of RAM with a clock speed ranging between 3.2-4.3 GHz. Each experiment was run for a minimum of 15 iterations to ensure statistically meaningful results.