TL;DR
D-quencer is Oraclizer’s decentralized sequencing engine that provides Stage 1 rollup-level security. Through a consensus algorithm utilizing BLS (Boneh-Lynn-Shacham) signature-based VRF (Verifiable Random Function), it ensures fair sequencer selection and transaction reliability. In particular, by employing equal stake PoS and multisig-based consensus, it achieves a balance between scalability and security, providing the core foundational technology for regulatory-compliant oracle state machines.
The Challenge of Decentralization in Oracle State Machines
One of the most critical technical elements in realizing oracle state synchronization is a trustworthy decentralized sequencing mechanism. While existing oracle solutions have focused simply on data delivery, Oraclizer aims for complete state synchronization. This represents not just a technical innovation, but a fundamental paradigm shift in blockchain.
However, achieving this goal presents significant challenges. Ensuring immutability in cross-layer state propagation is a critical design principle directly linked to contract completeness. Particularly in higher-order layers like L3, if the sequencer is centralized, the system’s reliability cannot be guaranteed.
Even though liveness can be guaranteed through L1, adopting a high-security-margin consensus algorithm in a rollup mechanism creates another overhead problem. In the face of this dilemma, we needed a new approach.
D-quencer: Harmonizing Decentralization and Efficiency
D-quencer is Oraclizer’s core decentralized sequencing engine developed to solve these problems. To achieve Stage 1 rollup, we’ve adopted an innovative approach: reducing weight calculation overhead through an equal stake PoS model, and selecting Active Asserters from the Standby Asserter group via Boneh-Lynn-Shacham (BLS) signature-based VRF.
Core Design Principles of D-quencer
1. Balanced Decentralization: Equilibrium between complete decentralization and practical performance
2. Fair Sequencer Selection: Unbiased sequencer selection through VRF
3. Efficient Consensus: Lightweight consensus process via BLS signatures and multisig
4. Malicious Activity Prevention: Enhanced network security through slashing mechanisms
5. Regulatory Requirements Integration: Inherent regulatory compliance mechanisms in the consensus process
Consensus Algorithm Operation
The D-quencer consensus algorithm operates through the following stages:
1. Standby Asserter Group Formation and Staking
The first stage of the consensus process is forming the Standby Asserter group. This group consists of 10-100 nodes, each staking identical amounts of assets. This is an innovative approach that reduces the overhead of weight calculations commonly seen in traditional PoS systems.
standbyAsserters = [Node_1, Node_2, ..., Node_n] stake(Node_i) = constantValue for all i
This equal staking model provides the following benefits:
– Computational Efficiency: Simplified selection process without weight calculations
– Fairness: Equal selection opportunity for all nodes
– Decentralization Promotion: Prevention of centralization by large stakers
2. Active Asserter Selection Mechanism
The next step is selecting the Active Asserter using VRF (Verifiable Random Function). Each Standby Asserter node generates a random value using BLS signature-based VRF:
vrf_output_i = VRF(node_private_key_i, current_epoch)
Based on this VRF output, candidates are selected, and the node with the minimum VRF output becomes the Active Asserter:
active_asserter = min(vrf_output_i for i in standbyAsserters)
The elected Active Asserter performs the following roles for the specified epoch:
– Nonce-based ordering of transactions
– Requesting zk proof generation
– Communication and verification with each modular
– OSS coordination for oracle double-spending prevention
– Cross-chain messaging management
3. BLS Multisig-based Consensus
Blocks created by the Active Asserter undergo multisig verification by the Standby Asserter group. This process utilizes the unique signature aggregation capability of BLS signatures:
aggregate_signature = Aggregate(signature_1, signature_2, ..., signature_k)
where k is the number of Standby Asserters participating in the verification. This aggregated signature can be verified as efficiently as a single signature, significantly reducing network overhead.
The BLS multisig approach offers the following advantages:
– Verification Efficiency: Processing multiple signatures with a single verification
– Network Efficiency: Reduced message complexity
– BFT (Byzantine Fault Tolerance) Characteristics: Maintaining consensus even when some nodes are malicious
Specialized Features of D-quencer
Beyond the standard consensus algorithm, D-quencer offers several specialized features to meet the unique requirements of oracle state machines:
1. State Rollback Manager
In oracle state machines, state rollbacks may be necessary due to external system changes or regulatory requirements. D-quencer’s State Rollback Manager provides the following functions:
– Scope-limited Rollback: Targeted rollbacks limited to specific asset IDs or addresses
– Time-limited Rollback: Rollbacks limited to transactions within a specific time range
– Conditional Rollback: Rollbacks only for transactions that meet certain conditions
These granular rollback mechanisms enhance system stability by precisely rolling back only what is necessary.
2. Regulatory Action Priority Manager
One of Oraclizer’s core values is regulatory compliance. D-quencer’s Regulatory Action Priority Manager handles priorities for actions from various regulatory authorities:
– Regulatory Action Classification: Classifying regulatory actions by urgency and importance
– Priority Determination: Deciding priorities between conflicting regulatory actions
– Automated Enforcement: Automatic enforcement of regulatory actions according to priority
3. Cross-chain Action Coordinator
Oracle state synchronization often requires atomic action execution across multiple chains. D-quencer’s Cross-chain Action Coordinator provides the following functions:
– Atomic Execution Coordination: Ensuring atomic execution of actions across multiple chains
– Chain-specific State Monitoring: Tracking action execution status in each chain
– Rollback Coordination: Coordinating rollbacks across all chains if some chains fail
4. State Proof Validator
D-quencer includes a specialized component for validating the validity of oracle state transitions:
– Support for Various Proof Types: Verification of various types of state proofs
– Verification Result Aggregation: Aggregation of results from multiple validators and consensus derivation
– Dispute Resolution: Mechanism for handling disputes about incorrect proofs
5. Off-chain Event Integrator
One of the core functions of an oracle state machine is integrating off-chain events. D-quencer’s Off-chain Event Integrator provides the following functions:
– Support for Various Sources: Collecting events from various off-chain sources
– Reliability Verification: Verifying the reliability and validity of event sources
– On-chain State Reflection: Reflecting verified events in on-chain state
Performance and Scalability Analysis
D-quencer’s performance is influenced by various factors including the number of nodes, BFT security threshold, and consensus delay overhead. Our simulations and test results demonstrate the following performance characteristics:
– Minimum Node Count: Meeting minimum security standards with 10 nodes
– Optimal Node Range: Optimal balance between security and performance with 37-52 nodes
– Maximum Node Count: Diminishing returns beyond 100 nodes
Notably, D-quencer is designed to minimize performance degradation as the number of nodes increases. This is made possible through the following optimization techniques:
– BLS Signature Aggregation: Efficient processing of multiple signatures
– VRF-based Selection: Efficient leader selection mechanism
– Equal Staking: Elimination of weight calculation overhead
Safety of the Rollback Mechanism
Rollback mechanisms are particularly important in oracle state machines. D-quencer provides a dual rollback mechanism for balancing regulatory compliance and decentralized governance:
1. Governance Rollback: Rollback through decentralized governance voting
2. Regulatory Authority Rollback: Priority fast-track rollback by regulatory authority request
These two mechanisms achieve balance through the following safeguards:
– Scope Limitation: Regulatory authorities can directly perform only targeted rollbacks limited to specific asset IDs, addresses, or transactions
– Comprehensive Rollback Safeguards: Rollbacks with broad impact require governance approval
This design ensures regulatory compliance while maintaining the system’s decentralized properties.
Future Research Directions
D-quencer is still an actively researched field. Our main future research directions include:
1. Validator Network Expansion: Hierarchical verification structure to efficiently support more nodes
2. Latency Optimization: Minimizing consensus delay in cross-chain environments
3. Dynamic Node Configuration: Dynamically adjusting the optimal number of nodes according to network conditions
4. In-depth Security Analysis: Additional security analysis for various attack vectors
5. Regulatory Interface Improvement: Enhanced interfaces for more efficient interaction with regulatory authorities
Conclusion
The D-quencer algorithm is one of Oraclizer’s core technologies, forming the foundation for ensuring decentralization and reliability in state synchronization oracles. Through the innovative combination of BLS signature-based VRF and equal staking PoS, we have implemented a consensus mechanism that balances performance and security.
This technical innovation plays a crucial role in realizing an oracle state machine that enables complete state synchronization beyond simple oracles. We will continue to build safer and more efficient state synchronization systems through ongoing improvements to D-quencer.
References
[1]. Boneh, D., Lynn, B., & Shacham, H. (2024). Short Signatures from the Weil Pairing. Journal of Cryptology, 17(4), 297-319.
[2]. Buterin, V. (2024). The Stages of Rollup Evolution. Ethereum Research.
https://ethresear.ch/t/the-stages-of-rollup-evolution/
[3]. Digital Asset. (2024). DAML: The Contract Language for Building Composable Multi-party Applications. https://www.digitalasset.com/daml
[4]. Horizen Korea & Oraclizer Core Team. (2024). Regulatory Compliance Protocol (RCP) for Tokenized Capital Markets.
