Incorporating CCS23 feedback/comments part II

[InaOana]

@AlistairStewart, @FatemeShirazi Feedback this may not need any action from us. I leave it up to you to decide:

• Regarding reviewer's 606A feedback, I have not incorporated the following:

1. "The manuscript seems to use the wrong template, as can be seen, e.g., from the increased margins at the border of the pages, as well as the wrongly configured parindent."

• Regarding reviewer's 606C feedback, I have not incorporated any reply to the following:

1. "The result does not seem to suggest any new methodology which can be applied more widely, the authors develop an optimization for one particular problem of BLS committee-based aggregation. The blueprint design is a naive application of a SNARK-based compression, the main contribution is then in the development of a more optimized custom SNARK for this particular problem." -->Question: We have replied to that in the rebuttal. Should we add any part of that reply in intro?

2."The implementation suggests that the prover time is still too slow, for 2^20 validators (which is a half of Ethereum validators today), the time to prove is about the length of the epoch, there is no much time for the prover to lag behind, a lagging prover might not be able to catch up with the chain. The paper lacks the discussion of directions in which the prover time could be improved. Although the authors instantiate the scheme over a different curve, not the one used in Ethereum, so it is not clear how the method applies to Ethereum or not." --> Question: We have replied to that in the rebuttal. Should we add any part of that reply in intro?

3."The paper is for the most part easy to follow, except for the notations of groups and curves (Section 3.1) which I find to be very confusing, e.g. the paper is talking about curves over prime fields, but then denotes the curves over extension fields." --> Not sure I agree/understand this comment from the reviewer so I cannot reply to it.

[InaOana]

@AlistairStewart and also @FatemeShirazi , I would like to discuss how is best to tackle the following comments from reviewers:

• "Throughout, current typesetting of formulas throughout makes them unpleasant to read/parse." (606A). --> Before making any changes, I would like to agree on a style.

• Deeper intuition for CKS soundness (606A)

• "Sec 3.3: Why do we not have to worry about adversarial key generation?" (606A) --> I am hot sure how to interpret it. Should we motivate why in our security properties for CKS we consider the most general case of keys being chosen by the adversary? But that is the same we do in the security defs of AS and there was no explanation asked from us there.

• "p. 8: notation and explanation of "conditional NP relation" unclear. Reference missing?'' (606A). -->Do we have a simple and clear way to improve this?

• "Key ingredients of the paper currently only found in appendix should at least be summarized in the main body of the manuscript, otherwise the paper becomes hard to follow (as it is now). This includes: Appendix E, H, G." (606A)

• "Typos: Appendix Section" (606A) --> What should we replace it with??

• "Why does the CKS.Prove procedure take the ck instead of re-deriving it to have only the necessary inputs to each of the algorithms?" (606C)

• Additionally, when I have added a summary intuition for CKS properties, I have mentioned for which security property of a light client system each of them is used, but those security properties in turn, are not mentioned anywhere in the main body of the paper, just in the appendix. How to fix this?

[InaOana]

@AlistairStewart, @FatemeShirazi , this is feedback that I have not tackled and needs action from us. May I leave this with you both?

• Regarding reviewer's 606A feedback

1. p. 1, 2nd column, paragraph "Following the consensus protocols ...": The authors speak of "existing approaches", yet include no references to those earlier works. References would make it easier for the reader to connect the ideas/statements of the authors to earlier works the reader might already be familiar with.

2. (p. 1, 2nd column, paragraph "Our Approach: ...", first half) + (p. 2, 1st column, paragraph "Application: ..."): Quite hard to understand the idea at this point in the paper and in this brevity.

3. p. 2, 1st column, paragraph "Accountability": Earlier works (such as https://arxiv.org/abs/1710.09437 or https://arxiv.org/abs/2010.06785) make precise the notion of "accountability" (and accountable misbehavior) achieved by many PoS consensus protocols, namely: accountable safety. The authors remain vague about what they mean with "accountability", while they seem to follow the notion of earlier works, but without providing any reference that would clarify it for the reader.

4. p. 3, 1st column, second half of paragraph "Our scheme is applicable to ...": References would help the reader understand better which consensus algorithms the proposed technique is (not) applicable to.

5. p. 3, 1st column: "as the commitment could be computed on chain, maybe in a smart contract": This seems to be effectively the same as the solution discussed right above?

6. Section 1 and Section 2 together are introduction, but have a lot of repetition. Often, the first mentioning of a topic is too brief/incomplete/imprecise. For instance: Sec 2.1: a/b/c and a'/b'/c' are the details missing in earlier "Our Approach" and related work discussion. Sec 2.3 para 2 is repetition. p. 5, 1st column, para 1/2/3 are repetition. Streamlining this would also free up space to include some of the manuscript's essentials currently only found in appendix (see below).

7. "CKS" is never defined.

8. p. 4, para "Keeping Track of ...": a diagram would improve readability.

9. p. 4, para "Proving the General Claim ...": Typos?

10. p. 4, para "Efficiency Gain:": "obvious approach described above": which one?

11. Allusions that absolute domain experts can "decipher", but probably remain nebulous to "average" blockchain expert readers: "impacting the security of PoS systems" (p. 1), "a more expensive procedure" (p. 2), "with consequences for usability" (p. 3), "more involved security model" (p. 4), "two parts" (p. 8, 2nd column, 1st line).

12. (p. 4, Sec 2.3: 3rd and 4th para) + (p. 6, 1st column, 1st para): are hard to understand without more context.

13. Nitpicks:

-p. 2: "Another approach to reducing on-chain complexity is optimism.": perhaps rather "fraud proofs"?
-p. 3, 2nd column, last para: "current validator": what is "current"?
-p. 5: "to a single malicious" -> "only"
-p. 6: missing reference for two-chain.

14. Typos:

• Commas around "e.g." or "i.e." missing
• Appendix Section --> What should we replace it with?