PaPoC '19 Paper #3 Reviews and Comments

Paper #3 SCEW: Programmable BFT-Consensus with Smart Contracts for Client-Centric P2P Web Applications

Submitted: 4 February 2021
Accepted: 27 February 2021

Review 1: 1 (weak accept)
Review 2: 1 (weak accept)
Review 3: 1 (weak accept)

Review 1


1 (weak accept)


This work proposes SCEW a programming framework for P2P (web) applications that allows for the manipulation of individual assets in the presence of byzantine faults. This is achieved by encoding the state of each asset via a Convergent Replicated Data Type that provides atomic register semantics via a BFT-consensus algorithm.

The paper defines the abstract interfaces of the logical components of the framework, exemplifying its use via a simple, yet clear, use case. It also includes an experimental study showing that the proposed framework can be used to build (simple) applications that scale up to 100 nodes.

The paper is well written and addresses a timely and interesting topic, at the intersection between smart-contracts/block-chain, CRDTs and programming models.

My main criticism towards the paper is that the choice of NOT providing support for transactions involving multiple assets should be supported by strong experimental evidence that "the pain is worth the gain". In fact, the paper argues that the choice of limiting the programming model allows for efficient synchronization. However, it does not present any experimental data to quantify the gains (e.g., in terms of latency or scalability) that are enabled by their proposed approach with respect to alternative systems that do not impose these limitations of the programming model.

Another baseline that would be interesting to include in the experimental study is FSolidM, in order to quantify the benefits deriving from reusing the transition results as the state of the register.

Other comments & Knitpicks:

Review 2


1 (weak accept)


This work investigates an interesting application of smart contracts in P2P web applications. The proposed framework nicely integrates prior technologies (e.g., BFT consensus, atomic register, primitive contracts) to provide a reasonable abstraction with moderate performance penalty. The key enabling component, in my opinion, is the atomic register CvRDT. I’m not an expert in the application domain, but I think the problem is interesting to the workshop, write-up is well-written, and the evaluation is reasonable. Hence, I recommend an accept.

The reason that I only recommend a weak accept is due to the following reasons. I encourage the authors to address them so that the work is more accessible for non-expert like me.

Review 3


1 (weak accept)


This paper entitled "SCEW: Programmable BFT-Consensus with Smart Contracts for Client-Centric P2P Web Applications" proposed a framework to build simple decentralized P2P web-based applications that don't have very latency-critical requirements and can't afford the blockchain storage/computational cost. The framework allows the developer to implement some application logic on top of pre-defined CRDT-like data types to do the merging, however after consensus (a quorum) is reached. This hides the BFT logic which is embedded in a smart contract-like abstraction.

Strengths: the idea is nice and timely, and the paper is well written Weakness: the guarantees and assumptions are not clear as compared to blockchain/CRDT solutions.

I liked this paper. Although it leaves many unanswered questions (which would need 14pages), the idea is worth publishing and the paper will spark nice discussion at PAPOC. The paper is also well-written and self-contained. In case the paper is accepted, please consider tackling the fixable comments below and prepare your answers for the talk :)

Major things that must not be overlooked (at least in a future longer paper): the proposed solution requires some assumptions and does not guarantee the same security as blockchains. These are not defined nor discussed. In addition, some details like the consensus used in merging is very important and deserves more emphasis (in a longer version). The evaluation does not compare with state of the art solutions.

More detailed comments:



Section 2

Section 3:

Section 4

Section 5

Section 6