DA Architecture Design Principles for Oracle State Machine

TL;DR

Data availability (DA) is not a “nice-to-have” optimization for oracle state machine—it is an existential condition. In a general rollup, DA failure means transaction delays. In an oracle state machine, DA failure means the complete collapse of the trust foundation for bidirectional state synchronization. A DA structure that regulators cannot independently verify is structurally unsuitable for compliance environments. To meet these requirements, Oraclizer adopts DAS (Data Availability Sampling) based DA protocols with KZG Commitments, and has designed a DA-Agnostic architecture that avoids dependency on any specific DA layer.

---

Introduction: The Hidden Premise of Bidirectional State Synchronization

In our preceding research, we have been constructing the core infrastructure of the oracle state machine. We demonstrated the mathematical necessity of Sparse Merkle Trees in our analysis of state data structures, and designed the L3 zk-Rollup architecture with zkProver-zkVerify integration in our infrastructure research. However, beneath all these designs lies an implicit assumption: state transition data is always accessible when needed.

What happens when this assumption breaks? No matter how sophisticated the zk proofs, no matter how efficient the SMT structure—if the original data cannot be accessed, all verification mechanisms lose their meaning.

“The validity of a zero-knowledge proof is only as strong as the availability of the data it commits to.”

— Vitalik Buterin, “Endgame” (2021)

This research explicitly addresses this hidden premise—Data Availability. We analyze the special requirements oracle state machine have for DA, and how Oraclizer satisfies them.

1. Redefining the DA Problem

1.1 What is Data Availability?

Data Availability (DA) is not merely “data storage.” More precisely, it means verifiable accessibility. In the blockchain context, DA answers this question: “Does the data that a block producer claims to have published actually exist, and can anyone retrieve it?”

This question matters because of the possibility of data withholding attacks. A malicious block producer can generate a valid state transition proof (validity proof) while refusing to publish the original transaction data. In this case, other nodes cannot independently verify whether the state transition was legitimate.

1.2 Why Not Store Directly on L1?

The simplest solution is to record all data directly on L1 (Ethereum mainnet). This approach fundamentally solves the DA problem—Ethereum’s full nodes retain the data, guaranteeing availability.

However, there’s a cost problem. Ethereum L1 calldata costs approximately 16 gas per byte, and directly recording large volumes of state synchronization data becomes economically unsustainable. Instead, by recording only the commitment on L1 while storing the original data in a separate DA layer, L1 recording costs can be reduced by over 99%[1].

This is the core idea of the Validium architecture. In our L3 architecture design, Oraclizer primarily operates in Validium mode, with Volition support enabling switches to zk-Rollup mode when needed.

1.3 The Special Importance of DA in Oracle State Machine

General rollups and oracle state machine face fundamentally different consequences from DA failure.

DA Failure in General Rollups:

• Transaction confirmation delays
• User inconvenience
• But recoverable—normalizes once data becomes available again

DA Failure in Oracle State Machine:

• On-chain ↔ off-chain state inconsistency becomes unverifiable
• Original data cannot be submitted for regulatory audits
• State verification data inaccessible → trust compromise
• Financial transaction legal finality becomes unprovable

The core value of an oracle state machine is the trustworthiness of bidirectional state synchronization. When OSS (Oracle State Synchronizer) propagates on-chain state changes to off-chain systems and vice versa, the original data for each state transition must be accessible for this synchronization to be trusted.

2. DA Requirements for Oracle State Machine

2.1 Essential Requirements from a Regulatory Compliance Perspective

What oracle state machine require from DA includes general rollup requirements while adding more stringent conditions:

Independent Verifiability: Regulators, auditors, or dispute parties must be able to independently verify data availability as third parties. A demand to “trust the operators” is unacceptable in regulatory compliance environments.

DA Finality Speed: Legal finality of financial transactions requires that state was confirmed at a specific point in time. If a DA layer only provides probabilistic guarantees of data availability, claims of legal finality become vulnerable.

Cost Efficiency: Continuous state synchronization involves frequent state updates. If DA costs are excessively high, the economic sustainability of the oracle state machine is threatened.

Technical Maturity: Systems handling financial assets require technology proven in production environments. Technology that is theoretically superior but lacks operational track record is a risk factor.

2.2 Why DAC is Unsuitable

A DAC (Data Availability Committee) is an approach where a small group of committee members store data and prove availability through their signatures. This was adopted in early Validium implementations like StarkEx.

Structural limitations of DAC:

1. Undetectable committee collusion: If committee members collude to hide data, external observers have no way to detect this.

2. Absent slashing mechanisms: In typical DAC structures, economic punishment mechanisms for committee misconduct are weak or non-existent[2].

3. Small committee size: A typical DAC consists of around 8 nodes, falling short of decentralized security standards.

From a regulatory compliance perspective, DAC’s fatal flaw is that regulators cannot independently verify data availability. The demand to “trust the committee” conflicts with RCP (Regulatory Compliance Protocol) core principles—Traceability and Enforceability.

2.3 The Suitability of DAS-Based DA

DAS (Data Availability Sampling) is a technique that allows even light nodes to verify data availability without downloading the full data. Core mechanisms:

Erasure Coding: Original data is extended using Reed-Solomon codes to generate encoded data of twice the size. The entire original can be reconstructed from just 50% of this encoded data. Therefore, for a block producer to hide data, they must hide more than 50%, which is detectable with high probability through random sampling[3].

Probabilistic Guarantee: If a light node randomly samples 100 chunks, the probability of detecting data being hidden by 50% or more is 1 – 0.5^100 ≈ 1 – 10^-30. This is virtually certain detection.

Independent Verification: In DAS-based DA, anyone (including regulators, auditors, and ordinary users) can independently verify data availability. This is fundamentally different from DAC’s “trust the committee” requirement.

2.4 Oraclizer’s Choice: DAS + Validity Proof

Based on the above requirements analysis, Oraclizer has adopted the following direction:

DAS-Based DA Protocol: We utilize a DAS-based DA layer that satisfies independent verifiability and decentralized security. Not specifying a particular DA layer name is intentional—Oraclizer’s DA-Agnostic design avoids dependency on any specific protocol.

KZG Commitment: KZG (Kate-Zaverucha-Goldberg) Commitment is a technique for generating concise cryptographic commitments to polynomials. Key characteristics:

• Constant-size commitment and proof: 48 bytes regardless of polynomial degree[4]
• O(1) verification time: Verification efficiency
• Proof aggregation: Multiple proofs can be combined into one

KZG has been adopted in Ethereum’s Proto-Danksharding (EIP-4844) and proven in production environments. Oraclizer leverages this verified cryptographic foundation.

Validity Proof Based DA Finality: Fraud Proof based systems (Optimistic Rollup) require a challenge period, unable to provide immediate finality. Consistent with our L3 zk-Rollup/Validium architecture, Oraclizer adopts Validity Proof based DA finality. Once state transition validity is proven, DA finality is also immediately confirmed without probabilistic uncertainty.

3. DA-Agnostic Architecture Design

3.1 Risks of Single DA Dependency

A system tightly coupled to a specific DA layer is exposed to these risks:

• Single point of failure: Failures, security incidents, or service disruptions in that DA layer affect the entire system
• Economic dependency: No negotiating power against pricing policy changes
• Difficulty adapting to technological evolution: Migration costs increase when better DA solutions emerge

3.2 DA Provider Interface

Oraclizer designs an abstraction layer that doesn’t depend on any specific DA layer. This interface enables access to various DAS-based DA protocols in a uniform manner.

Core function definitions (Go interface for OSS):

// DAProvider defines the interface for data availability layer integration
type DAProvider interface {
    // SubmitData submits data to DA layer and returns commitment
    // data: Raw state transition data
    // Returns: commitment (cryptographic commitment), proof (availability proof), error
    SubmitData(ctx context.Context, data []byte) (commitment [32]byte, proof []byte, err error)
    
    // VerifyAvailability verifies data availability using commitment
    // commitment: Previously returned commitment
    // proof: Availability proof
    // Returns: isAvailable (true if verified available), error
    VerifyAvailability(ctx context.Context, commitment [32]byte, proof []byte) (isAvailable bool, err error)
    
    // RetrieveData retrieves original data using commitment
    // commitment: Data commitment
    // Returns: original data, error
    RetrieveData(ctx context.Context, commitment [32]byte) (data []byte, err error)
    
    // GetCommitment computes commitment for given data without submission
    // data: Raw data
    // Returns: computed commitment
    GetCommitment(data []byte) [32]byte
}

Through this abstraction, OSS performs state synchronization with the same logic regardless of specific DA layer implementation.

3.3 Practical Approach: Single DA + Extensible Structure

Theoretically, multi-DA simultaneous operation provides the highest availability. However, practical technical challenges exist:

• L1 Commitment consistency: Managing commitment consistency when publishing the same data to multiple DA layers
• Cost increase: Multi-DA publishing multiplies costs
• Complexity: Each DA layer may have different finality timing

Therefore, Oraclizer’s current approach is:

1. Operate with a single DA layer: Complexity management and cost efficiency
2. Maintain DA-Agnostic interface: Structure enabling switches to other DA layers when needed
3. Multi-DA as future research: Reconsider when production-proven cases accumulate in the industry

4. OSS-DA Integration Design

4.1 DA’s Role in State Synchronization Flow

DA integrates into OSS (Oracle State Synchronizer)’s state synchronization flow as follows:

On-chain state change occurs
       ↓
OSS collects state transition data
       ↓
Submit data to DA layer → Receive commitment
       ↓
Record commitment on L1/L2
       ↓
Confirm DA finality
       ↓
Proceed with cross-chain state propagation

In this flow, the DA layer serves as a trusted repository for original data. Only the commitment is recorded on L1/L2, while the actual data is retrieved from the DA layer.

4.2 The Relationship Between zk Proofs and DA

In our L3 architecture, CDK’s zkProver generates Validity Proofs for state transitions, with verification costs optimized through zkVerify. DA plays the role of storing the input data for proofs in this flow:

1. zkProver input: State transition data (transactions, before/after state)
2. DA storage: The same state transition data
3. During verification: If needed, retrieve original from DA → Confirm match with zkProver output

zk proofs demonstrate “the state transition was correct,” and DA guarantees “the state transition data is accessible.” Complete verifiability is achieved only when both elements are combined.

4.3 OSS Response to DA Failure

As the DA layer is a distributed system, temporary failures can occur. OSS implements the following response strategies:

DA Submission Failure:

• Retry with exponential backoff
• Retry queue management
• Alert generation and manual intervention trigger when critical failure count exceeded

DA Retrieval Failure:

• Parallel requests to multiple nodes
• Timeout handling and fallback node attempts
• Fast retrieval of recent data through caching layer

DA Finality Delay:

• State propagation on hold (until finality confirmed)
• Alert generation and enhanced monitoring
• Escalation when delay exceeds threshold

These response mechanisms absorb temporary instability from the DA layer while inducing operational intervention through appropriate alerts when persistent issues occur.

5. On-chain Data Confidentiality and Original Preservation

5.1 What CANTON Solves and What It Doesn’t

In Oraclizer’s architecture, CANTON handles confidentiality between off-chain financial institutions. DAML’s powerful authorization model enables “need-to-know” based selective information disclosure.

However, there are areas CANTON doesn’t cover:

CANTON handles:

• Contract content confidentiality between parties
• Counterparty information with selective disclosure

On-chain challenges remain:

• L3 state change metadata exposure risk
• Transaction pattern analysis possible on DA layer data
• Cross-chain message relationship inference possible

5.2 On-chain Metadata Privacy Challenges

Even when data recorded on-chain is “summary data,” privacy risks exist:

Pattern Analysis Attacks: Even from state roots and transaction hashes alone, transaction frequency, timing, and relative scale can be inferred. Timestamp and frequency analysis can identify specific institutions’ trading activity patterns.

Metadata Correlation Attacks: Cross-analyzing metadata from multiple transactions can infer trading relationships and fund flows.

RCP’s Confidentiality principle must apply not only off-chain but also at on-chain layers. This requires the following design directions:

• Minimal exposure design: Separate essential verification data from sensitive metadata
• zk proof utilization: Verify condition satisfaction without revealing content

However, this area involves complex cryptographic challenges and will be analyzed in depth in our upcoming research on privacy-preserving state synchronization.

5.3 Original Preservation and Long-term Accessibility

DA layer data retention periods are not permanent. Most DA protocols perform data pruning after specific periods. However, financial regulations require long-term preservation:

• Korea: 5+ years retention under the Electronic Financial Transactions Act
• USA: 6 years retention under SEC Rule 17a-4
• EU: 5-7 years retention under MiFID II

Strategic directions to resolve this gap:

Archive Layer: Migrate original data to a separate long-term storage (archive) before DA expiration.

Selective Disclosure Mechanism: Archive data is stored in encrypted state, with decryption keys provided only upon legitimate regulator requests.

CANTON-On-chain Archive Role Division:

• CANTON domain: Contract details, party information
• On-chain archive: State transition evidence, commitment history

This area is also categorized as future research, with specific architecture to be developed considering regulatory environment and technology maturity.

6. Future Research Directions

6.1 Multi-DA Strategy

To mitigate risks of single DA layer dependency, multi-DA operation is theoretically desirable. However, these challenges must be resolved:

• L1 Commitment consistency management: Commitment synchronization when publishing the same data to multiple DAs
• Transition timing decision logic: Automatic transition criteria upon DA layer failure
• Absence of production-proven cases: Multi-DA simultaneous operation examples remain limited in the industry

We will continuously monitor this area and review applicability to Oraclizer as industry cases accumulate.

6.2 On-chain Privacy Enhancement

Areas to be analyzed in depth in our next research on privacy-preserving state synchronization:

• Selective encryption of state data: Full encryption vs. sensitive fields only
• Metadata minimization design patterns: Structures that reduce exposed information volume itself
• Regulator-exclusive access channels: Controlled access to encrypted data

6.3 Long-term Archive Architecture

Long-term preservation strategies meeting financial regulatory requirements:

• Data migration after DA expiration: Automated archive pipelines
• Legal evidence preservation requirements: Meeting legal requirements like digital signatures and timestamps
• Cost-efficient long-term storage: Cold storage utilization with on-demand restoration

---

Conclusion

Data availability is the existential condition for oracle state machine. The trustworthiness of bidirectional state synchronization directly depends on the trustworthiness of the DA layer. If DA failure means inconvenience in general rollups, in oracle state machine it means the collapse of the trust foundation itself.

Oraclizer has made clear choices to meet these requirements:

1. DAS-based DA protocol adoption: Independent verifiability, decentralized security
2. KZG Commitment utilization: Verified cryptographic foundation, efficient proofs
3. DAC approach exclusion: Structurally unsuitable for regulatory compliance environments
4. DA-Agnostic design: Avoiding specific DA layer dependency, securing flexibility

At the same time, we honestly acknowledge the limitations of our current design. On-chain metadata privacy, long-term original preservation, and multi-DA strategies remain open research challenges. These areas will be systematically explored in follow-up research.

“In distributed systems, availability is not merely a performance metric—it is a statement about trust.”

Our next research will deeply analyze the on-chain privacy challenges raised here, exploring state synchronization methodologies that simultaneously achieve privacy preservation and regulatory compliance.

---

References

1. Ethereum Foundation. (2024). EIP-4844: Shard Blob Transactions. https://eips.ethereum.org/EIPS/eip-4844

2. Gluchowski, A. (2021). zkRollup vs. Validium. Matter Labs. https://medium.com/matter-labs/zkrollup-vs-validium-starkex-5614e38bc263

3. Al-Bassam, M., Sonnino, A., & Buterin, V. (2018). Fraud and Data Availability Proofs: Maximising Light Client Security and Scaling Blockchains with Dishonest Majorities. https://arxiv.org/abs/1809.09044

4. Kate, A., Zaverucha, G., & Goldberg, I. (2010). Constant-Size Commitments to Polynomials and Their Applications. International Conference on the Theory and Application of Cryptology and Information Security. https://www.iacr.org/archive/asiacrypt2010/6477178/6477178.pdf

5. Buterin, V. (2021). Endgame. https://vitalik.eth.limo/general/2021/12/06/endgame.html

6. Nomos. (2025). KZG Commitments for Data Availability. https://blog.nomos.tech/kzg-commitments-for-data-availability/