この記事で学べること

This article will help you understand the differences between Corda and Solana and their respective design philosophies, data models, and consensus features.

目次

• What is Corda?
• What is Solana?
• Corda vs Solana
• 1. Account / Data Model
• Corda
• Solana
• 2. Transaction Components
• Corda
• Solana
• 3. Consensus Mechanism
• Commonalities
• Corda’s Uniqueness
• Solana’s Uniqueness
• 4. Architecture & Design Philosophy
• Corda
• Solana
• 5. Transaction Costs & Models
• Corda
• Solana
• 6. Permissioning & Ecosystem
• Corda
• Solana
• Key Difference
• 7. Use Cases
• 8. Summary
• 9. Similarities between Corda and Solana
• Stateless Program Design
• Deterministic Execution
• No Chain Forks
• 10. Conclusion

What is Corda?

Corda is not a traditional blockchain but a distributed ledger built for business. It allows organizations to record and manage agreements directly with counterparties, without broadcasting all transactions to a global network. By using concepts like states (immutable records of facts) and flows (automated transaction protocols), Corda enables secure, private, and efficient interactions across industries where confidentiality and regulatory alignment are critical.

What is Solana?

To understand solana we have come with a rough idea using the analogy of a bank, which helps everyone to have a clear perspective of what solana actually is . If you want to understand this better please refer to the link below: https://www.notion.so/cordajapan/Solana-26c8e769fdcc8087abddc527c8f3f839

Corda vs Solana

Before delving into a comparative analysis, it is important to establish the context for this discussion . Corda has been positioned as a prominent enterprise-focused distributed ledger platform, tailored to meet the specific needs of regulated industries. Solana, on the other hand, has emerged as a high-performance public blockchain, distinguished by its scalability, low latency, and thriving developer ecosystem. Its rapid adoption in decentralized finance, NFTs, and other Web3 applications highlights its versatility and momentum, making it a benchmark for modern blockchain innovation. The decision to feature Solana on the Corda Portal reflects an intention to bridge perspectives between enterprise and public blockchain ecosystems, while also acknowledging the technological advances and broader community traction that platforms like Solana have achieved.

1. Account / Data Model

Corda

• No global ledger → each participant maintains their own vault (local database of states).
• States = immutable facts (e.g., loan agreements, invoices, “Alice owes Bob ¥100”), shared only with the relevant parties.
• Privacy-first model → states are not broadcast network-wide.
• Updates occur only through new transactions, which consume old states and produce new ones.

Solana

• Global ledger → all accounts are visible to everyone.
• Accounts = on-chain storage units that can hold data; programs operate on accounts but do not store state internally. System Account – basic account that stores lamports (SOL) and may hold program data. Program Account – stores executable bytecode (the on-chain program itself). Data Account (PDA or user-owned) – used by programs to persist state (similar to a record in a database). Token Account – created via the SPL Token Program; represents ownership of fungible or non-fungible tokens. Associated Token Account (ATA) – a special token account automatically derived for a wallet & mint pair.
• Program Derived Addresses (PDAs):
• Deterministically generated by a program (no private key).
• Controlled only by the program that created them.
• Commonly used for escrow, token vaults, or user-specific program accounts.
• Global-by-default model → state is shared and accessible across the entire network.
• Cross-Program Invocation (CPI)
• A Solana program can call another program within the same transaction — e.g., your custom program calling the SPL Token Program to mint tokens.
• The called program operates on accounts passed into the transaction.
• Enables composability, similar to how smart contracts interact on Ethereum.

Example snippet:

let cpi_ctx = CpiContext::new(token_program, MintTo {
    mint: ctx.accounts.mint.to_account_info(),
    to: ctx.accounts.user_token_account.to_account_info(),
    authority: ctx.accounts.authority.to_account_info(),
});
token::mint_to(cpi_ctx, 100)?;

→ This shows how your program invokes another (Token Program) safely.

// Example: Custom Data Account in Anchor
#[account]
pub struct UserProfile {
    pub user: Pubkey,    // wallet address of the user
    pub level: u8,       // example state data
    pub score: u64,      // example state data
}

// Instruction handler
pub fn initialize_profile(ctx: Context<InitializeProfile>) -> Result<()> {
    let profile = &mut ctx.accounts.profile;
    profile.user = *ctx.accounts.user.key;
    profile.level = 1;
    profile.score = 0;
    Ok(())
}

#[derive(Accounts)]
pub struct InitializeProfile<'info> {
    #[account(init, payer = user, space = 8 + 32 + 1 + 8)]
    pub profile: Account<'info, UserProfile>,
    #[account(mut)]
    pub user: Signer<'info>,
    pub system_program: Program<'info, System>,
}

2. Transaction Components

Corda

In Corda, the network is composed of peer nodes (run by organizations like banks or companies) and a special class of nodes called Notaries.

• Regular Nodes (e.g., Alice, Bob)
• Each participant runs their own node, maintaining a local vault of states they are party to.
• They communicate directly to exchange and validate transactions (peer-to-peer model).
• These are not full replicas of the entire ledger — they only store data relevant to them.
• Notary Nodes
• A Notary is a trusted (or semi-trusted) service responsible for preventing double-spending.
• When a transaction is finalized, the Notary checks that the input states have not been consumed before and signs the transaction to confirm its uniqueness.
• Some Corda networks use a single notary cluster (centralized trust), while others use distributed notaries employing consensus algorithms (like Raft or BFT) for fault tolerance.
• Unlike Solana’s validators, notaries do not execute contract logic or maintain global state — their only role is to attest to the uniqueness of transactions.

Corda Transaction Flow

Solana

Solana takes a fully public, global ledger approach, where all nodes can view the same state.

Its node ecosystem is broader, with distinct operational roles:

• Validator Nodes
• The backbone of Solana’s consensus and execution.
• Validators receive transactions, verify signatures, execute program instructions, and produce new blocks.
• They use Proof of History (PoH) + Proof of Stake (PoS) to achieve high-speed agreement on ordering and validity.
• Validators are “special” because they secure and advance the chain, much like notaries ensure transaction uniqueness in Corda — but through decentralized consensus rather than trust.
• RPC Nodes (Remote Procedure Call)
• Provide public endpoints for wallets, dApps, and off-chain systems to submit transactions and query on-chain data.
• RPC nodes do not produce blocks or participate in consensus — they act as gateways to the validator network.
• Leader Nodes
• Within the validator set, Solana temporarily elects “leaders” that are responsible for batching and broadcasting transactions during a specific time slot (using PoH).
• Archiver Nodes (optional)
• Store historical data of the blockchain for long-term retrieval and redundancy.

Solana Transaction Flow

3. Consensus Mechanism

Commonalities

• Neither Corda nor Solana relies on mining or energy-intensive Proof of Work.
• Both use cryptographic validation and digital signatures to ensure transaction integrity.
• Both are designed to prevent double-spending, though the enforcement method differs.

Corda’s Uniqueness

• No global ledger: consensus is split into two aspects:
• Validity (checked by contracts)
• Uniqueness (ensured by a notary)
• Notaries can be centralized or distributed, running consensus algorithms such as Raft (CFT) or BFT.
• Consensus is selective and private: only the relevant parties (and the notary) need to agree, reflecting Corda’s enterprise use cases.

Solana’s Uniqueness

• Achieves global consensus: all participants share the same ledger.
• Relies on Proof of History (PoH) for ordering events, combined with Proof of Stake (PoS) for leader election and finality.
• Optimized for performance: very short block times (~400ms) and high throughput (thousands of TPS).
• Consensus is public and universal, supporting large-scale decentralized applications.

4. Architecture & Design Philosophy

Corda

• Not a classic blockchain — no single global ledger
• Transactions via flows, directly between parties
• Validity = contracts, uniqueness = notaries

Solana

• Public blockchain with a global state machine
• Programs are stateless; accounts hold data
• Sealevel runtime allows parallel execution for high throughput

5. Transaction Costs & Models

Corda

• Designed for enterprise deployments rather than public usage.
• Costs typically come from infrastructure (running nodes, hosting, storage) and licensing fees with R3.
• Pricing can vary widely depending on the size of the network and vendor contracts, but in general the cost per transaction is not structured like public blockchain fees — it’s closer to the cost of running enterprise middleware.

Solana

• Transactions typically cost a fraction of a cent (e.g., $0.0001–$0.0005 per transaction).
• Fees are low and predictable, making Solana consumer-friendly and suitable for high-volume use cases like payments, NFTs, or gaming.
• Why so cheap?
• Solana uses an efficient runtime (parallel transaction processing with Sealevel) that maximizes hardware utilization.
• The Proof of History (PoH) mechanism reduces coordination overhead for ordering transactions.
• Costs are effectively socialized across the entire validator network, keeping individual transaction fees minimal.

6. Permissioning & Ecosystem

Corda

• Permissioned by design → every participant must be identified and admitted to the network.
• Transactions are only visible to the directly involved parties (and notaries, when required).
• Strong fit for banks, trade finance, and supply chain networks where confidentiality and regulatory compliance are essential.

Solana

• Public, permissionless blockchain → anyone can create an account, deploy a program, or submit transactions.
• Enterprises can adopt Solana Permissioned Environments (SPEs) to create private, Solana-compatible deployments.
• In SPEs, privacy is achieved by running a separate instance of the Solana runtime with controlled access — rather than restricting visibility on the main public chain.

Key Difference

• Both Corda and Solana (via SPEs) can build private environments, but the methods differ:
• Corda → privacy is built into the transaction model itself (data shared only with relevant parties).
• Solana SPEs → privacy comes from separating environments from the public chain, since the core Solana ledger is global by default.
• This distinction shapes what information can be protected: Corda enforces privacy transaction by transaction, while Solana typically requires isolation to achieve the same effect.

7. Use Cases

8. Summary

• Account / Data Model: Solana maintains a global ledger where all accounts are visible and controlled by programs or Program Derived Addresses (PDAs). This enables open, composable applications. (By contrast, Corda uses private states in local vaults, visible only to relevant parties.)
• Transactions: Solana transactions consist of messages with accounts, instructions, blockhashes, and signatures. Programs are stateless, with all data stored in accounts. This design allows parallel execution at scale. (Corda relies on inputs/outputs/contracts verified by notaries in a point-to-point flow.)
• Consensus: Solana achieves public global consensus through Proof of History + Proof of Stake, supporting thousands of TPS with ~400ms block times. (Corda’s consensus is selective and private, depending on notaries for uniqueness.)
• Architecture: Solana is built as a global state machine with the Sealevel runtime for parallelism. Corda, on the other hand, runs flows directly between identified parties.
• Costs: Solana offers predictable fees at fractions of a cent, enabling mass-market use cases. Corda’s costs stem mainly from enterprise infrastructure and licensing, not per-transaction fees.
• Permissioning & Ecosystem: Solana is public and permissionless by default, but enterprises can deploy Solana Permissioned Environments (SPEs). Corda is permissioned by design, with privacy enforced at the transaction level.
• Use Cases: Solana powers DeFi (Serum, Raydium), NFT marketplaces (Magic Eden), games (Star Atlas), payments, and emerging AI agent interactions. Corda is used in finance (Progmat, syndicated lending) and supply chains, where privacy and regulatory compliance are critical.

9. Similarities between Corda and Solana

While Corda and Solana take very different approaches, they also share some important design principles:

Stateless Program Design

Both systems separate code from state.

• In Corda, contracts are stateless — they simply verify transaction validity based on input/output states.
• In Solana, on-chain programs are also stateless. They don’t store data within their code but instead rely on separate, on-chain accounts to hold state.

This design makes both systems more deterministic, parallelizable, and secure, as programs always produce predictable results.

Deterministic Execution

Due to their stateless nature, Solana’s programs facilitate deterministic execution. This ensures that a given set of inputs will always produce the same result across all nodes — a property essential for achieving consensus in a distributed system. The same holds true for Corda contracts, which validate transactions deterministically to ensure all participants reach the same conclusion.

No Chain Forks

Both Corda and Solana aim to maintain a consistent, authoritative transaction history without traditional blockchain forks.

• In Corda, there is no global chain — each participant maintains their own vault, but transactions are validated and notarized to ensure that conflicting states cannot exist.
• In Solana, the consensus mechanism (Proof of History + Proof of Stake) ensures that even though validators may briefly diverge, the network quickly converges on a single canonical ledger.

This design in both systems prevents competing histories and helps maintain data consistency and trust across participants.

10. Conclusion

"I feel that Solana is a very good option as a blockchain to use, offering low costs and high speed, while also providing strong security. Its efficiency and scalability make it well-suited for applications ranging from decentralized finance to gaming and AI-powered solutions. Solana’s robust architecture ensures reliable performance even under high transaction loads, making it a practical choice for developers seeking both speed and safety. Overall, it presents a balanced combination of affordability, speed, and security that is hard to overlook.”

Links related:

• solana.com
• Learn how the Solana blockchain works
• Solana Permissioned Environments
• Tokens on Solana

✍️

Written by Ramya

SBI R3 Japan Engineering Department

Engaged in application development and Proof-of-Concept initiatives .

Driven by the conviction that blockchain technology will form a foundational layer of tomorrow’s society.

→筆者の記事一覧