Pith. sign in

REVIEW 3 major objections 4 minor 31 references

Shelby: Decentralized Storage Designed to Serve

T0 review · 3 major / 4 minor · reviewed 2026-08-06 · deepseek-v4-flash

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

Pith's one-line read Shelby claims a decentralized storage design can stream 4K video at Web2 cost.

desk verdict Design paper with a genuinely fresh audit scheme, but the headline 99.9% availability is contradicted by the paper's own (10,6)-over-5-datacenter math: true availability is ~99.84%. read the letter →

arxiv 2506.19233 v1 pith:GTS5ONRC submitted 2025-06-24 cs.DC

Guy Goren , Andrew Hariri , Timothy D. R. Hartley , Ravi Kappiyoor , Alexander Spiegelman , David Zmick This is my paper · ORCID
classification cs.DC
keywords decentralizedstoragehotClaycodeserasurecodingmicropaymentchannelsauditprotocolsincentivecompatibilityvideostreaming
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

Existing decentralized storage has been limited to cold or archival data because reads are slow, costly, and hard to meter. This paper argues that the bottleneck is architectural and economic rather than fundamental, and introduces Shelby, a protocol that makes high-performance reads the center of the system. Its claim is that Clay erasure coding, a dedicated fiber network, paid reads over micropayment channels, and a hybrid audit protocol together deliver Web2-grade read performance with decentralized trust. If the claim holds, read-intensive Web3 applications such as video streaming, AI data access, and real-time collaboration would no longer need centralized cloud storage. The paper derives 99.999999999% durability and 99.9% availability for a (10,6) Clay-coded configuration, and positions Shelby as the only decentralized option in its comparison that meets 4K streaming throughput with a replication factor below 2x.

What carries the argument

The argument is carried by four coupled mechanisms. Clay codes are a practical erasure-coding family that is both Maximum Distance Separable (any k of n pieces reconstruct the data) and Minimum Storage Regenerating (near-optimal repair bandwidth), giving high durability with under 2x replication overhead. A dedicated fiber network connecting RPC and storage nodes supplies the low-latency, predictable-bandwidth substrate that the public internet cannot. Paid reads via micropayment channels align incentives: providers earn from serving data, and off-chain settlement keeps per-read payment overhead negligible. The hybrid audit protocol combines frequent off-chain peer audits, whose results are aggregated after discarding top and bottom thirds to tolerate Byzantine nodes, with low-frequency on-chain challenges that verify both low-scoring storage providers and the auditors' reports, enforcing honesty through slashing. A blockchain coordination layer maintains blob metadata, assignments, and rewards.

What would settle it

Run Shelby's read path without a dedicated backbone, over the public internet, with a (10,6) Clay configuration, and measure whether a single client can sustain 40 Mbps in 10 MiB chunks with sub-second startup latency under realistic loss and jitter; if it cannot, the Web2-grade performance claim fails. A second falsifier is a simulated coalition of storage providers that stores nothing and shares valid audit proofs; if such a coalition survives on-chain audit-the-auditor checks with high probability, the incentive-compatibility claim fails.

Watch

Extended reading notes

Core claim

On its own terms, Shelby's central claim is that Web2-grade hot storage is achievable without sacrificing decentralization, provided the system is engineered around the economics of fast reads. The protocol separates control from data, stores data as Clay-coded chunksets assigned randomly to storage providers, pays storage and RPC providers per read through off-chain micropayment channels, and runs a hybrid audit: frequent, cheap peer-to-peer audits with trimmed scoreboards, plus sparse on-chain challenges that verify both suspected auditees and the auditors themselves. The paper states that this combination offers 99.999999999% (11 nines) durability, 99.9% availability, a replication factor under 2x, and the throughput to stream 4K video in roughly 10 MiB chunks with minimal startup delay, all while preserving decentralization.

Load-bearing premise

The performance claims assume that a dedicated high-speed fiber network is actually deployed, reaching enough RPC and storage nodes at a cost that keeps bandwidth cheap; if that backbone is missing, centralized, or too expensive, the sub-second latency and Web2-comparable cost numbers do not follow from Shelby itself.

Editorial extensions

If this is right

  • Read-intensive Web3 applications—4K video streaming, real-time collaboration, retrieval-augmented AI—could run on decentralized infrastructure rather than centralized clouds.
  • Storage overhead below 2x replication (compared with 3x-15x in current decentralized systems) makes hot storage economically competitive with Web2.
  • Because reads are paid and rewards scale with data actually served, the protocol avoids the underutilized-capacity problem of storage networks that reward pledged bytes rather than useful reads.
  • The audit design keeps cryptographic enforcement on-chain but sparse, so frequent verification does not need consensus-layer gas costs, enabling high read volume without blockchain bottlenecks.
  • The architecture opens paths to decentralized compute—validator-based, sampled committee, optimistic-verification, trusted-execution-environment, or specialized zero-knowledge—over the same high-performance data access.

Reading between the lines

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

  • The performance headline depends on a dedicated fiber network that is an external deployment, not part of the protocol itself; if such a backbone does not materialize at scale, the latency and cost advantages over public-internet systems do not follow from the software design alone.
  • The durability and availability numbers (11 nines and 99.9%) are derived from assumed hardware failure rates, a 12-hour repair time, and a 24-hour detection window; real deployments with slower repairs, correlated failures, or higher churn would produce lower nines than advertised.
  • A natural stress test of the incentive model would be a coalition of storage providers that stores nothing but shares a pool of valid audit proofs; whether the audit-the-auditor sampling catches this depends on the slashing-to-reward ratio, a parameter that can be tuned but also attacked.
  • The paper's read-economics claims suggest a testable extension: measure whether RPC-side caching with the proposed fee-sharing mechanism keeps storage-provider read revenue stable while cutting egress costs.
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

3 major / 4 minor

Summary. The paper presents Shelby, a proposed decentralized storage protocol aimed at hot/read-heavy workloads. Its architecture combines Clay erasure coding, a dedicated fiber backbone connecting RPC and storage nodes, paid reads with micropayment channels, and a hybrid audit scheme in which off-chain peer audits are backed by sparse on-chain verification and slashing, with Aptos serving as the coordination and settlement layer. The paper claims Web2-grade read performance (e.g., 4K streaming), 11-nines durability, 99.9% availability, and incentive compatibility for storage providers; the derivations appear in Appendix A (durability and availability) and Section B (proof sketches for the incentive theorems). No implementation or measurement results are reported.

Significance. If the availability and incentive claims were rigorously established, Shelby would address a real gap: decentralized storage has generally been confined to cold and archival workloads, and the read-economics problem is genuinely important. The paper deserves credit for making its numerical assumptions explicit, grounding failure rates in published hardware studies, and structuring the audit protocol so that auditors are themselves audited on-chain. The use of Clay/MSR codes to lower repair bandwidth and the separation of control and data planes are sensible design choices. However, the headline numbers are not currently supported: the availability derivation contains a combinatorial error, and the incentive-compatibility results are proof sketches rather than formal theorems. The significance of the design can only be assessed once these load-bearing claims are corrected or reframed as design targets.

major comments (3)
  1. [Appendix A (Availability)] The availability computation assumes that a Chunkset is available whenever any 3 of the 5 datacenters are operational, but this is combinatorially impossible for a (10,6) Clay code. A Chunkset has 16 coded chunks, and every 3-datacenter subset contains at least k=10 chunks exactly when every complementary 2-datacenter subset contains at most 6 chunks. If every pair held at most 6 chunks, the sum over the 10 pairs would be at most 60, whereas the 16 chunks are counted in 4 pairs each, totaling 64. Hence some pair holds at least 7 chunks and the complementary triple holds at most 9. Concretely, with the balanced placement (4,3,3,3,3), taking the three 3-chunk datacenters while the 4-chunk datacenter is down yields only 9 chunks. The datacenter-related unavailability is therefore P(X≤2) + 4·0.98^3·0.02^2 ≈ 1.58×10^{-3}, not the 7.8×10^{-5} used in the paper; including the paper's own systemic-error term gives availability ≈ 99.84%, below the 99.9% claimed in the abstract and Section 3.3.
  2. [Section 4.4 / Section B] The incentive-compatibility theorems are not established by the proof sketches as written. The model lacks a precise game form: strategy sets, information structure, the full payoff function (including how rwd_st, rwd_au, S_ata, p_ata, and epsilon enter), and the timing of audits and rewards are not formalized. Theorem 3's epsilon-coalition-resistance bound is asserted rather than derived, with the key step that savings from collusion are small left unquantified. Since the abstract and Section 4 claim a strong game-theoretic equilibrium and fully incentive-compatible auditing, these sketches are load-bearing and need to be either made rigorous or substantially weakened to a statement about plausible incentive alignment under explicit assumptions.
  3. [Sections 3.1, 3.5, and Table 1] The paper's central performance claims—sub-second access latency, 4K streaming at 40 Mbps, and Web2 cost competitiveness—are presented as properties of Shelby but are supported only by qualitative engineering arguments and a comparison table whose entries are not measured. No prototype, simulation, benchmark, or deployment evidence is reported, and the dedicated fiber backbone is an external dependency (DoubleZero [2]) whose coverage, cost, and availability are outside the protocol's control. These claims should be framed as design targets, or the paper should report measurements; as written, the statement in the abstract that Shelby 'brings Web2-grade performance' overstates what has been demonstrated.
minor comments (4)
  1. [Section 5.4] The text contains the placeholder 'O(10^{-XXX})' in the discussion of per-audit verification and scoreboard-posting costs; this needs to be filled in or removed.
  2. [Throughout] Several typos remain: 'Ths hybrid' in Section 4, 'A WS5' in Section 5.4, and 'A WS S3' in Table 1.
  3. [Appendix A (Durability)] The durability calculation should include a sensitivity analysis for the assumed 50% per-chunk deletion probability and the 24-hour detection delay; the 11-nines figure changes considerably under modest variations of these inputs.
  4. [Section 3.2] The micropayment channel description is informal; for a protocol paper, a more precise channel construction or a concrete reference would aid reproducibility, though this does not affect the core design.

Circularity Check

0 steps flagged · score 0.0 of 10

No material circularity: the load-bearing results are conditional derivations anchored to external prices, published failure rates, and standard erasure-coding properties.

full rationale

After walking the derivation chain, I find no circular step. The headline durability and availability numbers in Section 3.3 are not restatements of inputs: Appendix A derives them from externally sourced hardware-failure statistics (Backblaze [16], Ford et al. [26], Schroeder et al. [27], Vishwanath and Nagappan [28], Jiang et al. [29]) together with explicitly stated modeling assumptions (a (10,6) MDS code, 12-hour MTTR, 24-hour detection, five datacenters at 98% uptime, a 30-minute systemic event per year); the probability arithmetic then yields the quoted figures. The incentive-compatibility claims are conditional: Lemma 1 and Section 5.4 use AWS S3 prices (retrieved May 8, 2025) to derive the threshold p_a >= 0.0076, and Theorems 1-3 prove that honesty is a Nash equilibrium provided the stated reward and penalty calibrations (p_a, C, S_ata, etc.) hold. Choosing protocol parameters so that sufficient conditions are satisfied is standard mechanism design, not fitting a parameter to a target and then calling it a prediction. Appendix B is explicitly labeled 'Proof Sketches,' and the availability premise in Appendix A that any three of five datacenters suffice for reads is an assumption rather than a derived consequence; both are rigor and correctness concerns, not circularity. I also find no load-bearing self-citation: the cited prior systems (Clay codes, DoubleZero, Walrus, Merkle and vector commitments, AWS) are external prior work, and no central claim reduces to a same-author citation.

Assumptions & free parameters 4 free parameters · 6 assumptions · 0 invented entities

The protocol introduces no new physical or mathematical entities. Its central claims rest on configurable economic parameters, standard cryptographic assumptions, external failure-rate data, and the availability of a dedicated fiber network.

free parameters (4)
  • p_a = >= 0.0076 per day (lower bound)
    Per-chunk audit probability. Lower bound derived from AWS storage/read prices to satisfy Lemma 1; actual value not specified.
  • C = 50 (example)
    Multiplier for number of on-chain audit challenges for low-score SPs. Configurable, example value used in the slashing-deterrence calculation.
  • k, m (erasure code parameters) = (10,6) example
    Clay code parameterization used in the durability and availability calculations in Appendix A.
  • rwd_st, rwd_au, S_a, S_ata, p_ata, epsilon = not specified
    Reward and slashing parameters. The paper gives inequalities they must satisfy but no concrete values, leaving the incentive claims qualitative.
assumptions (6)
  • domain assumption At most f < n/3 storage providers are Byzantine and the network is partially synchronous
    Used in Section 4.3 to argue BFT of audit score computation.
  • domain assumption Storage providers are rational expected-utility maximizers
    Section 4.4 bases all game-theoretic IC proofs on this behavioral model.
  • standard math Hash functions are collision-resistant
    Section 3.4 relies on Merkle tree commitments and standard cryptographic assumptions.
  • domain assumption Hardware failure rates from cited studies are representative
    Appendix A uses drive failure 2%/yr, latent sector 3.45%, host 1-5%, rack 5%, DC 2%, etc., to derive durability and availability.
  • domain assumption A dedicated fiber network connecting nodes will be available and affordable
    Section 3.1: performance claims require a dedicated high-performance network layer (e.g., DoubleZero), an external dependency not controlled by the protocol.
  • standard math Clay codes satisfy MDS and MSR properties as published
    Section 3.3 inherits the code properties from the Clay codes paper, not derived anew.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Shelby: Decentralized Storage Designed to Serve." pith.science (2026). https://pith.science/paper/GTS5ONRC

@misc{pith2026250619233,
  author       = {Pith},
  title        = {Pith review of: Shelby: Decentralized Storage Designed to Serve},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/GTS5ONRC}},
  note         = {Machine review of arXiv:2506.19233}
}
read the original abstract

Existing decentralized storage protocols fall short of the service required by real-world applications. Their throughput, latency, cost-effectiveness, and availability are insufficient for demanding workloads such as video streaming, large-scale data analytics, or AI training. As a result, Web3 data-intensive applications are predominantly dependent on centralized infrastructure. Shelby is a high-performance decentralized storage protocol designed to meet demanding needs. It achieves fast, reliable access to large volumes of data while preserving decentralization guarantees. The architecture reflects lessons from Web2 systems: it separates control and data planes, uses erasure coding with low replication overhead and minimal repair bandwidth, and operates over a dedicated backbone connecting RPC and storage nodes. Reads are paid, which incentivizes good performance. Shelby also introduces a novel auditing protocol that provides strong cryptoeconomic guarantees without compromising performance, a common limitation of other decentralized solutions. The result is a decentralized system that brings Web2-grade performance to production-scale, read-intensive Web3 applications.

Figures

Figures reproduced from arXiv: 2506.19233 by the authors.

Figure 1
Figure 1. System Diagram Reading data. RPC nodes pay for reading data from SPs. When joining the network, RPC nodes establish payment channels to the SP layer. RPC nodes read Chunks from SPs and reconstruct the requested range of Blob data. Since Blobs are cryptographically committed, attempts to alter data will be detected. 2.4 Storage Providers Storage providers are the core of Shelby. An SP stores data on behalf of users a… view at source ↗
Figure 2
Figure 2. Data preparation by the Client SDK 4 Audit and Incentive Compatibility Overview. The audit subsystem in Shelby is designed to ensure that storage providers (SPs) reliably store the data they have committed to, and to verify that peer auditing activity (i.e., SPs auditing each other) is conducted honestly. The protocol follows a hybrid design that combines high-volume, low-cost internal audits with low-frequency on-c… view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

31 extracted references · 28 canonical work pages

  1. [2]

    xyz / whitepaper.pdf

    Mateo Ward Austin Federa Andrew McConnell.DoubleZero Protocol.https : / / doublezero . xyz / whitepaper.pdf. Accessed: 2025-05-13

    work page 2025

  2. [3]

    Accessed: 2025-05-13

    Google Cloud.Google Cloud Pricing Calculator.https://cloud.google.com/products/calculator? hl=en. Accessed: 2025-05-13. [4]DPDK.https://www.dpdk.org/about/. Accessed: 2025-05-13. [5]Filecoin: A Decentralized Storage Network.https://filecoin.io/filecoin.pdf. Accessed: 2025-06- 04

    work page 2025

  3. [6]

    Accessed: 2025-05-13

    Backblaze Inc.Computer Cloud Backup Pricing Comparison.https://www.backblaze.com/cloud- backup/pricing. Accessed: 2025-05-13

    work page 2025

  4. [7]

    com / data- availability /projects / celestia /blobstream

    L2Beat.https: / / l2beat. com / data- availability /projects / celestia /blobstream. Accessed: 2025-05-15

    work page 2025

  5. [8]

    Accessed: 2025-05-15

    Foresight News.https://www.chaincatcher.com/en/article/2075740. Accessed: 2025-05-15

    work page arXiv 2025

  6. [9]

    NVIDIA.Confidential Computing on NVIDIA H100 GPUs for Secure and Trustworthy AI.https: / / developer . nvidia . com / blog / confidential - computing - on - h100 - gpus - for - secure - and - trustworthy-ai. Accessed: 2025-06-05

    work page 2025

  7. [10]

    Accessed: 2025- 06-06

    Amazon S3.Amazon S3 Durability and Availability.https://aws.amazon.com/s3/. Accessed: 2025- 06-06

    work page 2025

  8. [11]

    Accessed: 2025-05-13

    Amazon S3.Amazon S3 Pricing.https://aws.amazon.com/s3/pricing/?nc=sn&loc=4. Accessed: 2025-05-13

    work page 2025

Show all 31 references
  1. [12]

    Accessed: 2025-05-21

    Petroc Taylor.Volume of data/information created, captured, copied, and consumed worldwide from 2010 to 2023, with forecasts from 2024 to 2028.https://www.statista.com/statistics/871513/ worldwide-data-created/. Accessed: 2025-05-21

    2010

  2. [13]

    Accessed: 2025-05-15

    The MystenLabs Team.https://github.com/MystenLabs/walrus/blob/main/docs/book/walrus_ whitepaper_v2.pdf. Accessed: 2025-05-15

    2025

  3. [14]

    https : / / en

    Bitcoin Wiki.Contracts: Example 7: Rapidly-adjusted (micro)payments to a pre-determined party. https : / / en . bitcoin . it / wiki / Contracts # Example _ 7 : _Rapidly - adjusted _ {} . 28micro . 29payments_to_a_pre-determined_party. [15]XDP.https://www.iovisor.org/technology...

    2025

  4. [16]

    Accessed: 2025-04-28

    Backblaze, Inc.Hard Drive Data and Statistics. Accessed: 2025-04-28. 2025.url:https : / / www . backblaze.com/b2/hard-drive-test-data.html

    2025

  5. [17]

    A Survey of the Past, Present, and Future of Erasure Coding for Storage Systems

    Zhirong Shen et al. “A Survey of the Past, Present, and Future of Erasure Coding for Storage Systems”. In:ACM Trans. Storage21.1 (Jan. 2025).issn: 1553-3077.doi:10 . 1145 / 3708994.url:https : //doi.org/10.1145/3708994

    2025 doi

  6. [18]

    arXiv:2411.14779

    Lingfei Jin et al.New families of non-Reed-Solomon MDS codes. arXiv:2411.14779. Nov. 2024.doi: 10.48550/arXiv.2411.14779.url:http://arxiv.org/abs/2411.14779(visited on 04/29/2025)

    2024 doi arXiv

  7. [19]

    com / learn / breakpoint - 23 / breakpoint - 2023 - fast - reed - solomon - coding - for - network - communications

    Philip Taffet.Fast Reed-Solomon Coding For Network Communications.url:https://solanacompass. com / learn / breakpoint - 23 / breakpoint - 2023 - fast - reed - solomon - coding - for - network - communications. Nov. 2023

    2023

  8. [20]

    Clay Codes: Moulding MDS Codes to Yield an MSR Code

    Myna Vajha et al. “Clay Codes: Moulding MDS Codes to Yield an MSR Code”. In:16th USENIX Conference on File and Storage Technologies (F AST 18). Oakland, CA: USENIX Association, Feb. 2018, pp. 139–154.isbn: 978-1-931971-42-3.url:https://www.usenix.org/conference/fast18/ present...

    2018

  9. [21]

    Having Your Cake and Eating It Too: Jointly Optimal Erasure Codes for I/O, Storage, and Network-bandwidth

    KV Rashmi et al. “Having Your Cake and Eating It Too: Jointly Optimal Erasure Codes for I/O, Storage, and Network-bandwidth”. In:Proceedings of the 13th USENIX Conference on File and Storage Technologies. F AST ’15. Santa Clara, CA, USA: USENIX Association, Feb. 2015, pp. 81–9...

    2015

  10. [22]

    Lazy Means Smart: Reducing Repair Bandwidth Costs in Erasure-coded Distributed Storage

    Mark Silberstein et al. “Lazy Means Smart: Reducing Repair Bandwidth Costs in Erasure-coded Distributed Storage”. In:SYSTOR 2014: Proceedings of International Conference on Systems and Storage(2014).doi:10.1145/2611354.2611370.url:https://doi.org/10.1145/2611354.2611370

    2014

  11. [23]

    Vector Commitments and Their Applications

    Dario Catalano and Dario Fiore. “Vector Commitments and Their Applications”. In:Public-Key Cryp- tography – PKC 2013. Ed. by Kaoru Kurosawa and Goichiro Hanaoka. Berlin, Heidelberg: Springer Berlin Heidelberg, 2013, pp. 55–72.isbn: 978-3-642-36362-7

    2013

  12. [24]

    A Solution to the Network Challenges of Data Recovery in Erasure-coded Dis- tributed Storage Systems: A Study on the Facebook Warehouse Cluster

    K. V. Rashmi et al. “A Solution to the Network Challenges of Data Recovery in Erasure-coded Dis- tributed Storage Systems: A Study on the Facebook Warehouse Cluster”. In:Proceedings of the 5th USENIX Workshop on Hot Topics in Storage and File Systems (HotStorage ’13). USENIX A...

    2013

  13. [25]

    Network Coding for Distributed Storage Systems

    Alexandros G. Dimakis et al. “Network Coding for Distributed Storage Systems”. In:IEEE Transac- tions on Information Theory56.9 (2010), pp. 4539–4551.doi:10.1109/TIT.2010.2054295

    2010

  14. [26]

    Availability in globally distributed storage systems

    Daniel Ford et al. “Availability in globally distributed storage systems”. In:Proceedings of the 9th USENIX Conference on Operating Systems Design and Implementation. OSDI’10. Vancouver, BC, Canada: USENIX Association, 2010, pp. 61–74

    2010

  15. [27]

    Understanding latent sector errors and how to protect against them

    Bianca Schroeder, Sotirios Damouras, and Phillipa Gill. “Understanding latent sector errors and how to protect against them”. In:ACM Trans. Storage6.3 (Sept. 2010).issn: 1553-3077.doi:10.1145/ 1837915.1837917.url:https://doi.org/10.1145/1837915.1837917

    2010

  16. [28]

    Characterizing cloud computing hardware reliability

    Kashi Venkatesh Vishwanath and Nachiappan Nagappan. “Characterizing cloud computing hardware reliability”. In:Proceedings of the 1st ACM Symposium on Cloud Computing. SoCC ’10. Indianapolis, Indiana, USA: Association for Computing Machinery, 2010, pp. 193–204.isbn: 97814503003...

  17. [29]

    Are Disks the Dominant Contributor for Storage Failures? A Comprehensive Study of Storage Subsystem Failure Characteristics

    Weihang Jiang et al. “Are Disks the Dominant Contributor for Storage Failures? A Comprehensive Study of Storage Subsystem Failure Characteristics”. In:F AST ’08: Proceedings of the 6th USENIX Conference on File and Storage Technologies. USENIX Association. 2008, pp. 111–125

    2008

  18. [30]

    Ceph: A scalable, high-performance distributed file system

    Sage Weil et al. “Ceph: A scalable, high-performance distributed file system”. In:Proceedings of the 7th Conference on Operating Systems Design and Implementation (OSDI’06). 2006, pp. 307–320

    2006

  19. [31]

    The Google file system

    Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung. “The Google file system”. In:Proceedings of the nineteenth ACM symposium on Operating systems principles. 2003, pp. 29–43

    2003

  20. [32]

    A network on chip architecture and design methodology

    Shashi Kumar et al. “A network on chip architecture and design methodology”. In:Proceedings IEEE Computer Society Annual Symposium on VLSI. New Paradigms for VLSI Systems Design. ISVLSI

  21. [33]

    A digital signature based on a conventional encryption function

    Ralph C Merkle. “A digital signature based on a conventional encryption function”. In:Conference on the theory and application of cryptographic techniques. Springer. 1987, pp. 369–378

    1987

  22. [34]

    Polynomial Codes Over Certain Finite Fields

    I. S. Reed and G. Solomon. “Polynomial Codes Over Certain Finite Fields”. In:Journal of the Society for Industrial and Applied Mathematics8.2 (1960), pp. 300–304.doi:10 . 1137 / 0108018. eprint: https://doi.org/10.1137/0108018.url:https://doi.org/10.1137/0108018. 20 A Durabili...

    1960 doi

  23. [2002]

    2002, pp

    IEEE. 2002, pp. 117–124

    2002

Pith tools

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