3.4.6 Oracles and Notaries
3.4.6.1 Off-chain calculation
Off-chain calculations play a crucial role in distributed systems, such as the DGT (Distributed Governance Technology) network, by providing an additional layer of network interaction beyond the traditional on-chain operations. Unlike on-chain calculations that occur directly within the blockchain, off-chain calculations are performed outside of the blockchain network.
The main purpose of off-chain calculations is to handle computations that are resource-intensive, complex, or require confidentiality. These computations may involve processing large amounts of data, performing advanced algorithms, or executing operations that involve sensitive or confidential information. By moving these calculations off-chain, it allows for more efficient use of network resources and ensures the privacy and security of sensitive data. In the context of the DGT network, off-chain calculations are utilized for various tasks, including:
Confidential Information: Off-chain calculations are essential for handling confidential information that cannot be securely stored on the blockchain. This includes sensitive data, private keys, personal information, or proprietary algorithms. By keeping such information off-chain, the DGT network ensures that it remains secure and protected from unauthorized access.
Complex Computations: Certain computations may be computationally expensive or require extensive computational resources. By performing these calculations off-chain, the DGT network can achieve better scalability and efficiency. Off-chain calculations enable faster processing of complex tasks, reducing the burden on the blockchain network and improving overall system performance.
Privacy and Confidentiality: Off-chain calculations provide a way to maintain privacy and confidentiality by ensuring that sensitive data is not exposed on the public blockchain. This is particularly crucial for applications that deal with sensitive information, such as financial transactions or personal data. By keeping these computations off-chain, the DGT network protects the privacy of its users while still ensuring the integrity and security of the overall system.
Advanced Algorithms and Analytics: Off-chain calculations enable the execution of advanced algorithms and analytics that require extensive computational power or access to external data sources. These calculations can provide valuable insights, perform complex data analysis, or facilitate machine learning models. By leveraging off-chain computations, the DGT network can offer sophisticated features and services that go beyond the capabilities of the blockchain itself.
3.4.6.2 Oracle Approach
In the context of blockchain technology, oracles play a crucial role in bridging the gap between the blockchain and the external world. Oracles are mechanisms or entities that provide external data and trigger smart contract execution based on real-world events. They enable blockchain applications to interact with real-world data, such as market prices, weather conditions, sports results, or any other information that resides outside the blockchain.
However, integrating oracles into blockchain systems comes with its own set of challenges, often referred to as the Oracle Problem. The Oracle Problem stems from the fact that blockchain networks are designed to be trustless and decentralized, while oracles introduce a centralized point of failure or trust.
Here are some challenges associated with the Oracle Problem:
Trustworthiness: Oracles are typically operated by a single entity or a centralized group. This centralization creates a potential vulnerability where the oracle provider could manipulate or tamper with the data it provides. Ensuring the trustworthiness and reliability of oracles becomes a critical challenge.
Data Authenticity: Verifying the authenticity and integrity of the data received from oracles is essential. Blockchain systems need mechanisms to validate that the data provided by oracles has not been tampered with or manipulated.
Data Source Reliability: Oracles rely on external data sources, and the reliability of these sources varies. Ensuring the accuracy and reliability of the data retrieved from external sources is a challenge, as these sources may be prone to errors or malicious manipulation.
Real-time Data: Many blockchain applications require real-time or near real-time data from oracles. However, retrieving and verifying real-time data can be challenging due to network latency, data transmission delays, and the need for consensus on the validity of the data.
Cost and Performance: Data retrieval from oracles can incur costs and introduce latency due to external dependencies. Smart contract developers need to consider these factors and optimize their design to balance the benefits of using oracles with the associated costs and performance implications.
To address some of these challenges, the concept of Random Oracle has been proposed. The Random Oracle approach is a cryptographic concept where an oracle acts as a mathematical function that responds to queries with random and unpredictable outputs. In this approach, the oracle's behavior is deterministic but unknown, providing a level of unpredictability that prevents malicious actors from exploiting oracles.
The Random Oracle approach helps ensure the integrity and security of the oracle's responses by introducing an element of unpredictability. It provides a solution to the Oracle Problem by minimizing the potential for manipulation or tampering with the data provided by oracles.
Oracles could be realized using smart contracts approach:
Oracle Integration: Oracles are integrated into smart contracts through specific functions or interfaces. Smart contracts define functions that interact with the oracle, allowing them to fetch external data or trigger actions based on real-world events.
Data Retrieval: When a smart contract requires external data, it makes a request to the oracle using a designated function. The oracle then retrieves the requested data from external sources, such as APIs or external systems. It verifies the authenticity and integrity of the data, ensuring it has not been tampered with.
Data Verification: After retrieving the data, the oracle validates its integrity. It may perform various checks, such as verifying digital signatures, comparing data against predefined criteria, or checking the data against trusted sources. The oracle ensures that the data is accurate and trustworthy before providing it to the smart contract.
Data Transmission: Once the oracle has verified the data, it transmits the information back to the smart contract. The smart contract can then utilize the received data to execute predefined actions or trigger further contract logic based on the provided information.
3.4.6.3 Notary Model
The notaries are special nodes in the DGT network (placed outside chain producing chain) serve multiple purposes and perform various tasks, including:
Storage, Verification, and Issuance of Access Certificates:
Notaries could write information to the registry, creating anchors, hash sums, identifiers, and other meta-information.
They can validate the correctness of records, ensuring proper signature verification and other attributes.
Notaries also play a role in issuing access certificates for nodes, acting as a decentralized repository for certificate management.
Formation of Decentralized Identifiers (DIDs):
Following W3C specifications, notaries are responsible for generating decentralized identifiers that uniquely identify entities within the network.
Store and Proof VC (Verifiable credentials).
Verification of Digital Objects:
Notaries verify digital objects such as Twins, ensuring their authenticity and integrity within the network.
From a technical perspective, a notary is implemented as a separate server using open-source software like Hashicorp VAULT. The notary consists of a VAULT component for storing secrets and a service gateway for interacting with telegrams and the DGT network.
The gateway component in Telegram is responsible for creating and signing certificates using the notary's key. This ensures that certificate operations are controlled and validated by the certificate processor. The certificates contain a set of attributes entered by users during natural language dialogues with the Telegram bot. The certificates are stored in VAULT, and their availability and validity can be checked by contacting a notary using the unique DID identifier.
3.4.6.4 Standard Oracles
The objective of integrating a standard oracle into blockchain systems is to bridge the gap between on-chain operations and external, off-chain data sources. Oracles play a crucial role in enhancing the functionality, reliability, and scope of blockchain applications by providing a secure and verified way to incorporate real-world data into the blockchain. This introduction aims to outline the mechanisms of standard oracle operation, their applications, and the specific benefits of employing a random oracle model.
Mechanisms of Oracle Operation:
Data Verification: Oracles verify external data before it is used in blockchain transactions, ensuring its authenticity and accuracy. This is crucial for maintaining the integrity of smart contracts that rely on external inputs.
Secure Data Transmission: The oracle acts as a secure intermediary, transmitting verified data from external sources to the blockchain. Encryption and secure communication protocols are used to protect the data from tampering or interception.
Consistency and Determinism: Oracles provide consistent and deterministic outputs for the same inputs, a fundamental requirement for blockchain systems to ensure that all participants agree on the state of the blockchain.
Random Oracle Model:
Definition: The random oracle model is a theoretical framework used to simulate an idealized oracle that provides perfectly random responses to queries. In practical applications, this model helps in designing cryptographic systems that approximate this ideal behavior.
Application in Cryptography: Random oracles are used to prove the security of cryptographic protocols under the assumption that the oracle provides a truly random, unpredictable output for each unique query.
Benefits for Blockchain: Implementing a random oracle model in blockchain systems can enhance security and fairness, particularly in applications like decentralized finance (DeFi), where unpredictability and resistance to manipulation are essential.
Applications and Purposes:
Smart Contract Execution: Oracles enable smart contracts (or transaction family processing ) to execute based on real-world events and data, such as price feeds, weather conditions, or the outcome of events, thereby expanding the scope of blockchain applications.
Zero-Knowledge Proofs (ZKP): Oracles facilitate the use of ZKPs by providing a way to verify claims about data without revealing the data itself, enhancing privacy and security in blockchain transactions.
Interoperability: By providing a method for secure data exchange between different blockchains and external systems, oracles enhance interoperability and enable a wide range of cross-chain functionalities.
3.4.6.5 Notary Torus
Notary nodes form rings (groups of nodes) and each ring supports a specific type of information storage. The aggregate of all the notary rings forms a layer of notaries called Torus. These rings maintain a unified registry of information using the CFT consensus algorithm RAFT. Notary nodes have specific roles in facilitating a secure information exchange scheme:
KEY KEEPER:
This node is responsible for storing the key required to print all other VAULT instances within the RAFT cluster.
The KEY KEEPER node operates separately from the cluster and facilitates the transfer of the printing key to the cluster nodes during initialization.
It operates within a trusted part of the network.
LEADER:
The leader node is a member of the RAFT cluster and plays a critical role in key transit during the startup of nodes.
To initiate key transit, the leader node obtains a token and the actual address of the key holder from the DGT network.
The leader node prints its vault, initializes the network, and shares its data with other RAFT nodes.
It serves as a gateway for other notaries to enter the notary network, providing access to the VAULT network connected through RAFT consensus.
SUCCESSORS:
Successor nodes are subsequent nodes within the RAFT cluster, excluding the leader.
To join the cluster, successor nodes require a token for printing the vault, the address of the leader node for network entry, and a token for accessing secrets.
This data is obtained from the DGT network and is only accessible to notaries with keys from the notary ring.
Once successfully joined, successor nodes actively participate in the network.
All types of notary nodes, including KEY KEEPER, LEADER, and SUCCESSORS, need to print their storage to facilitate their operations. During startup, they utilize the token from the KEY KEEPER node obtained from the DGT network. This token enables them to utilize the key transit mechanism provided by VAULT. The actual key required for printing is known only to the KEY KEEPER node, which operates within a trusted network segment and does not directly interact with users.
3.4.6.6 Notaries and DGT Network
The information stored in the notary's repository is not directly accessible within the DGT network. During the notary's initialization process, the VAULT instance is set up, and the necessary keys and tokens are stored in the configuration file. This includes the root token and keys for accessing the secret vault. Additionally, a read-only access token is generated for transferring certificates to the processor.
To connect a notary to the DGT network, a transaction is executed to activate the notary, creating a record in the network topology. This process provides the notary with information about other active notaries and establishes connections within the notary network. The transaction processor, which works in conjunction with the notaries, retrieves information about active notaries from the topology and interacts with available networks in its segment. Once the notary ring is launched (note that the network can function without notaries with some limitations), an anchor is placed in the registry representing the token of the key holder node from the DGT. This allows the subsequent utilization of the key transit mechanism by VAULT notaries. The actual key is owned by the KEY KEEPER node, which operates within a trusted network segment and does not directly interact with users.
The following information is stored in the DGT network:
Token/anchor for initializing the VAULT secret store within the notary ring.
Address of the KEY KEEPER node.
Leader token for working with secrets within the ring.
Address of the LEADER node to connect SUCCESSORS nodes to the notary network.
Keys of the SUCCESSORS nodes, representing notaries authorized to work with secrets.
3.4.6.7 Notary Security approach
Ensuring the security of notaries is of paramount importance to maintain the integrity and confidentiality of the data they handle. Here are some security measures employed in the context of notaries:
Off-Chain Security Mechanisms: Notary security is primarily addressed through off-chain security mechanisms. These mechanisms include encryption, access control, secure communication protocols, and other established security practices that protect the confidentiality and integrity of data at rest and in transit.
Network Isolation: Notaries are often deployed in a separate network segment, isolated from the public or less secure parts of the network. This isolation provides an additional layer of protection against unauthorized access and potential attacks.
Key Management: Proper key management practices are crucial for notary security. This includes securely generating, storing, and distributing cryptographic keys used for encryption, digital signatures, and other security operations. Key rotation and revocation procedures are also implemented to maintain the confidentiality and integrity of the keys.
Access Control and Authentication: Notaries employ access control mechanisms to ensure that only authorized entities can interact with them. This involves robust authentication protocols, such as multi-factor authentication, to verify the identity of users or systems accessing the notaries. Access privileges are granted based on the principle of least privilege to minimize the risk of unauthorized access.
Zero-Knowledge Proofs (ZKP): ZKP is a cryptographic technique used to prove the validity of a statement without revealing any additional information. Notaries can utilize ZKP protocols to provide cryptographic proofs of correctness or authenticity without disclosing sensitive data. This enhances the security and privacy of the interactions between the notaries and other entities within the network.
Secure Multiparty Computation (SMPC): SMPC allows multiple parties, including notaries, to perform computations on shared data without revealing the underlying information. This technique ensures that sensitive data remains private even during collaborative computations. SMPC protocols enable secure data processing and prevent unauthorized access to confidential information.
Auditing and Monitoring: Continuous monitoring and auditing of notaries are essential to detect and respond to any security incidents or suspicious activities. Logging mechanisms capture relevant events and actions within the notaries, allowing for forensic analysis and ensuring accountability.
Incident Response and Recovery: Well-defined incident response plans are established to handle security breaches or other incidents that may affect notaries. These plans outline the steps to be taken, including containment, investigation, recovery, and communication, to mitigate the impact and minimize any potential disruptions.
Last updated
