1 Introduction↩︎

Decentralized finance (DeFi) continues to expand, yet the underlying blockchain layer still struggles to deliver service-grade scalability. Since every on-chain transaction requires consensus validation, end-to-end latency can hinder interactive payment services. Off-chain payment channels mitigate this bottleneck by moving frequent transactions outside the consensus path while keeping channel opening, closure, and dispute resolution on-chain [2], [3]. From a service-computing perspective, they offer low-latency, high-throughput payment services with blockchain-backed settlement finality.

As payment channels interconnect, they form a payment channel network (PCN) that routes off-chain payments through intermediaries when no direct channel exists. This reachability turns payment forwarding into a service orchestration problem: requests must be assigned, traffic must be distributed, and latency and reliability must be maintained under bursty demand. TumbleBit [4] introduced an unlinkable payment hub for fast off-chain payments, motivating the payment channel hub (PCH) model.

In the PCH model, participants maintain channels with a hub that coordinates transfers and collects service fees. While this simplifies transaction coordination, it also concentrates service work at one node, limiting flexibility under high-frequency workloads and creating a potential bottleneck. As always-on payment services grow, PCH architectures must support higher concurrency, balanced workloads, and privacy across multiple cooperating hubs.

Motivation. As shown in Fig. [Fig1a], the total value locked (TVL) in the Lightning Network [2] has increased substantially despite short-term fluctuations². Although TVL does not directly measure transaction demand, it reflects the growing economic scale of off-chain payment services. Fig. [Fig1b] illustrates a complementary risk: payment traffic may concentrate on a subset of nodes and channels, producing uneven routing load. Together, these observations expose two coupled service-computing challenges: scaling with demand and preventing load concentration. Future off-chain payment services must distribute requests, absorb workload bursts, and maintain responsive forwarding when popular nodes or channels become congested. Three limitations remain.

(i) PCH-based solutions usually rely on one hub to relay payments and hide transactional relationships [4]–[9], concentrating request processing at a single service point. Multiple hubs alone are insufficient because poor request allocation can still leave some hubs overloaded and others underused. (ii) Collaborative hubs require routing that coordinates concurrent payments without relying only on sender-selected paths. Existing PCN routing protocols include source routing and decentralized schemes based on landmarks, helpers, or embeddings [2], [3], [10]–[18], but they do not directly address privacy-preserving load balancing across PCHs. (iii) TEE-based approaches protect off-chain confidentiality [19]–[23], yet they either require all participants to support TEEs or rely on a single TEE-enabled PCH. Existing approaches therefore do not jointly provide scalable request allocation, load-aware multi-hub routing, and privacy-preserving coordination without a centralized point of failure.

Challenges. SHARE addresses three coupled challenges. (i) PCH selection and request allocation. A service architecture must choose suitable hubs, decide how many to activate, and assign clients as network conditions change. (ii) Multi-PCH routing. Collaborative hubs must coordinate concurrent payments while respecting liquidity, avoiding contention, and supporting large-value transfers. (iii) Privacy-preserving collaborative routing. Routing across multiple service nodes must protect payment amounts, endpoint identities, and transaction relationships.

Contributions. This paper presents SHARE (Secure Hub Allocation and Routing Efficiency), a TEE-assisted multi-PCH architecture for secure and scalable off-chain payment services. Following Splicer [1], we call the selected PCHs smooth nodes; in SHARE, each smooth node is TEE-enabled. SHARE distributes payment processing and routing across multiple smooth nodes to balance network load and avoid single-hub bottlenecks. The main contributions are as follows.

• Cost-aware multi-PCH allocation. We formulate smooth-node deployment and client assignment as an NP-hard optimization problem that captures deployment, client-management, and inter-smooth-node synchronization costs. SHARE solves small instances exactly through MILP and large instances through a randomized double-greedy heuristic based on supermodular structure.

  2.1pt

  Comparison of representative PCN routing, PCH, and TEE-assisted schemes.

  Schemes
  locus
  routing
  service nodes
  coord.
  privacy
  privacy
  proof
  TumbleBit, A\(^{2}\)L [4], [5]	None			N/A
  BlindHub, Accio [6], [9]	None			N/A
  SilentWhispers [16]	None		N/A	–
  SpeedyMurmurs [17]	None		N/A	–			–
  Flare [10]	None		N/A	–	–	–	–
  Flash [14]	None		N/A		–	–	–
  Sprite [18]	None		N/A	–
  Teechain, Speedster [20], [21]	Clients	–	N/A	N/A		–	–
  Twilight [24]	Relays	–		–
  RouTEE [22]	PCH			–		–	–
  SorTEE [23]	Service nodes			–			–
  Splicer [1]	None				–		–
  SHARE	PCHs

  Notes: “”: explicitly supported; “”: not supported; “N/A”: not applicable; “–”: not explicitly established or not a main focus in the cited paper. Grouped schemes in one row share the listed feature values. \(^a\) Relationship unlinkability is inherited from the underlying PCH construction and is not reproved in this work.

• TEE-assisted distributed routing. SHARE combines previous-epoch global state with local payment requests to coordinate multipath rates, apply congestion control, balance load, and preserve channel liquidity. A receiver-generated shared hashlock ensures that honest receivers accept only complete transaction-unit sets, while attested state management supports concurrent logical channels between smooth nodes.

• Formal security analysis. We define a UC-inspired ideal functionality and give a property-based proof showing routing confidentiality, execution integrity, and receiver-side acceptance atomicity under the stated leakage model and threshold-corruption bound. Relationship unlinkability is inherited from the underlying PCH construction and is not reproved here.

• Prototype implementation and evaluation. MATLAB simulations and an LND/SGX prototype [25], [26] show that SHARE improves average transaction success ratio by 43.6% as transaction size varies and normalized throughput by 181.5% over the comparison set.

2 Related Work↩︎

This section reviews prior work from three perspectives: PCH mechanisms for off-chain payment services, PCN routing strategies for service coordination, and TEE-assisted approaches to privacy-preserving off-chain execution.

PCH mechanisms. TumbleBit [4] introduced a Bitcoin-compatible untrusted payment hub that supports fast off-chain payments while preventing the intermediary from linking payers to payees. A\(^{2}\)L [5] uses anonymous atomic locks to provide a backward-compatible PCH protocol with atomicity and payment unlinkability. BlindHub [6] introduces blind adaptor signatures and flexible blind conditional signatures to support variable-amount payments while preserving atomicity, relationship anonymity, and value privacy. Accio [9] combines randomizable signatures with updatable commitments to support variable-amount payments without the overhead of non-interactive zero-knowledge proofs. These schemes strengthen private hub-mediated payments, but they retain a single-hub architecture and do not address request allocation or collaborative routing across multiple PCHs.

Routing strategies. Most PCH protocols focus on hub-mediated transfers rather than general multi-hop routing. PCN routing remains relevant because it determines how payment requests are discovered, split, and forwarded under changing liquidity and network load. Beyond sender-computed source routing, decentralized protocols reduce the sender’s dependence on complete topology information. SilentWhispers [16] adapts landmark-based routing to support privacy-preserving transactions in decentralized credit networks. SpeedyMurmurs [17] uses embedding-based path discovery and on-demand stabilization to improve routing efficiency under topology changes. Flare [10] and Flash [14] explore route discovery with partial topology knowledge and liquidity-aware path selection, while Sprite [18] separates offline path discovery from online transaction processing to support concurrent private payments with lower message complexity. These protocols improve decentralized path discovery, but they are not designed to jointly optimize multi-PCH allocation, inter-hub load balancing, and confidential coordination among hubs.

TEE-based solutions. Teechain [20] uses TEEs to execute off-chain transactions asynchronously with respect to the underlying blockchain. Speedster [21] develops an account-based state-channel system in which enclave-backed certified channels support dispute-free off-chain operation and multiparty contracts. Twilight [24] uses TEE-enabled relays to enforce a noisy relay mechanism for differential privacy, while SorTEE [23] delegates path computation to TEE-enabled service nodes to reduce user-side routing overhead and protect payment information. RouTEE [22] implements a TEE-protected routing hub that conceals payment information, improves liquidity utilization, and removes the need for users to continuously monitor the blockchain. Despite these advances, existing TEE-assisted systems either require broad client-side TEE deployment, depend on a single TEE-enabled PCH, or do not jointly address cost-aware multi-PCH allocation and load-aware confidential routing.

Comparison. Table ¿tbl:tab-routing-compare? summarizes representative schemes along dimensions relevant to SHARE. Conventional PCH protocols provide private hub-mediated payments but funnel requests through one intermediary. Decentralized routing protocols reduce sender-side topology knowledge and computation, but they do not coordinate multiple service hubs under concurrent workloads. TEE-assisted systems protect sensitive off-chain execution, yet they do not combine selective hub-side TEE deployment with cost-aware allocation and load-aware inter-hub routing. SHARE targets this gap by deploying TEEs only at selected PCHs and distributing routing computation across them. Our previous work, Splicer [1], establishes a multi-PCH architecture with cost-aware hub allocation and rate-controlled routing. SHARE extends this foundation with TEE-protected routing computation, concurrent inter-PCH channel management, and a UC-inspired ideal-functionality specification with a scoped property-based security analysis. Relationship unlinkability is inherited from the underlying PCH construction and is not reproved in this work.

3 SHARE: System Overview↩︎

This section presents the system model, workflow, and threat assumptions of SHARE as an off-chain payment service architecture. We first define the participating entities and their interactions, then describe the payment workflow, and finally state the adversary capabilities and security objectives that guide the protocol design and security proof.

3.1 System Model↩︎

Entities. SHARE involves two types of entities:

Client. Clients are lightweight end users in the PCN who initiate or receive payments. They do not execute the routing protocol themselves. Instead, each client delegates payment coordination to one assigned smooth node and communicates only with that smooth node through a secure channel.

Smooth node. A smooth node is a TEE-enabled hub that executes the routing logic inside an enclave. Smooth nodes collaboratively process client payment requests, determine route splitting and forwarding decisions, and generate execution evidence for later verification. A subset of \(\iota\) smooth nodes forms the key management group (KMG) and runs a robust threshold public-key encryption scheme \(\mathcal{TE}=(\textsf{DKG},\textsf{Enc},\textsf{PDec},\textsf{VerifyShare},\textsf{Combine})\) [27]. Let \(t\) be the maximum number of statically corrupted KMG members. SHARE sets the decryption threshold to \(\tau_{\rm dec}=t+1\) and requires \(\iota\geq 2t+1\). During offline preprocessing, the KMG repeatedly runs distributed key generation [28] to fill a pool of unused one-time entries. Each entry contains public and verification material and one sealed private-key share in every KMG enclave. Online, the KMG atomically binds one unused entry to a fresh transaction or TU identifier \(x\), exposes \((\textsf{pk}_x,\textsf{vk}_x)\), and marks the entry as allocated. Every private-key share \(\textsf{sk}_x^{(q)}\) remains sealed inside its holder’s enclave; no complete private key is materialized, exported, or reconstructed.

Workflow. A PCN is modeled as a graph \(\mathbb{G}=(\mathbb{V}, \mathbb{E})\), where \(\mathbb{V}\) is the set of nodes and \(\mathbb{E}\) is the set of payment channels. Let \(\mathbb{V}_{\rm CLI} \subseteq \mathbb{V}\) denote the set of clients and let \(\mathbb{V}_{\rm SN} \subseteq \mathbb{V}\) denote the set of smooth nodes, such that \(\mathbb{V}_{\rm CLI}=\mathbb{V}\setminus \mathbb{V}_{\rm SN}\). We further define an assignment function \[a: \mathbb{V}_{\rm CLI} \rightarrow \mathbb{V}_{\rm SN}, \label{eq:assignment-function}\tag{1}\] where \(a(P)\) returns the smooth node assigned to client \(P\). In the default deployment, each client maintains a direct channel to exactly one assigned smooth node, while smooth nodes may communicate with each other through the hub network and the KMG.

As shown in Fig. 2, when a client \(P_s \in \mathbb{V}_{\rm CLI}\) initiates a payment to another client \(P_r \in \mathbb{V}_{\rm CLI}\), the assigned smooth nodes are \(S_i=a(P_s)\) and \(S_j=a(P_r)\), respectively. The payment workflow consists of three phases: initialization, processing, and acknowledgment.

a) Payment initialization phase: For simplicity, we omit the channel-opening procedure and assume that all channels already contain sufficient initial deposits, following prior work [29], [30]. Before initiating a payment, \(P_r\) samples a one-time payment preimage \(z_{\textsf{tid}}\leftarrow\$\{0,1\}^{\lambda}\), sends the invoice commitment \(h_{\textsf{tid}}=\textsf{H}(z_{\textsf{tid}})\) to \(P_s\), and retains \(z_{\textsf{tid}}\). During setup, \(S_i\) installs \(\textsf{prog}\) in \(\mathcal{G}_{\rm att}\) and obtains an enclave identifier \(\textsf{eid}_i\), an attestation public key \(\textsf{mpk}_{\rm att}\), and platform evidence binding \((\textsf{eid}_i,\textsf{prog},\textsf{mpk}_{\rm att})\). The corresponding signing key remains inaccessible inside \(\mathcal{G}_{\rm att}\). The client \(P_s\) verifies this evidence and establishes an attestation-authenticated secure channel with the enclave of \(S_i\); \(P_r\) does the same with the enclave of \(S_j\). After the secure channels are established, \(P_s\) sends \(\textsf{pay}_{\rm req}\) and \(h_{\textsf{tid}}\) to \(S_i\). The enclave samples a fresh transaction identifier \(\textsf{tid}\leftarrow\$\{0,1\}^{\lambda}\) and asks the KMG to allocate an unused pre-generated threshold-key entry. The KMG atomically binds the entry to \(\textsf{tid}\) and returns only \((\textsf{pk}_{\textsf{tid}},\textsf{vk}_{\textsf{tid}})\); the private-key shares \(\{\textsf{sk}_{\textsf{tid}}^{(q)}\}_{q\in[\iota]}\) remain sealed in the corresponding KMG enclaves. Smooth node \(S_i\) sends \((\textsf{tid},\textsf{pk}_{\textsf{tid}})\) to \(P_s\) and initializes \(\textsf{state}_{\textsf{tid}}=(\textsf{tid},\theta_{\textsf{tid}},h_{\textsf{tid}})\), where \(\theta_{\textsf{tid}}\) indicates whether the transaction has completed.

b) Payment processing and acknowledgment phases: Fig. 2 illustrates the payment execution process, which consists of a processing stage followed by an acknowledgment stage.

Step (1): The transaction begins when \(P_s\) constructs the payment request \[D_{\textsf{tid}}=(P_s, P_r, \textsf{val}_{\textsf{tid}},h_{\textsf{tid}}), \label{eq:payment-request}\tag{2}\] where \(\textsf{val}_{\textsf{tid}}\) is the payment amount and \(h_{\textsf{tid}}\) is the receiver-generated payment hash. \(P_s\) then computes \(\textsf{inp}=\mathcal{TE}.\textsf{Enc}(\textsf{pk}_{\textsf{tid}},D_{\textsf{tid}})\) and sends \((\textsf{tid},\textsf{inp})\) together with a conditional transfer locked by \(h_{\textsf{tid}}\) to \(S_i\).

Step (2–3): Smooth node \(S_i\) loads \(\textsf{inp}\) into its enclave. The enclave produces authorization evidence \(\pi_{\textsf{tid}}^{\rm dec}\) that binds \((\textsf{eid}_i,\textsf{prog},\textsf{tid},\textsf{H}(\textsf{inp}))\). A KMG member responds only after verifying this evidence, confirming that \(\textsf{tid}\) is bound to an allocated entry, and establishing an attestation-authenticated channel terminating at \(\textsf{eid}_i\). Each responsive member \(q\) then returns \(\delta_{\textsf{tid}}^{(q)}=\mathcal{TE}.\textsf{PDec}(\textsf{pk}_{\textsf{tid}},\textsf{sk}_{\textsf{tid}}^{(q)},\textsf{inp})\) directly to the enclave. The enclave accepts only shares satisfying \(\mathcal{TE}.\textsf{VerifyShare}(\textsf{pk}_{\textsf{tid}},\textsf{vk}_{\textsf{tid}},\textsf{inp},\delta_{\textsf{tid}}^{(q)})=1\). After collecting a set \(Q\) of at least \(\tau_{\rm dec}\) valid shares, it recovers \[D_{\textsf{tid}}=\mathcal{TE}.\textsf{Combine}(\textsf{pk}_{\textsf{tid}},\textsf{vk}_{\textsf{tid}},\textsf{inp},\{\delta_{\textsf{tid}}^{(q)}\}_{q\in Q}). \label{eq:threshold-decryption}\tag{3}\] If fewer than \(\tau_{\rm dec}\) valid shares are available, the transaction aborts. The routing program \(\textsf{prog}\) then partitions \(D_{\textsf{tid}}\) into \(K\) transaction units (TUs) \(\{D_{\textsf{tuid}_k}\}_{k=1}^{K}\), where each TU has a unique identifier \(\textsf{tuid}_k\). For every TU, \(S_i\) creates \(\textsf{state}_{\textsf{tuid}_k}=(\textsf{tuid}_k,\theta_{\textsf{tuid}_k})\), where \(\theta_{\textsf{tuid}_k}\) records whether that TU has completed successfully and \[\theta_{\textsf{tid}}=\bigwedge_{k=1}^{K}\theta_{\textsf{tuid}_k}. \label{eq:completion-flag}\tag{4}\]

For each \(\textsf{tuid}_k\), the KMG atomically allocates and binds another unused pre-generated entry, then publishes \((\textsf{pk}_{\textsf{tuid}_k},\textsf{vk}_{\textsf{tuid}_k})\). Every TU carries the same payment hash \(h_{\textsf{tid}}\) and is forwarded as an HTLC with a path-valid expiry. Smooth node \(S_i\) encrypts \(D_{\textsf{tuid}_k}\) under \(\textsf{pk}_{\textsf{tuid}_k}\) and dispatches the ciphertext and conditional transfer over the selected path without waiting for other TUs to finish. The enclave of \(S_j\) obtains authorization evidence binding the TU ciphertext to its attested program, requests shares through its attested enclave channel, verifies them, and combines any \(\tau_{\rm dec}\) valid shares to recover the TU; the complete private key is never reconstructed. If the TU is valid, its HTLC is irrevocably locked, and sufficient expiry margin remains, \(S_j\) returns \(\textsf{READY}_{\textsf{tuid}_k}\) without revealing the preimage. Only after all \(K\) readiness messages have arrived does \(S_j\) request \(z_{\textsf{tid}}\) from \(P_r\), verify \(\textsf{H}(z_{\textsf{tid}})=h_{\textsf{tid}}\), and initiate fulfillment of the complete HTLC set with the common preimage. In accordance with Basic MPP semantics, the destination does not fulfill an incomplete set and, if it fulfills one TU, it issues fulfillment for the entire set. The preimage then propagates backward along each path under the standard HTLC protocol, and \(S_i\) marks a TU complete only after observing its fulfillment. If any TU fails or expires before preimage release, \(P_r\) withholds \(z_{\textsf{tid}}\); each pending HTLC then follows its timeout branch. Thus, an honest receiver accepts either the complete payment or none of its TUs. After preimage release, individual paths may resolve at different times under adversarial scheduling, so SHARE claims receiver-side acceptance atomicity rather than simultaneous end-to-end settlement. Once all fulfillment acknowledgments are received, \(S_i\) updates \(\textsf{state}_{\textsf{tid}}\) and asks \(\mathcal{G}_{\rm att}\) to finalize the state and generate \[\sigma_{\textsf{tid}}\leftarrow\mathcal{G}_{\rm att}.\textsf{resume}(\textsf{eid}_i,(\textsf{finalize},\textsf{state}_{\textsf{tid}})), \label{eq:exec-proof}\tag{5}\] where the signing key remains internal to \(\mathcal{G}_{\rm att}\). The signature covers the enclave identity, program measurement, command, and final state and is verified under the previously attested \(\textsf{mpk}_{\rm att}\).

Step (4): The release of \(z_{\textsf{tid}}\) makes the complete HTLC set claimable and allows \(P_r\) to accept the consolidated payment. Each conditional transfer then resolves through the underlying HTLC success path, which may complete at different times. \(P_r\) generates \(\textsf{ACK}_{\textsf{tid}}\) after accepting the complete set, while \(S_i\) finalizes success for \(P_s\) only after receiving all TU fulfillment acknowledgments. Because clients verified the platform quote and its binding to \(\textsf{mpk}_{\rm att}\) during channel setup, they verify \(\sigma_{\textsf{tid}}\) locally under that key; the platform attestation service is not invoked for every transaction. The forwarding fees paid by the initiator incentivize relay nodes along the routing path.

3.2 Threat Model↩︎

Adversary model. We consider a static PPT adversary that can observe the public network, corrupt smooth-node hosts, and control their operating systems and network stacks. Before protocol setup, the adversary may corrupt at most \(t\) of the \(\iota\) KMG members, where \(\iota\geq 2t+1\) and \(\tau_{\rm dec}=t+1\). It may drop, delay, replay, or reorder messages handled by corrupted hosts and learn any information exposed outside their enclaves. However, it cannot break the confidentiality or integrity of honest TEEs, extract a private-key share from an honest KMG enclave, cause an honest KMG enclave to release a share outside an authorized attested channel, combine at most \(t\) shares to recover a plaintext or private key, or forge valid platform evidence or enclave-generated execution proofs.

Security objectives. SHARE is designed to satisfy the following goals:

• Routing confidentiality: sensitive routing inputs, including payment amounts and transaction payloads, should not be revealed to entities outside the trusted execution environment.

• Conditional relationship unlinkability: assuming the underlying PCH construction provides relationship unlinkability, splitting a payment must not introduce additional endpoint-linkage leakage beyond the explicitly modeled metadata. This inherited property is not part of SHARE’s UC theorem.

• Execution integrity: the externally visible execution proof should allow a verifier to check that the routing program was executed correctly.

• Receiver-side acceptance atomicity: for honest endpoints, the receiver should release the shared preimage only for a complete HTLC set and should never accept a partial payment. An incomplete set remains unfulfilled and its pending HTLCs resolve through their timeout branches.

Assumptions. We assume that all parties trust Intel processors and the SGX attestation infrastructure, instantiated by IAS in legacy EPID deployments or by DCAP/PCS in ECDSA deployments. KMG members use authenticated secure channels and an authenticated broadcast channel during \(\mathcal{TE}.\textsf{DKG}\), and release partial decryptions only to enclaves whose evidence and program measurement have been verified. The threshold encryption scheme is robust and IND-CCA secure against exposure of at most \(t\) private-key shares, and every partial decryption is verifiable. Confidentiality holds against the static corruption of at most \(t\) KMG members, whereas threshold-decryption availability requires at least \(\tau_{\rm dec}\) responsive members. The underlying PCN enforces standard HTLC success and timeout semantics and the Basic MPP terminal rule³: a conditional transfer can be fulfilled only with a valid preimage before expiry; an incomplete HTLC set is not fulfilled; and a terminal node that fulfills one member of a complete set issues fulfillment for the entire set. The receiver releases its payment preimage only after all \(K\) TUs are irrevocably locked. These assumptions guarantee atomic acceptance at the honest receiver, but do not impose a bound on network delay or require all paths to resolve simultaneously. The offline pool must contain enough unused entries for the admitted workload; if it is exhausted, new payments wait for a preprocessing refill rather than falling back to online DKG. Clients trust a smooth node only after verifying its platform evidence and establishing the corresponding attested channel.

Side-channel mitigation. Existing TEE implementations remain vulnerable to side-channel attacks [31], [32]. To reduce this risk, SHARE uses side-channel-resistant cryptographic libraries⁴. Side-channel hardening is not the main focus of this paper and is treated as an orthogonal engineering concern.

4 SHARE: System Design↩︎

4.1 Design Overview↩︎

Fig. 3 summarizes the SHARE design. The system consists of three tightly coupled components. First, we formulate the smooth-node allocation problem, whose goal is to balance deployment and client-management costs against inter-smooth-node synchronization costs. For small networks, we solve the allocation problem exactly as a mixed-integer linear program (MILP). For larger networks, we exploit its supermodular structure under uniform synchronization costs and use a scalable randomized heuristic.

Second, we design a rate-based distributed routing protocol for smooth nodes. The protocol combines global state from the previous epoch with current client requests to compute routing prices, adjust per-path flow rates, and prevent both capacity overload and directional liquidity depletion. This allows SHARE to support concurrent multipath forwarding while keeping channel utilization stable.

Third, we analyze channel concurrency. Smooth nodes execute routing logic inside TEEs and obtain threshold decryption shares from the KMG. SHARE can therefore operate multiple pre-funded logical channels between PCHs without an on-chain transaction for every off-chain state update. We model the concurrency benefit using the Universal Scalability Law (USL) and use batch processing to reduce enclave state-management overhead.

4.2 Allocation Problem Formulation↩︎

For brevity, we refer readers to Appendix B for the long-term candidate selection mechanism and to Appendix C for the broader problem context. Here we formalize the allocation problem that selects active smooth nodes from the candidate set.

Let \(\mathbb{V}_{\rm SNC}\) denote the smooth-node candidate set and let \(\mathbb{V}_{\rm CLI}\) denote the client set. We use two binary decision vectors: \[\begin{align} \boldsymbol{x}&=\{x_n \in \{0,1\}: n \in \mathbb{V}_{\rm SNC}\}, \tag{6}\\ \boldsymbol{y}&=\{y_{mn} \in \{0,1\}: m \in \mathbb{V}_{\rm CLI}, n \in \mathbb{V}_{\rm SNC}\}. \tag{7} \end{align}\] Here, \(x_n=1\) means that candidate \(n\) is deployed as an active smooth node, and \(y_{mn}=1\) means that client \(m\) is assigned to smooth node \(n\). Each client is assigned to exactly one active smooth node, and at least one smooth node must be deployed:

The allocation objective balances three costs. The management cost \(\mathcal{C}_M(\boldsymbol{y})\) captures client-to-smooth-node assignment overhead, the deployment cost \(\mathcal{C}_D(\boldsymbol{x})\) penalizes activating smooth nodes, and the synchronization cost \(\mathcal{C}_S(\boldsymbol{x},\boldsymbol{y})\) captures inter-smooth-node coordination overhead:

Here, \(\zeta_{mn}\geq0\) is the management cost of assigning client \(m\) to smooth node \(n\), \(f_n\geq0\) is the deployment cost of node \(n\), \(\delta_{nl}\geq0\) is the per-client synchronization cost from \(n\) to \(l\), and \(\epsilon_{nl}=\epsilon_{ln}\geq0\) is the fixed pairwise synchronization overhead. The factor \(1/2\) prevents double counting of the fixed overhead.

We define the balanced objective as \[\mathcal{C}_B(\boldsymbol{x},\boldsymbol{y}) =\mathcal{C}_M(\boldsymbol{y})+\mathcal{C}_D(\boldsymbol{x}) +\omega\mathcal{C}_S(\boldsymbol{x},\boldsymbol{y}), \label{eq:balanced-cost}\tag{14}\] where \(\omega\geq0\) controls the weight of synchronization overhead. The PCH allocation problem is \[\min_{\boldsymbol{x},\boldsymbol{y}}\mathcal{C}_B(\boldsymbol{x},\boldsymbol{y}) \quad\text{s.t. Equations }\eqref{constraint13}\text{--}\eqref{constraint15}. \label{eq:allocation-problem}\tag{15}\]

NP-hardness. Set \(\omega=0\). Equation 15 then selects facilities with opening costs \(f_n\) and assigns every client \(m\) to one open facility at cost \(\zeta_{mn}\). This is precisely uncapacitated facility location, which is NP-hard. Therefore, the general SHARE allocation problem is NP-hard.

4.3 Allocation Algorithms↩︎

Small-scale exact solution. For small networks, we linearize the binary products by introducing

The following constraints enforce \(\vartheta_{nl}=x_nx_l\) and \(\varphi_{nlm}=x_ly_{mn}\):

The exact MILP objective is \[\begin{align} \min\quad &\sum_{m,n}\zeta_{mn}y_{mn}+\sum_nf_nx_n \notag\\ &+\omega\sum_n\sum_{l\ne n}\left(\delta_{nl}\sum_m\varphi_{nlm} +\frac{1}{2}\epsilon_{nl}\vartheta_{nl}\right), \label{eq:allocation-milp} \end{align}\tag{18}\] subject to Equations 8 –10 , 16 , and 17 , with indices ranging over their corresponding client and candidate sets. Standard branch-and-bound solvers can obtain the optimum for small instances.

Large-scale heuristic. Once a deployment set is fixed, the best assignment is separable across clients.

Thus, the main combinatorial decision is the deployment set. Let \(\mathcal{S}\) denote the candidate-node ground set and let \(\varnothing\ne\mathcal{X}\subseteq\mathcal{S}\). Substituting Equation ?? into the objective gives \(f(\mathcal{X})=\mathcal{C}_B(\boldsymbol{x}_{\mathcal{X}},\boldsymbol{y}(\mathcal{X}))\).

Under uniform \(\delta\), the assignment-dependent cost for client \(m\) is \(\min_{n\in\mathcal{X}}\zeta_{mn}+\omega\delta(|\mathcal{X}|-1)\). The minimum term is supermodular, the cardinality and deployment terms are modular, and the nonnegative pairwise term is supermodular. Their sum is therefore supermodular.

For large instances, we maximize the submodular surrogate \(g(\mathcal{X})=-f(\mathcal{X})\) using the randomized double-greedy heuristic in Algorithm 4. Because feasible deployments exclude the empty set and \(g\) need not be nonnegative, the standard \(1/2\) guarantee for unconstrained nonnegative submodular maximization [33] does not directly apply. We therefore use the method as a scalable heuristic and evaluate its solution quality empirically. The algorithm seeds both sets with the best singleton, processes every remaining candidate, and maintains \(X_i^s\subseteq Y_i^s\) until the two sets coincide.

4.4 Rate-Based Routing Protocol Design↩︎

Formal constraints. Let \(\mathcal{D}=\{(s,e):s\ne e,\;d_{se}>0\}\) be the set of active payment demands, and let \(\mathbb{P}_{se}\) be the candidate paths for demand \((s,e)\). For path \(p\), let \(r_p\geq0\) denote its payment rate, and define \[R_{se}=\sum_{p\in\mathbb{P}_{se}}r_p,\qquad r_{ab}=\sum_{(s,e)\in\mathcal{D}}\sum_{\substack{p\in\mathbb{P}_{se}\\(a,b)\in p}}r_p. \label{eq:aggregate-rates}\tag{19}\] For channel \(\{a,b\}\), let \(b_{ab}\) and \(b_{ba}\) be the current directional balances, with \(b_{ab}+b_{ba}=c_{ab}\); let \(b_{\min}\) be the liquidity reserve and \(c_{ab}^{\rm eff}\) the amount available to in-flight TUs. During confirmation delay \(\Delta\), SHARE solves \[\begin{align} \max_{\{r_p\}}\quad &\sum_{(s,e)\in\mathcal{D}}\log R_{se} \tag{20}\\ \text{s.t.}\quad &R_{se}\Delta\leq d_{se}, &&\forall(s,e)\in\mathcal{D}, \tag{21}\\ &r_{ab}+r_{ba}\leq c_{ab}^{\rm eff}/\Delta, &&\forall\{a,b\}\in\mathbb{E}, \tag{22}\\ &r_{ab}-r_{ba}\leq(b_{ab}-b_{\min})/\Delta, &&\forall\{a,b\}\in\mathbb{E}, \tag{23}\\ &r_{ba}-r_{ab}\leq(b_{ba}-b_{\min})/\Delta, &&\forall\{a,b\}\in\mathbb{E}, \tag{24}\\ &r_p\geq0, &&\forall p. \end{align}\] The capacity constraint limits total in-flight value, while Equations 23 and 24 prevent either direction from depleting its reserve.

Each smooth node applies projected primal–dual updates. Let \(\lambda_{ab}\) be the capacity multiplier, \(\mu_{ab}\) and \(\mu_{ba}\) the directional-liquidity multipliers, and \(\nu_{se}\) the demand multiplier. With step sizes \(\kappa\), \(\eta\), and \(\chi\), respectively, \[\begin{align} \lambda_{ab}^{+}&=\left[\lambda_{ab}+\kappa\left(r_{ab}+r_{ba}-c_{ab}^{\rm eff}/\Delta\right)\right]_{+}, \tag{25}\\ \mu_{ab}^{+}&=\left[\mu_{ab}+\eta\left(r_{ab}-r_{ba}-(b_{ab}-b_{\min})/\Delta\right)\right]_{+}, \tag{26}\\ \mu_{ba}^{+}&=\left[\mu_{ba}+\eta\left(r_{ba}-r_{ab}-(b_{ba}-b_{\min})/\Delta\right)\right]_{+}, \tag{27}\\ \nu_{se}^{+}&=\left[\nu_{se}+\chi(R_{se}\Delta-d_{se})\right]_{+}. \tag{28} \end{align}\] The signed directional prices are \(\xi_{ab}=\lambda_{ab}+\mu_{ab}-\mu_{ba}\) and \(\xi_{ba}=\lambda_{ab}+\mu_{ba}-\mu_{ab}\). A negative signed price acts as a rebalancing credit. The charged service fee remains nonnegative: \(\textsf{fee}_{ab}=T_{\rm fee}[\xi_{ab}]_{+}\). We define the effective link price as \(\widehat{\xi}_{ab}=\xi_{ab}+\textsf{fee}_{ab}\) and the path price as \(\varrho_p=\sum_{(a,b)\in p}\widehat{\xi}_{ab}\). For logarithmic utility, the projected path-rate update is \[r_p^{+}=\left[r_p+\alpha\left(\frac{1}{R_{se}}-\nu_{se}-\varrho_p\right)\right]_{+}, \label{eq:rate-update}\tag{29}\] for \(p\in\mathbb{P}_{se}\). Global state from the preceding epoch initializes these prices, while current requests determine the local updates. Each payment is split over at most \(K\) selected paths, consistent with the \(K\) TUs defined in Section 3.

Congestion control. Price updates react to persistent load but may not immediately absorb queue bursts. SHARE therefore maintains a bounded window \(w_p\in[w_{\min},w_{\max}]\) for each path. If queue delay exceeds \(T\) or queued value exceeds the window, the smooth node decreases the window by \(\beta\) and caps the sending rate. After successful transmission, it increases the window additively using \(\gamma\). Algorithm 5 summarizes one update epoch.

Compared with Spider [13], SHARE differs in three respects. It incorporates PCH service fees, combines rate control with queue-based congestion control, and delegates route computation to attested PCH enclaves rather than requiring senders to compute complete paths.

4.5 Channel Concurrency↩︎

Concurrent channels. Multi-hop payments temporarily lock liquidity on intermediate channels, which can limit concurrent forwarding [2], [3]. SHARE does not bypass the blockchain funding requirement for a base channel. Instead, smooth nodes pre-fund inter-PCH capacity on-chain and use attested off-chain state transitions to partition that capacity into concurrently processed logical channels or subchannels, analogous to Teechain’s off-chain execution model [20]. This design reduces online coordination latency without creating unfunded payment capacity.

In the Lightning protocol, peers negotiate the max_accepted_htlcs channel parameter, whose specified upper bound is 483⁵. Thus, increasing only the monetary capacity of one channel does not increase its number of simultaneous HTLC slots. Multiple pre-funded channels or logical processing lanes can expose more parallelism, but excessive concurrency also increases contention. We characterize this tradeoff through channel concurrency benefit theory (CCBT).

The number of channels that a smooth node can process concurrently depends on both workload and available resources. Workload consists of client payment requests. Resources include SGX processor and enclave memory, pre-funded channel liquidity, and TU queue capacity. Concurrent requests contend for these resources, while smooth nodes also synchronize shared state. We model these effects using the Universal Scalability Law (USL) [34].

Let \(N_{\rm CC}\) denote the number of concurrent channels. The system throughput is \[T(N_{\rm CC})= \frac{\varepsilon N_{\rm CC}}{1+\varsigma(N_{\rm CC}-1)+\varpi N_{\rm CC}(N_{\rm CC}-1)}, \label{CCBT}\tag{30}\] where \(\varepsilon>0\) is the single-channel throughput \(T(1)\), \(\varsigma\geq0\) captures contention for serialized resources, and \(\varpi\geq0\) captures coherence and synchronization overhead. Equation 30 remains positive, but its marginal gain can become negative as \(N_{\rm CC}\) grows. When \(\varpi>0\) and \(\varsigma<1\), the continuous relaxation is maximized at \(N_{\rm CC}^{*}=\sqrt{(1-\varsigma)/\varpi}\); an implementation selects a nearby feasible integer and adapts it to the observed workload.

Batch processing. SHARE batches state updates and seals the resulting checkpoints to reduce enclave bookkeeping and rollback-protection overhead [35]. Legacy SGX platform services exposed rate-limited hardware monotonic counters; therefore, the design does not increment a hardware counter for every TU. Instead, it follows Teechain [20] by aggregating updates for each sender–receiver pair and commits one authenticated checkpoint per batch. The security argument requires freshness and rollback detection, not a specific counter throughput.

5 Security Analysis↩︎

This section gives a property-based security analysis using a UC-inspired ideal functionality [36]. We specify the real protocol \(\boldsymbol{Prot}_{SHARE}\) and the leakage and external behavior captured by \(\mathcal{F}_{SHARE}\). The theorem establishes three scoped properties rather than a general UC realization; Appendix D provides the complete argument.

The static PPT adversary may observe the network, control corrupted smooth-node hosts, and drop, delay, replay, or reorder their messages. It corrupts at most \(t\) of \(\iota\geq2t+1\) KMG members before setup, where \(\tau_{\rm dec}=t+1\), but cannot break honest TEEs, extract honest shares, bypass enclave-bound decryption authorization, or forge attestation evidence. The analysis covers routing confidentiality, execution integrity, and receiver-side acceptance atomicity under explicit leakage; it excludes simultaneous path resolution under arbitrary scheduling. Relationship unlinkability remains conditional on the underlying PCH construction.

The ideal functionality \(\mathcal{F}_{SHARE}\) specifies protected inputs, permitted leakage, complete-set acceptance, and delayed outputs.

5.1 The Real-World Protocol Model \(\boldsymbol{Prot}_{SHARE}\)↩︎

\(\boldsymbol{Prot}_{SHARE}\) operates in the \((\mathcal{G}_{\rm{att}}, \mathcal{F}_{\rm{bc}})\)-hybrid model. A \(t\)-private, robust threshold scheme \(\mathcal{TE}=(\textsf{DKG},\textsf{Enc},\textsf{PDec},\textsf{VerifyShare},\textsf{Combine})\) supplies one-time key entries. KMG members release verifiable shares only to an authorized attested program, which combines at least \(\tau_{\rm dec}\) shares without reconstructing a complete private key. A shared hashlock and the Basic MPP terminal rule restrict an honest receiver to complete-set acceptance.

Appendix D gives the protocol algorithms and states the scoped security theorem.

5.2 The Ideal-World Functionality \(\mathcal{F}_{SHARE}\)↩︎

\(\mathcal{F}_{SHARE}\) separates confidential payloads from the identifiers, lengths, timing, routing metadata, and HTLC outcomes permitted by the leakage model.

Each participant may act as a client or smooth node over secure channels. For a protected message \(m\), the adversary learns only \(\ell(m)\). Under the standard delayed-output convention [36], outputs pass through the ideal adversarial interface before delivery.

Initialization exposes only its declared leakage. Processing reveals \(\ell(D_{\textcolor{colorwheel}{\textsf{tid}}})\) and the TU leakages, and records receiver acceptance only after every TU is locked and a valid common preimage is supplied. An incomplete set is not accepted; subsequent per-TU fulfillment or timeout remains visible through the HTLC interface. The sender receives a proof and acknowledgment only after all TU fulfillments are observed.

Under the stated cryptographic, attestation, and HTLC assumptions, Theorem 1 establishes routing confidentiality, execution integrity, and receiver-side acceptance atomicity against static corruption of at most \(t\) KMG members.

6 Evaluation↩︎

6.1 Experiment Setup↩︎

Our evaluation uses MATLAB simulations and an LND/SGX prototype. Fig. 6, Fig. 7, Fig. 10, and Table 1 are simulation results; Fig. 8 and Fig. 9 are produced by a prototype that executes routing and concurrent-channel logic inside SGX. We simulate networks with 100 and 3,000 nodes. The prototype runs on an Intel i7-9750H CPU with SGX support, 32 GB RAM, a 500 GB SSD, and a 10 Gbps network card. Following Spider’s benchmark, we generate Watts–Strogatz topologies using ROLL [37]; capacities follow the heavy-tailed Lightning distribution [38], transaction directionality is derived from a preprocessed Lightning dataset, and amounts follow the credit-card dataset [39].

Parameter settings. The minimum, average, and median channel capacities are 10, 403, and 152 tokens. The timeout is 3 seconds, TU values range from 1 to 4 tokens, and \(K=5\). We use \(\zeta_{mn}=0.02\,hops_{mn}\), \(\delta_{nl}=0.01\,hops_{nl}\), and \(\epsilon_{nl}=0.05\,hops_{nl}\). The allocation experiment sets \(f_n=0\), focusing on the restricted management–synchronization objective. Each queue holds 8,000 tokens, \(\beta=10\), \(\gamma=0.1\), \(\Delta_{\rm upd}=200\) ms, \(T=400\) ms, \(N_{\rm CC}=5\), and the default batch wait is 100 ms.

Evaluation scope. The prototype evaluates TEE-assisted routing and channel concurrency, but excludes a production threshold-DKG service and KMG partial-decryption communication. Reported latency and throughput therefore exclude offline pool-refill cost and online \(\mathcal{TE}.\textsf{PDec}\) network overhead. The retained artifacts contain aggregate curves, so the following results are descriptive point estimates without confidence intervals.

Let \(\mathcal{T}\) be the generated transactions and \(\mathcal{T}_{\rm succ}\) the completed subset. We use \[\mathrm{TSR}=\frac{|\mathcal{T}_{\rm succ}|}{|\mathcal{T}|}\times100\%,\qquad \mathrm{NTP}=\frac{\sum_{t\in\mathcal{T}_{\rm succ}}\mathrm{val}(t)}{\sum_{t\in\mathcal{T}}\mathrm{val}(t)}\times100\%. \label{eq:evaluation-metrics}\tag{31}\] TSR measures completion frequency, whereas normalized throughput (NTP) weights completion by payment value. Average gains over operating points \(\Omega\) are computed as \(|\Omega|^{-1}\sum_{o\in\Omega}(M_A(o)-M_B(o))/M_B(o)\times100\%\).

6.2 Performance of SHARE↩︎

We evaluate SHARE along three axes: performance relative to non-TEE schemes, throughput and latency relative to TEE-assisted baselines, and the effect of concurrent channels. The comparison focuses on the mechanisms that SHARE changes: multi-PCH coordination, distributed routing, and TEE-assisted execution.

6.2.1 Comparison with Non-TEE Schemes↩︎

The MATLAB comparison uses the same simulator, topology, capacity assignment, trace, timeout, and TU constraints for all non-TEE routing rules. Splicer [1] is SHARE’s closest non-TEE ablation, while Spider [13], Flash [14], Flare [10], and A\(^2\)L [5] represent source-routing, landmark, and single-hub designs.

As shown in Fig. 6 and Fig. 7, SHARE achieves the highest TSR at both network scales in the tested settings. Its average relative gain over the comparison set is 51.1% when channel size varies and 43.6% when transaction size varies. As the update interval increases, all methods complete fewer transactions before timeout, but SHARE remains above 91.0% TSR and exceeds Spider by 7.2% and 13.8% at the two scales. It also exceeds A\(^2\)L by 38.8% and 60.3%, with a 78.2% average advantage over A\(^2\)L. Relative to Splicer, SHARE improves TSR by 6.3% on average.

Using Equation 31 , SHARE achieves an average NTP gain of 181.5% over the comparison set; the corresponding large-scale gain is 189.3%. Relative gains over Spider are 156.0% and 161.3% at the two scales, and gains over A\(^2\)L are 202.5% and 235.4%. SHARE also exceeds Splicer by 130.9% on average, showing that it completes a larger fraction of payment value under the tested contention and timeout settings.

Overall, the simulations support the claim that collaborative PCH routing improves completion and payment-value throughput in the evaluated workloads.

6.2.2 Comparison with TEE-Assisted Schemes↩︎

We evaluate NTP and latency under a trace containing up to 10,000 transactions. Because Teechain [20] and Speedster [21] have different native system models, Fig. 8 compares workload-matched TEE-protected execution paths rather than complete protocol deployments.

In this prototype, SHARE’s average NTP is 72.6% and 90.9% higher than the adapted Speedster and Teechain execution paths, respectively. All three curves initially increase with transaction volume, but beyond approximately 2,000 transactions the adapted baselines grow more slowly, whereas SHARE continues to increase over a wider range.

Latency initially decreases as larger batches amortize fixed execution costs. Beyond approximately 5,000 transactions, latency increases for the adapted Speedster and Teechain paths, while SHARE remains more stable, which is consistent with moving route computation away from clients.

These results concern the measured execution paths and exclude the production DKG/PDec service.

6.2.3 Performance Benefits of Concurrent Channels↩︎

Fig. 9 shows normalized peak throughput as \(N_{\rm CC}\) varies under three batch waits. Throughput first increases and then decreases, reflecting the transition from parallelism gains to contention overhead. A 100 ms wait and \(N_{\rm CC}=5\) provide the best measured tradeoff and are used as defaults.

6.3 Evaluation of Smooth Node Allocation↩︎

This subsection evaluates the restricted allocation objective from Section 4.2 with \(f_n=0\), focusing on the management–synchronization tradeoff and routing behavior under smooth-node deployment.

6.3.1 Efficiency Tradeoff↩︎

Fig. [fig95para-cost] and Fig. [fig95tradeoff] show how the restricted balance cost changes with \(\omega\). The heuristic tracks the exact small-instance solution over the displayed values, and the cost tradeoff follows the expected trend: higher \(\omega\) favors fewer smooth nodes and lower synchronization overhead, whereas lower \(\omega\) favors more smooth nodes and lower client-management overhead.

Fig. [number-small] and Fig. [number-large] show that the selected number of smooth nodes increases with network scale, matching the need for more coordination capacity as the client population grows.

6.3.2 Allocation Effectiveness Verification↩︎

Fig. [cost-small] and Fig. [cost-large] compare latency and traffic overhead with and without smooth nodes. In the small-scale setting, SHARE reduces latency by 72.0% relative to the PCH-free baseline and has 5.5% higher average latency than Splicer, reflecting the measured overhead of SHARE’s simulated TEE-assisted path.

6.4 Routing Strategy Selection in SHARE↩︎

We now select the routing primitives used by SHARE for the final configuration. The goal of this subsection is not to show that every candidate is equally good, but to justify the choices that appear in the protocol and the implementation.

6.4.1 Path Types↩︎

Table 1 compares \(k\)-shortest paths (KSP), the heuristic selector, edge-disjoint widest paths (EDW), and edge-disjoint shortest paths (EDS). EDW performs best at both scales, indicating that wide disjoint paths use heavy-tailed channel liquidity more effectively than hop-count optimization alone.

6.4.2 Number of Paths↩︎

TSR increases when moving from 1 to 3 to 5 EDW paths, but saturates and slightly drops at 7 paths. We therefore set the default path count to 5, balancing load spreading and routing overhead.

6.4.3 Scheduling Algorithms↩︎

We compare FIFO, LIFO, shortest-payment-first (SPF), and earliest-deadline-first (EDF) scheduling. LIFO yields the highest TSR at both scales; SPF may defer large payments, while EDF prioritizes deadlines without directly considering liquidity. SHARE therefore uses LIFO in the evaluated configuration.

In practice, these routing choices can be adjusted for target workloads.

7 Conclusion↩︎

This paper shows that PCHs can be organized as distributed service infrastructure rather than isolated payment relays. SHARE coordinates multiple TEE-enabled smooth nodes to jointly allocate service load, route concurrent payments, and protect sensitive routing information. The main finding is that multi-PCH coordination improves both scalability and service robustness: load-aware allocation reduces concentration at individual hubs, rate-controlled multipath routing preserves channel liquidity under contention, and TEE-assisted execution supports confidential coordination without requiring every client to run trusted hardware. The security analysis establishes routing confidentiality, execution integrity, and receiver-side acceptance atomicity under the stated leakage and threshold-corruption assumptions.

The evaluation further indicates that this architecture can translate the above design goals into measurable service benefits, including higher transaction completion and larger completed payment value under the tested workloads. These results suggest that secure multi-hub coordination is a viable direction for building scalable, privacy-preserving off-chain payment services. Future work will extend SHARE with production-grade asynchronous threshold-key management and broader deployment studies on longitudinal Lightning snapshots, heterogeneous hardware, and more dynamic workload and failure settings.

8 Background and Preliminaries↩︎

This appendix provides background on payment-channel liquidity and trusted execution.

8.1 Payment Channel Network↩︎

An example payment channel network (PCN) is shown in Fig. 11, where bidirectional payment channels connect nodes \((A,C)\) and \((C,B)\). Each direction initially holds 10 tokens. When \(A\) transfers five tokens to \(B\), intermediary \(C\) forwards the payment over the two channels and receives a routing fee. A hash timelock contract (HTLC) ensures that \(C\) can claim the incoming conditional payment only if it completes the outgoing transfer before the timeout.

8.2 Transaction Deadlocks in PCNs↩︎

To illustrate a local liquidity deadlock, consider Fig. [fig95PCN2]. The offered flows are \(A\rightarrow B\) at 1 token/s through \(C\), \(B\rightarrow A\) at 2 tokens/s through \(C\), and an additional \(C\rightarrow B\) flow at 2 tokens/s. Each channel initially holds 10 tokens in each direction. On channel \((A,C)\), \(C\) forwards 2 tokens/s toward \(A\) but receives only 1 token/s from \(A\); on channel \((C,B)\), it sends 3 tokens/s toward \(B\) (one relayed token plus two local tokens) but receives only 2 tokens/s from \(B\). Consequently, \(C\) loses one unit of outbound liquidity per second on both channels. Once either outbound balance is exhausted, otherwise feasible payments can no longer be forwarded through \(C\), and achieved throughput falls below the offered load, as shown in Fig. [fig95PCN3]. This example motivates rate control that accounts for directional liquidity rather than aggregate channel capacity alone.

8.3 Trusted Execution Environment↩︎

SHARE uses Intel SGX as its trusted execution environment (TEE). SGX isolates enclave code and data from the host operating system, while remote attestation allows a verifier to check the enclave measurement and platform security state before provisioning secrets or accepting protocol messages.

The evidence is verified through the applicable SGX attestation infrastructure, such as IAS for legacy EPID platforms or DCAP/PCS for ECDSA platforms. The quote authenticates the enclave identity and trusted-computing-base status; it does not automatically authenticate arbitrary application outputs. SHARE therefore binds an enclave-held application verification key to the attested session and uses that key to authenticate subsequent routing and decryption-authorization messages. The parties establish an encrypted channel only after verifying the platform evidence.

9 Additional Details of System Model↩︎

9.1 Topology Structure↩︎

Fig. 12 illustrates the star topology commonly used by single-PCH schemes, where clients maintain channels with one intermediary. SHARE generalizes this structure to a multi-star topology in which clients are assigned across multiple TEE-enabled smooth nodes. Fig. [PCH2] shows an example with \(N\) senders, \(M\) receivers, and \(Z\) smooth nodes.

9.2 Trust Model↩︎

SHARE takes an authenticated candidate set as input to the allocation problem. Candidate nomination, governance, collateral, and dispute resolution are external deployment policies and are not modeled by the routing protocol or the UC theorem. A deployment may use voting or stake-based governance to construct this set, but SHARE requires only that every admitted candidate can produce valid platform evidence and that the allocation contract receives authenticated cost inputs.

At the beginning of an allocation epoch, the contract evaluates the authenticated candidate set using the objective in Section 4.2. The resulting active set remains fixed for that epoch and is recomputed when cost inputs or candidate eligibility change. Consensus on the contract output is provided by the underlying blockchain; SHARE does not assume that all candidates independently observe identical request distributions or reach an off-chain unanimous decision.

Fig. 13 illustrates the separation between external candidate governance and SHARE’s allocation step. The security analysis does not claim that peers can always detect collusion or that collateral alone deters malicious behavior. Instead, it relies on verified enclave execution, the stated threshold-corruption bound, and authenticated communication. Sensitive transaction values and routing inputs are released only inside authorized enclaves, subject to the leakage defined by \(\mathcal{F}_{SHARE}\).

9.3 Communication Model↩︎

As shown in Fig. 14, SHARE uses bounded communication epochs. At the beginning of epoch \(e+1\), each PCH synchronizes the finalized state from epoch \(e\), including topology, channel conditions, and aggregate flow rates. Each PCH then combines this preceding global state with newly received local requests to update its routing decisions. Receiver acknowledgments are returned through the corresponding PCHs. The security proof additionally requires all sensitive messages and threshold-decryption shares to travel over attestation-authenticated channels.

10 Problem Statement↩︎

Multi-PCH allocation problem. A long-running allocation contract selects active PCHs from the authenticated candidate set and assigns clients to them. The active set remains fixed during an allocation epoch and is recomputed when cost inputs or candidate eligibility change. The model balances client-management, deployment, and inter-PCH synchronization costs; Sections 4.2 and 4.3 give the formal objective and solution methods.

Geographically distributed clients experience different communication and routing costs. Activating more PCHs can reduce client-side management cost but increases deployment and synchronization overhead. SHARE therefore seeks a cost-aware deployment rather than assuming either one global hub or one hub per client cluster.

Routing problem. Sender-side source routing becomes increasingly expensive as the network and concurrent workload grow. SHARE delegates routing decisions to multiple PCHs and evaluates networks with up to 3,000 nodes. Inspired by packet switching, it splits a payment into independently routable TUs and controls their rates subject to directional liquidity, in-flight capacity, and Min-TU/Max-TU constraints. Spider [13] demonstrates the utility of multipath rate control; SHARE adapts this principle to attested multi-PCH coordination.

Different intermediate nodes may participate in paths selected for different TUs. Assuming that the underlying PCH construction provides relationship unlinkability, splitting does not intentionally expose additional endpoint linkage beyond the leakage specified by \(\mathcal{F}_{SHARE}\). SHARE’s UC theorem covers routing confidentiality and execution integrity, not a new proof of relationship unlinkability. Section 4.4 presents the routing protocol.

11 Security Analysis↩︎

11.1 The Real-World Protocol Model \(\boldsymbol{Prot}_{SHARE}\)↩︎

Table 2 summarizes the notation used in the protocol formalization, which follows Canetti’s UC framework [36]. We formalize SHARE as \(\boldsymbol{Prot}_{SHARE}\) in Algorithm [SHAREProtocol]. The protocol is defined in a hybrid model with two ideal functionalities: (i) the attested-execution functionality \(\textcolor{brickred}{\mathcal{G}_{\rm{att}}}\) of Pass et al.⁶, and (ii) the blockchain functionality \(\textcolor{brickred}{\mathcal{F}_{\rm{bc}}}\) in Algorithm 16.

\(\textcolor{brickred}{\mathcal{G}_{\rm{att}}}\) abstracts a general-purpose secure processor. As shown in Algorithm 15, initialization generates an attestation key pair \((\textsf{mpk},\textsf{msk})\). The processor keeps \(\textsf{msk}\) private and exposes \(\textsf{mpk}\) through “getpk()". A party invokes”install" to create an enclave, load \(\textsf{prog}\), and obtain a fresh enclave identifier \(eid\). On “resume", \(\textcolor{brickred}{\mathcal{G}_{\rm{att}}}\) executes \(\textsf{prog}\) and signs the output and its execution metadata under \(\textsf{msk}\).

The blockchain ideal functionality \(\textcolor{brickred}{\mathcal{F}_{\rm{bc}}}\) defines a general-purpose blockchain protocol that models an append-only ledger. As shown in Algorithm 16, \(\textcolor{brickred}{\mathcal{F}_{\rm{bc}}}\) can append blockchain data associated with a transaction tid to an internal Storage via the “append" command. The parameter succ is a function that models the notion of the appended transaction validity. The basic operations of the payment channel, e.g., initialization, creation, and settlement, invoke the functionalities in \(\textcolor{brickred}{\mathcal{F}_{\rm{bc}}}\). Due to page limits, we omit these descriptions in \(\boldsymbol{Prot}_{SHARE}\).

We emphasize that SHARE’s security is designed to be independent of specific blockchain and TEE instances, as long as they provide the functionalities required by \(\textcolor{brickred}{\mathcal{F}_{\rm{bc}}}\) and \(\textcolor{brickred}{\mathcal{G}_{\rm{att}}}\).

Following the workflow described in §3.1, we formalize \(\boldsymbol{Prot}_{SHARE}\) (Algorithm [SHAREProtocol]) in three parts:

(i) Payment initialization: (Lines [A3l2]-[A3l5]) Before the sender invokes “init", the receiver generates a one-time preimage \(z_{\textsf{tid}}\), publishes \(h_{\textsf{tid}}=\textsf{H}(z_{\textsf{tid}})\) in the invoice, and retains the preimage. The sender passes the invoice commitment to its assigned smooth node \(\textcolor{brickred}{\mathcal{S}_i}\). (Lines [A3l18]-[A3l21]) Before processing payments, \(\textcolor{brickred}{\mathcal{S}_i}\) installs \(\textsf{prog}\) in \(\textcolor{brickred}{\mathcal{G}_{\rm{att}}}\) and receives only \((\textsf{eid}_i,\textsf{mpk}_i)\); the corresponding secret signing key remains internal to \(\mathcal{G}_{\rm att}\). (Lines [A3l22]-[A3l24]) During preprocessing, the \(\iota\) KMG members, with \(\iota\geq2t+1\) and \(\tau_{\rm dec}=t+1\), jointly generate a pool of one-time threshold-key entries. Online, they atomically bind one unused entry to the uniformly sampled transaction identifier \(\textcolor{colorwheel}{\textsf{tid}}\), return only \((\textsf{pk}_{\textcolor{colorwheel}{\textsf{tid}}},\textsf{vk}_{\textcolor{colorwheel}{\textsf{tid}}})\), and retain their private-key shares inside their enclaves.

(ii) Payment processing: (Lines [A3l6]-[A3l12]) Client \(\textcolor{brickred}{\mathcal{P}_i}\) encrypts \(D_{\textcolor{colorwheel}{\textsf{tid}}}\) under \(\textsf{pk}_{\textcolor{colorwheel}{\textsf{tid}}}\), conditionally locks the corresponding funds under \(h_{\textsf{tid}}\), and calls “pay_t". Before releasing a share, each KMG member verifies enclave-generated authorization evidence binding the identifier and ciphertext hash and delivers the share only through the attested enclave channel. The enclave invokes \(\mathcal{TE}.\textsf{Combine}\) after collecting at least \(\tau_{\rm dec}\) valid shares. It splits the recovered demand into \(K\) TUs that share \(h_{\textsf{tid}}\), allocates one pre-generated key entry per TU, and dispatches the TUs as conditional transfers. The destination enclave applies the same authorization and threshold-decryption checks and returns \(\textsf{READY}_{\textsf{tuid}_k}\) only after the corresponding HTLC is irrevocably locked.

(iii) Complete-set acceptance and acknowledgment: (Lines [A3l60]-[A3l65]) After all \(K\) readiness messages are available, \(\textcolor{brickred}{\mathcal{S}_j}\) asks \(P_r\) to release \(z_{\textsf{tid}}\). It verifies \(\textsf{H}(z_{\textsf{tid}})=h_{\textsf{tid}}\) and issues fulfillment for the complete HTLC set with the common preimage. If any TU fails or expires before this point, no preimage is released, the receiver does not accept the payment, and pending transfers follow their timeout branches. After release, individual paths resolve through the underlying HTLC protocol and may complete at different times. Only after every TU fulfillment has been observed does \(\textcolor{brickred}{\mathcal{S}_i}\) attest the final state and return \((\sigma_{\textcolor{colorwheel}{\textsf{tid}}},\textsf{ACK}_{\textcolor{colorwheel}{\textsf{tid}}})\) to the sender.

11.2 The Ideal-World Functionality \(\textcolor{brickred}{\mathcal{F}_{SHARE}}\)↩︎

Algorithm [F-SHARE] specifies the ideal functionality \(\textcolor{brickred}{\mathcal{F}_{SHARE}}\). Each participant \(\textcolor{brickred}{\mathcal{P}_i}\) may act as a client or a smooth node, and parties communicate over secure channels. The leakage function \(\ell(\cdot)\) explicitly reveals message length and permitted routing metadata but not the protected payload. We use the standard delayed-output convention [36]: an output is exposed through the ideal adversarial interface and delivered to its recipient only after acknowledgment. For an encrypted message \(m\), that interface receives only \(\ell(m)\).

(i) During initialization, the adversary learns the explicitly leaked request metadata, the payment hash, and the transaction identifier. (ii) During processing, it learns \(\ell(D_{\textcolor{colorwheel}{\textsf{tid}}})\) and \(\ell(D_{\textcolor{colorwheel}{\textsf{tuid}}})\) for each encrypted TU. The functionality records receiver acceptance only after every conditional lock is established and the receiver supplies a valid common preimage; otherwise, it records failure without releasing the preimage. After acceptance, each TU resolves through the underlying HTLC interface, and sender success is returned only after every fulfillment is observed. (iii) The execution proof and payment acknowledgments are delivered privately to their designated callers. This captures black-box execution modulo the stated leakage and the externally visible HTLC outcomes without modeling all paths as one atomic ledger transition.

11.3 Security Analysis↩︎

We state the scoped security of \(\boldsymbol{Prot}_{SHARE}\) in Theorem 1.

References↩︎