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

Martijn Sauwens, Kristof Jannes, Bert Lagaisse, Wouter Joosen imec-Distrinet, KU Leuven

Abstract ACM Reference Format: Collaborative web applications are becoming increasingly Martijn Sauwens, Kristof Jannes, Bert Lagaisse, Wouter Joosen. 2021. client-centric, with technologies such as WebRTC, WebWork- SCEW: Programmable BFT-Consensus with Smart Contracts for Client-Centric P2P Web Applications. In 8th Workshop on Principles ers and IndexedDB enabling a shift towards a decentralized and Practice of Consistency for Distributed Data (PaPoC’21), April 26, peer-to-peer (P2P) model. Contemporary systems such as 2021, Online, United Kingdom. ACM, New York, NY, USA, 7 pages. Automerge, Legion, OWebSync and Yjs provide https://doi.org/10.1145/3447865.3457965 and consistency by using Conflict-free Replicated Data Types for synchronization. These systems tolerate crash-faults, but lack resilience against arbitrary faults and malicious users, 1 Introduction also known as Byzantine faults. Providing Byzantine fault Collaborative web applications are becoming increasingly tolerance (BFT) in web apps is non-trivial. Web apps are popular and versatile. Browser technologies such as Web- executed in web browsers on end user devices. The scarce RTC [5], WebWorkers [9] and IndexedDB [1] enable the im- compute resources and the interactive nature of collabora- plementation of responsive and persistent peer-to-peer (P2P) tive web apps do require both a lightweight and low-latency applications in the browser [11]. Existing frameworks for de- solution, while still providing the Byzantine fault tolerance veloping P2P web apps such as Automerge [14], Legion [31], required by P2P systems to protect shared assets. OWebSync [13] and Yjs [24, 25] provide crash-fault toler- Our work aims to fill this gap by indroducing SCEW, a pro- ance [28] by using CRDTs [29] and their P2P architecture. gramming framework for client-centric P2P web apps that However, none of these systems can tolerate arbitrary or require BFT and interactive collaboration. SCEW achieves Byzantine faults. The source of these faults is diverse, ranging this by combining state-based Convergent Replicated Data from software bugs to colluding and malicious users [17, 28]. Types (CvRDTs) and smart contracts. SCEW represents as- Dealing with Byzantine faults is more complex compared to sets shared by peers as CvRDTs with atomic register semanc- fail-stop crashes, requiring elaborate protection mechanisms. tics, that provide BFT through the use of BFT-consensus Byzantine fault tolerance (BFT) is often required by P2P algorithms. SCEW employs smart contracts to define the life- applications that collectively manage shared assets with real cycle of these shared assets, shielding the application and world value. Examples are integrated loyalty programs [12] it’s developers from the complexity of the CvRDT’s consen- and sharing economy [8, 18]. Abuse of shared assets in these sus protocol. Experimental results indicate that applications applications may lead to real-world damage, either in the using SCEW can support P2P networks with 100 peers, even form of financial loss or damage to the reputation of partici- when Byzantine faults are present. pating users. To protect the shared assets against Byzantine CCS Concepts: • Security and privacy → Distributed faults, P2P applications use BFT-consensus protocols [6]. systems security; • Networks → Peer-to-peer protocols; Consensus protocols ensure that state changes are only com- • Information systems → Web applications. mitted when a quorum of peers agree on the newly proposed state. Designing and implementing BFT-consensus protocols Keywords: Smart Contracts, Web applications, Peer-to-peer is sophisticated, requiring thorough testing and formal veri- protocols, Byzantine Fault Tolerance fication to prove safety. To capitalize on development costs, it is useful to make consensus algorithms programmable. An Permission to make digital or hard copies of all or part of this work for abstraction for programming BFT-consensus are smart con- personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear tracts [30]. Smart contracts specify how users interact with this notice and the full citation on the first page. Copyrights for components shared assets and one another. Deploying the same contract of this work owned by others than ACM must be honored. Abstracting with on all peers, in combination with BFT-consensus, ensures credit is permitted. To copy otherwise, or republish, to post on servers or to that the protected shared state can only evolve according to redistribute to lists, requires prior specific permission and/or a fee. Request the specifications of the contract. permissions from [email protected]. Client-centric P2P web apps execute exclusively in web PaPoC’21, April 26, 2021, Online, United Kingdom © 2021 Association for Computing Machinery. browsers of end-users. This environment is characterized by ACM ISBN 978-1-4503-8338-7/21/04...$15.00 a lack of compute resources, unreliable communication and https://doi.org/10.1145/3447865.3457965 high churn rates. The interactive nature of collaborative P2P 1 PaPoC’21, April 26, 2021, Online, United Kingdom Martijn Sauwens, Kristof Jannes, Bert Lagaisse, Wouter Joosen web apps requires a solution to BFT-consensus that is not 3 Background only lightweight, but also provides low latencies, preferably This section provides the background information and ter- in the order of seconds [26]. To fulfil these requirements we minology on CvRDTs, and BFT-consensus used present the SCEW ( Execution for the Web) in the remainder of the text. Other related technologies and programming framework. This framework: systems are discussed in Section 6. 1. enables development of client-centric P2P web apps Convergent Replicated Data Types (CvRDTs) [29] are a that require BFT and interactive collaboration, flavor of Conflict-free Replicated Data Types (CRDTs) [29] 2. uses state-based CRDTs with atomic register semantics providing Strong Eventual Consistency (SEC) between mul- for efficient synchronization and BFT, tiple replicas by defining a join semilattice over a shared 3. and both defines and manages life-cycles of individual state. This lattice has both a partial ordering relation (≤) and assets with state machine based smart contracts. a Least-Upper-Bound (LUB) operation. Replicas periodically exchange their local copy of the state with each other to Experimental results indicate that SCEW can support in- propagate any received updates, merging both the received teractive collaboration in client-centric P2P web apps that and local state using the LUB operation. CvRDTs only re- require BFT to protect their users’ assets. SCEW can support quire a fair-lossy channel for communication, which makes networks with up to 100 users, keeping latencies below 3.2 state-based protocols ideal for use in unreliable networks and 2 seconds for 99% of all transactions in scenarios with such as the Internet. Note that attention should be paid at and without Byzantine faults respectively. design time to minimize the size of the CvRDT, as the entire The remainder of this text is structured as follows: Sec- state is sent over the network during synchronization. tion 2 elaborates on motivation and use cases. Section 3 Consensus algorithms are an important part of Block- provides the reader with additional background. Section 4 chains [35]. Well known blockchains include [27], presents SCEW, the main contribution of this work. Sec- [34] and Hyperledger Fabric [3]. Blockchains repli- tion 5 discusses the evaluation. We consider related work in cate a data-structure called the ledger, that is maintained by Section 6 and conclude in Section 7. the protocol. Users update the ledger by propos- 2 Motivation and Use Cases ing new transactions, aggregating them into blocks. Block- chains such as Ethereum and Fabric use these transactions This section provides two motivating examples of client- to initiate calls to smart contracts [30]. Based on their spec- centric P2P web apps that require BFT to manage shared ification, smart contracts can read and write to the ledger, assets. The first application Loyalty Programs, demonstrates allowing them to update the ledger’s state in a programmable the use of BFT in protecting shared loyalty points, while the manner. A consensus algorithm decides which block of trans- second, Sharing Economy, aims to mitigate distrust between actions is added next to the chain. Blocks are chained to- users participating in a sharing economy application. gether by hashes, making it computationally infeasible to Loyalty Programs. Local shops or merchants at a market- change the contents of blocks or their order at a later time. place can implement a shared loyalty program in which their Examples of consensus algorithms used by blockchains in- customers can exchange earned loyalty points at any partic- clude Nakamoto Consensus [27] and BFT, depending on the ipating shop [12]. To avoid abuse or fees by a central party, context [35]. Nakamoto Consensus requires vast amounts of the shops set up the loyalty program as a client-centric P2P computational resources, as it essentially tries to brute force web app where the loyalty points are managed collectively a solution to a cryptographic puzzle. Nakamoto Consensus by the merchants. Decentralizing loyalty point management also lacks consensus finality [33] which causes confirmation involves solving BFT-consensus to prevent abuse, such as times in the order of minutes. Regardless of the used consen- customers double spending [27] their loyalty points. sus algorithm, peers must also store the entire blockchain to Sharing Economy. The sharing economy [8, 18] is based be able to validate the state of the ledger. The high storage on the observation that consumer items such as tools, cars overhead combined with potentially high resource usage and other equipment are expensive, while remaining unused and confirmation times, makes blockchains a poor fit for for most of the time. Therefore small communities, such as client-centric interactive P2P webapps. neighborhoods or apartment buildings, can decide to share Tickets [11] are an alternative approach for managing their equipment to cut down costs. To avoid unwanted fees or shared assets in a setting with Byzantine faults. Tickets man- privacy issues associated with central parties, sharing econ- age a single asset owned by an individual user. At their cre- omy applications can be provided as a client-centric P2P web ation, Tickets are replicated across all available replicas to app. The web app is responsible for tracking the items and be redeemed at a later date. To redeem a Ticket, the replica regulating exchange, enabling the users to trace back damage creates a new proposal that contains both asset data and or theft. BFT-consensus eases trust requirements, expecting a signature that approves the transaction. This proposal that users only trust the application and a supermajority of is then synchronized and validated by the other replicas, the network, rather than every participating user separately. 2 SCEW: Programmable BFT-Consensus with Smart Contracts for Client-Centric P2P Web Applications PaPoC’21, April 26, 2021, Online, United Kingdom

interface Transition { name, from, to: string BMachine smart contracts model the life-cycle of a single guard(s:State,i:Input,c:Ctx):bool BMachine effect( shared asset as a state machine. SCEW enforces the contract s:State,i:Input,c:Ctx ):Output by atomically updating the shared asset across all replicas (2) (3) } with a BFT-consensus protocol in which each replica verifies interface Primitive { the updates against the contract. Contrary to blockchains, a input(v:Value,c:Ctx):Proposal Primitive Contract check(p:Proposal,c:Ctx):bool SCEW smart contract instance only manages a single shared retrieve(p:Proposal,c:Ctx):Value } asset and is not allowed to call the contract of other assets, (1) (4) (0) interface Register{ thus precluding support for transactions across multiple get():Value shared assets. This restriction enables SCEW to synchronize Atomic Register propose(p:Proposal):bool merge(r:Register):bool (9) each shared asset independently of one another in the same Integration } Logic (8) (5) manner as Tickets [12]. Independently synchronizing assets (7) interface RM { reduces the latency, as it limits the size of the state that needs update(r:Register):bool Replica manager merge(r1,r2:Register):Register to be exchanged between the replicas. } IndexedDB (6) The integration logic of the application acts as a consumer Sequence: Create Proposal of the smart contract. SCEW exposes functionality that al-

0. call:propose 5. call:update lows the application to invoke the smart contract and retrieve 1. call:input 6. call:set

2. call:guard 7. return:void the shared state. This functionality can then be used to build 3. return:true 8. return:true user interfaces or provide other services. WebRTC 4. return:proposal 9. return:true Atomic Register CvRDTs. CvRDTs with atomic register Figure 1. Schematic overview of SCEW. Components are semantics [4, 12, 15, 16] provide both synchronization and shown as colored rectangles and communicate with each BFT-consensus. Each register stores and protects the state 푠 푠 other using the interfaces on the right. The Create Proposal ∈ S of a single shared asset. The state consists of a value 푣 푃 sequence at the bottom right shows the control flow for an ∈ V and a set of proposals ⊆ V for the next value of the application that successfully proposes a new value. register, with S and V the sets of register states and values respectively. Atomic registers ensure a consistent view of the shared assets by only permitting a single simultaneous which in turn cast their vote, approving the transaction. The change of the register’s value 푣 across the entire P2P net- Ticket is considered redeemed only after a supermajority work, thus ruling out conflict in the sequence of changes has approved the proposal. Tickets do not exhibit the high in register’s value and allowing the peers to agree on the storage requirements of a blockchain and are particularly most recent value of the register. To support these seman- lightweight, making them suitable for browser environments. tics, the register CvRDT should implement a BFT-consensus However, their one-shot nature, together with a lack of sup- protocol. This ensures that changes of the register’s value 푣 port for multiple ownership, restricts Tickets to modelling are atomic, as long as a quorum of peers behaves correctly. only simple asset life-cycles. SCEW requires the register CvRDT to provide the Register interface shown in Figure 1. The get method enables the 4 SCEW caller to retrieve the most recent known value of the register. This section presents SCEW: a programming framework for Calling propose proposes a new value for the register and lightweight programmable BFT-consensus in client-centric digitally signs it with the private key of the peer for authen- P2P web apps with interactive collaboration. We first present ticity. The proposal is then added to the register CvRDT and SCEW’s core concepts, followed by an overview of its sup- subsequently accepted or rejected by the network that uses porting components, such as the atomic register CvRDT, the register’s BFT-consensus protocol. The consensus pro- BMachines and primitive contracts, illustrating these con- tocol is implemented by the merge method, which joins the cepts with an example. A schematic overview of SCEW’s state of two atomic registers. Joining registers enables peers main components is shown in Figure 1. to discover new proposals and reach a consensus on the next value of the register. Once consensus is reached, the peers The SCEW Programming Framework. We first present update the value 푣 of the register to the winning proposal the SCEW programming framework for client-centric P2P 푝 ∈ 푃, reflecting the new asset state. Paying attention to web apps that require both lightweight BFT consensus and in- size, the atomic register CvRDT can be implemented with teractive collaboration. SCEW draws inspiration from smart the same storage requirements and efficiency as Tickets. contracts and their role in blockchains, combining contracts with the asset management model of Tickets. Applications BMachines. SCEW uses smart contracts to define the using the SCEW programming framework must provide the life-cycle of shared assets stored in atomic register CvRDTs. following two components: BMachine smart contracts and These contracts are specified as a variant of finite state integration logic, both of which are shown in Figure 1. machines we call Byzantine Fault Tolerant State Machines 3 PaPoC’21, April 26, 2021, Online, United Kingdom Martijn Sauwens, Kristof Jannes, Bert Lagaisse, Wouter Joosen

Register Modifications. To support primitive contracts, the create Offered reject atomic register has to call the Primitive interface when ex- offer ecuting its methods. To initiate a state transition, users of cancel create report Start Ready Broken SCEW invoke the propose method of the hosting register, providing the transition’s input 휎푖 ∈ Σ푖 as arguments. The register then calls the input method of the primitive contract Figure 2. BMachine for sharing tools in a sharing economy to encode the proposal in a form that allows the other peers to use case. Users create tools with the create transition and verify the proposal. This encoding is then digitally signed by offer them to others by calling offer. The offer can then be the register for integrity and non-repudiation. Consequently, accepted (accept) or rejected (reject) by the recipient or can when fetching the value 휔 of the BMachine instance IB with be canceled (cancel) by the original owner. Items can be the register’s get method, the register must call retrieve to de- decommissioned by calling report, ending the life-cycle. code the value 푣 stored in the register. Joining register state with merge requires the register to check the validity of any new proposals 푝 ∈ 푃 with the check method. This method or BMachines. BMachines are characterized by the 7-tuple contains the validation logic of the primitive contract and (푄, 푞 , , , N, 훿, ) 0 Σ푖 Σ푠 Ω shown in Definition 4.1. uses the stored BMachine instance IB to make a decision. Executing BMachines. To execute BMachines on atomic Definition 4.1. BMachine B : (푄, 푞0, Σ푖, Σ푠, N, 훿, Ω) registers, the primitive contract must encode the BMachine 푄 푞 푄 • the set of states, with 0 ∈ the start state instance (B, (푞, 휎 )) and any pending proposals in terms of , 푠 • Σ푖 Σ푠 the input and state values respectively the register state 푠 ∈ S, such that other peers can validate any •N set of transition names new proposals using the BMachine contract B. One possible • the transition function 훿 : (푄×N ×Σ푖 ×Σ푠 ) ↦→ (푄×Σ푠 ) 푛, 휎 , 푞′, 휎 ′ encoding for proposals is ( 푖 ( 푠 )) ∈ (N × Σ푖 × Ω). The • Ω : (푄, Σ ) the set of instance values for BMachines 푠 field 푛 names the transition invoked by the proposal, while 휎푖 (푞′, 휎 ′) BMachines consist of a set of states 푄 connected via the par- and 푠 are for validation. A proposal is deemed valid by 푛 tial transition function 훿. Each asset is stored as a BMachine the primitive contract if (i) the transition is defined for the current state 푞 of the BMachine instance (B, (푞, 휎푠 )), (ii) the instance IB ≡ (B, 휔) that combines the definition of the (휎 , 휎 ) BMachine B and the instance’s value 휔 ∈ Ω. Users of SCEW guard with arguments 푠 푖 yields true, (iii) the effect with (휎 , 휎 ) 휎 ′ define a BMachine B by providing a set of transitions T . arguments 푠 푖 returns 푠 and (iv) the target state of the transition corresponds to 푞′. Once the consensus protocol Each transition (푛, 푞푠, 푞푡,푔, 푒) ∈ T consists of the transition’s name 푛 ∈ N, a source state 푞 ∈ 푄, a target state 푞 ∈ 푄, a approves the proposal, the latter is assigned as the new value 푠 푡 푣 ′ ∈ V guard 푔 : (Σ × Σ ) → B and an effect 푒 : (Σ × Σ ) ↦→ Σ of the register and the retrieve method can be used 푠 푖 푠 푖 푠 휔 ′ ≡ (푞′, 휎 ′) as shown in the Transition interface of Figure 1. The transi- to decode the new value 푠 from the BMachine instance. The sequence for proposing a new value by the tion is applicable if (i) the source state 푞푠 correspond to the integration logic is shown in Figure 1. current state of the BMachine instance 퐼B and (ii) the guard, acting as a precondition, approves the transition based on the Example. Developers using the SCEW middleware only 휎 휎 current state’s associated value 푠 ∈ Σ푠 and the input 푖 ∈ Σ푖 have to implement BMachines and integration logic, being (푞 , 휎 ′) ∈ (푄 × ) provided by the caller. The result 푡 푠 Σ푠 of a oblivious to the BFT-protocol provided by the middleware. 푞 transition is the combination of both its target state 푡 and Listing 1 shows a stylized implementation of the offer transi- the result of the effect, the latter of which is the postcondition tion, a transition which initiates the exchange of tools for the of the transition that computes the next state’s associated sharing economy contract of Figure 2. From a developer’s 휎 ′ ∈ value 푠 Σ푠 based on the same arguments as the guard. perspective, the guard first checks if the caller is the owner 푄 Using T , SCEW infers the states and composes the partial of the tool, after which the effect updates the BMachine in- transition function 훿 to form a BMachine as in Definition 4.1. stance value 휎푠 ∈ Σ푠 with new ownership information. If Primitive Contracts. Primitive contracts are the glue be- both calls succeed, the state of the BMachine is updated from tween the high-level BMachines and the low-level atomic Ready to Offered, completing the transition. The integration registers, translating the states 푠 ∈ S and methods of the logic for calling the transition and retrieve the resulting value atomic register into states 푞 ∈ 푄 and transitions 푡 ∈ T of is shown in Listing 2. BMachines. The hosting register provides this translation by calling the primitive contract with the methods provided Listing 1. Implementation of the offer transition, types from by the Primitive interface shown in Figure 1. These methods the Transition interface have been expanded for clarity. enable the primitive contract to encode the information nec- 1 type Offer={borrower: ID}; essary to execute the BMachine at all peers, using the set of 2 type ToolOffer={ proposals 푃 ⊆ 푉 and value 푣 ∈ V of the atomic register. 3 tool: ID; offerer: ID; offeree: ID; 4 SCEW: Programmable BFT-Consensus with Smart Contracts for Client-Centric P2P Web Applications PaPoC’21, April 26, 2021, Online, United Kingdom

4 }; any real-world interactions. Each experiment was executed 5 type State={tool: ID;owner: ID}; ten times to increase confidence in our results. 6 type Ctx={caller: ID}; 7 const offerTransition: Transition = { 8 name : ' o f f e r ' , from : ' Ready ' , to : ' O f f e r e d ' , Latency [s] 9 guard:(s: State ,o: Offer ,ctx: Ctx)=> 3.5 10 s.owner===ctx. caller , 3 11 effect :(s:State ,o:Offer ,ctx:Ctx)=>({ 12 tool: s.tool, 13 offerer: s.owner, 2 14 offerree: o.borrower , 15 } as ToolOffer) , 1 16 }; Peers [#] 0 20 40 60 80 100 Listing 2. Integration logic for calling the offer transition Register-Only Contracts Crash Malicious on a register containing the tool and retrieve the result. 1 await tool .propose({ Figure 3. Distribution of latency versus network size for th th 2 transition : ' o f f e r ' , each scenario. Whiskers indicate the 1 and 99 percentile. 3 args: {borrower: borrowerID }, 4 }); 5 const v a l u e = await tool.get(); Results and discussion. Results are shown in Figure 3. Comparing the first two scenarios register-only and contracts, 5 Evaluation it is clear that adding smart contracts only introduces very This section presents and discusses the evaluation of SCEW. limited overhead. Both scenarios show latencies below 2 To evaluate SCEW, we implemented a research prototype seconds, even for larger networks, which is sufficient for of both the middleware and a tool sharing application. The the interactive performance required by both use cases. The contract used by the application is shown in Figure 2. The increase in latency for larger networks can mostly be attrib- atomic registers are implemented using a quorum based uted to an increase in overhead by the underlying consensus BFT-protocol similar to Tickets [12]. We first show the ex- protocol, as more peers need to vote to reach the quorum. perimental setup, followed by a discussion of the results. For both the crash and malicious scenarios 30% of all peers are affected by faults. Theth 99 percentile latency increases Setup. The experiments aim to measure the performance in both scenarios for larger networks, but stays below 3.2 and scalability of SCEW in terms of latency for varying seconds. This relative increase in latency compared to earlier network sizes in different scenarios. The first two scenarios, scenarios can be explained by the way in which the network register-only and contract, aim to establish a baseline for both handles the aforementioned faults. In the case of crashes, the performance overhead caused by the contracts as well peers stop actively partaking in the application, while the as the performance of a network with no faults. The third remaining peers try to heal the overlay network. The sce- scenario crash investigates the impact of crashes, and the nario with malicious peers behaves similarly, as peers which last scenario malicious considers malicious peers which are violate the contract will be ignored by any honest peers actively injecting faults by violating the contract. that detect malicious behavior. In both cases the quorum re- The experiments were conducted on the Azure public quired to reach consensus remains unaltered while the active cloud. The P2P network is emulated by 4 to 20 standard F8s portion of the network decreases, meaning that a smaller v2 virtual machines with 8 vCPUs and 16GB RAM. Each VM number of peers must collect the same amount of votes to runs 5 containerized instances of the tool sharing application confirm a proposal. This increases the contribution of slower in the chromium web browser. The P2P overlay is structured peers to the critical path, increasing latency. as a flat overlay where each browser is connected with at Overall, our evaluation shows that SCEW is able to keep least 5 other peers. We modelled 4G mobile network condi- transaction latencies below 3.2 seconds in 99% of all trans- tions with the Linux traffic control tool tc [10], increasing the actions, even in the case of failures in networks with 100 network delay to 60ms [7]. Users are emulated by exchang- peers. These latencies are acceptable for both the Loyalty ing tools for 5 minutes at a fixed transaction rate of 1 tx/s, Programs and Sharing Economy use cases, as transactions are scaling down proportionally as peers leave the network. This only performed when loyalty points are redeemed and tools transaction rate was chosen as an over approximation for are exchanged between users. 5 PaPoC’21, April 26, 2021, Online, United Kingdom Martijn Sauwens, Kristof Jannes, Bert Lagaisse, Wouter Joosen

6 Related Work scale up to 100 peers, keeping the latency below 2 seconds This section discusses related work not mentioned in Sec- in scenarios with no faults. Even in the case of Byzantine tion 3. We first discuss examples of frameworks for collabo- faults, performance remains acceptable with latencies under rative P2P web apps, followed by delta-state-based CRDTs 3.2 seconds. and C-CRDTs. We next discuss Fabric CRDT and wrap up with a discussion of FSolidM, a state machine representation of smart contracts for the Ethereum blockchain. References Automerge [14], Legion [31], OWebSync [13] and Yjs [24, [1] Ali Alabbas and Joshua Bell. 2018. Indexed Database API. Recom- 25] are frameworks for developing P2P web apps in the mendation. W3C. https://www.w3.org/TR/2018/REC-IndexedDB-2- browser. All four frameworks make use of CRDT technology 20180130/ [2] Paulo Sérgio Almeida, Ali Shoker, and Carlos Baquero. 2018. Delta for synchronization such as operation-based Commutative state replicated data types. J. Parallel and Distrib. Comput. 111 (2018), Replicated Data Types [29], Δ-CRDTs [32] and state-based 162–173. https://doi.org/10.1016/j.jpdc.2017.08.003 CvRDTs [29], making them resilient against crashes. How- [3] Elli Androulaki, Artem Barger, Vita Bortnikov, Christian Cachin, ever, none of there frameworks considers Byzantine faults. Konstantinos Christidis, Angelo De Caro, David Enyeart, Christo- 훿-CRDTs [2] and Δ-CRDTs [32] are delta-state-based CRDTs pher Ferris, Gennady Laventman, Yacov Manevich, Srinivasan Mu- ralidharan, Chet Murthy, Binh Nguyen, Manish Sethi, Gari Singh, that focus on network efficiency by using deltas to incremen- Keith Smith, Alessandro Sorniotti, Chrysoula Stathakopoulou, Marko tally update the state of CRDTs. SCEW instead uses a Merkle Vukolić, Sharon Weed Cocco, and Jason Yellick. 2018. Hyperledger tree approach for efficient state synchronization [13]. Fabric: A Distributed Operating System for Permissioned Blockchains. Computational CRDTs or C-CRDTs [20, 22, 23] are CRDTs In Proceedings of the Thirteenth EuroSys Conference (Porto, Portugal) that perform collective computations, using CRDT semantics (EuroSys ’18). Association for Computing Machinery, New York, NY, USA, Article 30, 15 pages. https://doi.org/10.1145/3190508.3190538 to merge results from local computations into the final result. [4] Hagit Attiya, Amotz Bar-Noy, and . 1995. Sharing Mem- Examples include the distributed computation of a sum [23] ory Robustly in Message-Passing Systems. J. ACM 42, 1 (Jan. 1995), and top-K leaderboards [22]. This stands in contrast with 124–142. https://doi.org/10.1145/200836.200869 smart contracts, which all perform the same computation [5] Adam Bergkvist, Daniel C. Burnett, Cullen Jennings, Anant Narayanan, and reach a consensus on the result of a single invocation. Bernard Aboba, Taylor Brandstetter, Jan-Ivar Bruaroey, and Hen- rik Boström. 2020. WebRTC 1.0: Real-time Communication Between FabricCRDT [21] combines CRDTs with the Hyperledger Browsers. W3C. https://www.w3.org/TR/2020/CRD-webrtc-20201125/ Fabric [3] blockchain. FabricCRDT avoids Multi Version Con- [6] Miguel Castro and . 1999. Practical Byzantine Fault currency Control (MVCC) conflicts by using CRDT trans- Tolerance. In Proceedings of the Third Symposium on Operating Systems actions. These transactions merge conflicting values in the Design and Implementation (New Orleans, Louisiana, USA) (OSDI ’99). ledger using CRDT semantics. SCEW instead uses CvRDTs USENIX Association, USA, 173–186. [7] Kevin Fitchard. 2019. USA Mobile Network Experience Report January inside the protocol to achieve consensus. 2019. Opensignal. https://www.opensignal.com/reports/2019/01/usa/ FSolidM [19] is a tool for building and verifying Ethereum mobile-network-experience smart contracts as finite state machines. It does so by storing [8] Koen Frenken and Juliet Schor. 2017. Putting the sharing economy the state of the contract as a single object that persists across into perspective. Environmental Innovation and Societal Transitions 23 state transitions. However, this does not work well with (2017), 3 – 10. https://doi.org/10.1016/j.eist.2017.01.003 Sustainability Perspectives on the Sharing Economy. a state-based approach where the entire object, including [9] Ian Hickson. 2015. Web Workers. Working Draft. W3C. http://www. superfluous fields, needs to be sent over the network during w3.org/TR/2015/WD-workers-20150924/ synchronization. We instead used a representation that re- [10] Bert Hubert. 2020. tc(8). Linux man-pages project. https://man7.org/ uses the transition’s results as the state of the register. linux/man-pages/man8/tc.8.html [11] Kristof Jannes, Bert Lagaisse, and Wouter Joosen. 2019. The Web Browser as Distributed Application Server: Towards Decentralized 7 Conclusion Web Applications in the Edge. In Proceedings of the 2nd International Workshop on Edge Systems, Analytics and Networking (Dresden, Ger- This work presented SCEW, a programming framework for many) (EdgeSys ’19). Association for Computing Machinery, New York, lightweight programmable BFT-consensus in client-centric NY, USA, 7–11. https://doi.org/10.1145/3301418.3313938 P2P web apps that require interactive collaboration. SCEW [12] Kristof Jannes, Bert Lagaisse, and Wouter Joosen. 2019. You Don’t Need manages shared assets and their life-cycle using a combina- a Ledger: Lightweight Decentralized Consensus Between Mobile Web Clients. In Proceedings of the 3rd Workshop on Scalable and Resilient tion of smart contracts based on state machines and CvRDTs Infrastructures for Distributed Ledgers (Davis, CA, USA) (SERIAL ’19). with atomic register semantics, implementing a BFT-consen- Association for Computing Machinery, New York, NY, USA, 3–8. https: sus protocol. Assets are managed individually rather than //doi.org/10.1145/3366611.3368143 collectively, allowing for efficient synchronization at the cost [13] Kristof Jannes, Bert Lagaisse, and Wouter Joosen. 2021. OWebSync: of lacking support for transactions involving multiple assets. Seamless Synchronization of Distributed Web Clients. IEEE Transac- tions on Parallel and Distributed Systems (2021). https://doi.org/10. However, the absence of cross-asset transactions poses no 1109/TPDS.2021.3066276 problems for the use cases considered in this work. The eval- [14] Martin Kleppmann, Adam Wiggins, Peter van Hardenberg, and Mark uation shows that SCEW is suited to implement systems that McGranaghan. 2019. Local-First Software: You Own Your Data, in 6 SCEW: Programmable BFT-Consensus with Smart Contracts for Client-Centric P2P Web Applications PaPoC’21, April 26, 2021, Online, United Kingdom

Spite of the Cloud. In Proceedings of the 2019 ACM SIGPLAN Inter- 145–154. https://doi.org/10.1145/190.357399 national Symposium on New Ideas, New Paradigms, and Reflections [29] Marc Shapiro, Nuno Preguiça, Carlos Baquero, and Marek Zawirski. on Programming and Software (Athens, Greece) (Onward! 2019). As- 2011. Conflict-free Replicated Data Types. Research Report RR-7687. sociation for Computing Machinery, New York, NY, USA, 154–178. INRIA. 18 pages. https://hal.inria.fr/inria-00609399 https://doi.org/10.1145/3359591.3359737 [30] . 1997. Formalizing and Securing Relationships on Public [15] . 1986. On interprocess communication. Distributed Networks. First Monday 2, 9 (Sept. 1997). https://doi.org/10.5210/fm. Computing 1, 2 (01 Jun 1986), 86–101. https://doi.org/10.1007/ v2i9.548 BF01786228 [31] Albert van der Linde, Pedro Fouto, João Leitão, Nuno Preguiça, San- [16] Leslie Lamport. 1986. On interprocess communication. Distributed tiago Castiñeira, and Annette Bieniusa. 2017. Legion: Enriching In- Computing 1, 2 (01 Jun 1986), 77–85. https://doi.org/10.1007/ ternet Services with Peer-to-Peer Interactions. In Proceedings of the BF01786227 26th International Conference on World Wide Web (Perth, Australia) [17] Leslie Lamport, , and Marshall Pease. 1982. The Byzan- (WWW ’17). International World Wide Web Conferences Steering tine Generals Problem. ACM Trans. Program. Lang. Syst. 4, 3 (July Committee, Republic and Canton of Geneva, CHE, 283–292. https: 1982), 382–401. https://doi.org/10.1145/357172.357176 //doi.org/10.1145/3038912.3052673 [18] Akash Madhusudan, Iraklis Symeonidis, Mustafa Mustafa, Ren Zhang, [32] Albert van der Linde, João Leitão, and Nuno Preguiça. 2016. Δ-CRDTs: and Bart Preneel. 2019. SC2Share: Smart Contract for Secure Car Making 훿-CRDTs Delta-Based. In Proceedings of the 2nd Workshop on Sharing. In Proceedings of the 5th International Conference on Infor- the Principles and Practice of Consistency for Distributed Data (London, mation Systems Security and Privacy - Volume 1: ICISSP,. INSTICC, United Kingdom) (PaPoC ’16). Association for Computing Machinery, SciTePress, Prague, Czech Republic, 163–171. https://doi.org/10.5220/ New York, NY, USA, Article 12, 4 pages. https://doi.org/10.1145/ 0007703601630171 2911151.2911163 [19] Anastasia Mavridou and Aron Laszka. 2018. Designing Secure [33] Marko Vukolić. 2016. The Quest for Scalable Blockchain Fabric: Proof- Ethereum Smart Contracts: A Finite State Machine Based Approach. In of-Work vs. BFT Replication. In Open Problems in Network Security, Financial and Data Security, Sarah Meiklejohn and Kazue Jan Camenisch and Doğan Kesdoğan (Eds.). Springer International Sako (Eds.). Springer Berlin Heidelberg, Berlin, Heidelberg, 523–540. Publishing, Cham, 112–125. [20] Christopher Meiklejohn and Peter Van Roy. 2015. Lasp: A Language [34] Gavin Wood. 2014. Ethereum: A secure decentralised generalised trans- for Distributed, Coordination-Free Programming. In Proceedings of the action ledger (eip-150 revision ed.). http://gavwood.com/paper.pdf 17th International Symposium on Principles and Practice of Declarative [35] X. Xu, I. Weber, M. Staples, L. Zhu, J. Bosch, L. Bass, C. Pautasso, Programming (Siena, Italy) (PPDP ’15). Association for Computing and P. Rimba. 2017. A Taxonomy of Blockchain-Based Systems for Machinery, New York, NY, USA, 184–195. https://doi.org/10.1145/ Architecture Design. In 2017 IEEE International Conference on Software 2790449.2790525 Architecture (ICSA). IEEE, Lyon, France, 243–252. https://doi.org/10. [21] Pezhman Nasirifard, Ruben Mayer, and Hans-Arno Jacobsen. 2019. 1109/ICSA.2017.33 FabricCRDT: A Conflict-Free Replicated Datatypes Approach to Per- missioned Blockchains. In Proceedings of the 20th International Mid- dleware Conference (Davis, CA, USA) (Middleware ’19). Association for Computing Machinery, New York, NY, USA, 110–122. https: //doi.org/10.1145/3361525.3361540 [22] David Navalho, Sérgio Duarte, and Nuno Preguiça. 2015. A Study of CRDTs That Do Computations. In Proceedings of the First Workshop on Principles and Practice of Consistency for Distributed Data (Bordeaux, France) (PaPoC ’15). Association for Computing Machinery, New York, NY, USA, Article 1, 4 pages. https://doi.org/10.1145/2745947.2745948 [23] David Navalho, Sérgio Duarte, Nuno Preguiça, and Marc Shapiro. 2013. Incremental Stream Processing Using Computational Conflict-Free Replicated Data Types. In Proceedings of the 3rd International Workshop on Cloud Data and Platforms (Prague, Czech Republic) (CloudDP ’13). Association for Computing Machinery, New York, NY, USA, 31–36. https://doi.org/10.1145/2460756.2460762 [24] Petru Nicolaescu, Kevin Jahns, Michael Derntl, and Ralf Klamma. 2015. Yjs: A Framework for Near Real-Time P2P Shared Editing on Arbitrary Data Types. In Engineering the Web in the Big Data Era, Philipp Cimi- ano, Flavius Frasincar, Geert-Jan Houben, and Daniel Schwabe (Eds.). Springer International Publishing, Cham, 675–678. [25] Petru Nicolaescu, Kevin Jahns, Michael Derntl, and Ralf Klamma. 2016. Near Real-Time Peer-to-Peer Shared Editing on Extensible Data Types. In Proceedings of the 19th International Conference on Supporting Group Work (Sanibel Island, Florida, USA) (GROUP ’16). Association for Computing Machinery, New York, NY, USA, 39–49. https://doi.org/10.1145/2957276.2957310 [26] Jakob Nielsen. 2010. Website Response Times. Nielsen Norman Group. https://www.nngroup.com/articles/website-response-times/ [27] Nakamoto Satoshi. 2008. Bitcoin: A Peer-to-Peer Electronic Cash System. https://bitcoin.org/bitcoin.pdf [28] Fred B. Schneider. 1984. Byzantine Generals in Action: Implement- ing Fail-Stop Processors. ACM Trans. Comput. Syst. 2, 2 (May 1984),

7