SERIAL '19 Paper #46 Reviews and Comments

Paper #46 You Don't Need a Ledger: Lightweight Decentralized Consensus Between Mobile Web Clients

Submitted: 7 September 2019
Accepted: 30 September 2019

Review A: 2. Weak reject
Review B: 2. Weak reject
Review C: 4. Accept

Review A

Overall merit

2. Weak reject

Reviewer expertise

4. Expert

Paper summary

Blockchains require to store the full ledger and need a complex backend infrastructure to run. This paper proposes a lightweight browser-based middleware that allows to set-up a private blockchain that does not require nodes and users to store the ledger.

Comments for author

A lightweight consensus algorithm for mobile clients is an interesting idea and it seems fair to assume that some use cases could profit from it. However, this paper suffers from several shortcomings:

Review B

Overall merit

2. Weak reject

Reviewer expertise

3. Knowledgeable

Paper summary

The paper proposes a browser-based infrastructure to solve accounting problems in p2p-based fashion.

Comments for author

Review C

Overall merit

4. Accept

Reviewer expertise

3. Knowledgeable

Paper summary

This paper presents a lightweight platform for decentralized coordination between multiple entities that does not use Blockchain, but instead runs some form of distributed consensus on mobile web clients.

Comments for author

Over-all, this is a nicely written and structured paper that adresses an interesting issue. It argues that some problems which are currently seen (by many) as a great application area for blockchains might in fact have better solutions without blockchain. From this perspective it is certainly an excellent paper for stirring discussions at the workshop on when using blockchains is the right thing.

The paper is well-motivated with two examples, requirements clearly defined, and the solution adequately presented.

On a technical level, there are a few minor issues that I would be somewhat concered about if this were a full conference/journal paper. As for a workshop paper, these are more a reason to accept to paper and have the chance to discuss these issues at the workshop.

One concern is the assumption that a client who changes its mind is considered a malicious one. In the first use case, if a customer wants claim some award points at store A, and this is not successfull (maybe becaus of some temporary outage lets say for one day) so the customer changes its mind and tries to claim these award points at a different store, this might now might be considered double spending. Some discussion for which applications such behaviour is acceptable or not might be a valuable aspect to add.

The statement that "...other nodes can detect when a node acts maliciously" is somewhat too generic. Malicious behaviour might also include not doing anything after a customer's request. So the customer might have to wait forever (without being able to find out whether the local node or some other part of the system are causing the delay). If he instead tries to claim the token elsewhere, the customer will appear as malicious, as in my previous comment.

A possibly more imporant aspect that is completely ignored in the paper is the question of crashes and recoveries. Surely there needs to be some *persistent* storage mechanisms, otherwise if, e.g., in the extrem case all participants turn off their web browsers at night, all state information is lost the next morning. So synchronizing protocol execution with persistent storage updates is crutial. How this synchronization is done, such that even in the worst case it is not vulnerable to state loss, should be described as part of the protocol.

Also, a node failure with amnesia (i.e., in which local state is lost) is a reasonable failure scenario. So state recovery is als an aspect that might be discussed.

On p1. I disagree with the statement "crash failures (e.g. a node that goes down *or sends erroneous data*)". Sending erroneous data is not a crash failure.