Pith. sign in

REVIEW 4 major objections 6 minor 36 references

Depermissioning Web3: a Permissionless Accountable RPC Protocol for Blockchain Networks

T0 review · 4 major / 6 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read PARP makes blockchain RPC permissionless and accountable by pairing light-client Merkle verification with fraud proofs and payment channels.

desk verdict A serious systems prototype combining light-client checks, payment channels, and slashing for RPC, but a payment-response gap lets nodes bill without serving; needs a security pass before publication. read the letter →

arxiv 2506.03940 v2 pith:IPLSJT3C submitted 2025-06-04 cs.CR cs.DC

Weihong Wang , Tom Van Cutsem This is my paper
classification cs.CRcs.DC
keywords blockchainRPClightclientfraudproofpaymentchannelpseudonymityaccountabilityEthereumnode-as-a-service
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper proposes PARP, a protocol that restructures the RPC serving layer of blockchain networks so that light clients and full nodes can interact without registration or API keys while holding both sides accountable. Clients verify every response against block headers using Merkle proofs, full nodes put up collateral that can be slashed if fraud proofs show they lied, and payment channels let clients pay per request without revealing identity. The paper argues that this combination removes the need to trust centralized node providers for data integrity, gives full nodes an economic reason to serve, and does so with overhead small enough for practical use. A working Ethereum prototype is presented as evidence that the protocol is compatible with existing networks.

What carries the argument

The load-bearing mechanism is the light-client verification loop. The client holds fresh block headers from an independent source, every full-node response must include a Merkle proof tied to the header's trie root, and fraud proofs let a third 'witness' full node relay the request/response pair to an on-chain contract, which re-checks Merkle proof, signatures, payment amounts, and block height, slashing the serving node's collateral on any failed check. A unidirectional payment channel, with each request carrying a signed cumulative payment amount, is the economic anchor: the client prepays a budget into the channel, each request commits more of that budget, and the full node redeems the final amount at closure.

What would settle it

Run a PARP testbed where the light client's only header source is a malicious full node that supplies a false but internally consistent header; if the client accepts an RPC response whose Merkle proof verifies against that false header, and the on-chain fraud module also upholds the proof because it derives the root from the same header, the claimed accountability guarantee is disproven.

Watch

Extended reading notes

Core claim

PARP's central claim is that a blockchain RPC layer can be both permissionless and accountable: any client can pseudonymously request data from any full node that has deposited collateral, and any full node can be paid for its work, while a combination of light-client-style Merkle proof verification and on-chain fraud proofs ensures that a lying full node loses its deposit. The protocol wraps each standard RPC request with a signed cumulative payment and each response with a Merkle proof of inclusion against a block header the client obtains independently, and it defines an on-chain dispute path that re-verifies the proof and slashes the node's collateral if the response is inconsistent. The authors demonstrate this with a Geth-based Ethereum prototype and report measured overheads in message size, latency, gas cost, and node resource use, concluding that the protocol integrates efficiently into real-world blockchain networks.

Load-bearing premise

The protocol works only if the light client can obtain a correct, current block header from some source outside the PARP full node and without paying for it; if an attacker controls every header source the client can reach, the client will accept false responses and the fraud-proof mechanism will not catch them.

Editorial extensions

If this is right

  • Clients can switch full nodes at will without registration or identity, so a censoring or misbehaving node can be abandoned at negligible cost.
  • A full node that returns incorrect data can be reported anonymously and have its deposit slashed, with the recovered funds split among the reporter, a witness node, and other serving nodes.
  • Full nodes gain direct payment per served request, giving them an economic incentive to serve light clients that does not exist in the base protocol.
  • The Ethereum prototype adds only hundreds of bytes per message and a few milliseconds per call, and one-time on-chain costs can be pushed to Layer-2 networks, keeping the protocol viable for real deployments.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The paper does not analyze the case where the client's header source is itself malicious; a natural extension is to make header sourcing an explicit part of PARP, e.g., by sampling multiple independent nodes or using a sync committee.
  • The 'Proof of Serving' reward sketched in Section VIII would require Sybil resistance; without it, a full node could create fake light clients to inflate served volume and claim disproportionate block rewards.
  • The protocol protects data integrity but not content privacy: the serving node still sees the client's IP address and the exact requests, so combining PARP with an anonymity network would close that gap but would require routing payment channels through the same network.
  • If PARP gains adoption, the economics of running a full node shift from validator rewards alone to a serving market, which could make light-client access cheaper and more reliable as nodes compete on latency and price rather than on identity.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 6 minor

Summary. The paper proposes PARP, a protocol that wraps a blockchain's RPC layer with light-client Merkle-proof verification, a fraud-proof mechanism, and unidirectional payment channels, aiming to let light clients and full nodes interact pseudonymously while remaining mutually accountable. The protocol's lifecycle covers channel bootstrapping, opening, request/response, and closure with dispute; the on-chain modules handle deposits, channel state, and fraud slashing. The authors implement a prototype for Ethereum by modifying Geth and a custom light client, and they report communication, latency, on-chain cost, and scalability measurements. The central claim is that PARP provides permissionless, accountable, and economically sustainable RPC service.

Significance. The problem addressed is real and timely: centralized node providers dominate Ethereum RPC access, and existing permissionless public endpoints lack accountability. The paper's design leverages standard, well-understood primitives (Merkle proofs, payment channels, collateral slashing), and the open-source prototype on Geth is a concrete artifact that could be built upon. The measurement study, despite the issues detailed below, is a useful first-step feasibility demonstration, and the related-work comparison is informative. If the design flaw in the settlement mechanism is repaired and the evaluation data are corrected, the protocol could be a meaningful contribution to decentralized RPC infrastructure.

major comments (4)
  1. [Section IV-E.3, IV-E.4, IV-F] The bilateral-accountability claim is contradicted by a payment-response gap. In Section IV-E.3 the request carries a signed cumulative payment (a, sigma_a), and the text states that both the light client and the full node primarily track the requests; the full node therefore retains a valid payment proof even if it never sends a response. Section IV-E.4 says closure requires only the latest signed payment amount, with the CMM accepting the highest valid a; no proof of service is required. The slashing conditions in Section IV-F cover only payment mismatch, stale block height, and invalid Merkle proof, all of which presuppose a validly signed response. A response with an invalid signature is classified as "invalid," and the text explicitly says the client cannot hold the full node accountable for fraud. Consequently, a malicious full node can collect cumulative payments for requests it never answered (or answered with an invalid signature), close the channel, and have the client's budget transferred to it without any on-chain evidence of non-service. This directly undermines the "bilateral assurances" design goal in Section IV-A, and the limitation list in Section VIII does not acknowledge the gap. The settlement logic must require a valid signed response corresponding to each claimed payment, or an equivalent on-chain proof of service, before funds are released.
  2. [Section VI-F, Figure 7] The scalability evaluation is not reproducible from the manuscript: Figure 7 is labeled "Additional computation steps required in processing a PARP request and response," the same caption as Figure 5, and no CPU/memory plot is actually shown. The text of Section VI-F reports specific numbers (14.3% CPU and 2.63% memory at 20 clients) but the figure that is supposed to substantiate them is absent. The conclusion in Section VI-G that PARP maintains "acceptable CPU and memory usage" therefore rests on an unverifiable claim. The authors should replace the duplicate figure with the actual CPU/memory measurements, ideally including per-client breakdowns and variability across runs.
  3. [Section VI-D, Table III] Table III contains an internally inconsistent measurement: for the read workload, "(D) Response Verification (proof)" is 5.78 ms while "(D) Response Verification (in total)" is 1.01 ms. A total that includes Merkle-proof verification cannot be smaller than the proof verification alone. This suggests a unit error or data-entry mistake (e.g., 0.578 ms versus 5.78 ms). Since the latency overhead is central to the feasibility claim, the authors should correct the table and report the variance over the 100 requests rather than only the average.
  4. [Sections IV-D and I] The paper does not provide a threat model or security analysis for the "accountability" property it claims. Section IV-D assumes the light client can fetch a correct current header from some full node without payment, and all integrity checks and fraud proofs reduce to verification against that header root. If an attacker controls every header source available to the client, the client cannot detect even obviously incorrect RPC responses, and the fraud-proof mechanism collapses because the CMM also relies on the same root. This is a standard light-client bootstrap assumption, but it must be stated as an explicit trust assumption with a precise adversarial model; the paper should discuss the minimum number of independent honest header sources required and the consequences when that condition fails. Without this, the claim in Section I that PARP "does not require trust in a centralized third party" is not precisely scoped.
minor comments (6)
  1. [Section VI-C] The communication-cost discussion would be clearer with a field-wise breakdown of the 226-byte request overhead and the 187-byte response overhead, rather than only aggregate byte counts.
  2. [Figure 4] The state-transition diagram is dense; labeling each edge with the corresponding message or condition from Section V-B would make it easier to verify the protocol's state logic.
  3. [Table I] The table uses several symbols (checks, '*', 'G#', and a cross) whose meaning is not immediately clear; moving the legend directly beneath the table or using concise column headers would improve readability.
  4. [Section II-B] The provider-traffic statistics are based on a dataset from Torres et al. (2023); the authors should state the data collection period explicitly and note that the market may have shifted substantially.
  5. [Section IV-B] The full-node role mentions that nodes may be pruned to save disk space, but the protocol's Merkle proofs may require access to historical state; the authors should clarify how the fraud-proof and verification mechanisms handle pruned nodes.
  6. [Section VI-E] The on-chain cost table reports USD conversions assuming an ETH price of $4000 and gas prices of 12 Gwei / 0.1 Gwei; reporting raw gas costs as the primary metric would make the results less dependent on volatile assumptions.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: PARP is a constructive protocol design with benchmark-based evaluation, not a derivation from fitted inputs or self-citations.

full rationale

The paper does not fit parameters to data and then predict closely related quantities. Its central claims are that the proposed protocol provides mutual accountability via light-client verification, fraud proofs, and payment channels, and that the Ethereum prototype incurs acceptable overhead. The evaluation compares PARP against a standard Geth node as an external baseline, and the reported costs are measured, not derived from the protocol's own assumptions. The security model is stated as explicit trust assumptions (e.g., the light client obtains block headers from an independent source without payment, Section IV-D), not as a conclusion derived from the protocol itself. There are no load-bearing self-citations: the references to prior light-client and payment-channel work are standard background, and the authors do not invoke their own prior results to justify the design. The protocol's limitations are acknowledged in Section VIII, and while the skeptically noted payment-response gap is a potential correctness or incentive-design issue, it is not a circularity: the protocol does not define its conclusion into its premises. Overall, the derivation chain is self-contained and the central claims are supported by independent implementation and measurement, so the appropriate circularity score is 0.

Assumptions & free parameters 0 free parameters · 5 assumptions · 0 invented entities

The paper introduces new smart-contract modules and a witness-node role, but no new cryptographic or physical entities with independent falsifiable handles. No free parameters are fitted to data, since the protocol is a design and measurement study rather than a derivational model. The central claims rest on the external trust assumptions listed in the axioms.

assumptions (5)
  • domain assumption Light client can obtain a correct current block header from any full node without payment.
    Stated in Section IV-D. All data integrity checks and fraud proofs verify against this header root. An attacker who controls all reachable header sources defeats verification.
  • domain assumption Strong synchrony: messages between honest parties are delivered within a bounded delay.
    Stated in Section IV-D. Needed for the dispute window and liveness checks to operate correctly.
  • standard math Cryptographic primitives (signatures, hashes, Merkle proofs) are computationally secure.
    Assumed implicitly throughout; the security of the fraud-proof protocol and payment channel depends on these.
  • domain assumption Full node rational behavior is deterred by collateral slashing.
    The incentive model assumes slashing losses exceed gains from fraudulent responses. The paper does not quantify or prove this, listing formalization of cryptoeconomic incentives as future work.
  • domain assumption The underlying blockchain consensus is secure and produces canonical block headers.
    The protocol builds on the assumption that the network's consensus is sound, stated via the use of block headers as roots of trust.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Depermissioning Web3: a Permissionless Accountable RPC Protocol for Blockchain Networks." pith.science (2026). https://pith.science/paper/IPLSJT3C

@misc{pith2026250603940,
  author       = {Pith},
  title        = {Pith review of: Depermissioning Web3: a Permissionless Accountable RPC Protocol for Blockchain Networks},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/IPLSJT3C}},
  note         = {Machine review of arXiv:2506.03940}
}
read the original abstract

In blockchain networks, so-called "full nodes" serve data to and relay transactions from clients through an RPC interface. This serving layer enables integration of "Web3" data, stored on blockchains, with "Web2" mobile or web applications that cannot directly participate as peers in a blockchain network. In practice, the serving layer is dominated by a small number of centralized services ("node providers") that offer permissioned access to RPC endpoints. Clients register with these providers because they offer reliable and convenient access to blockchain data: operating a full node themselves requires significant computational and storage resources, and public (permissionless) RPC nodes lack financial incentives to serve large numbers of clients with consistent performance. Permissioned access to an otherwise permissionless blockchain network raises concerns regarding the privacy, integrity, and availability of data access. To address this, we propose a Permissionless Accountable RPC Protocol (PARP). It enables clients and full nodes to interact pseudonymously while keeping both parties accountable. PARP leverages "light client" schemes for essential data integrity checks, combined with fraud proofs, to keep full nodes honest and accountable. It integrates payment channels to facilitate micro-payments, holding clients accountable for the resources they consume and providing an economic incentive for full nodes to serve. Our prototype implementation for Ethereum demonstrates the feasibility of PARP, and we quantify its overhead compared to the base RPC protocol.

Figures

Figures reproduced from arXiv: 2506.03940 by the authors.

Figure 1
Figure 1. A schematic of the typical serving layer underlying [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. Primary participants in a PARP connection. [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Structure of a PARP request and a PARP response [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (4 more)
Figure 4
Figure 4. Figure 4: Tripartite state transition diagram illustrating the lifecycle of a PARP connection. [PITH_FULL_IMAGE:figures/full_fig_p006_4.png]
Figure 6
Figure 6. Figure 6: Merkle proof size variation with transaction index [PITH_FULL_IMAGE:figures/full_fig_p009_6.png]
Figure 5
Figure 5. Figure 5: Additional computation steps required in processing a [PITH_FULL_IMAGE:figures/full_fig_p009_5.png]
Figure 7
Figure 7. Figure 7: Additional computation steps required in processing a [PITH_FULL_IMAGE:figures/full_fig_p010_7.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

36 extracted references · 35 canonical work pages

  1. [1]

    (2024) Spin up your own ethereum node

    Ethereum. (2024) Spin up your own ethereum node. [Online]. Available: https://ethereum.org/en/developers/docs/nodes-and-clients/ run-a-node/#requirements

    work page 2024

  2. [2]

    (2024) Nodes as a service

    ——. (2024) Nodes as a service. [Online]. Available: https://ethereum. org/en/developers/docs/nodes-and-clients/nodes-as-a-service/

    work page 2024

  3. [3]

    [Online]

    (2024) Web3 development platform — ipfs api &gateway — blockchain node service. [Online]. Available: https://www.infura.io/

    work page 2024

  4. [4]

    (2024) Alchemy

    Alchemy. (2024) Alchemy. [Online]. Available: https://www.alchemy. com/

    work page 2024

  5. [5]

    M. M. (2022) My first impressions of web3. [Online]. Available: https://moxie.org/2022/01/07/web3-first-impressions.html

    work page 2022

  6. [6]

    M. Support. (2023) Why infura cannot serve certain areas. [Online]. Available: https://support.metamask.io/troubleshooting/ why-infura-cannot-serve-certain-areas

    work page 2023

  7. [7]

    [Online]

    (2024) Ankr — the fastest web3 infrastructure. [Online]. Available: https://www.ankr.com/

    work page 2024

  8. [8]

    [Online]

    (2024) Quicknode - blockchain infrastructure powering secure, decentralized innovation. [Online]. Available: https://www.quicknode. com/

    work page 2024

Show all 36 references
  1. [9]

    [Online]

    (2024) Fast and reliable blockchain infrastructure provider - chainstack. [Online]. Available: https://chainstack.com/

    2024

  2. [10]

    Sok: Blockchain light clients,

    P. C., F. B., and K. C., “Sok: Blockchain light clients,” inFinancial Cryptography and Data Security: 26th International Conference, 2022, pp. 615–641

    2022

  3. [11]

    C. F. Torres, F. Willi, and S. Shinde. (2024) wallet-address-leakage- datasets. [Online]. Available: https://zenodo.org/record/8071006/files/ wallet-address-leakage-datasets.zip

    2024

  4. [12]

    Is your wallet snitching on you? an analysis on the privacy implications of web3,

    ——, “Is your wallet snitching on you? an analysis on the privacy implications of web3,” inUSENIX Security’23, 2023

    2023

  5. [13]

    (2024) Awesome list rpc nodes providers

    Aard. (2024) Awesome list rpc nodes providers. [Online]. Available: https://github.com/arddluma/awesome-list-rpc-nodes-providers

    2024

  6. [14]

    [Online]

    (2024) Chainlist. [Online]. Available: https://chainlist.org/

    2024

  7. [15]

    M. Support. (2023) What is infura, and why does metamask use it? [On- line]. Available: https://support.metamask.io/networks-and-sidechains/

    2023

  8. [16]

    Bitcoin: A peer-to-peer electronic cash system,

    S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” 2009. [Online]. Available: http://www.bitcoin.org/bitcoin.pdf

    2009

  9. [17]

    Flyclient: Super-light clients for cryptocurrencies,

    B. B ¨unz, L. Kiffer, L. Luu, and M. Zamani, “Flyclient: Super-light clients for cryptocurrencies,” in2020 IEEE Symposium on Security and Privacy (SP), 2020, pp. 928–946

    2020

  10. [18]

    Coda: Decentralized cryptocurrency at scale,

    J. Bonneau, I. Meckler, V . Rao, and E. Shapiro, “Coda: Decentralized cryptocurrency at scale,”Cryptology ePrint Archive, 2020

    2020

  11. [19]

    M. Hearn. (2013) Micro-payment channels implementation now in bitcoinj. [Online]. Available: https://bitcointalk.org/index.php?topic= 244656.0;all

    2013

  12. [20]

    Sok: Layer-two blockchain protocols,

    L. Gudgeon, P. Moreno-Sanchez, S. Roos, P. McCorry, and A. Gervais, “Sok: Layer-two blockchain protocols,” inFC. Springer, 2020

    2020

  13. [21]

    V . Buterin. (2015) Ethereum foundation blog - state tree pruning. [On- line]. Available: https://blog.ethereum.org/2015/06/26/state-tree-pruning

    2015

  14. [22]

    (2024) Go implementation of the ethereum protocol

    Ethereum. (2024) Go implementation of the ethereum protocol. [Online]. Available: https://github.com/ethereum/go-ethereum

    2024

  15. [23]

    (2024) The portal network

    ethereum.org. (2024) The portal network. [Online]. Available: https: //www.portal.network/#/

    2024

  16. [24]

    Kademlia: A peer-to-peer informa- tion system based on the xor metric,

    P. Maymounkov and D. Mazi `eres, “Kademlia: A peer-to-peer informa- tion system based on the xor metric,” inPeer-to-Peer Systems. Springer, 2002

    2002

  17. [25]

    [Online]

    (2024) Decentralised rpc — web3 infrastructure — pokt network. [Online]. Available: https://www.pokt.network/

    2024

  18. [26]

    [Online]

    (2024) Rpch — private rpc provider. [Online]. Available: https://rpch.net/

    2024

  19. [27]

    [Online]

    (2024) Hopr — blockchain data protection and privacy. [Online]. Available: https://hoprnet.org/protocol

    2024

  20. [28]

    Relay mining: Incentivizing full non-validating nodes servicing all rpc types,

    D. Olshansky and R. R. Colmeiro, “Relay mining: Incentivizing full non-validating nodes servicing all rpc types,” 2024

    2024

  21. [29]

    Blockchain-based payment channel net- works: Challenges and recent advances,

    N. Papadis and L. Tassiulas, “Blockchain-based payment channel net- works: Challenges and recent advances,”IEEE Access, vol. 8, pp. 227 596–227 609, 2020

    2020

  22. [30]

    smartfhe: Privacy- preserving smart contracts from fully homomorphic encryption,

    R. Solomon, R. Weber, and G. Almashaqbeh, “smartfhe: Privacy- preserving smart contracts from fully homomorphic encryption,” in2023 EuroS&P, jul 2023. [Online]. Available: https://doi.ieeecomputersociety. org/10.1109/EuroSP57164.2023.00027

    2023

  23. [31]

    Zether: Towards privacy in a smart contract world,

    B. B ¨unz, S. Agrawal, M. Zamani, and D. Boneh, “Zether: Towards privacy in a smart contract world,” 2019. [Online]. Available: https://eprint.iacr.org/2019/191

    2019

  24. [32]

    (2024) The next generation of privacy infrastructure

    Nymtech. (2024) The next generation of privacy infrastructure. [Online]. Available: https://nymtech.net/nym litepaper.pdf

    2024

  25. [33]

    Cryptoeconomic security for data availability committees,

    E. N. Tas and D. Boneh, “Cryptoeconomic security for data availability committees,” inFC’24, 2024

    2024

  26. [34]

    Stakesure: Proof of stake mecha- nisms with strong cryptoeconomic safety,

    S. Deb, R. Raynor, and S. Kannan, “Stakesure: Proof of stake mecha- nisms with strong cryptoeconomic safety,” 2024

    2024

  27. [35]

    Incentive schemes for rollup validators,

    A. Mamageishvili and E. W. Felten, “Incentive schemes for rollup validators,” 2023

    2023

  28. [36]

    Uncon- ditionally safe light client,

    N. Moshrefi, P. Sheng, S. Deb, S. Kannan, and P. Viswanath, “Uncon- ditionally safe light client,” 2024. 11

    2024

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.