# Coalition Formation Game for Cost-Efficient Multiparty Payment Channel in Payment Channel Networks
## 4 Multiparty Payment Channel
### MPC State Synchronization
#### 4.3.2 Partial Synchronization  
For scalability, the MPC state can be partially synchronized along the order of the SPCs, which allows each user to update the global view only at their turn. For this, a user of an SPC \(v_{ij}(t)\) sends the updated local chain only to users of the next SPC \(v_{mm}(t+1)\), which can therefore reduce the communication overhead compared to full synchronization. For partial synchronization, each SPC user verifies \(n\) previous SPC blocks, \(v_{ij}(t-n,t)\), of the received local chain for the MPC state update if the last state that the user confirmed is \(v_{ij}(t-n-1)\). For example, in Figure 5, user B must confirm the current MPC state before trading with counterparty A at the \(T_{6}\). Since the balance of user A could be changed in the block of \(v_{AD}\) at the \(T_{5}\), user B must acquire and verify the \(v_{AD}(t=T_{5})\) block. If the \(v_{AD}(t=T_{5})\) transaction is incorrect, user B can invoke a dispute procedure and close the MPC. Contrarily, user A does not need to update at \(T_{6}\) because the last MPC state is already known at \(T_{5}\). Therefore, the number of blocks to verify depends on the SPC schedule as below. * Periodic SPC for minimum blocks: in fully connected PSPs that individually have \(N-1\) SPCs over total \(N(N-1)/2\), each PSP has its own SPC every \(N/2\) round and the same number of blocks to verify. * Aperiodic SPC for minimum communication: as shown in Figure 5, SPCs can be linked by an anchoring node that can reduce the communication overhead for local chain propagation. According to the Euler trail algorithm, all SPCs can be visited without additional communication if the \(N\) is an odd number, and a single extra communication instance is needed otherwise. However, in the worst case, the maximum number of verification blocks can be \(V-N+1\). The aperiodic SPC probably has a serious update overhead with the propagation of previous \(n\) blocks if the MPC size, \(N\), grows exponentially, even though each block is only around a hundred bytes, containing a round count (4 bytes), user accounts (20 bytes \(\times\) 2), the BPs of two users (4 bytes \(\times\) 2), and the two signatures of \(i,j\) of \(v_{ij}\) (32 bytes \(\times\) 2). In this study, we use the periodic SPC schedule in the following algorithms. Algorithm 1 describes the update procedure in the MPC. An SPC user updates the MPC state sequentially along the order of blocks in the received chain unless the signatures are wrong or the balance sum differs from the previous state. Otherwise, the dispute procedure will be triggered by the user. During the dispute procedure, the smart contract  
Figure 5: Local chain structure for 4 users and 6 SPCs of the MPC in Figure 4. To verify the final MPC state, user A holds total \(V\) previous blocks at \(t=T_{6}\). Subsequently, the new update by \(v_{AB}(t=T_{6})\) removes the obsolete \(v_{AB}(t=T_{6})\). settles the balances based on the final MPC state. Algorithm 2 shows the dispute resolution algorithm conducted by the smart contract. All participants upload their own \(V\) blocks of the last SPC cycle \(v_{ij}(t),t\in[n-V,n-1]\) before closing the channel, where the last round counts \(n\) can vary for each user. Subsequently, the smart contract orders receive blocks chronologically and verify each one to update the MPC state sequentially, as in Algorithm 1. In the end, the block with the highest round count finalizes the user balance.