4.3.5 DEC Transaction Family Flow
In the DGT Network ecosystem, DEC operations offer a nuanced multi-layered transaction process, distinctively different from other prevalent blockchain networks like Ethereum. Let's delve deeper into understanding the flow and conditions that govern the DEC transaction family.
Preliminary Steps (Optional):
Secret Placement: The user introduces a confidential Verifiable Credential (VC) into the micro-ledger associated with the Notary nodes.
Notary Verification: The Notary nodes authenticate this VC and, post-verification, grant a certificate or a Decentralized Identifier (DID) to the client.
DID & Public Key Registration: Using a designated gateway to the DGT, the Notary captures both the DID and the client's public key (or its equivalent) in the DGT's network Ledger (blockchain ledger). This aids in authenticating the ownership of the DID in subsequent operations.
DID Confirmation: The client obtains a verification for the issued DID. As a next step, the DID, along with the secret (in case solely a public key is insufficient), becomes a part of a standard transaction subjected to validator checks.
The issued DID or certificate can cater to various attributes like expanding regular account capabilities, claiming ownership of an alias (synonym), an object designated for tokenization, or any other data subset necessitating validation in off-chain operations. Crucially, the confidential VC, demanding validation, remains off-limits from the network. It's securely ensconced within a ring of Notaries in a fortified micro-ledger. These Notaries communicate amongst themselves and through the Raft protocol, obtaining write access to the conventional ledger of the DGT network, navigated by PoS mechanisms.
DEC Standard Transaction Flow:
Client Initialization: DEC operations originate at the client's end, primarily through the API interface of the node termed as the PRIMARY.
· Verification by PRIMARY: The PRIMARY node engages in dual verification:
- Evaluating the transaction's format for accuracy.
- Gauging the requirement for advanced undertakings like condition verification by a notary. Certain maneuvers demand prior liaisons with notary nodes, leading to the inclusion of an anchor record within the distributed ledger.
Cluster Approval: Upon successful validation by the PRIMARY node, the transaction is presented for cluster consent. This stage mandates interaction with the dynamic cluster leader, referred to as the LEADER node, where consensus—typically P-BFT or HotStuff—is established.
Cluster-Based BFT Consensus: Each node within the cluster undertakes synchronized checks in alignment with the operation protocol. A majority consensus, as laid out by the BFT protocol, is mandatory.
Final Placement: The transaction's conclusive registration in the ledger transpires after the ring of arbitrators authenticate it. This epitomizes the secondary consensus stratum, steered by the PoS protocol.
The overarching transactional logic is pictorially represented in the accompanying figure.
Distinctive Features of DEC Transaction Process:
Streamlined Verification: Contrary to renowned networks like Ethereum, the DGT ecosystem process transaction with modular approach, the transaction processor, equipped with a specific set of conditions via transaction "family" plug-ins, verifies certain business logic conditions.
Multifaceted Transactions: The DGT network facilitates the coexistence of multiple transaction types. Interestingly, not all are financially inclined.
DEC Family Dynamics: Positioned as a financial transaction, the DEC family manages issued tokens. It boasts its distinct address space and an account management subsystem. Consequently, the transaction's execution intricately ties back to the account status and its inherent attributes.
The DEC transaction family, with its comprehensive validation criteria and dual-layer consensus approach, ensures transactions are robust, secure, and adaptive. It’s a testament to the versatility and forward-thinking approach of the DGT ecosystem.
Last updated
