VINE Technical Paper

Proprietary DAG
as a decentralized
infrastructure of Grape

v.04
 Contents
1. Introduction
1.1. Grape’s foundation
1.2. Comparison of the DLT Grape project with other known solutions
2. Distributed ledger structure
2.1. Sites
2.2. Commit transaction
2.3. Smart contracts
3. Sites and transactions
3.1. Transaction lifecycle
3.2. Algorithms for selecting vertices for sites
3.2.1. Algorithm 1 (random selection of vertices)
3.2.2. Description of MCMC, MCMC+, MCMC++ algorithms
3.2.3. Algorithm 2 (MCMC+)
3.2.4. Algorithm 3 (MCMC++)
3.3. Formal veri cation
3.4. Veri cation
4. Processing of smart contracts
4.1. Stages of processing of smart contracts
4.1.1. Creating a smart contract
4.1.2. Pool with uncon rmed smart contract transactions
4.1.3. Verifying and adding a smart contract to a commit transaction
4.1.4. Executing smart contracts and updating balances
4.2. Storing information about smart contracts in a commit transaction
5. Site Veri cation and Registry Synchronization
5.1. Algorithm for calculating the share of vertices that directly or indirectly
con rmed the site
5.2. Algorithm for accepting a commit transaction
5.3. Synchronization
5.3.1. Synchronization of commit transactions
5.3.2. Site synchronization
5.3.3. Information exchange (normal synchronization mode)
6. Scalability

Appendix A. Commit Transaction Format

Appendix B. Site Format

2
fi
fi
fi
fi
fi
 1. Introduction
Since the introduction of distributed ledger technology (DLT), blockchain has improved
security, provided transparency and visibility, and decreased transaction costs. Blockchain
today has many use cases, from basic token transactions to private applications for
enterprises and governments. Due to various technical limitations, public blockchain vendors
are working to solve issues with speed and scalability, considered the core barriers to mass
adoption.

Ethereum, the second biggest blockchain, is still working on a solution to improve TPS, but
currently, it can only handle around 13 TPS. Due to this limitation, projects such as Polygon, a
Layer 2 solution on Ethereum, became popular. Polygon can process up to 7,000 TPS at a
fraction of the cost. Other Layer 1 solutions, such as Algorand, process 3,000 TPS; the self-
proclaimed fastest is Solana reaching up to 65,000 TPS. In contrast, Grape can
reach 700,000 TPS, which is not the limit, as its technology allows it to scale even further.

Blockchain is not the only type of DLT on the market. Various projects use DAG (Directed
Acyclic Graph) as a foundation for a decentralized ledger. DAG differs from the usual
blockchain in its record structure and asynchrony. It is not a blockchain or a consensus-
building model because it has no blocks. DAG functions as a network of interconnected
branches that expands in multiple directions. Transactions can be con rmed much faster
while remaining decentralized since each node only con rms the previous one. Each
transaction refers to one or more previous parent transactions. They, in turn, refer to their
parent transactions, and so on. Thus, the system knows the exact order between transactions
in this chain of transactions. The result is forming a "tree" of transactions, where each is
con rmed and immutable.

Grape aims to solve the shortcomings of DLT and existing DAG solutions. Grape created
several new technical solutions to ensure high transaction processing speeds, historically
reliable and secure information storage, implementation of smart contracts, and much more.
This solution is called VINE, which is Grape's decentralized infrastructure.

Figure 1.1
DAG
DAG and
blockchain ledger
structures

VS

Blockchain 1 2 3 4 5

3
fi
fi
fi
 Core Bene ts of VINE
Scalability Asynchronous Flexibility
User growth does not Transactions are not queued Microtransactions are
create bottlenecks, but or formed into blocks, a handled much more
rather more nodes create crucial factor for real-time effectively due to the lack
greater scalability focused applications used for of technical requirements
resulting in more TPS. banking, gaming, etc. affecting fees.

1.1. Grape’s Foundation

The Grape project is built on the principles of a Directed Acyclic Graph (DAG) using modern
solutions:
• Bulding a DLT in the form of a DAG as a chain of entities (sites) processed and included in
the registry in parallel and independently by different network participants. This potentially
allows for high throughput, i.e. solving the problem of DLT scaling;
• Own advanced algorithms for selecting vertices based on a random movement of particles
taking into consideration the mathematical apparatus of Markov Chain Monte Carlo (MCMC).
This reduces computational complexity (compared to the MCMC algorithm) and provides
protection against building parallel chains of sites (solves the problem of distributed ledger
security);
• Verification mechanisms designed to formally verify DAG entities (solves the security problem
of a distributed ledger);
• Account models for storing the state of wallets and aggregate balances in a decentralized
ledger, which speeds up fund transfer operations and simplifies the implementation of smart
contracts;
• Commit transactions - special entities that are periodically (every 5 seconds) added to the
parallel blockchain and are designed to synchronize local copies of the DAG on individual
network nodes. Commit transactions are used to quickly load the current state of the ledger
by newly connected nodes, as well as to coordinate account balances between individual
network nodes.

1.2. Comparison of the DLT Grape Project with Other Known Solutions

There are many different DLT technologies, such as blockchain, DAG, Hashgraph, Holochain,
etc. A comparison of these technologies can be made based on the following criteria:
• Scalability is one of the key criteria when choosing a DLT technology. Blockchain can
provide robust scalability, but it comes with performance and transaction speed issues. DAG
provides higher scalability and transaction speed but may require more network members.
• Transaction con rmation speed is a criterion that determines how quickly transactions can
be processed and con rmed. DAG can provide faster transaction processing than
blockchain, which makes it more attractive for use in some areas.

4
fi
fi
fi
 • Security is a criterion that determines how secure users' data and funds are. Blockchain can
provide high security, but centralization problems can arise. The DAG provides a more
decentralized structure, making it more secure from attacks.
• Energy ef ciency is a criterion that is becoming increasingly relevant because of growing
environmental concerns. Proof-of-Work (PoW) blockchain consumes a signi cant amount of
energy, while Proof-of-Stake (PoS) and DAG-based blockchains consume much less energy.
• Transaction cost: a DLT cost-effectiveness measure that determines how expensive it is for
users to send their transactions. Fees for sending and processing transactions on Proof-of-
Stake (PoS) blockchains and DAG-based DLTs can be very low.
• Flexibility is a criterion that determines how easy it is to make changes in technology and
adapt to different needs and tasks.

A brief comparison of the various DLT technologies is shown in Table 1.1.

Table 1.1
DLT on blockchains DLT on graph structures
Brief comparison
of different DLT
technologies
PoS Hashgraph /
PoW consensus DAG
consensus Holochain

Scalability Very low Low Very high Very high

Transaction
Very low Low Very high Very high
con rmation speed

Safety Very high High Very high Potentially high

Energy
Very low High Very high Very high
ef ciency

Transaction cost High Low Very low Very low

Flexibility Low High Very high Very high

Thus, DLTs based on graph structures have clear advantages over classical chains based on
the blockchain. For example, DAG technology has the following advantages:
• High scalability: DAG has no limit on the block size and the number of transactions that
can be processed per unit of time.
• Fast transactions: In DAG, transactions can occur in parallel, which allows the processing
of a large number of transactions per second.
• High security and reliability: Due to mutual con rmation of transactions and parallel
processing, DAG is more secure and is not subject to long delays in transaction
processing, which increases the reliability and stability of the system.

5
fi
fi
fi
fi
fi
 • High energy ef ciency: In DAG, there is no need to solve complex mathematical
problems, which require a lot of energy. Instead, DAGs use consensus algorithms that
minimize the use of network resources and the amount of information that needs to be
passed between participants.
• Lower fees: DAG transactions are cheaper than PoW blockchain transactions because
they do not require mining. This allows users to send transactions with lower fees or no
fees at all.
• High exibility: DAG technology can be adapted to various use cases, capable of
providing high scalability and high speed, which is useful for creating micro-
transactions or solving other problems.

Table 1.2 provides a brief comparison of various DLT projects using DAG technology.

Table 1.2 Technology Release Consensus Transaction Scalability Security Governance Transaction Fee
Date Speed (TPS) Approval
Brief comparison Time
of DLT projects
using DAG
technology
IOTA June Coordinator- 1,000 (with Limited by Cryptographically Decentralized 1-3 minutes Zero
2016 based consensus Coordinator) Coordinator, secured foundation
it's slower
without it

DAGCoin July DAG-based 8.000 Limited by Cryptographically Centralized 30 seconds 0,0005

2018 consensus hardware secured DAGCoin
resources

ByteBall December DAG-based 100 Limited by Cryptographically Centralized Few minutes 1MB
2016 consensus hardware secured storage
resources fee
$0,033

Nano November Open Up to 7,000 Limited by Cryptographically Decentralized Limited only Zero
2017 representative hardware secured by
voting consensus resources transaction
transfer
delays

XDag December DAG-based 200-300 Limited by Cryptographically Decentralized 30 seconds Min of

2017 consensus hardware secured 0,01
resources XDAG

Fantom February Lachesis-based 300,000 Horizontally Cryptographically Decentralized Few seconds Very low
2018 consensus (Up to 10,000 scalable secured
in real tests)

Grape 2023 VINE proprietary Higher than Increased Post-quantum Decentralized Sub-second Very low
synchronization 700,000 with every cryptographically limited by or zero
and con rmation connected secured front-end
algorithms node (linear
complex effect)

* The data in this table is taken from the of cial pages of DLT projects
6
fl
fi
fi
 The conducted research shows that the main problem of modern DLT projects built on
graphs is ensuring consistency.

Consistency is one of the key concepts in computer science that refers to the property of
data and systems that ensures that the data is always in the correct state and is in a
consistent state between the various nodes or components of the system. In the context
of distributed systems and databases, consistency means that all copies of data in
different nodes of the system must be in the same state at any given time. This means
that any data changes made in one node of the system must be re ected in all other
nodes in the system to ensure that the data does not contradict each other and does not
contain errors.

In a DAG-based DLT, different participants can see different graph branches. This means
that local versions of the DAG may differ between nodes, which can lead to consistency
issues in transaction processing, errors in calculating wallet balances, and registry
security issues. This explains the relatively low-speed characteristics of modern DAG
registries. For example, with 300,000 TPS declared, real testing of DLT Fantom on
TestNet of 7 nodes showed only 4000-10000 TPS. Different projects solve the problem of
consistency in different and not always successful ways. For example, the IOTA project
uses a centralized solution in the form of a special coordinator node, which violates the
basic principle of registry decentralization.

An integrated approach has been implemented to solve the problem of consistency in

DLT Grape, consisting of the use of new innovative solutions:
• Ledger storage model that takes into account the structure of the DAG and the height
of each transaction for fast veri cation and calculation of balances.
• Ledger synchronization and consensus algorithms with 100% con rmed transactions
included in the irrevocable part of the ledger (we call this a DAG slice).
• Algorithm for the formation of the so-called xing transactions for fast synchronization
of network nodes and acceleration of registry veri cation;
• Vertex selection algorithms in the DAG, which speed up the procedure for con rming
previously generated transactions;
• Algorithms for processing smart contracts, taking into account the structure of the
registry and processing xing transactions.

7
fi
fi
fi
fi
fi
fl
fi
 These new high-tech solutions made it possible to solve the problem of fast synchronization
of local DAG copies at different nodes, which, together with parallel processing of
transactions in different branches of the graph, provide the unique characteristics of DLT
Grape:
• Scalability is very high, limited only by the hardware resources of the connected nodes
and the number of nodes.
• The speed of generating and processing transactions is more than 700,000 TPS.
• The speed of transaction con rmation is very high, limited only by the time delay when
transferring transactions in a peer-to-peer network (usually, fractions of a second).
• Transaction cost is zero or very low (depending on the number of connected nodes and
motivation model).

Separately, there’s a possibility of including transactions in the irrevocable part of the registry.
This is a new feature implemented in DLT Grape, which guarantees 100% con rmation of the
transaction, i.e., the impossibility of canceling it under any scenarios in the behavior of
network nodes. As a rule, in modern DLT projects, the acceptance of transactions is
probabilistic in nature, i.e., their con rmation can be challenged and canceled with some
(usually very small) probability. At the same time, the longer the waiting time, the less likely it
is for the con rmation of the transaction to be canceled. In DLT Grape, each transaction
enters the pool of irrevocable transactions after about 5 seconds, and the probability of
con rmation cancellation is zero, i.e., con rmation of transactions is certain.

It should also be noted that in DLT Grape, cryptographic information protection is

implemented using fast and secure algorithms that are resistant to quantum cryptographic
analysis. This guarantees historically reliable and secure storage of transactions even in the
conditions of using new calculations based on physical principles and phenomena of quantum
physics by intruders.

2. Distributed Ledger Structure

A distributed ledger is a set of replicated, shared, and synchronized arrays of digital data
(entities) distributed among different users of the system.
DLT VINE is implemented using DAG technology by connecting individual entities (we call
them sites) with edges. The direction of the edge means a link to the previous site.

2.1 Sites
Entities in DLT VINE are formed by network nodes in the form of sites.
Sites include transactions and are stored in a distributed ledger in the form of an acyclic-
directed graph. Each new site links to the two previous ones, thus con rming all the sites to
which it directly or indirectly links. Validation involves performing a check and establishing the
correctness of the recorded information.

8
fi
fi
fi
fi
fi
fi
fi
 2.2 Commit Transaction
Architecturally, commit transactions are not included in the DAG structure, but are made in
the form of a parallel linear structure of sequential entities, following the example of a classic
blockchain. This is shown schematically in Figure 2.1.

Figure. 2.1
A simpli ed
structure of the
formation of a DAG
and a parallel
structure from a
linear sequence of
commit
transactions.

Each commit transaction is formed as a result of:

• counting the share of con rmations of each site by the current DAG vertices. If the site
has a 100% con rmation rate, it is marked as 100% con rmed (this is indicated by the
corresponding color in the gure);
• synchronization of the generated list of 100% veri ed sites between the validating nodes.

Each commit transaction stores:

• up-to-date balance of accounts corresponding to the result of completing 100% of the
share of veri ed sites;
• information about smart contracts, the result of their veri cation, and execution.

Thus, smart contracts in Grape only appear in commit transactions.

The format of commit transactions (TxPin) complies with the speci cation given in annex A.
Figure 2.2 shows the structure of a commit transaction in the notation of a UML diagram.

9
fi
fi
fi
fi
fi
fi
fi
fi
fi
 Figure. 2.2 TxPin

UML diagram of the bytes prev

commit transaction
structure google.protobuf.Tim
estamp ts

repeated SiteID
sites

repeated Node nodes

Balance balance
Balance
bytes pk
map<string, bytes>
bytes sign balance

repeated
ExecutedSmcTx
smcTxs
ExecutedSmcTx
repeated Diff diffs
Txv1 tx

Diff TxReceipt receipt

Mapping mappingDiff
TxReceipt
AccountDiff Mapping
accountDiff TxStatus {
bytes address SUCCESSFUL = 0;
FAILED = 1;
AccountDiff bytes key }

AccountData bytes value int32 fuelUsed

newValue
TxStatus status
reserved 2 to 5
string
statusMessage
AccountData
repeated TxExecLog
bytes address logs

bytes balance

int64 nonce
TxExecLog
bytes codehash
bytes
contractAddress
bytes code
repeated LogTopic
topics

LogTopic bytes data

bytes hash int64 pinTxNumber

2.3 Smart Contracts

VINE is made using DAG technology. This means that individual entities are stored not in the
form of a directed linear structure of a classical blockchain, but in the form of a tree-like,
branching graph with cross-references and a complex non-linear structure.
To simplify the work with smart contracts, VINE uses only the linear part of the distributed
ledger. In other words, the only “visible” part of the ledger for smart contracts is the
information published in commit transactions (see Figure 2.1). This means that smart
contracts can only operate on information (account balances, accounts, validators, etc.) that
is directly speci ed in commit transactions. However, it also has its own characteristics:
• The balances of accounts in VINE between commit transactions are changed by entities
“invisible” to smart contracts – transactions from DAG sites. This means that at the time of
the next commit transaction, the states of the accounts will be provided (for a smart
contract) "a priori", i.e. given "as is" with already changed states that are "invisible"
entities for the smart contract;

10
fi
 • The “invisible” part of the registry for smart contracts is executed before the formation of a
commit transaction. This means that the following is the nal order of execution of smart
contracts: the smart contract is executed in relation to the state of the system that exists
at the time the initiating (publishing or calling) smart contract transaction is written to the
commit transaction.

3. Sites and Transactions

The main entities of VINE are sites (Node) that include transactions as well as links to veri ed
sites.
Site Format (Node) complies with the speci cation given in Appendix B.
Figure 3.1 shows the structure of the site in the notation of the UML diagram.
The stages of creating a site are shown in Figure 3.2.
•

Figure. 3.1
Node
UML site structure
diagram NodeId id

float cumWeight NodeId

float txWeight bytes id

google.protobuf.Tim string address

estamp time
uint64 idMajor
bool valid
uint32 idMinor
Height height

Height Txv1 tx
map<string, bool>
uint64 minheight missingTargets

uint64 maxheight

Figure 3.1
Light node Full node
Stages of creating
a site

Creating TX Picking a vertex

PSP 2
Creating TX
DAG storage model

TX of light mode

Registry integrity
PSP 2 Formal True check
veri cation of Site formation Full registry
TX veri cation

Description about
the correctness or
authority of TX
Forget TX PSP 2

11
fi
fi
fi
fi
fi
 3.1 Transaction Lifecycle
The transaction lifecycle includes:
• Creation - the client application creates a transaction, serializes, signs, and sends it to a
peer-to-peer network node;
• Formal veri cation - the node that received the transaction performs its formal veri cation;
• Encapsulation - the node that received and veri ed the transaction encapsulates the
veri ed transaction in the site. If the node generated the transaction, the rst two steps
are skipped;
• Site formation. The node, using the vertex selection algorithm, selects two previously
uncon rmed sites. The identi ers of the selected vertex sites are speci ed in the
generated site. The site is serialized and signed by the host;
• Distribution - a node sends a site to peers connected to it;
• Synchronization - all nodes that received the site perform their formal veri cation
(checking the structure, version, signatures, etc.) and synchronize their own copies of
VINE;
• Formation of a commit transaction.

3.2 Algorithms for Selecting Vertices for Sites

Each new site links (veri es) two other (previous) uncon rmed sites (vertices).
The choice of site (transactions) for con rmation is based on the vertex selection algorithm.
VINE implements three main algorithms:
• by default - random selection algorithm (Algorithm 1);
• algorithm based on random walk MCMC+ with additional normalization of cumulative site
weights (Algorithm 2).
• algorithm based on random walk MCMC++ with processing only own site weights
(Algorithm 3).

The random selection algorithm is the fastest and most economical to use. Algorithms based
on MCMC provide resistance to the imposition of third-party DAG branches and protection
from "lazy" (non-vertex-con rming) sites.

3.2.1 Algorithm 1 (random selection of vertices)

Input: weight set of vertices (unveri ed sites);
Output: number of a selected vertex.
1) generate x - implementation of a uniformly distributed random variable
on the interval [0,1];
2) normalize the weights. For this, we calculate for everyone:

Check the correctness of normalization:

3) Accept and select the range that belongs to x :

Return a number .

12
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
 3.2.2 Description of MCMC, MCMC+, MCMC++ Algorithms
The MCMC (Markov Chain Monte Carlo) algorithm is described in detail in the article
"The Tangle", section 4.1 "A parasite chain attack and a new tip selection algorithm."
The main idea of the MCMC algorithm is to put some "particles" (also known as random
wanderers) at different nodes of the graph and let them move toward the vertices in a random
way. The vertices "chosen" during the random walk become candidates for approval.
The MCMC random walk algorithm is described as follows.
1
1. Consider all nodes on the interval , Where large enough .
2. Self-post particles at nodes in this interval.
3. Let these particles perform independent random walks with discrete time "to the
vertices", which means that the transition from the node to node is possible if and only
if the node con rms the node .
4. The two random walks that reach the set of vertices rst, determine the two vertices to be
validated. However, it may be wise to modify this rule as follows: rst, discard those
random walks that reached the vertices too quickly because they could end up on one of
the "lazy vertices."
5. The walk transition probabilities are de ned as follows: if con rms , then the transition
probability is proportional to:

Where:
• – adjustable parameter of the MCMC algorithm; (3.1)
• cumulative node weights , , ;
• denotation means that the node con rms node .

The most genuine approach to modernize the MCMC algorithm is to normalize the weights,
i.e. transform the formula (3.1) as follows:

Where:
• – adjustable parameter of the MCMC algorithm;
(3.2)
• – normalized aggregate (cumulative) node weights , , :

• denotation means that the node con rms node .

(3.3)

1 The indicated interval depends, rst of all, on the order (rule) of numbering the nodes of the graph. In further studies, we directly
13 set this interval by indicating the serial numbers of nodes corresponding to the order in which they are formed.
​​
fi
fi
fi
fi
fi
fi
fi
fi
 Thus, different variants of the MCMC algorithm differ only in the way the probabilities are
calculated in Step 5:
• The MSMS algorithm (in the author's interpretation) uses formula (3.1), where
are the cumulative weights of the nodes , , ;

• The MCMC+ algorithm uses formula (3.2), where are the normalized
aggregate (cumulative) node weights , , ;

• The MCMC++ algorithm uses formula (3.2), where are the normalized own
weights of the nodes , , .

Input data for the implementation of algorithms:

• – adjustable parameter of the algorithm. At the algorithm also works, but only
takes into account the network topology. At the algorithm gives preference to
vertices that are located farther from the genesis and there are many paths to these
vertices (higher throughput);
• – depth of "throwing" of a random walk particle. The higher there is a more reliable
algorithm, potential protection from "parasitic" chains;
• set of weights at each "transition" of the random walk.

3.2.3 Algorithm 2 (MCMC+)

Input:
• – adjustable parameter of the algorithm;
• – depth of "throwing" of a random walk particle. By default, we select the maximum
depth, i.e. we consider the genesis block to be the throwing point;
• DAG as a set of transactions with assigned weights
,
including a set of weights
vertices (unveri ed sites).

Output: number selected vertex.

We implement a random walk through a chain of transitions “from the site to the
site ". Let's assume that the random walk particle is located in the site and this site
con rms sites with own weights .
Then transition algorithm consists of steps:

1. Accept . We normalize the weights . For this, we calculate

to all, according to the formula (3.3):

Checking the correctness of normalization:

14
fi
fi
 2. Calculate the transition probabilities . For this, we expect for everyone
the following:

3. Select a vertex for the transition. To do this, we use Algorithm 1 with the input
(the weight normalization step can be omitted, the weights are already
normalized). The output of Algorithm 1 gives the number
of the selected site from to go to .

Then we repeat the transition algorithm until one of the vertices of the graph with weights is
selected . We return the number of selected vertex.

3.2.4 Algorithm 3 (MCMC++)

The main difference in the use of MCMC+ is the rapid growth of cumulative weights. For
example, for a throwing depth of 100, the values of the cumulative weights can be on the
order of 2 which is very dif cult to store and process. In addition, with a large discrepancy in
100,

the cumulative weights, the probabilities can also differ signi cantly. For example,
after normalization will be , i.e. we have a
practically uncontested transition of a random walk.
The MCMC++ algorithm uses only its own weights (determined by node ratings,
commissions, etc.).

3.3 Formal Veri cation

The formal veri cation is performed by a full node upon receipt of each new transaction.
Veri cation is performed for all transactions. During the synchronization process, each node
receives sites from a trusted node (the leader node acting as a validator) and includes them in
its copy of VINE without veri cation, since it does not have all the necessary information to
conduct a formal veri cation on its own. If at least one of the formal requirements is not met,
the check is recognized as not passed, the site is not included in the registry. Full veri cation
of the registry is not carried out in this case.

3.4 Veri cation

A simpli ed registry veri cation process is shown in Figure 3.2.

15
fi
fi
fi
fi
fi
fi
fi
fi
fi
​​
fi
fi
 Figure 3.2
Simpli ed registry
veri cation
Accounts

Con ict

100% synchronisation
Solving the con ict
Ranked list of sites

100% con rmed sites

DAG
Time

The registry veri cation includes:

• representation of the registry as an ordered array of all sites. Changes in account
balances are directly related to site transactions, i.e. these changes are also ranked;
• making a decision on the correctness of transactions included in the checked part of the
registry. The check is performed according to the criterion: "The value of the balance of
the wallet must be above zero.”

4. Processing Smart Contracts

The following stages of the life cycle are applicable to each smart contract:
• Creation (construction) of a smart contract. At this stage, the logic of the contract actions
is programmed (in the form of program code);
• Veri cation (audit) of a smart contract. It is performed by the smart contract developer, as
a rule, before the smart contract is published in the distributed ledger. This stage is
designed to check the logic of the program code and the correctness of the possible
results of its completion with different initial data. Veri cation (audit) of a smart contract is
not recorded in the distributed ledger;
• Publication (initialization, deployment) of a new smart contract. The transaction is formed
and published to the network by any user of the system. At this stage, the smart contract
account is created, the internal state is initiated, etc.;

16
fi
fl
fi
fi
fi
fl
fi
fi
 • adding a smart contract to a special Diff object for the commit transaction, where the new
account for the published contract is stored;
• smart contract call. The transaction is formed and published to the network by any user of
the system. The same smart contract can be called multiple times;
• adding the results of a smart contract call to the internal storage (MappingDiff object) of
the Diff object for the committing transaction. The results of the call are re ected as a
change in the smart contract storage;
• validation of initialization correctness / execution of the smart contract. In the current
implementation, veri cation, and publication of the results of the execution of a smart
contract is performed by one node - the leader, whose actions imitate the work of
validators;
• validation of initialization / execution of the smart contract. Initialization/execution of a
smart contract is considered correct if no con icts are found in the system as a result of
the check.

Thus, actions with smart contracts are recorded in the distributed ledger in two cases:
• publication of a new smart contract and the results of this publication (with a mark of
correctness or incorrectness);
• calling a smart contract and the results of this call (with a mark of correctness or
incorrectness).

Publishing and calling a smart contract are made in the form of corresponding transactions,
and further, when referring to a smart contract transaction, we will mean any of these options
unless otherwise speci ed.

4.1 Stages of Processing of Smart Contracts

The general process for processing smart contracts and generating a commit transaction is
presented in the UML notation of the sequence diagram in Appendix B.
Smart contract processing includes:
• creation of a smart contract;
• formation of a pool of uncon rmed transactions of smart contracts;
• adding of smart contracts to the commit transaction;
• execution of smart contracts and updating balances

4.1.1 Creating a Smart Contract

The user (light client or full node), having created a smart contract, draws it up in the form of a
special transaction. This transaction propagates across the network.
When a transaction with a smart contract is distributed over the network, it is formally veri ed.
If the formal veri cation was successful, then the transaction with the smart contract is
broadcast by the node further. If the formal veri cation fails, the transaction with the smart
contract is forgotten.

17
fi
fi
fi
fi
fl
fi
fl
fi
 4.1.2 Pool with Uncon rmed Smart Contract Transactions
Pool of uncon rmed smart contracts - a pool with a set of transactions with smart contracts that
have successfully passed formal veri cation but have not yet been added to the commit
transaction.
After receiving a transaction with a smart contract:
• a check is performed to see if this transaction was previously added to the pool of
uncon rmed smart contracts. If the transaction has not yet been added, then
• it is formally tested. If the formal check was successful, then
• a transaction with a smart contract is added to the local pool of uncon rmed smart
contracts;
• a transaction with a smart contract is broadcast further over the network.

4.1.3 Verifying and Adding a Smart Contract to a Commit Transaction

Veri cation of smart contracts is performed at the stage of formation of a commit transaction.
The transactions themselves with smart contracts, the result of their veri cation and execution,
are added to a special section of the xing transaction.

4.1.4 Execute Smart Contracts and Update Balances

The result of the execution of smart contracts is a change in account balances. Balances are
updated within a commit transaction. The result of the update, in the form of a new account
balance, is stored in the commit transaction and used as input for further transactions in VINE.

4.2 Storing Information About Smart Contracts in a Commit Transaction

All information regarding smart contracts is an integral part of the commit transaction. There
are two attributes for this:
• ExecutedSmcTx – information about executed smart contracts;
• Diff - differences in the state store that appeared during the execution of the smart
contract.
A detailed speci cation of these attributes is given in Appendix A, and is also schematically
presented in Figure 2.2.

5. Site Verification and Registry

Synchronization
Each node in the local copy of the registry recalculates the proportion of vertices that directly or
indirectly con rm a site that has not yet been added to the commit transaction. If this share
reaches 100%, the site is added to the pool of 100% veri ed sites.

18
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
 For all transactions included in the pool of 100% veri ed sites, based on the decisions made
by the full nodes, we determine their correctness.

5.1 Algorithm for Calculating the Share of Vertices that Directly or Indirectly
Con rm the Site
Input:
• own copy of the registry with a list of current vertices ;
• new vertex , added to the DAG;
• – particle throwing depth (adjustable parameter of the MCMC
• algorithm). In this algorithm measured from genesis, i.e., for example:
• at particles are thrown into the genesis site;
• at particles are thrown into the 1000th site after genesis.

Output:
• own copy of the registry indicating the share of vertices (each -th site), directly or
indirectly con rming the site;
• a pool of 100% con rmed vertices ready to be sliced.

Algorithm:
1. For each -th site in the DAG, create a list indexes (numbers) of vertices that
directly or indirectly con rmed the site. Each index from speci es the vertex
number from . The ratio of the number of elements to the number of
elements sets the desired parameter – the proportion of vertices that directly or
indirectly con rmed -th site:

List initialization , and relevant :

• – list of vertices referring to genesis;
• – list of indexes for the genesis site ( );
• – empty set (for all current vertices);
• (for the genesis site);
• (for the rst vertex sites referring to genesis).

All new items from the list are initialized to zero.

2. When adding each new vertex list of vertices updated:
• some vertices "closed" by links from , after which they are excluded from
the list ;
• new vertex added to the list .

19
fi
fi
fi
fi
fi
fi
fi
fi
 3. If (particles in MCMC are thrown up to -th site in DAG) or ( and ):
• update after every update update for all sites . To do this, we
consider only indexes that refer to These indexes are excluded from ,
replacing them with indexes referring to ;
• update .

4. If (particles in MCMC are thrown after -th site in DAG) and , Then
don't update anymore -th site is included in the pool of 100% con rmed vertices ready to
be sliced.

The algorithm is executed when adding each new vertex, Step 3 (the most costly) is performed
only for or ( and ).

5.2 Algorithm for Accepting a Commit Transaction

A commit transaction is generated at least once every 5 seconds. With a signi cant decrease
in the intensity of the receipt of transactions, up to their complete absence, the frequency of
formation of commit transactions should not change.
The algorithm consists of ve-time phases, as shown in Figure 5.1.
•

Figure 5.1
Commit phases
of a commit
transaction

t4 t0 t1 t2 t3 t4 t0

• t0 – formation of a "blank" of a commit transaction.

• t1 – formation of a local pool of 100% con rmed sites.
• t2 – exchange of information about commit sites.
• t3 – veri cation of smart contracts.
• t4 – exchange of prototypes of a commit transaction.

5.3 Synchronization
Synchronization is the process of updating information about the contents of the registry and
writing the updated information to the local copy of VINE.
For different tasks (in order to reduce the time of updating and reduce the volume of stored
data) synchronization of commit transactions can be performed – updating information only
about a chain of commit transactions.

20
fi
fi
fi
fi
fi
 5.3.1 Synchronization of Commit Transactions
Synchronization starts with the last known CT (commit transaction). After adding the last
CT to the local copy, the node can proceed in parallel to the synchronization and
subsequent work in the normal mode, without waiting for the end of the CT synchronization
process.
Commit transactions refer to each other, all queries and storage are in the same order. The
update is subject to a formal review.
Synchronization occurs starting from the last received CT in the direction of earlier CTs (as
needed).
The necessary synchronization ends when the required number of links to sites is reached,
which is necessary to enable the node to work.
If a node connects to the system for the rst time and does not have a local copy of VINE,
then the last CT included in the local copy is considered to be the genesis of the CT.
When connecting to the network, each node noti es the network of its latest CT version
and receives a copy of the current CT from the leader node acting as a validator. The last
CT is the current starting position for the new node. All other artifacts are requested from
the validator as needed.

5.3.2 Site Synchronization

The node synchronizes sites that are not yet included in the commit transaction, i.e. those
that have been generated since the last commit transaction and up to the current time if
needed (e.g. the new site refers to sites not yet included in any commit transaction).

5.3.3 Information Exchange (normal synchronization mode)

One of the modi cations of the Gossip algorithm, the HyParView (Hybrid Partial View)
protocol, is taken as the basis for distributing information between peers.
By constant exchange of information, we mean the exchange of all new objects (sites,
smart contract transactions and commit transactions).
To speed up the check and ght against spam objects, we can use a local database of
rejected objects. In this database, we will record the identi ers of objects that have not
passed formal veri cation. This base has a xed size and when it is lled with new objects,
older objects are removed from the base.

Information Synchronization Algorithm:

1. According to the HyParView protocol, we get an object.

Possible events; probabilities; actions:

• Object received; the probability is high; go to the next step of the algorithm (normal
mode);
• Object not received; the probability is extremely low; reinstalling the software,
communicating with the community, looking for a problem on our server;

21
fi
fi
fi
fi
fi
fi
fi
fi
 2. Check if the given object is in the local database of rejected objects. If the object is in
the database, then exit the algorithm.
3. Check if the given object exists in the local copy of VINE. If it is a network, then exit the
algorithm.
4. We carry out a formal check (for the site we do not check the condition whether the
veri ed sites exist in the registry). If the formal check fails, then we write the object
identi er to the local database of rejected objects and exit the algorithm.

4.1 Check whether veri ed sites exist in the local copy of VINE. If at least one
con rmed site does not exist, then we add the site to the database of orphan sites and
exit the algorithm.
4.2 Check whether orphan sites are linking to this site. If they are, then depending on
the information about the remaining con rmed sites of the referring site, we make an
appropriate note about it about the reduction of "orphan" links or perform step 4.2 and
then step 5.
5. We add the object to the local copy of VINE.
6. We leave the algorithm.

6. Scalability
Testing the DLT Grape functionality, which, with an increase in the number of generator
nodes, leads to a multiple increase in the number of generated transactions per unit of
time, each validator node connected to the network becomes a project scaling step.
Thus, when adding additional nodes to the network, we get a multiple increase in TPS
(transactions per second) due to an increase in the number of transactions processed and
included in VINE on the node.

22
fi
fi
fi
fi
fi
 In the future, in order to process all generated transactions by individual nodes,
synchronize their local registries, verify and validate, it is necessary to perform additional
computational operations, the volume of which increases rapidly over time (as the size of
the registry increases). To stabilize the high-performance of the network with a large
number of generator nodes and transactions generated by them, DLT Grape provides for
the formation of slices - an irrevocable part of the registry, consisting of 100% veri ed sites.
All sites and slices’ transactions are excluded from further veri cation as unconditionally
valid, which allows for stabilizing the computing load and achieving high-speed
characteristics as the registry grows.
Slicing and mechanisms for consensus acceptance of commit transactions by validators
are not implemented in Grape DLT, this is one of the most relevant areas for further
development of the project. Other areas for the development of Grape DLT are working on
optimizing site processing, including block processing of transactions, the introduction of
fast post-quantum cryptography algorithms, registry sharding, etc. These activities allow for
repeated increases in the performance of the network and successful reaching of the
target of 700,000 TPS which with more nodes will increase inde nitely.

23
fi
fi
fi
 Appendix A.
Commit Transaction Format

The commit transaction format is speci ed in vine-dev/p2p/tx/pb/txpin.proto and looks like

this:
// TxPin - pinning transaction de nition
message TxPin {
bytes prev = 1; // prev pin tx id
google.protobuf.Timestamp ts = 2; // timestamp when the tx was created
repeated SiteID sites = 3; // a collection of site ids (a list of fully con rmed sites in the
current slice)
repeated Node nodes = 4; // sites included in this pin tx
Balance balance = 5; // all balances for all the tx in the current pinning tx
bytes pk = 6; // public key to verify this pin tx signature
bytes sign = 7; // this pin tx signature
repeated ExecutedSmcTx smcTxs = 8; // executed smart contract transactions within
this pin tx
repeated Diff diffs = 9; // diffs on smart contract state store appeared after
executing smart contract transactions
}

message Balance {
map<string, bytes> balance = 1; // a map of wallet - balance (big.Int as []byte)
}

message LogTopic {
bytes hash = 1;
}
message TxExecLog {
bytes contractAddress = 1;
repeated LogTopic topics = 2;
bytes data = 3;
int64 pinTxNumber = 4;
}

24
fi
fi
fi
 message TxReceipt {
enum TxStatus {
SUCCESSFUL = 0;
FAILED = 1;
}
int32 fuelUsed = 1; // used fuel for execution
TxStatus status = 2; // tx failed or successful
string statusMessage = 3; // details about tx status
repeated TxExecLog logs = 4; // logs generated during tx execution
}

message AccountData {
bytes address = 1;
bytes balance = 3;
int64 nonce = 4;
bytes codehash = 5;
bytes code = 6;
}

message AccountDiff {
AccountData newValue = 1;
reserved 2 to 5;
}

message Mapping {
bytes address = 1;
bytes key = 2;
bytes value = 3;
}

message Diff {
oneof mappingOrAccount {
Mapping mappingDiff = 1;
AccountDiff accountDiff = 2;
}
}

message ExecutedSmcTx {
Txv1 tx = 1;
TxReceipt receipt = 3;
}

25
 Appendix B.
Site Format

The site format is speci ed in vine-dev/p2p/tx/pb/node.proto and looks like this:

message Node {
message NodeId {
bytes id = 1;
string address = 2;
uint64 idMajor = 3;
uint32 idMinor = 4;
}
message Height {
uint64 minheight = 1;
uint64 maxheight = 2;
}
NodeId id = 1;
oat cumWeight = 2;
oat txWeight = 3;
google.protobuf.Timestamp time = 4;
bool valid = 5;
Height height = 6;
Txv1 tx = 7;
map<string, bool> missingTargets = 8;
}

26
fl
fl
fi
 Figure B.1 Processing Smart Contracts and Generating a Commit Transaction
UML diagram of
sequences for
processing smart
contracts and
forming a commit
transaction

Send transfer TX

Light node Full node Full node Light node

Receive Transfer TX
Send SMC TX Resend SMC TX Resend transfer TX

Formal validation
Formal validation
Not valid
Select uncon rmed TX
Set using SMC policy

Not valid
Creating uncon rmed SMC TX
While set not empty

Look for random vertex

Save uncon rmed SMC TX
Execute SMC
to the local pool

Create new site Each SMC is

SMC result executed on the new
VM instance
Create
Sync TX P2P
Update the balance of
Check results for accounts that were
touched during the
Save site to the local DAG state con ict
contract execution;
Mark transfer TX in the
100% con rmed pool
Balances - Broadcast as 'Invalid’ for ‘touched’
Account based uncon rmed accounts.
state SMC TX Con rmed SMC TX with
execution status

Faid contracts Create

container P2P
Save to smart
Uncon rmed transaction
SMC TX pool Broadcast site

100% con rmed

sites list Uncon rmed TX record
While set not empty

Con rmed
SMC TX pool Base sync TX ID: Sync N

Original TX ID: SMC TX ID

Validator TX
Original signature: 64 byte 100% con rmed sites pool

SMC TX data: byte array

Result hash: 32 byte
Exec signature: 64 byte Uncon rmed SMC TX pool

Sync N Sync N+1 Sync N+2

Leader Leader

Incoming TX [ t0 ] [Time to generate sync TX] [ t1 ]

Con rmed TX pool

Create draft sync TX

Start appropriated formal (1.2.3.4.5.6)
validation routine
Con rmed TX record [ t2 ]
7

Modify draft sync TX,

Save received TX to resolve con icts (10.11)
Acceptor/Candidate Node ID appropriated local pool

Acceptor signature: 64 byte [ t3 ] Uncon rmed SMC TX pool

processing (12,1,12,2,12,3,12,4)
Uncon rmed TX data Iterate all SMC transactions and
Call smart TX execution modify the 100% Con rmed
Create
Sites Pool
P2P Status result

Call smart TX creation Balance TX creation

Broadcast TX Result: balance TX subroutine (13)

Call validator TX creation Validator TX creation

subroutine (13)
Result: validator TX

Create sync TX (14)

15
[ t4 ]

Choose the correct sync TX,

(Signed by the quorum 2/3 +1)
(17,18,19,20)

Save sync TX to the local store

Create
P2P

Broadcast sync TX
Sync N+1

27
fi
fi
fi
fi
fl
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fl
fi
fi
fi