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

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:

• The use cases described by the authors do not fit the motivation of lightweight system, as companies can provide some (small) infrastructure dedicated to this solution and would not require any mobile client. Furthermore, it seems likely that those use cases could be implemented through the usage of existing blockchains/consensus protocols and SPV clients.
• Even if the use cases would benefit from having such a lightweight consensus protocol, it is not clear that a BFT algorithm would be a good choice in this case. Namely, BFT typically requires the presence of a fixed set of mobile clients in the same round - an assumption that cannot be easily met for mobile clients.
• The core idea of the paper is to use a state-based rather than an operation-based approach, meaning that each node stores in its local copy information related to the latest state rather than the transactions exchanged (i.e., the operations) within the network. The authors leave their state-based replication protocol underspecified, though. They do not discuss what data a state stores, how a state changes over time, what is a valid state transition, and how their approach can be beneficial for the network other than simply allowing for the deletion of old enough states. In the context of their example use-cases, it is unclear how this approach can prevent, for example, double-spending. If nodes delete old states storing redeemed token, they would have no information at their disposal to prevent double-spending.
• Expanding on this point, the token's timestamp mechanism is unclear. According to the authors each token has a timestamp in the future, "great enough" to allow all nodes to replicate the token in their local datastore. It is, however, unclear how this timestamp considers network delays/disruptions. It's also unclear how this prevents double-spending, since tokens can be removed after being redeemed.
• Finally, the authors propose to utilize a BFT protocol as their consensus algorithm of choice. However, they never clearly state, not even in the performance evaluation section, exactly which BFT protocol they used in their solution. In recent years, a number of BFT-based protocol have emerged that can improve the performance of the traditional BFT, but can also add additional infrastructure requirements to function properly (e.g., TEEs, such as Intel SGX). The authors are therefore advised to further elaborate on this aspect of their work. This makes it hard to extract any meaningful information of their performance evaluation section, as the protocol being evaluated there is not known, and the low performance might be due to their choice of BFT protocol.

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

• Critic to Fabric and similar systems is that a backend infrastructure and a ledger is needed. I had the feeling that the proposed solution makes every node to an ordering node and therefore the scalability issue in the evaluation. E.g., maybe similar to other permissioned blockchains it would be better to distinguish node types.
• Also if as stated in the requirements tracking of assets is not necessary as they are consumed other infrastructures would also not need to store the entire ledger. So this optimization seems possible by the requirements of your applications. "By using tickets, we don't need to keep track of who owns which coin, which is typically tracked via a distributed ledger." So it seems as we avoid storage demands by addressing a class of 'friendly' applications.
• Regarding "uses an efficient state-based replication protocol to propagate updates and votes through the P2P network" I was not fully convinced that I understood the approach see below.
• Adversary model. The formula for the malicious nodes looks odd to me. Missing brackets? Pls check.
• "Protocol to issue tokens." I'm not really convinced. E.g. what if the node issuing the token does not forward the token to the other -- because he does not like to pay for it in the future. Or informs only a subset of the nodes. The client would go to a different shop -- it likes to spend its token but a.) the node does not know or b.) it knows but there are not enough nodes to confirm. Another question is if I can issue lots of tokens on behalf of one of my clients and then let the client trade its coins and I close my node?
• Protocol to redeem tokens. So if I try to spend a token and it was not forwarded by a malicious node -- I get nothing. Of if the node was a malicious node and issued a lot of token for me ...
• My main concern is the protocol seems to not be embedded in the SOTA of BFT protocols and looks extremely easy. For me it is not clear enough explained how this is possible. In essence one round of message exchange looks like not enough to me. General SMR, e.g. supported in the context of PBFT requires 3 rounds. Optimistic protocols (Zyzzyva) work with one round but in case of conflicts it gets quite complicated. Okay -- it is only about writes (create/delete) and you don't need to actually order the requests? How is the relation to quorum systems? So it is a single writer replicated storage? What about protocols that address this issue? What I'm really missing is to put your approach into the context of the large body of related works of BFT and show that your more lightweight approach is actually sufficient.

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.