Framework: analysis of DLT-systems
This paper aims to determine whether the object being analyzed is a DLT system. The results obtained are well suited for a comparative analysis of different projects, ranging from the management structure, to the definition of references to which transactions refer.
Distributed ledger technology is a technology for storing information, the key features of which are sharing and synchronization of digital data according to a consensus algorithm, the geographical distribution of equivalent copies at different points around the world, and the absence of a central administrator.
')
Genesis
The protocol level refers to the processes that need to be developed and run before the network starts.
Dependence on other networks.
Dependence on other protocols depends on the boundaries of the analyzed project. This determines whether the system can operate as an independent system (to be self-sufficient) or is under the dependency of another network.
Table 1. Dependence on other systems
Program code
The code can be based on an existing framework or written from scratch. The most popular frameworks are code databases from open source systems (Bitcoin / Ethereum). Also, there are bases with closed source code for closed platforms provided by such projects as Digital Asset / Clearmatics and SETL.
Table 2. Program Code
Rule definition
The introduction of rules refers to the definition of the set of rules on which the DLT system must operate. This process can be performed by different participants and is individual for a particular DLT system.
Protocol updates refer to existing processes that allow you to modify system rules. Updating the protocol may include eliminating technical errors (bugs), improving the security and functionality of the system, as well as extending or limiting existing protocol rules.
Protocol control
Protocol management refers to a set of decision-making processes that allow you to change a protocol in an orderly and legal manner. This is a subset of broader project management that covers the complete set of processes and norms that describe and define coordination and actions, but which cannot be embedded formally in the DLT system.
An important element of any proposed protocol change is the way it is accepted and ratified — or, in other words, how legitimacy is provided at the suggestion of network participants. Since legitimacy in this context is a social concept, it seems to us expedient to identify some of the possible “socio-political” relationships found in DLT systems.
Table 3. Protocol Management
Protocol control takes many forms and is often unclear. Initially, DLT systems are characterized by anarchic power (free), there are no companies or groups of people responsible for making decisions. Most often, they are similar to the open-source movement management processes. An example of a discussion of protocol changes may be the communication of developers in a chat / GitHub / conference. Under dictatorial conditions, the process of discussing change may be exactly the same, but the final decision will be made by one person. In some cases, the form of protocol control can be defined by more than one type of government. For example, the EOS blockchain operates as a federation of manufacturers of blocks that are chosen by users who have an EOS asset in their possession. Voice weight is determined by the number of tokens held at the address. This type of government divides the protocol into two sides: the “elite” and the “ordinary” users, taking the characteristics of a hierarchical system: federation, democracy, and plutocracy.
The actual process of updating the protocol implies:
Table 4. Protocol change form
Different DLT systems use different methods to update the network. For example, Ethereum accepts donations to finance development, and also updates the network using software from developers funded through grants.
The DLT protocol network is a direct result of the implementation of protocol rules. The network consists of coordinated work of participants and processes that adhere to the technological standard (protocol) and actively participate in the exchange of data and information via certain communication channels.
The process of transferring data between members of the DLT system.
Network access
Access to the network implies the ability to connect to the protocol, it can be limited or unlimited.
As a rule, systems with unlimited access are not limited in the number of participants, while closed networks may establish a limited number of participants.
Usually, participants gain direct access to the network by launching full nodes: they are considered “elite” with a large set of rights, since they can send / check and send record data. Network members can also get indirect access to the network by running “light clients” that request data from complete nodes by connecting through a special service (API).
Table 5. The form of network access
As a rule, the more open a system is, the more susceptible it is to attacks. In particular, these systems are vulnerable to the Sibyl attack, when an attacker creates many fake personalities to increase the impact on the network.
Sending data
Data transfer is the process of distributing data to connected nodes. The data may be unprocessed / unformatted or standardized for a specific format (for example, in the form of a transaction or record). Data can be transferred to each node (universal diffusion), or only to a certain subset of nodes (multichannel diffusion). In the latter case, the dissemination of data is usually limited to the parties to the transaction. This allows you to create a "channel" for data transfer, usually by this means sharding / Lightning Network.
Table 6. Form of sending data
An example of multichannel data diffusion is that not all network participants should be involved in reaching consensus on channel conditions: only channel participants must achieve consistency over the data stored in this channel (“local” consensus). This is significantly different from systems with global data diffusion, since each individual node must come to a consensus on the global state of the system (“global” consensus); the impossibility of reaching a consensus of certain nodes may lead to their disconnection, or the creation of a fork.
Transaction creation
The process of creating transactions contains a set of instructions that will be executed after adding a transaction to the network. Transaction creation may be unlimited (i.e. accessible to all) or limited to some participants. Transactions are created by users signing a message with their private key. Various interfaces are available for users to create and send transactions to the network (for example, PCs and mobile wallets).
Transaction processing
Transaction processing describes the set of actions required to add an unconfirmed transaction to the confirmed list. A transaction is considered (previously) valid after being added to the list (“confirmed”), which results in the execution of instructions embedded in the transaction. However, confirmation alone is not enough for this transaction to become the basis for subsequent operations; before the transaction outputs can be used by the system.
Figure 1. Transaction processing in a DLT system
Records are subject to a specific consensus algorithm used in the DLT system. This includes the process of determining whether the proposed entry is valid, as well as rejecting invalid entries (for example, entries that are defective or incompatible) and choosing between different, but equally valid entries.
Record Candidate
Records that may be moved to the list of confirmed transactions in the future are sent by the creators of the blocks who select them from the list of unconfirmed transactions and merge them together to form candidates for entry into the list of confirmed records. There are two properties that determine the right to send a record and its future inclusion in the list of confirmed records.
Table 7. Record Forms
Since the records are subject to consensus, they must adhere to the rules of the protocol. First, they must be properly formatted and not contain invalid or invalid transactions. In addition, each entry must include a link / pointer to the previous entry and, if necessary, use PoW or any other method that complicates the conduct of the Sibyl attack.
The consensus algorithm can be classified according to its level of complexity (electrical / cash costs). Algorithms with an unlimited level of complexity are measured in the resources that are necessary to achieve consensus. For example, in the case of calculating PoW Bitcoin, the difficulty of finding the right solution increases as the complexity of data hashing increases. Quite the contrary, other algorithms work (for example, the task of the Byzantine generals / BFT) do not require significant computational costs and have limited complexity.
In open systems, an algorithm should be provided that reduces the chance of a Sybil attack. Private (closed) systems check each participant before allowing them access to the network connection, which prevents the possibility of an attack. In closed systems, a group of nodes usually tends to choose one node that will create blocks.
Conflict resolution
Conflict can be caused by several reasons:
In the event of a situation of the first item in the Bitcoin network, the network selects the longest block chain as the real one and ignores the shorter one. In Tezos, the validity of a block with another one by “block weight” is determined, the weight here is the number of “approvals” from validators, which it receives in a random way from steakers.
Validation
Validation refers to the set of processes required to ensure that entities independently arrive at the same conclusion regarding an approved set of records. This includes: checking the transactions sent / checking the recorded data / checking the overall network status. This one is important to distinguish from non-DLT systems, since it provides participants with the opportunity to conduct an independent system audit.
Transaction verification
Verifying a transaction is to ascertain whether an individual entry conforms to the protocol rules before transferring it to other subjects. This includes: the correctness of the transaction format, the presence of an appropriate signature and the fulfillment of the condition that the transaction does not conflict with any other. In some systems, there may be a system that prevents transactions from being performed until a certain point in time or another reason. Usually, such conditions are met by smart contracts.
Checking the entry to be sent allows you to make sure that the entry conforms to the protocol rules. If the proposed entry is recognized as valid, it is added to the list of confirmed entries and is relayed to all connected nodes on the network. Although, this process is different in each system, but, as a rule, by general principles it is similar everywhere, for example, checking that PoW work was performed on a transaction. The combination of checking the sent transactions and their subsequent recording by the validators provides the possibility of an independent audit of the entire system.
Transaction record
The confirmed transaction / record is not necessarily irreversible. Record irreversibility can be probabilistic in nature (for example, a PoW-based system in which it is impractical to re-calculate all recorded transactions), or systems that include “checkpoints” that must be assigned to each transaction. Confirmed entries may be called immutable, but those entries that have been “pre-confirmed” may be canceled. Pre-confirmed records become unchangeable after overcoming the transition state from “pre-confirmed” to “confirmed”.
Figure 2. Transaction processing in DLT systems
Figure 2 describes a schematic description of the process that occurs during the processing of a transaction. First, the user creates a transaction and sends it to the network. Each node checks if the transaction complies with the protocol rules. If it is considered valid, the node adds the transaction to its list (mempool), where all unconfirmed transactions are stored, waiting to be added to the list of confirmed transactions.
At the transaction processing stage, the nodes randomly select unconfirmed transactions from their mempool and then merge them together into a list of “pre-approved” transactions. Further, the transactions will be checked in accordance with the consensus algorithm in order to offer these transactions to all other participants in the network. Nodes will view received transactions and their contents; if a transaction passes validation, the transaction is added to the node list. Lists with transactions of each node are eventually sent to a single, most important list of confirmed transactions and will be considered completed.
However, confirmed transactions can be "canceled" due to an alternative transaction, which means that at the settlement stage, transactions can be canceled - in this case they are returned to the nodes as unconfirmed transactions, waiting for the creation of a new transaction list. The transaction processing time at the “Settlement” stage depends on the settings of a single system. Some systems implement instant transaction recording and irrevocability, but some protocols have “probabilistic” completion, in the sense that, in theory, transactions can be canceled. In practice, however, the likelihood of this action decreases with each new transaction added, since the costs of nodes associated with PoW can become high. While transactions are at the “settlement” stage, they cannot be considered “completed”. The transaction settlement process enhances the assurance that transactions are accurately included in the lists of all participating nodes, rather than being stored only on local nodes, this helps prevent double waste attacks.
Some systems implement a system of “control points” to limit the possibility of “long-range” attacks. In the event of this attack, the node creates an alternative chain with its own personal transactions (which are stored only in it), these transactions do not appear on the network, but are immediately sent to the nodes in the “settlement” phase to force other nodes to replace them with its local transactions. “Control points” are blocks that will never be canceled or replaced. As a result of control points, attack "reach" decreases. However, control points increase the risk of creating a fork.
Table 8. Properties of Confirmed Transactions
The protocol level determines how the system will work and which rules to follow. The network layer implements the underlying principles of the protocol. Together, the protocol and network layers form the basis for the data layer, which accumulates over time as transactions are recorded in the list of confirmed records.
Operations
The operations component includes all the processes by which participants perform interactions with the system.
Data sources
The input process refers to the source or method of obtaining data for the protocol. Data sources can be internal or external, which may reflect active user interaction with the system, a change in the state of the protocol caused by an internal system process or received from the outside (for example, a transaction sent from another protocol) or a smart contract.
We define internal input sources as any record or transaction created by the user or due to the result of user interaction with the protocol. External input sources, on the other hand, are the result of input from other systems that interact with the protocol, but which are in principle separate from the underlying platform (i.e. they are dependent or interoperable). Hybrid protocols allow users to transfer transactions using "payment channels - the state channel" at any time, but the development of these methods is still at an early stage.
Table 9. Data entry forms
Software executable transactions
Not all data level changes are a direct result of internal or external input data. Some changes in the system occur due to the execution of instructions of the program code. A prime example is smart contracts. When executing the pledged program code, a change in the network state occurs in the protocol, for example, a transaction occurs that is recorded in the confirmed list. Some DLT systems only support scripting language (scripting). For example, Bitcoin Script, it works in a simple scripting language that allows you to create restricted-simple programs. Such systems are called Stateless. Ethereum (Solidity), Tezos (Michelson) and EOS (WebAssembly) - these systems support Turing-complete programming languages ​​to develop complex smart contracts, while Bitcoin and Monero use a scripting language that allows limited operations.
Table 10. Properties of program-executed transactions
The actual execution of the calculations
The location of the program determines where the calculations take place. As a rule, the place of execution can be within the network - on-chain or off-chain (outside the network). On-chain calculations are performed on each node. This environment can vary from a simple virtual machine, both to a scripting language, and to be complex (EVM is an Ethereum virtual machine), which ensures the execution of Turing complete programs. Smart contracts in the on-chain are launched by each node in the network and, therefore, are often called "self-executing".
Off-chain computations are performed in environments that are external to the protocol. The event that runs the program code occurs on the on-chain, and the calculations take place on another system, without loading the main network. Also, there is a hybrid (Hybrid) application launch system, for example, Plasma in Ethereum. Or, for example, Cosmos, where the main network serves as a "center", but the calculations themselves occur in the child networks.
Table 11. Properties of the execution of software-executable transactions
Links
From the moment users start interacting with the DLT system, the log is updated over time. However, the magazine is an abstraction. All processes that occur in a DLT system are specific to a protocol. For example, an electronic payment protocol should contain information about assets owned by specific users. On the other hand, the DLT system, which includes smart contracts, must have its own virtual machine that implements the execution of program code. Therefore, the concept of the magazine is an abstraction.
Types of links
There are four different types of raw data: endogenous, exogenous, hybrid, and self-referenced data.
Endogenous (internal) links refer to data that track information about variables that are “native” to the system. For example, in Bitcoin, one endogenous reference variable is used to track the number of bitcoins that users had at a given time. This internal variable is updated as the user sends and receives Bitcoins to other addresses. Exogenous (external) link refers to data that tracks information about variables that exist outside the system. Hybrid reference refers to data that has both endogenous and exogenous characteristics. There is still a fourth type, which is neither endogenous, nor exogenous, nor hybrid: it is a neutral or empty data type — it is a self-reference. For example, a smart contract is simply a piece of code that can be executed when certain conditions are met. Although the smart contract may require information about external or internal system variables, the code itself does not have an internal reference to anything outside of itself (“null link”).
Table 12. Types of links and their meaning
This paper aims to determine whether the object being analyzed is a DLT system. The results obtained are well suited for a comparative analysis of different projects, ranging from the management structure, to the definition of references to which transactions refer.
Distributed ledger technology is a technology for storing information, the key features of which are sharing and synchronization of digital data according to a consensus algorithm, the geographical distribution of equivalent copies at different points around the world, and the absence of a central administrator.
')
Technical analysis
Protocol level
Genesis
The protocol level refers to the processes that need to be developed and run before the network starts.
Dependence on other networks.
Dependence on other protocols depends on the boundaries of the analyzed project. This determines whether the system can operate as an independent system (to be self-sufficient) or is under the dependency of another network.
Table 1. Dependence on other systems
Program code
The code can be based on an existing framework or written from scratch. The most popular frameworks are code databases from open source systems (Bitcoin / Ethereum). Also, there are bases with closed source code for closed platforms provided by such projects as Digital Asset / Clearmatics and SETL.
Table 2. Program Code
Rule definition
The introduction of rules refers to the definition of the set of rules on which the DLT system must operate. This process can be performed by different participants and is individual for a particular DLT system.
Protocol update
Protocol updates refer to existing processes that allow you to modify system rules. Updating the protocol may include eliminating technical errors (bugs), improving the security and functionality of the system, as well as extending or limiting existing protocol rules.
Protocol control
Protocol management refers to a set of decision-making processes that allow you to change a protocol in an orderly and legal manner. This is a subset of broader project management that covers the complete set of processes and norms that describe and define coordination and actions, but which cannot be embedded formally in the DLT system.
An important element of any proposed protocol change is the way it is accepted and ratified — or, in other words, how legitimacy is provided at the suggestion of network participants. Since legitimacy in this context is a social concept, it seems to us expedient to identify some of the possible “socio-political” relationships found in DLT systems.
Table 3. Protocol Management
Protocol control takes many forms and is often unclear. Initially, DLT systems are characterized by anarchic power (free), there are no companies or groups of people responsible for making decisions. Most often, they are similar to the open-source movement management processes. An example of a discussion of protocol changes may be the communication of developers in a chat / GitHub / conference. Under dictatorial conditions, the process of discussing change may be exactly the same, but the final decision will be made by one person. In some cases, the form of protocol control can be defined by more than one type of government. For example, the EOS blockchain operates as a federation of manufacturers of blocks that are chosen by users who have an EOS asset in their possession. Voice weight is determined by the number of tokens held at the address. This type of government divides the protocol into two sides: the “elite” and the “ordinary” users, taking the characteristics of a hierarchical system: federation, democracy, and plutocracy.
On-chain control, implies the inclusion of control functions at the data level. The goal is to formalize governance, thereby increasing legitimacy and avoiding network splits due to disputes or inconsistent protocol updates. A diverse set of on-chain voting schemes have been developed for DLT systems, ranging from a community mood barometer to referendums. However, on-chain control functions, as a rule, are only an addition to other forms of control.Protocol change
The actual process of updating the protocol implies:
- software update on GitHub, if it is an open-source project;
- client update if it is a closed source protocol;
- Customers running on old software code may be considered irrelevant and blacklisted;
- clients running on old software code form a fork, which leads to the creation of an alternative version of the protocol.
Table 4. Protocol change form
Different DLT systems use different methods to update the network. For example, Ethereum accepts donations to finance development, and also updates the network using software from developers funded through grants.
Network level
The DLT protocol network is a direct result of the implementation of protocol rules. The network consists of coordinated work of participants and processes that adhere to the technological standard (protocol) and actively participate in the exchange of data and information via certain communication channels.
Communication process
The process of transferring data between members of the DLT system.
Network access
Access to the network implies the ability to connect to the protocol, it can be limited or unlimited.
- Unlimited access - any user can freely connect / disconnect at any time;
- Restricted access - only certain users can connect to the network, usually controlled by a designated subject.
As a rule, systems with unlimited access are not limited in the number of participants, while closed networks may establish a limited number of participants.
Usually, participants gain direct access to the network by launching full nodes: they are considered “elite” with a large set of rights, since they can send / check and send record data. Network members can also get indirect access to the network by running “light clients” that request data from complete nodes by connecting through a special service (API).
Table 5. The form of network access
As a rule, the more open a system is, the more susceptible it is to attacks. In particular, these systems are vulnerable to the Sibyl attack, when an attacker creates many fake personalities to increase the impact on the network.
A sibyl attack is a type of attack where an attacker gains access to or hides a change in the protocol, creating many false personalities.Because identification is an exogenous (ie, “real”) property, the DLT system cannot prevent these attacks, it must rely on external participants (certification system) or mechanisms that reduce the likelihood of an attack (PoW / PoS).
Sending data
Data transfer is the process of distributing data to connected nodes. The data may be unprocessed / unformatted or standardized for a specific format (for example, in the form of a transaction or record). Data can be transferred to each node (universal diffusion), or only to a certain subset of nodes (multichannel diffusion). In the latter case, the dissemination of data is usually limited to the parties to the transaction. This allows you to create a "channel" for data transfer, usually by this means sharding / Lightning Network.
Early DLT systems (for example, Bitcoin, Litecoin) use a universal data distribution model, which still remains the most popular data dissemination method.In order to maintain anonymity and privacy for companies, the later systems implemented a multi-channel diffusion model (for example, Hyperledger Fabric, Corda). Other systems, such as Cosmos, are designed to act as “Hubs” so that independent DLT systems can be interconnected by sharding.
Table 6. Form of sending data
An example of multichannel data diffusion is that not all network participants should be involved in reaching consensus on channel conditions: only channel participants must achieve consistency over the data stored in this channel (“local” consensus). This is significantly different from systems with global data diffusion, since each individual node must come to a consensus on the global state of the system (“global” consensus); the impossibility of reaching a consensus of certain nodes may lead to their disconnection, or the creation of a fork.
Transaction creation
The process of creating transactions contains a set of instructions that will be executed after adding a transaction to the network. Transaction creation may be unlimited (i.e. accessible to all) or limited to some participants. Transactions are created by users signing a message with their private key. Various interfaces are available for users to create and send transactions to the network (for example, PCs and mobile wallets).
Transaction processing
Transaction processing describes the set of actions required to add an unconfirmed transaction to the confirmed list. A transaction is considered (previously) valid after being added to the list (“confirmed”), which results in the execution of instructions embedded in the transaction. However, confirmation alone is not enough for this transaction to become the basis for subsequent operations; before the transaction outputs can be used by the system.
Figure 1. Transaction processing in a DLT system
Records are subject to a specific consensus algorithm used in the DLT system. This includes the process of determining whether the proposed entry is valid, as well as rejecting invalid entries (for example, entries that are defective or incompatible) and choosing between different, but equally valid entries.
Record Candidate
Records that may be moved to the list of confirmed transactions in the future are sent by the creators of the blocks who select them from the list of unconfirmed transactions and merge them together to form candidates for entry into the list of confirmed records. There are two properties that determine the right to send a record and its future inclusion in the list of confirmed records.
Table 7. Record Forms
Since the records are subject to consensus, they must adhere to the rules of the protocol. First, they must be properly formatted and not contain invalid or invalid transactions. In addition, each entry must include a link / pointer to the previous entry and, if necessary, use PoW or any other method that complicates the conduct of the Sibyl attack.
The consensus algorithm can be classified according to its level of complexity (electrical / cash costs). Algorithms with an unlimited level of complexity are measured in the resources that are necessary to achieve consensus. For example, in the case of calculating PoW Bitcoin, the difficulty of finding the right solution increases as the complexity of data hashing increases. Quite the contrary, other algorithms work (for example, the task of the Byzantine generals / BFT) do not require significant computational costs and have limited complexity.
In open systems, an algorithm should be provided that reduces the chance of a Sybil attack. Private (closed) systems check each participant before allowing them access to the network connection, which prevents the possibility of an attack. In closed systems, a group of nodes usually tends to choose one node that will create blocks.
Conflict resolution
Conflict can be caused by several reasons:
- participants disagree on which version of the protocol is relevant;
- participants disagree on verified transactions.
In the event of a situation of the first item in the Bitcoin network, the network selects the longest block chain as the real one and ignores the shorter one. In Tezos, the validity of a block with another one by “block weight” is determined, the weight here is the number of “approvals” from validators, which it receives in a random way from steakers.
Any consensus algorithm carries a number of compromises.Table 7. Forms of transaction processing motivation
Validation
Validation refers to the set of processes required to ensure that entities independently arrive at the same conclusion regarding an approved set of records. This includes: checking the transactions sent / checking the recorded data / checking the overall network status. This one is important to distinguish from non-DLT systems, since it provides participants with the opportunity to conduct an independent system audit.
Transaction verification
Verifying a transaction is to ascertain whether an individual entry conforms to the protocol rules before transferring it to other subjects. This includes: the correctness of the transaction format, the presence of an appropriate signature and the fulfillment of the condition that the transaction does not conflict with any other. In some systems, there may be a system that prevents transactions from being performed until a certain point in time or another reason. Usually, such conditions are met by smart contracts.
The 51% attack is a case where a participant or several participants combine their computing power (voices) and process transactions on the network faster than the rest of the protocol. Such attacks allow you to conduct invalid transactions and record them as valid ones. Particularly vulnerable is a system using PoWChecking records
Checking the entry to be sent allows you to make sure that the entry conforms to the protocol rules. If the proposed entry is recognized as valid, it is added to the list of confirmed entries and is relayed to all connected nodes on the network. Although, this process is different in each system, but, as a rule, by general principles it is similar everywhere, for example, checking that PoW work was performed on a transaction. The combination of checking the sent transactions and their subsequent recording by the validators provides the possibility of an independent audit of the entire system.
Transaction record
The confirmed transaction / record is not necessarily irreversible. Record irreversibility can be probabilistic in nature (for example, a PoW-based system in which it is impractical to re-calculate all recorded transactions), or systems that include “checkpoints” that must be assigned to each transaction. Confirmed entries may be called immutable, but those entries that have been “pre-confirmed” may be canceled. Pre-confirmed records become unchangeable after overcoming the transition state from “pre-confirmed” to “confirmed”.
Figure 2. Transaction processing in DLT systems
Figure 2 describes a schematic description of the process that occurs during the processing of a transaction. First, the user creates a transaction and sends it to the network. Each node checks if the transaction complies with the protocol rules. If it is considered valid, the node adds the transaction to its list (mempool), where all unconfirmed transactions are stored, waiting to be added to the list of confirmed transactions.
At the transaction processing stage, the nodes randomly select unconfirmed transactions from their mempool and then merge them together into a list of “pre-approved” transactions. Further, the transactions will be checked in accordance with the consensus algorithm in order to offer these transactions to all other participants in the network. Nodes will view received transactions and their contents; if a transaction passes validation, the transaction is added to the node list. Lists with transactions of each node are eventually sent to a single, most important list of confirmed transactions and will be considered completed.
However, confirmed transactions can be "canceled" due to an alternative transaction, which means that at the settlement stage, transactions can be canceled - in this case they are returned to the nodes as unconfirmed transactions, waiting for the creation of a new transaction list. The transaction processing time at the “Settlement” stage depends on the settings of a single system. Some systems implement instant transaction recording and irrevocability, but some protocols have “probabilistic” completion, in the sense that, in theory, transactions can be canceled. In practice, however, the likelihood of this action decreases with each new transaction added, since the costs of nodes associated with PoW can become high. While transactions are at the “settlement” stage, they cannot be considered “completed”. The transaction settlement process enhances the assurance that transactions are accurately included in the lists of all participating nodes, rather than being stored only on local nodes, this helps prevent double waste attacks.
Some systems implement a system of “control points” to limit the possibility of “long-range” attacks. In the event of this attack, the node creates an alternative chain with its own personal transactions (which are stored only in it), these transactions do not appear on the network, but are immediately sent to the nodes in the “settlement” phase to force other nodes to replace them with its local transactions. “Control points” are blocks that will never be canceled or replaced. As a result of control points, attack "reach" decreases. However, control points increase the risk of creating a fork.
Table 8. Properties of Confirmed Transactions
Data level
The protocol level determines how the system will work and which rules to follow. The network layer implements the underlying principles of the protocol. Together, the protocol and network layers form the basis for the data layer, which accumulates over time as transactions are recorded in the list of confirmed records.
Operations
The operations component includes all the processes by which participants perform interactions with the system.
Data sources
The input process refers to the source or method of obtaining data for the protocol. Data sources can be internal or external, which may reflect active user interaction with the system, a change in the state of the protocol caused by an internal system process or received from the outside (for example, a transaction sent from another protocol) or a smart contract.
We define internal input sources as any record or transaction created by the user or due to the result of user interaction with the protocol. External input sources, on the other hand, are the result of input from other systems that interact with the protocol, but which are in principle separate from the underlying platform (i.e. they are dependent or interoperable). Hybrid protocols allow users to transfer transactions using "payment channels - the state channel" at any time, but the development of these methods is still at an early stage.
Table 9. Data entry forms
Software executable transactions
Not all data level changes are a direct result of internal or external input data. Some changes in the system occur due to the execution of instructions of the program code. A prime example is smart contracts. When executing the pledged program code, a change in the network state occurs in the protocol, for example, a transaction occurs that is recorded in the confirmed list. Some DLT systems only support scripting language (scripting). For example, Bitcoin Script, it works in a simple scripting language that allows you to create restricted-simple programs. Such systems are called Stateless. Ethereum (Solidity), Tezos (Michelson) and EOS (WebAssembly) - these systems support Turing-complete programming languages ​​to develop complex smart contracts, while Bitcoin and Monero use a scripting language that allows limited operations.
Table 10. Properties of program-executed transactions
The actual execution of the calculations
The location of the program determines where the calculations take place. As a rule, the place of execution can be within the network - on-chain or off-chain (outside the network). On-chain calculations are performed on each node. This environment can vary from a simple virtual machine, both to a scripting language, and to be complex (EVM is an Ethereum virtual machine), which ensures the execution of Turing complete programs. Smart contracts in the on-chain are launched by each node in the network and, therefore, are often called "self-executing".
Off-chain computations are performed in environments that are external to the protocol. The event that runs the program code occurs on the on-chain, and the calculations take place on another system, without loading the main network. Also, there is a hybrid (Hybrid) application launch system, for example, Plasma in Ethereum. Or, for example, Cosmos, where the main network serves as a "center", but the calculations themselves occur in the child networks.
Table 11. Properties of the execution of software-executable transactions
Log component
Links
From the moment users start interacting with the DLT system, the log is updated over time. However, the magazine is an abstraction. All processes that occur in a DLT system are specific to a protocol. For example, an electronic payment protocol should contain information about assets owned by specific users. On the other hand, the DLT system, which includes smart contracts, must have its own virtual machine that implements the execution of program code. Therefore, the concept of the magazine is an abstraction.
Types of links
There are four different types of raw data: endogenous, exogenous, hybrid, and self-referenced data.
Endogenous (internal) links refer to data that track information about variables that are “native” to the system. For example, in Bitcoin, one endogenous reference variable is used to track the number of bitcoins that users had at a given time. This internal variable is updated as the user sends and receives Bitcoins to other addresses. Exogenous (external) link refers to data that tracks information about variables that exist outside the system. Hybrid reference refers to data that has both endogenous and exogenous characteristics. There is still a fourth type, which is neither endogenous, nor exogenous, nor hybrid: it is a neutral or empty data type — it is a self-reference. For example, a smart contract is simply a piece of code that can be executed when certain conditions are met. Although the smart contract may require information about external or internal system variables, the code itself does not have an internal reference to anything outside of itself (“null link”).
Table 12. Types of links and their meaning
Conclusion
This paper aims to determine whether the object being analyzed is a DLT system. The results obtained are well suited for a comparative analysis of different projects, ranging from the management structure, to the definition of references to which transactions refer.
Source: https://habr.com/ru/post/433246/
All Articles