Interpreting SCP: A Trustless Infrastructure Paradigm Beyond the Rollup Convention
TechFlow Selected TechFlow Selected
Interpreting SCP: A Trustless Infrastructure Paradigm Beyond the Rollup Convention
SCP's vision and practical application is to build a new generation of trustless infrastructure, even as a non-blockchain computing platform.
Navigating Web3 tides with focused insightsAuthor: Wuyue, Geeker Web3
Introduction: This article prospectively introduces a somewhat unconventional Web3 infrastructure design paradigm—Storage-based Consensus Paradigm (SCP). While theoretically diverging significantly from mainstream modular blockchain solutions like Ethereum Rollups, this product design pattern boasts high feasibility in terms of ease of implementation and integration with Web2 platforms. From the outset, it does not confine itself to a narrow technical path as Rollups do, but instead aims for a broader, more open framework to integrate Web2 platforms with Web3 infrastructure—a highly imaginative and innovative approach.
Let’s imagine a public chain scaling solution with the following characteristics:
-
Speed comparable to traditional Web2 applications or exchanges, far surpassing any public chain, L2, rollup, or sidechain.
-
No gas fees, with near-zero usage cost.
-
High fund security—significantly exceeding centralized entities like exchanges, slightly less secure than Rollups but at least on par with sidechains.
-
User experience identical to Web2—users need no knowledge of blockchain private/public keys, wallets, or infrastructure.
Such a solution is indeed exciting: on one hand, it pushes scalability to its limits; on the other, it lays a solid foundation for mass Web3 adoption, effectively bridging the usability gap between Web2 and Web3.
Yet, few existing solutions come close to achieving all these goals, primarily due to limited mainstream discussion and practical exploration.
We used scalability—a familiar topic—as an entry point, but in reality, SCP is not limited to scaling alone. Its design inspiration stems from scalability discussions and proposals within communities around Bitcoin, Ethereum, and similar chains. Its vision and practical application aim to build a new generation of trustless infrastructure, even non-blockchain computational platforms.
Core Components and Working Principles of SCP
Generally speaking, like the "modular blockchains" discussed by the Ethereum and Celestia communities, SCP also features modular layers such as data availability (DA), execution, consensus, and settlement.
-
Data Availability Layer: Handled by a well-established, battle-tested public chain or dedicated storage system—for example, Ethereum, Arweave, or Celestia.
-
Execution Layer: A server that receives user transactions, executes them, and batches signed transaction data to submit to the DA layer—similar to a Rollup sequencer. However, the execution layer doesn’t require a blockchain-style linked structure; it can be entirely a Web2 database plus computation system, provided the entire system is open-source and transparent.
-
Consensus Layer: A group of nodes that pull data submitted by the execution layer to the DA layer and recompute results using the same algorithm, verifying the correctness of the execution output. This layer also serves as disaster recovery redundancy for the execution layer. Users can query data returned by consensus nodes to ensure no fraud occurs in the execution layer.
-
Settlement Layer: Composed of nodes and smart contracts or addresses on other chains, handling user deposits into and withdrawals from SCP—functioning similarly to cross-chain bridges. Settlement nodes control withdrawal functions of deposit addresses via multi-sig contracts or TSS-based addresses. When depositing, users send assets to a designated address on their respective chain; when withdrawing, they submit requests. Upon detecting the request, settlement nodes jointly approve asset release via multi-sig or TSS. The security level of the settlement layer depends on the cross-chain mechanism used.
The Practical Framework of SCP
We can understand the SCP paradigm through the following framework. A product satisfying the SCP model may support core functions such as deposit, transfer, withdrawal, and swap, with room for further expansion. The diagram below illustrates how such a system works:
-
The project uses Arweave, a permanent storage system, as its DA layer, represented by the large circle in the figure.
-
Coordinator—the Execution Layer. Users submit transactions to the coordinator, which executes computations, displays results, and batches raw input data to submit to the DA layer.
-
Detector: Pulls raw transaction data submitted by the coordinator from Arweave and validates the data and results using the same algorithm. The detector client is open-source, allowing anyone to run it.
-
Watchmen—a group of detectors managing the multi-sig withdrawal system. They verify and approve withdrawal requests based on transaction data and are also responsible for signing proposals.
We can see that the entire system achieves consensus entirely off-chain. This is the core of the Storage Consensus Paradigm—it discards the blockchain-style node consensus system, freeing the execution layer from heavy consensus communication and confirmation processes, allowing it to function simply as a server—achieving nearly unlimited TPS and economic efficiency. This resembles Rollup, but SCP takes a different path, transforming what was once a scaling-specific use case into a new transitional model from Web2 to Web3.
Although the coordinator mentioned above is a centralized server, this doesn’t mean it can act arbitrarily. Similar to a Rollup sequencer, once user-submitted raw data is batched and posted to Arweave, anyone can run a detector program to validate it and compare the resulting state against what the coordinator returns. In a way, this mirrors the logic behind inscription-based applications.
In this architecture, a centralized server or database isn't fundamentally problematic. Another key aspect of SCP is decoupling the concepts of “centralization” and “single entity”—a trustless system can include centralized components, even critical ones, without compromising overall trustlessness.
We might coin a slogan: “The next generation of trustless infrastructure doesn’t necessarily rely on consensus protocols, but should be built on open-source systems and P2P node networks.”
The original intent behind inventing and using blockchains—trustlessness, ledger consistency, immutability, traceability, etc.—was clearly articulated in the Bitcoin whitepaper. But after Ethereum, whether discussing legacy chain scaling, Rollups, or modular blockchains, a mental rigidity has formed: whatever we build must be a blockchain (defined by node consensus protocols), or something resembling a chain (possessing blockchain data structures but lacking direct consensus message exchange among nodes).
Yet under the SCP framework, even non-blockchain systems can achieve trustlessness, ledger consistency, immutability, traceability, and so on—provided there are clearer implementation details.
Execution Layer
The execution layer is crucial in the entire system, handling all computational processes and determining what kinds of applications can run on the platform.
Endless Possibilities in Execution Environments
In theory, the execution environment can take any form—its possibilities are limitless, depending entirely on how the project defines itself:
-
Exchange: SCP can enable public, transparent, high-TPS exchanges combining CEX-like speed and zero-cost operations with DEX-like decentralization. The line between CEX and DEX blurs here.
-
Payment Network: Similar to Alipay or PayPal.
-
Virtual Machine / Blockchain supporting programmable apps / contracts: Any developer can deploy arbitrary applications sharing user data and acting upon user instructions.
SCP’s design supporting arbitrary execution environments offers unique advantages: It avoids reliance on legacy-laden components, especially Ethereum’s homegrown concept of “account abstraction,” which SCP inherently doesn’t need.
Under SCP architecture, account abstraction simply doesn’t exist—you’re free to adopt Web2-style accounts, blockchain accounts, or any hybrid. From this perspective, many mature Web2 use cases can be directly ported to SCP without re-engineering. This may be SCP’s key advantage over Rollup.
Transparency and Asymmetry
Earlier we mentioned account systems. Alert readers may have noticed that while SCP can leverage Web2 account models, using them unchanged poses problems.
Because the entire system is fully transparent! Directly applying the traditional server-user interaction model would cause serious issues, rendering the system insecure. Let’s first review how the conventional server-user model works:
1. Account Registration: Users enter username and password on the app's registration page. To protect passwords, servers hash them upon receipt. To increase hashing complexity and resist rainbow table attacks, a randomly generated string ("salt") is typically appended to each password before hashing. The username, salt, and hash are stored in plaintext in the provider’s database and are not publicly exposed. Even so, salting and secure handling are essential—to prevent insider threats and external attacks.
2. User Login: Users enter their username and password on the login form. The system compares the hashed password with the stored hash in the database. If they match, the login proceeds.
3. Operation Authentication: After successful login, the system creates a session for the user. Session data is stored on the server, and a token (e.g., cookie or JWT) is sent to the user’s browser/app. Subsequent operations don’t require re-entering credentials: the browser/app stores the cookie identifier and includes it in every request, indicating authorization from the associated server.
Now let’s review the typical Web3 blockchain-user interaction model:
1. Account Registration: There is no registration process or username-password system. Accounts (addresses) exist inherently—whomever controls the private key owns the account. Private keys are locally generated by wallets without internet connection.
2. User Login: Using a blockchain doesn’t require logging in. Most dApps skip login and instead connect wallets. Some dApps request a signature verification after wallet connection to confirm actual private key ownership rather than just passing a wallet address to the frontend.
3. Operation Authentication: Users directly submit signed data to nodes, which validate and broadcast the transaction across the blockchain network. Once consensus is reached, the operation is confirmed.
The difference between the two models arises from symmetry vs. asymmetry. In the server-user model, both parties share the same secret. In the blockchain-user model, only the user holds the secret.
Although the SCP execution layer doesn’t need to be a blockchain, all data must be synchronized to a publicly visible DA layer. Therefore, the authentication methods used for login and operations in SCP must be asymmetric. Yet, to avoid the cumbersome and adoption-hindering requirement of managing private keys and wallets, many SCP-based applications still strongly desire traditional ID-password or OAuth third-party logins. How can these be reconciled?
Given the asymmetry inherent in public-key cryptography and zero-knowledge proofs, I propose two possible approaches:
-
For ID-password systems, keep the password storage module outside SCP, making it invisible to others. Internally, the SCP execution layer still uses blockchain-style public-private key accounts and logic—no registration, no login. The user ID maps to a private key. This private key shouldn’t be stored centrally. A feasible solution is using 2-of-3 MPC to eliminate centralization risks while sparing users the burden of handling private keys directly.
-
When relying on OAuth login, JWT (Json Web Token) can serve as identity verification. This method appears slightly more centralized, as it ultimately depends on Web2 tech giants’ third-party login services for identity proofing.
-
On first third-party login, register fields in the JWT representing user and service provider identities within the system. For subsequent user actions, treat the operation command as public input and the entire JWT as a secret witness, using ZKP to verify each transaction.
-
Each JWT has an expiration time. New JWTs are issued upon re-login, so long-term storage isn’t needed. The system also relies on JWKs (JSON Web Key sets), where big tech firms provide public keys for JWT validation. How to decentralizedly input JWKs into the system and handle key rotation deserve further exploration.
Whichever method is used, development and computation costs are higher than traditional approaches—but this is a necessary price for decentralization. Of course, if a project doesn’t prioritize maximal decentralization or has varying milestones across development phases, these designs aren’t mandatory. Decentralization isn’t binary but exists on a spectrum.
Privacy
The transparency issue mentioned earlier affects not only interaction patterns but also user data—everything is exposed. While acceptable in blockchains, this is often undesirable in certain applications, so developers may build privacy-preserving transaction systems.
Fees
Another important consideration is how the execution layer charges fees. Submitting data to the DA layer incurs costs, along with server operation expenses. Traditional blockchains charge gas fees primarily to prevent spam transactions that could overwhelm the network, with transaction ordering being secondary. Web2 lacks such concerns, having only basic concepts like flood protection and DDoS mitigation.
The execution layer can define custom fee strategies—completely free or partially charged, or generate revenue from other activities like MEV (already mature in sequencers), market events, etc.
Censorship Resistance
The execution layer lacks censorship resistance and can theoretically reject any user transaction indefinitely. In Rollups, censorship resistance is guaranteed by L1 contract-enforced inclusion. Sidechains or public chains, being fully distributed networks, are inherently resistant to censorship.
Currently, there is no clear solution to censorship resistance—an acknowledged weakness of the SCP paradigm.
Consensus Layer
This layer consists of loosely connected nodes that don’t actively form a network, so it’s not a consensus layer in the strict sense. Instead, it merely serves to externally (e.g., to users) confirm the current state of the execution layer.
For instance, if you doubt the operational status of these nodes, you can download the detector client, which runs the same code as the coordinator.
However, similar to Rollups, since data is submitted in batches, the state returned by the execution layer is always fresher than what’s recorded on the DA layer. This introduces a pre-confirmation issue:
The execution layer provides users with pre-confirmations—soft finality—since data hasn’t yet been committed to the DA layer;
The consensus layer provides hard finality. Users may not care much, but for applications like cross-chain bridges, hard finality is mandatory. For example, an exchange’s deposit/withdrawal system won’t trust off-chain broadcast data from a Rollup sequencer—it waits until the data lands on Ethereum before acknowledging it.
Beyond result verification, the consensus layer plays another vital role: serving as disaster recovery redundancy for the execution layer. If the execution layer permanently fails or acts maliciously, any consensus node can theoretically take over its duties and accept user requests. In such extreme cases, the community would likely select stable, reliable nodes to serve as the new execution layer.
Settlement Layer
Since SCP isn’t a Rollup, it cannot offer trustless withdrawals fully automated by cryptography and smart contracts like Rollup settlement layers. The security level of SCP’s cross-chain bridge matches that of sidechains or third-party validator bridges, relying on permissioned multi-sig managers to authorize asset releases—what we call the “watchman” model.
Making watchman bridges as decentralized as possible is a major research topic in cross-chain technology. Due to space constraints, we won’t delve deeper here. A well-designed SCP platform must partner with reputable, decentralized multi-sig bridge operators in practice.
One might ask why SCP doesn’t use a smart-contract-enabled chain as its DA layer? That way, a fully trustless settlement layer based on contracts could be built.
Long-term, overcoming technical hurdles to place the DA layer on chains like Ethereum with smart contract capability—and building corresponding verification contracts—could allow SCP to achieve Rollup-level settlement security without multi-sig.
But in practice, this may not be optimal:
1. Ethereum isn’t purpose-built for data storage and is relatively expensive compared to pure data-storage blockchains. For SCP, sufficiently low or fixed storage costs are crucial—only then can Web2-level throughput be sustained.
2. Proof systems are extremely difficult to develop because SCP isn’t limited to EVM simulation but can implement arbitrary logic. Considering teams like Optimism still haven’t launched fraud proofs, and the immense difficulty of zkEVM development, implementing generalized proof systems on Ethereum remains a monumental challenge.
Thus, Rollup is only practically viable in specific scenarios. If your goal is a broader, more open system breaking free from the EVM paradigm and embracing more Web2 features, the Ethereum Layer2 approach is unsuitable.
SCP isn’t a scaling solution for any particular blockchain, but a broader Web3 computing platform architecture—so naturally, it doesn’t follow the Ethereum Layer2 path.
A diagram comparing SCP with other paradigms
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@godrealmx
