2. Weak reject
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
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.
2. Weak reject
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
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