Achieving High Efficiency in Schnorr-Based Multi-Signature Applications in Blockchain

Round 1

Reviewer 1 Report

Comments and Suggestions for Authors

The manuscript presents a two-round Schnorr-based multi-signature scheme named MEMS that uses a Public Third Party (PTP) to resist k-sum. The authors provide formal security proofs under the discrete logarithm assumption in the random oracle model. Additionally they demonstrate the practical applicability of the scheme by integrating it with the Hyperledger Fabric. The paper is well-motivated and presents a novel and efficient solution for secure multi-signature schemes in blockchain environments.
However, while the use of the PTP is innovative and beneficial for reducing communication and computation overhead, the scheme assumes that the PTP operates reliably and without interruption. This assumption may not hold in real-world deployments, especially when the PTP is implemented as a smart contract, which can be vulnerable to network congestion, gas limitations, or denial-of-service (DoS) attacks. The manuscript does not address how the protocol handles PTP failures or delays, nor does it propose fallback mechanisms or fault-tolerance strategies. Given that the PTP serves as a central coordination point in the scheme, its robustness is critical to the overall reliability of the protocol. It is recommended that the authors expand their discussion to address these practical considerations.
In addition, the use of the term “maximum efficiency” both in the title and in the name of the proposed scheme may be too strong, as the paper does not provide a formal proof or lower-bound analysis to justify such an absolute claim. While the proposed scheme is clearly efficient and performs well compared to the existing work provided in the paper, the authors may consider softening this terminology (e.g., Highly Efficient) to more accurately reflect the scope and evidence presented.

Author Response

Please see the attachment.

Author Response File: Author Response.pdf

Reviewer 2 Report

Comments and Suggestions for Authors

1. Clarification on PTP Security Assumptions and Decentralization
The paper introduces a Public Third Party (PTP) as a critical component to prevent k-sum attacks. While the PTP is described as a publicly verifiable smart contract, the manuscript should more explicitly address how the integrity and security of the PTP are maintained in a decentralized blockchain environment. For example:

1. How does the PTP avoid becoming a single point of failure or a target for adversarial manipulation?
2. In permissioned blockchains such as Hyperledger Fabric, how does the PTP align with existing trust models (e.g., Certificate Authorities)?

A brief discussion of these points would significantly strengthen the security analysis and reassure readers of the scheme’s robustness in practice.

2. Experimental Setup Transparency
The performance evaluation notes that network delays were excluded from consideration. However, real-world blockchain deployments are subject to latency and synchronization overhead. To enhance reproducibility and realism:

1. Please clarify how the Go implementation simulates multi-signer interactions (e.g., were these executed locally or across distributed nodes?).
2. Specify whether the reported “signing time” includes only the cryptographic operations, or also message serialization/deserialization.
3. Evaluate the computational overhead of the PTP (e.g., managing commitments and timestamps), especially in scenarios involving thousands of signers.

3. Comparative Analysis of Security Assumptions

The manuscript highlights that MEMS relies on the Discrete Logarithm (DL) assumption, in contrast to schemes like MuSig2 and DWMS which rely on stronger assumptions such as the One-More Discrete Logarithm (OMDL). This is an important distinction, and the paper could be improved by:

1. Elaborating on how the inclusion of the PTP enables reliance on a weaker assumption (DL), and what trade-offs are involved.
2. Discussing any practical limitations of the DL-based approach, such as implications on group size or implementation overhead.
3. Comparing the trust model in MEMS (which involves a PTP) with schemes like MuSig2 that do not rely on third parties.

Suggested Revisions:

1. Expand the security model section to formalize the PTP’s role and the trust assumptions involved.
2. Add a subsection detailing the PTP's implementation in Fabric, including how it interacts with endorsers and maintains synchronization.
3. Enhance the experiments section with a sensitivity analysis that accounts for varying network conditions and potential PTP load.

Additional Concern:
It is important to note that the manuscript appears to have a high similarity rate (86%) with an existing paper published on arXiv, authored by the same individuals. The authors should clarify this point and ensure the submission complies with the journal’s originality standards.

Author Response

Please see the attachment.

Author Response File: Author Response.pdf

Reviewer 3 Report

Comments and Suggestions for Authors

This paper introduces a new variant of Schnorr-based multi-signature schemes, referred to as MEMS (Maximum Efficient Multi-Signature), designed to maximize efficiency without compromising security, particularly in defending against k-sum attacks. The core of the proposal is the introduction of a so-called Public Third Party (PTP), a transparent and automated entity—modeled after smart contract mechanisms—that participates in the signature generation phase.

The authors address a well-known issue in blockchain systems: the overhead of managing multiple signatures. Their solution, MEMS, leverages the PTP to coordinate the signing phase: each signer communicates solely with the PTP, which collects commitments, certifies their receipt, and generates a timestamp. This structure eliminates the need for direct signer-to-signer communication and effectively prevents manipulative behaviors such as k-sum attacks. The scheme’s security is proven under the random oracle model, and a practical implementation on Hyperledger Fabric is proposed, with promising experimental results.

 

Strengths

 

• Conceptual innovation: The introduction of a PTP represents an evolution from traditional Trusted Third Parties, adding benefits of public verifiability and decentralization.
• Communication efficiency: MEMS reduces communication overhead, requiring a linear number of messages ($n$) instead of the quadratic number ($n(n-1)$) typical of other schemes.
• Computational efficiency: With just one exponentiation per signature and two for verification, MEMS demonstrates strong performance.
• Resilience to k-sum attacks: By embedding the PTP’s timestamp into the joint commitment generation, the scheme effectively mitigates this type of attack.
• Theoretical and practical validation: The combination of formal proof and implementation in Fabric reinforces the feasibility and applicability of the proposed approach.

 

Critical Points and Suggested Improvements

 

1. PTP reliability: While the PTP is described as transparent and publicly verifiable, it remains a critical component. A more in-depth discussion of potential failure or compromise scenarios—even if implemented as a smart contract—would strengthen the security argument. This could include fallback mechanisms or mitigation strategies. The most appropriate place for such discussion would be after the operational description of the PTP, where a note on the assumptions regarding its integrity and trusted setup would naturally fit.

 

2. Dependence on the random oracle model: Although common in cryptographic proofs, reliance on the random oracle model introduces theoretical limitations. A brief discussion on the implications of this choice and potential paths toward a standard-model proof would enhance the completeness of the security analysis. Such a reflection could be added after the main theorem (Theorem 1), offering a nuanced view of the strength and boundaries of the presented proof.

 

3. Aggregation scalability: The linear cost of public key aggregation (n exponentiations), though justified by the use of the Plain Public-Key (PPK) model, could pose performance challenges in settings with a very large number of signers. A short note acknowledging this and referencing possible optimizations or hierarchical structuring would be informative. This would be best placed immediately following the performance comparison tables (Table 1 or 2), as a contextual caveat regarding system behavior under extreme conditions.

 

4. Technical implementation of the PTP: The conceptual description of the PTP is clear, but the paper would benefit from further technical details—perhaps a dedicated section or appendix—describing the concrete implementation of the PTP as a smart contract. This could include handling of input data, the structure for collecting commitments, timestamp generation, response dissemination, and even a schematic or pseudocode example. Such content would be especially helpful following the revised transaction process in Fabric (Figure 4), or alternatively as a final appendix with a code-level focus.

Author Response

Please see the attachment.

Author Response File: Author Response.pdf

Reviewer 4 Report

Comments and Suggestions for Authors

The paper proposes a multi signature scheme (MEMS) based on Schnorr signature, which introduces a common third party (PTP) to defend against k-sum attacks, and proves its security under a random oracle model. This method performs well in communication and computing efficiency, especially in blockchain application scenarios where it has practical significance.

But there are still some areas in the paper that need further improvement：

1、Although the design inspiration for PTP comes from the transparency and automation of smart contracts, the paper does not discuss in detail the security impact when PTP is attacked or maliciously controlled. If PTP is not trustworthy, the security of the entire solution may be threatened.
2、The depth of innovation is insufficient. Although PTP is a novel concept, its core idea is to utilize the characteristics of smart contracts, which is not a completely new idea in the field of blockchain. The paper needs to further demonstrate the unique contribution of PTP in multi signature schemes and its advantages over traditional trusted third parties (TTPs).

3、The paper mentions using PTP timestamps to prevent k-sum attacks, but does not provide a detailed analysis of whether manipulating or estimating timestamps by attackers would affect the security of the scheme.

4、The paper mentions the use of a random oracle model (ROM), but does not specify the specific parameter selection (such as group size, implementation of hash function, etc.), which may affect the actual security of the scheme.

5、Although the paper mentions that the verification process only requires two exponential operations, it does not discuss whether the verification efficiency will be affected by other factors such as network latency and computational resource limitations in large-scale signature scenarios.

6、The paper mentions the use of Go language to implement the scheme, but does not provide detailed information on the specific configuration of the experimental environment (such as hardware performance, network conditions, etc.), which may affect the reproducibility of the experimental results.

7、Have other schemes mentioned in the paper, such as mBCJ and MuSig2, been tested in the same experimental environment? If not, the comparison of experimental results may not be fair enough.

8、Although the paper mentions the application of MEMS on Fabric, it does not discuss whether the performance of MEMS will be affected in more complex blockchain networks such as high concurrency and large-scale nodes.

9、Some sentences appear lengthy, such as' the proposed scheme MEMS reduces the amount of communication connections that need to be established '; Some key terms, such as PTP and k-sum attacks, are not explained in detail in the main text, which may cause comprehension barriers for non professional readers; The format of some citations is not consistent, for example, some citations use numbering (such as [1]), while others directly state the author's name (such as Drijvers et al. [8]).

Author Response

Please see the attachment.

Author Response File: Author Response.pdf

Round 2

Reviewer 4 Report

Comments and Suggestions for Authors

The author has made sufficient and thorough revisions to the review comments. The article has made substantial improvements in terms of security discussion, emphasis on innovative contributions, explanation of timestamp security, clear parameter selection, supplementation of experimental environment, clarification of other schemes, and revision of terminology and format But there are still some issues that can be further explored, such as:
1. Although the author has added a discussion on the security of PTP, it mainly focuses on the countermeasures when PTP is attacked, and there is still a lack of in-depth analysis on the security of PTP itself. For example, it is not elaborated how PTP can resist network attacks in practical blockchain environments, and how it can ensure its transparency, public verifiability, and stability in various complex scenarios.
2. The verification mainly focuses on the computational cost of the signature and verification process, but does not conduct actual testing and analysis of the communication cost. In addition, the experiment did not simulate high concurrency and large-scale node scenarios, making it difficult to evaluate the performance of the scheme in actual complex blockchain networks.
I hope the author can consider the above issues. After modification, it can be considered for publication.

Author Response

Please see the attachment.

Author Response File: Author Response.pdf