Submitted: 3 June 2020
Rejected: 28 August 2020
Review A: 1. Reject
Review B: 2. Weak reject
Review C: 2. Weak reject
1. Reject
The paper presents a browser based ledger middleware for P2P applications, It includes a novel consensus protocol. The work is evaluated against itself.
Shared ledger is a trendy topic.
I do not buy the motivation - more details below. I am not convinced by the protocol and there is no correctness proof. The evaluation is only for the author's solution with no comparison to related work.
First sentence of Abstract: do you have credible references for these bold statements?
Why is browser so important? Why not any kind of application running P2P? Would the farmers refuse to install an app on their computers or mobiles?
If I understand the description of your work, you also maintain all transactions, so what is the difference between this and a blockchain?
Section 2, sharing economy: Suppose we have such a community, who is going to maintain the software, ensure everyone is running the latest version of the software, fix security bugs, etc.?
Section 2,2: The fact that one blockchain named HyperLedger requires this infrastructure does not mean that all blockchains require it. At any event, this is a specific implementation and setup problem, not an inherent issue.
Section 3.1: When a bunch of farmers, as in Section 2.1, whom are technology ignorant, how can you ensure that only 1/3 of the browsers would run malicious code?
Section 3.1, 2nd paragraph: "The protocol..." which protocol?
Also, if you are implementing a R/W atomic register, why do you need consensus in the first place? See for example Chapter 9 in the book of Michel Raynal"Fault-Tolerant Message-Passing Distributed Systems".
3.3: I am not convinced that the CRDT semantics is enough to ensure Transaction finality at any known point in time.
3.4: No proof of correctness.
Section 4: The idea of using threshold crypt for blockchains is also not knew, e.g., SBFT, HotStuff and LibraBFT.
2. Weak reject
The paper focuses on creating light-weight, browser-based P2P networks to reach/remember consensus, called WebLedger. The authors argue rightly that the public chain is too compute-intensive due PoW and private blockchain are infrastructure-intensive. The latter is a bit questionable since the noted shortcomings due to Hyperledger and not fundamental. In fact, why not extracting a BFT protocol (such as PBFT) and attempt to implemented on the client-side through the browser.
1. Weak reject
Describes byzantine fault-tolerant state-based ledger for decentralized web applications between mistrusting clients. The ledger lives in the mobile client browsers. The use case is loyalty program. The ledger uses a leaderless, client-side Byzantine Fault Tolerant synchronization and consensus protocol for atomic register with an optimistic fast path for failure free operation that degrades to slow path under attack. The state synchronization uses state-based CRDT. The BLS signature scheme is used to reduce cost of signature computation and storage. The performance study performs thorough evaluation of signature overhead including two different BLS signature aggregation schemes and evaluates the performance for the fast path and failure fallback.
An new protocol combination of atomic register consensus and CRDT. An improved BLS signature aggregation scheme. The system is implemented and evaluated breaking down the performance of main costs.
I am not convinced the intended use case of community applications matches the requirement to keep track of all the network participants. Protocol wise, the failure independence assumptions for this essentially permissioned setting are not well rationalized. The correctness of the protocol is not clearly argued
Unless I am confused your protocol requires participants to keep track of all other participants in the client network running essentially a permissioned replication scheme. Please explain why the use case of loyalty points and other community based applications is compatible with the protocol requirement. Please also explain the failure independence assumptions.