DGT DOCS
  • 1. INTRODUCTION
    • 1.1 Executive Summary
    • 1.2 Why DGT
    • 1.3 Distributed Ledgers Technology
      • 1.3.1 Decentralization approach
      • 1.3.2 Consensus Mechanism
      • 1.3.3 Transactions
      • 1.3.4 Layered Blockchain Architecture
      • 1.3.5 Tokenomics
      • 1.3.6 Web 3 Paradigm
      • 1.3.7 Common Myths about Blockchain
    • 1.4 The DGT Overview
      • 1.4.1 Platform Approach
      • 1.4.2 DGT Functional Architecture
      • 1.4.3 Technology Roadmap
    • 1.5 How to create a Solution with DGT Networks
    • 1.6 Acknowledgments
  • 2. REAL WORLD APPLICATIONS
    • 2.1 Case-Based Approach
      • 2.1.1 DGT Mission
      • 2.1.2 The Methodology
      • 2.1.3 Case Selection
    • 2.2 Supply Chain and Vertical Integration
      • 2.2.1 Logistics Solution for Spare Parts Delivery
      • 2.2.2 DGT Based Solution for Coffee Chain Products
    • 2.3 Innovative Financial Services
      • 2.3.1 Crowdfunding Platform
      • 2.3.2 Real World Assets Tokenization
      • 2.3.3 Virtual Neobank over DGT Network
      • 2.3.4 DGT based NFT Marketplace
    • 2.4 Decentralized Green Energy Market
      • 2.4.1 Peer To Peer Energy Trading
      • 2.4.2 DGT based Carbon Offset Trading
    • 2.5 B2B2C Ecosystems and Horizontal Integration
      • 2.5.1 KYC and User Scoring
      • 2.5.2 Decentralized Marketing Attribution
      • 2.5.3 Case Decentralized Publishing Platform
      • 2.5.4 Value Ecosystem
    • 2.6 More Cases
  • 3. DGT ARCHITECTURE
    • 3.1 Scalable Architecture Design
      • 3.1.1 High Level Architecture
      • 3.1.2 DGT Approach
      • 3.1.3 Unique contribution
      • 3.1.4 Component Based Architecture
    • 3.2 Performance Metrics
    • 3.3 Network Architecture
      • 3.3.1 Nework Architecture in General
      • 3.3.2 Network Identification
      • 3.3.3 H-Net Architecture
      • 3.3.4 Transport Level
      • 3.3.5 Segments
      • 3.3.6 Static and Dynamic Topologies
      • 3.3.7 Cluster Formation
      • 3.3.8 Node Networking
      • 3.3.9 Permalinks Control Protocol
    • 3.4 Fault-Tolerant Architecture
      • 3.4.1 Introduction to Fault Tolerance
      • 3.4.2 F-BFT: The Hierarchical Consensus Mechanism
      • 3.4.3 Cluster Based Algorithms
      • 3.4.4 Arbitrator Security Scheme
      • 3.4.5 Heartbeat Protocol
      • 3.4.6 Oracles and Notaries
      • 3.4.7 DID & KYC
    • 3.5 Transactions and Performance
      • 3.5.1 Transaction Basics
      • 3.5.2 Transaction Processing
      • 3.5.3 Transaction and block signing
      • 3.5.4 Transaction Families
      • 3.5.5 Transaction Receipts
      • 3.5.6 Smart Transactions
      • 3.5.7 Private Transactions
      • 3.5.8 Multi signature
    • 3.6 Data-Centric Model
      • 3.6.1 Data layer overview
      • 3.6.2 Global State
      • 3.6.3 Genesis Record
      • 3.6.4 Sharding
      • 3.6.5 DAG Synchronization
    • 3.7 Cryptography and Security
      • 3.7.1 Security Architecture Approach
      • 3.7.2 Base Cryptography
      • 3.7.3 Permission Design
      • 3.7.4 Key Management
      • 3.7.5 Encryption and Decryption
      • 3.7.6 Secure Multi Party Computation
      • 3.7.7 Cryptographic Agility
      • DGTTECH_3.8.4 Gateway Nodes
    • 3.8 Interoperability
      • 3.8.1 Interoperability Approach
      • 3.8.2 Relay Chain Pattern
      • 3.8.3 Virtual Machine Compatibility
      • 3.8.4 Gateway Nodes
      • 3.8.5 Token Bridge
    • 3.9 DGT API and Consumer Apps
      • 3.9.1 Presentation Layer
      • 3.9.2 Application Architecture
    • 3.10 Technology Stack
    • REFERENCES
  • 4. TOKENIZATION AND PROCESSING
    • 4.1 Introduction to Tokenization
      • 4.1.1 DGT Universe
      • 4.1.2 Driving Digital Transformation with Tokens
      • 4.1.3 Real-World Tokenization
      • 4.1.4 Key Concepts and Definitions
    • 4.2 Foundations of Tokenization
      • 4.2.1 Definition and Evolution of Tokenization
      • 4.2.2 Tokenization in the Blockchain/DLT Space
      • 4.2.3 The Tokenization Process
      • 4.2.4 Tokenization on the DGT Platform
      • 4.2.5 Regulatory and Legal Aspects of Tokenization
      • 4.2.6 Typical Blockchain-Based Business Models
    • 4.3 The DEC Transaction Family
      • 4.3.1 DEC Transaction Family Overview
      • 4.3.2 DEC Token Features
      • 4.3.3 DEC Token Protocol
      • 4.3.4 DEC Account Design
      • 4.3.5 DEC Transaction Family Flow
      • 4.3.6 DEC Commands
      • 4.3.7 DEC Processing
      • 4.3.8 Payment Gateways
    • 4.4 Understanding Secondary Tokens
      • 4.4.1 The different types of tokens supported by DGT
      • 4.4.2 How secondary tokens are produced
  • 5. EXPLORING TOKENOMICS
    • 5.1 Introduction
      • 5.1.1 What does tokenomics mean?
      • 5.1.2 Goals of Building the Model for DGT Network
      • 5.1.3 Tokens vs Digital Money
      • 5.1.4 The Phenomenon of Cryptocurrency
      • 5.1.5 Basic Principles of Tokenomics
      • 5.1.6 AB2023 Model
    • 5.2 Node & User Growth
      • 5.2.1 Node Ecosystem
      • 5.2.2 User Growth and Retention Modeling
    • 5.3 Transactions
      • 5.3.1 Transaction Amount Components
      • 5.3.2 Shaping the Transaction Profile: A Three-pronged Approach
      • 5.3.3 Calculation of Transaction Number
    • 5.4 Network Performance Simulation
      • 5.4.1 Endogenous Model
      • 5.4.2 Network Entropy
      • 5.4.3 Network Utility
    • 5.5 Token Supply Model
      • 5.5.1 Introduction to Supply and Demand Dynamics
      • 5.5.2 Token distribution
      • 5.5.3 Supply Protocol
      • 5.5.4 Token Balance and Cumulative Supply
    • 5.6 Token Demand Model
      • 5.6.1 Node-Base Demand
      • 5.6.2 Transaction-Based Token Demand
      • 5.6.3 Staking Part Modeling
      • 5.6.4 Total Demand
    • 5.7 Token Price Simulation
      • 5.7.1 Nelson-Siegel-Svensson model
      • 5.7.2 The Price Model
    • 5.8 Decentralization Measurement
      • 5.8.1 Active Node Index
      • 5.8.2 Node Diversity in Hybrid Networks
      • 5.8.3 Token distribution
      • 5.8.4 Integral Calculation of Decentralization Metric
    • 5.9 Aggregated Metrics
      • 5.9.1 Transaction Throughput: Evaluating Network Performance and Scalability
      • 5.9.2 Market Capitalization: A Dimension of Valuation in Cryptocurrency
      • 5.9.3 Total Value Locked (TVL): A Spotlight on Network Engagement and Trust
  • 6. ADMINISTRATOR GUIDE
    • 6.1 Introduction
      • 6.1.1 Administrator Role
      • 6.1.2 Platform sourcing
      • 6.1.3 DGT Virtualization
      • 6.1.4 Using Pre-Built Virtual Machine Images
      • 6.1.5 Server Preparation
      • 6.1.6 OS Setup and initialization
    • 6.2 DGT CORE: Single Node Setup
      • 6.2.1 Launch the First DGT Node
      • 6.2.2 Dashboard setup
      • 6.2.3 Nodes Port Configuration
      • 6.2.4 Single Node Check
    • 6.3 DGT CORE: Setup Private/Public Network
      • 6.3.1 Network launch preparation
      • 6.3.2 A Virtual Cluster
      • 6.3.3 A Physical Network
      • 6.3.4 Attach node to Existing Network
    • 6.4 DGT Dashboard
    • 6.5 DGT CLI and base transaction families
    • 6.6 GARANASKA: Financial Processing
      • 6.6.1 Overview of DGT’s financial subsystem
      • 6.6.2 DEC emission
      • 6.6.3 Consortium account
      • 6.6.4 User accounts
      • 6.6.5 Payments
    • 6.7 Adjust DGT settings
      • 6.7.1 DGT Topology
      • 6.7.2 Manage local settings
    • 6.8 DGT Maintenance
      • 6.8.1 Stopping and Restarting the Platform
      • 6.8.2 Backing up Databases
      • 6.8.3 Network Performance
      • 6.8.4 Log & Monitoring
Powered by GitBook
On this page
  1. 3. DGT ARCHITECTURE
  2. 3.5 Transactions and Performance

3.5.8 Multi signature

Multi-signature is an approach used in DGT to enhance security and enable collaborative decision-making in transactions. It involves multiple participants jointly authorizing and validating a transaction before it can be executed. This approach is particularly useful in scenarios where multiple parties need to collectively approve and authorize sensitive operations, such as fund transfers or asset issuance.

At the protocol level, DGT incorporates multi-signature functionality by implementing specific algorithms for critical operations. In the case of the DEC (banking) family, two algorithms are implemented: ThresholdSig and MultiSig (MuSig2).

ThresholdSig is used for consecutive transactions where each transaction has only one participant. The first participant determines the threshold, and once the threshold is reached, the transaction is executed. This scheme allows for deferred transactions and requires a predefined number of participants to reach a consensus before the transaction can proceed:

  • Determine the threshold value for the required number of participants.

  • Each participant signs the transaction individually.

  • Once the threshold number of signatures is reached, the transaction is considered valid and can be executed.

MultiSig -MuSig2, (Nick, Ruffing, & Seurin, 2021), is a two-round Schnorr multi-signature scheme. It allows multiple signers to collectively create a single signature for a transaction. This approach enhances security by requiring a threshold number of signers to create a valid signature, ensuring that no single participant can unilaterally authorize a transaction.

The Schnorr signature scheme is a digital signature scheme that provides strong security guarantees while offering efficiency in terms of signature size and verification. It is based on the discrete logarithm problem in a finite cyclic group. The scheme allows for the creation of compact and secure signatures using a single round of communication between the signer and verifier. In the Schnorr scheme, the signer generates a private-public key pair and commits to a specific message. The signer then computes a unique signature by combining their private key with the committed message and other relevant parameters. The resulting signature is a fixed-size value that can be easily verified by the verifier using the signer's public key and the committed message.

Multi-Hop Locks are a technique used in blockchain systems to enable atomic swaps or multi-party transactions across multiple blocks or channels. It allows participants to coordinate and synchronize their actions to ensure that the transaction is executed only if all conditions are met. In a multi-hop lock scenario, each participant involved in the transaction sets up a lock on their funds, specifying the conditions under which the funds can be spent. These locks are designed to be time-bound and require certain cryptographic proofs for unlocking.

Here is a table describing the steps involved in the two-round Schnorr multi-signature scheme (MuSig2) and the utilization of Multi-Hop Locks.

Step

Description

1. Key Generation

Participants generate their own private and public keys.

private_keys = [random.randint(1, 2**256) for _ in range(num_participants)]

public_keys = [private_key * G for private_key in private_keys]

The aggregated public key is computed from individual public keys:

agg_public_key = sum(public_keys)

2. Message Preparation

Participants agree on the transaction details and create a message:

nonces = [random.randint(1, 2**256) for _ in range(num_participants)]

nonces_hash = hashlib.sha256(b''.join([pub_key.serialize() for pub_key in public_keys])).digest()

commitments = [G * hmac.new(nonces_hash, pub_key.serialize(), hashlib.sha256).digest() for pub_key in public_keys]

3. Partial Signature Generation

Participants generate partial signatures using their private keys and the aggregated public key:

partial_sigs = []

for i in range(num_participants):

r = (nonces[i] + agg_public_key * commitments[i].x) % curve_order

e = int.from_bytes(hashlib.sha256(b''.join([commit.serialize() for commit in commitments])).digest(), 'big')

partial_sigs.append((r, (nonces[i] - r * private_keys[i] * e) % curve_order))

4. Partial Signature Exchange

Participants exchange their partial signatures.

5. Partial Signature Aggregation

Participants combine the received partial signatures to create an aggregated partial signature.

agg_partial_sig = (sum([partial_sig[0] for partial_sig in partial_sigs]) % curve_order,

sum([partial_sig[1] for partial_sig in partial_sigs]) % curve_order)

6. Multi-Hop Locks

Multi-Hop Locks are utilized to ensure the aggregated partial signature can only be spent if certain conditions are met.

7. Finalization

Participants add their contributions to the aggregated partial signature.

s = (agg_partial_sig[0] + agg_partial_sig[1] * agg_public_key.x) % curve_order

8. Signature Verification

The aggregated partial signature, along with the aggregated public key, is verified against the original message to ensure validity.

e = int.from_bytes(hashlib.sha256(b''.join([commit.serialize() for commit in commitments])).digest(), 'big')

R = agg_public_key

assert (R * s).x == (commitments[0] + commitments[1]).x

The multi-hop locks mechanism adds a layer of security and flexibility to the multi-signature scheme. It ensures that the aggregated partial signature can only be spent when specific conditions, defined by the participants, are met. This can include requirements such as time locks, spending limits, or multi-party consensus.

Previous3.5.7 Private TransactionsNext3.6 Data-Centric Model

Last updated 1 year ago