DKG 1.0 Enhancement

[cocoyoon]

Issues Tracking:

• Handling duplicate partial key submission(Handling of duplicate partial key submissions #29)
• Decouple next session trigger(Decouple next session trigger from SyncDecryptionKey sync #37)
• Config trait(Introduce Config trait #48)
• SessionWorker(Introduce SessionWorker #49)
• Error Handling(Error Recovery #46)
• Test Scenarios(Test Scenarios #50)

Description:

This pull request implements a fundamental architectural refactoring, transitioning the entire project from a single, monolithic crate into a structured, multi-crate Cargo workspace. This strategic overhaul is aimed at enhancing modularity, enforcing clearer API boundaries, and improving the overall maintainability and scalability of the codebase.

I. High-Level Summary of Changes

The core of this refactoring is the decomposition of the original src directory into several independent, yet interconnected, crates. Each crate is designed around a specific domain of responsibility, creating a clean separation of concerns. The new architecture provides a robust foundation for future development, parallelizes build processes, and simplifies dependency management.

II. Detailed Architectural Breakdown
The new workspace is comprised of the following crates:

1. primitives crate:
   This crate serves as the foundational layer of the workspace, containing the core data structures, traits, and consensus logic that are shared across all other crates.
   types module: Defines universal data models such as Error, Event, Hash, and other core model structures.
   consensus module: Encapsulates consensus-related logic, including Commitment and Payload structures.
   traits.rs: Contains shared traits that define common behavior for different components in the system.

2. node crate (Logical Grouping):
   This is the heart of the node's functionality and is physically divided into two crates for better separation between data definition and service implementation.

node/primitives Crate: Defines the essential building blocks and configurations specific to a node's operation.

• config.rs: Manages node configuration and setup.
• auth.rs: Handles authentication logic.
• key_service/skde.rs: Contains definitions for the SKDE key service.

node/service Crate: Implements the node's runtime logic and orchestrates its various roles through background tasks.

• builder.rs: A service builder responsible for constructing and initializing a node instance with all its dependencies.
• task module: The core of the node's concurrent operations, containing role-specific workers:
  • committee/worker.rs: Logic for committee members.
  • solver/worker.rs: Logic for the solver role.
  • verifier/worker.rs: Logic for the verifier.

3. cli crate:
   This crate is the main entry point for users, providing a command-line interface to configure and launch a node.
   It parses command-line arguments to determine the node's role, data directory, and other settings.
   It utilizes the node/service crate to build and run the node instance according to the provided configuration.

III. Key Benefits and Motivation

• Strict Separation of Concerns: RPC logic is now completely decoupled from core service implementation, and data structures are separated from the logic that operates on them.
• Improved Maintainability: With smaller, focused crates, it is easier to navigate, understand, and modify the code without unintended side effects.
• Enhanced Scalability: The new architecture makes it straightforward to add new functionality or node roles by simply adding new crates to the workspace, minimizing disruption to the existing codebase.
• Clearer Dependency Graph: The workspace structure makes dependencies between components explicit in their respective Cargo.toml files, providing a clear overview of the project's architecture.