<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Decentralized Electronic Voting System Based on Blockchain Technology Developing Principals</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Required:</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>V. N. Karazin Kharkiv National University</institution>
          ,
          <addr-line>4 Svobody Sq., Kharkiv, 61022</addr-line>
          ,
          <country country="UA">Ukraine</country>
        </aff>
      </contrib-group>
      <fpage>0000</fpage>
      <lpage>0002</lpage>
      <abstract>
        <p>Electronic trust services are becoming an integral part of the information space. With the reliable implementation of basic services as an electronic signature and electronic authentication, it is possible to build more complex systems that rely on them, particularly the electronic voting system. In the paper, the new concept for developing a decentralized electronic voting system using blockchain technology is proposed. The two-level architecture provides a secure voting process without redundancy of existing (not based on blockchain) systems. The presented blockchain-based voting protocol has six steps that ensure all requirements that are put forward to such types of protocols including voting transparency and anonymity.</p>
      </abstract>
      <kwd-group>
        <kwd>Decentralized Electronic Voting System</kwd>
        <kwd>Decentralized identification</kwd>
        <kwd>Electronic Voting Protocol</kwd>
        <kwd>Blockchain Technology</kwd>
      </kwd-group>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>-</title>
      <p>
        Electronic trust services are becoming an integral part of the information space. Their
use is governed by Regulation (EU) No 910/2014 of the European Parliament and of
the Council of 23 July 2014 on electronic identification and trust services for
electronic transactions in the internal market and repealing Directive 1999/93/EC [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ]
which establishes terms and conditions. With the reliable implementation of such
basic services as an electronic signature and electronic authentication, it is possible to
build more complex systems that rely on them, for example, an electronic voting
system.
      </p>
      <p>
        Remote (electronic) voting has many advantages. It is assumed that they are more
convenient for end-users because people can vote without leaving home; this
increases the activity of voters. Maintenance of electronic voting is cheaper: instead of
permanently printing ballots, it’s enough to develop a system once. In addition, the
assumption that no one can interfere with the program on the voting device implies
that electronic voting is less susceptible to corruption, administrative pressure, and
human factors. However, this raises a number of specific problems that hinder the
integrity of elections. Remotely, it is much more difficult to authorize a voter or make
sure that no one has influenced the voting process. On the other hand, the Internet
provides more opportunities for checking by ordinary voters whether the voice is
correctly taken into account. Currently, electronic voting is fully legal or partially
applicable in many countries of the world [
        <xref ref-type="bibr" rid="ref2">2</xref>
        ]. Since more and more people are
involved in them, the need for safer and more efficient methods for their
implementation is increasing, which is what special cryptographic protocols are designed for
[38].
      </p>
      <p>
        It should be noted that today the developing process of any system has to take into
account the evolution of quantum computers and as a result the growth of
computational speed. In the conditional of current cyber threats secure of the system should
not base only on key parameters cryptographical secure [
        <xref ref-type="bibr" rid="ref10 ref11 ref9">9-11</xref>
        ]. Important point is to
ensure the resilience of the system. From this point of view blockchain technology
might be useful.
      </p>
      <p>The main purpose of this paper is to formulate the development principles for a
decentralized e-voting system that would prevail over existing e-voting systems without
a decentralized structure.
2</p>
    </sec>
    <sec id="sec-2">
      <title>Electronic Voting System Principals Structure</title>
      <p>The system of electronic voting is a set of interrelated rules, methods, processes,
tools, and technologies, as well as legal norms that together provide and regulate the
remote legitimate voting of authorized users (voters).</p>
      <p>Components (subsystems / levels) of the electronic voting system (see Fig. 1):
legal level (laws and other regulatory documents);
organizational level (e-voting system architecture);
process level (processes for participants);
technological level (methods, tools, protocols, technologies).</p>
      <p>
        Desirable:
 no one except the voter should know his choice;
 only legitimate members can vote, and moreover only once;
 the decision of the voter cannot be secretly or explicitly changed by anyone
(except, perhaps, by himself). In addition, the desired requirements are set out [
        <xref ref-type="bibr" rid="ref12">12</xref>
        ]:
 each legitimate participant can check whether his voice is correctly counted;
 each legitimate participant may change his mind and change his choice within a
certain period of time;
 the system should be protected from the sale of votes by voters;
 in case the vote is incorrectly counted, each legitimate participant can report this to
the system without revealing his anonymity;
 it is impossible to track where the voter remotely voted from;
 operator authentication;
 you can find out who participated in the vote, and who - no;
 maintaining the system should not require a lot of resources;
 the system must be fault tolerant in case of technical malfunctions (loss of power
supply), unintended (loss of the key by the voter) and malicious (intentionally
disguising itself as another voter, DoS / DDoS) attacks.
      </p>
      <sec id="sec-2-1">
        <title>The major threats to systems of this type are:</title>
        <p> legitimate voter cannot vote;
 loss of voter anonymity;
 registration of non-existent voters;
 the use of blank ballots that registered but did not participate in the election.
3</p>
      </sec>
    </sec>
    <sec id="sec-3">
      <title>The architecture of the decentralized voting system</title>
      <p>The architecture of the decentralized e-voting system is two-level and consists of two
intersecting blockchain networks, the lower network is a decentralized electronic
identification infrastructure (DI eID), and the upper network is a decentralized
infrastructure for voting itself and counting the results (DI voting) (see Fig. 2).
3.1</p>
      <sec id="sec-3-1">
        <title>Decentralized Electronic Identification Infrastructure (DI eID)</title>
        <p>This infrastructure should provide a procedure for the reliable identification of users
and a list of legitimate voters’ establishment. It consists of providers of identification
services (hereinafter - IdP providers). It is necessary to ensure the implementation of
the identification using:
BankID;
MobileID;
e-passport of the citizen;
electronic signature (including both software and hardware implementation
(token))
According to the requirements, the following entries may act as identity providers:
Bank institutions;
Mobile operators;
Migration Service Centers (Administrative Service Centers - ASC);
Certification authorities of the national digital signature system.</p>
        <p>Provisions for the operation of providers are established by the Law of Ukraine
“On Electronic Trust Services”, implemented by the EU Regulation and other
international and national normative documents.</p>
        <p>Each identity provider has a pre-generated local database of its users, which
contains their identities and possibly local IDs. The responsibility for the secure storage
and correct use of local databases rests with identity providers.</p>
        <p>In order to organize the identification infrastructure within a decentralized
electronic voting system, the identity providers are combined into a separate private
permissioned blockchain network. In this network, each of the identity provider acts as a
validator node. It should be noted that complex and energy-intensive consensus
protocols are not required for such a network because the network connects trusted
("honest") nodes.
3.2</p>
      </sec>
      <sec id="sec-3-2">
        <title>Decentralized Infrastructure for Voting and Results Counting</title>
        <p>The infrastructure should provide for the process of the remote voting of registered
(authorized) legitimate voters and the process of results counting. In addition,
generation processes for voters’ wallets and candidates’ wallets should be organized in this
infrastructure. For the organization voting infrastructure under the decentralized
electronic voting system, the representative offices responsible for conducting the election
process (A1, A2, ..., An), like identification providers, are combined into a separate
private blockchain network, in which each of Ai acts as a validator node - collectively
they represent a decentralized Agency (A). Similar to the upper blockchain network,
the lower one also does not need to use complex and energy-intensive consensus
protocols because the network connects trusted ("honest") nodes. Validator nodes form
purses for legitimate voters and carry out voter authentication. They are also
responsible for the process of wallet generation for alternatives (candidates).
3.3</p>
      </sec>
      <sec id="sec-3-3">
        <title>Voting Protocol in a Decentralized Electronic Voting System</title>
        <p>The voting protocol in a decentralized electronic voting system consists of the
following steps:
1. Formation of the of legitimate voters’ list in a decentralized electronic
identification infrastructure;
2. Generation of legitimate voters' wallets in a decentralized infrastructure for remote
voting and results counting;
3. Candidates registration in a decentralized infrastructure for remote voting and
results counting;
4. Voters’ authentication in decentralized infrastructure for remote voting and results
counting;
5. Voting in a decentralized infrastructure for voting and results counting;
6. Counting of votes in a decentralized infrastructure for voting and results counting.</p>
        <p>The implementation of this protocol using blockchain technology allows
depending on the needs of the target system to change the order of some stages (basically the
fourth and fifth) without loss of reliability. The direct sequence (fourth to fifth)
implies that only authenticated users (legitimate voters) are allowed to vote. The reverse
sequence (fifth to fourth) allows participation in the voting process of potential
violators (illegitimate voters), but due to the peculiarities of the implementation of the
transaction consensus mechanism, and accordingly, the votes of illegitimate users will
not be taken into account. This is based on the assertion that in any blockchain
network, a transaction is considered validated only if both conditions are fulfilled:</p>
        <sec id="sec-3-3-1">
          <title>1. the format and signatures of the transaction are verified;</title>
          <p>2. validator nodes have reached consensus on including this transaction in the block
chain.</p>
          <p>The principles of building a decentralized infrastructure for remote voting and
counting results do not allow validation nodes to include a transaction from an
illegitimate voter in the blockchain since the first condition will not be fulfilled
(transaction signature will not be valid).</p>
        </sec>
      </sec>
      <sec id="sec-3-4">
        <title>Stage One (Formation of the of legitimate voters’ list in a decentralized electronic identification infrastructure).</title>
        <p>Forming lists of legitimate voters occurs in the lower blockchain network. Each
potential voter independently generates a key pair (SK; PK). Then he/she sents a
request to be included in the voters’ list to one of his/her available identity provider, in
which he/she provides his/her with his identification information and public key.</p>
        <p>The format of the request depends on the available communication channels
between the voter and the identity provider. It can be made remotely via the Internet
provided there is a reliable communication channel (see Fig. 3b), or such an
identification request can be made personally by a potential voter within the identity provider
controlled zone. If the request is made remotely, the responsibility for complying with
the key pair generation rules rests with the user. If the request is made personally
within the controlled zone, the identity provider is responsible for complying with the
conditions of the generation of the key pair of the user.</p>
        <p>If a potential voter already has generated key pair as required by one of the
identification providers, he or she may use it. In this case, the public key certificate must be
included in the request to the provider (see Fig. 3a).</p>
        <p>If a positional voter does not have a local ID in any of the identity provider
database, he or she must undergo a primary identification procedure with one of the
identity providers and only then be included in the list of legitimate voters (see Fig. 3c).
The initial identification procedure should be conducted in accordance with the rules
of a certain identity provider.</p>
        <p>Thus, when the time allotted for forming legitimate voters’ list has run out, an
anonymous (depersonalized) list of potential legitimate voters is created in the lower
blockchain, and the Agency receives a list of all registered legitimate voters, but
voters remain anonymous. The identification processes for different types of users are
shown on the figures 4a-4c.
where ID is the user ID in the following sequence: (series and passport number of the
citizen); and H is a cryptographic hash function</p>
        <p>The ID format must be the same for all identity providers. This condition makes it
impossible for voters to re-register with different identity provider.</p>
      </sec>
      <sec id="sec-3-5">
        <title>Stage Two (Generation of legitimate voters' wallets in a decentralized infrastructure for remote voting and results counting).</title>
        <p>The process of generating a voter wallet (see Fig. 5) is initiated by the validator
node of the upper blockchain network when it receives the public key from any of the
identity providers in the form of a transaction. The voter wallet's initial balance is 0.</p>
      </sec>
      <sec id="sec-3-6">
        <title>Stage Three (Candidates registration in a decentralized infrastructure for remote voting and results counting).</title>
        <p>Candidates are registered in the top blockchain network. Hereinafter, the Agency
will be understood to mean the totality of territorial polling stations combined into a
separate private permissioned blockchain.</p>
        <p>Responsibility for the candidates’ registration rests on the Agency (upper
blockchain validators) (see Fig. 6).</p>
        <p>Representatives of the Agency are responsible for conducting the initial
identification of the candidates and initiate a transaction for the inclusion of the candidate
which means the generation of the candidate wallet with zero starting balance (see
Fig. 7).</p>
      </sec>
      <sec id="sec-3-7">
        <title>Stage Four (Voters’ authentication in decentralized infrastructure for remote voting and results counting).</title>
        <p>A voter who has received confirmation from the identity provider for admission to
the voting process and wishes to participate in the voting will contact one of the
Agency's nodes for the authentication procedure (see Fig. 8). The user can only
authenticate with a private key (SK), provided that there is a corresponding public key
(PK) in the Agency's blockchain network.</p>
        <p>If the authentication process (see Fig. 9) was successful, the balance of the voter's
wallet is increased by 1 token.</p>
      </sec>
      <sec id="sec-3-8">
        <title>Stage Five (Voting in a decentralized infrastructure for voting and results counting).</title>
        <p>Voters who have undergone an authentication procedure will make a choice by
forwarding a token to one of the wallets which corresponds to the registered candidate
by forming a corresponding transaction, which they sign with their own private key
(see Fig. 10).</p>
      </sec>
      <sec id="sec-3-9">
        <title>Stage Six (Counting of votes in a decentralized infrastructure for voting and results counting).</title>
        <p>Vote counting is done automatically. The results will become available to everyone
after the voting time has elapsed.
In the face of cyber threats, the deployment of reliable electronic services systems
becomes an important task. The analysis showed that blockchain technology can be
useful for this purpose. Particularly, for developing electronic voting systems.
Classical systems do not meet all desired requirements for voting systems (for example, a
voter cannot check whether his voice is correctly taken into account and, if necessary,
inform the authorized bodies about this).</p>
        <p>In the paper, the new concept for developing a decentralized electronic voting
system using blockchain technology is proposed. The two-level architecture provides a
secure voting process without redundancy of existing (not based on blockchain)
systems. The presented blockchain-based voting protocol has six steps that ensure all
requirements that are put forward to such types of protocols including voting
transparency and anonymity. Proposed blockchain-based approach has several advantages:
central trust point absence, as a result there is no directed attack aim; reducing
material costs for each stage of voting (since there is no need to print ballots, deliver them
to polling stations).</p>
        <p>
          Moreover, it should be noted that blockchain technology is more convenient for
switching to post-quantum crypto primitives. Such an opportunity is also an important
advantage in conditions of rapid evolution of quantum computers. It can also be used
in other important applications [
          <xref ref-type="bibr" rid="ref13 ref14 ref15 ref16 ref17">13-17</xref>
          ].
        </p>
      </sec>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1.
          <string-name>
            <surname>Regulation</surname>
          </string-name>
          (EU)
          <article-title>No 910/2014 of the European Parliament and of the Council of 23 July 2014</article-title>
          . https://www.eid.as/Regulation
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>2. E-voting world map. https://www.e-voting.cc/en/it-elections/world-map/</mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          3.
          <string-name>
            <surname>Menezes</surname>
            , A.J., van Oorschot,
            <given-names>P.C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Vanstone</surname>
            ,
            <given-names>S.A.</given-names>
          </string-name>
          : Handbook of Applied Cryptography (
          <year>2018</year>
          ).
          <source>doi: 10.1201/9780429466335</source>
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          4.
          <string-name>
            <surname>Kuznetsov</surname>
            ,
            <given-names>O.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Potii</surname>
            ,
            <given-names>O.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Perepelitsyn</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ivanenko</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Poluyanenko</surname>
          </string-name>
          , N.:
          <article-title>Lightweight Stream Ciphers for Green IT Engineering</article-title>
          . In: Green IT Engineering: Social, Business and
          <string-name>
            <given-names>Industrial</given-names>
            <surname>Applications</surname>
          </string-name>
          . pp.
          <fpage>113</fpage>
          -
          <lpage>137</lpage>
          . Springer International Publishing (
          <year>2018</year>
          ). doi:
          <volume>10</volume>
          .1007/978-3-
          <fpage>030</fpage>
          -00253-
          <issue>4</issue>
          _
          <fpage>6</fpage>
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          5.
          <string-name>
            <surname>Gorbenko</surname>
          </string-name>
          , Yu.І.,
          <string-name>
            <surname>Isirova</surname>
            ,
            <given-names>K.V.</given-names>
          </string-name>
          :
          <article-title>Improved mechanism of one-time keys for post-quantum period based on the hashing functions</article-title>
          .
          <source>Telecommunications and Radio Engineering</source>
          . Volume
          <volume>77</volume>
          ,
          <source>Issue</source>
          <volume>14</volume>
          ,
          <fpage>1277</fpage>
          -
          <lpage>1296</lpage>
          (
          <year>2018</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          6.
          <string-name>
            <surname>Andrushkevych</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Gorbenko</surname>
            ,
            <given-names>Y.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kuznetsov</surname>
            ,
            <given-names>O.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Oliynykov</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Rodinko</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          :
          <string-name>
            <given-names>A Prospective</given-names>
            <surname>Lightweight</surname>
          </string-name>
          <article-title>Block Cipher for Green IT Engineering</article-title>
          . In: Green IT Engineering: Social, Business and
          <string-name>
            <given-names>Industrial</given-names>
            <surname>Applications</surname>
          </string-name>
          . pp.
          <fpage>95</fpage>
          -
          <lpage>112</lpage>
          . Springer International Publishing (
          <year>2018</year>
          ). doi:
          <volume>10</volume>
          .1007/978-3-
          <fpage>030</fpage>
          -00253-
          <issue>4</issue>
          _
          <fpage>5</fpage>
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          7.
          <string-name>
            <surname>Gorbenko</surname>
            ,
            <given-names>I.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kuznetsov</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Gorbenko</surname>
            ,
            <given-names>Y.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Vdovenko</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Tymchenko</surname>
            ,
            <given-names>V.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Lutsenko</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          :
          <article-title>Studies on Statistical Analysis and Performance Evaluation for Some Stream Ciphers</article-title>
          .
          <source>International Journal of Computing</source>
          .
          <volume>18</volume>
          (
          <issue>1</issue>
          ),
          <fpage>82</fpage>
          -
          <lpage>88</lpage>
          (
          <year>2019</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          8.
          <string-name>
            <surname>Bernstein</surname>
            ,
            <given-names>D.J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Buchmann</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Dahmen</surname>
          </string-name>
          , E. eds: Post-Quantum Cryptography. Springer Berlin Heidelberg (
          <year>2009</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          9.
          <string-name>
            <surname>Pass</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Seeman</surname>
            ,
            <given-names>L.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Shelat</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          :
          <article-title>Analysis of the blockchain protocol in asynchronous networks</article-title>
          .
          <source>Annual International Conference on the Theory and Applications of Cryptographic Techniques</source>
          .
          <fpage>643</fpage>
          -
          <lpage>673</lpage>
          (
          <year>2017</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          10.
          <string-name>
            <surname>Isirova</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Potii</surname>
            ,
            <given-names>O.</given-names>
          </string-name>
          :
          <article-title>Decentralized public key infrastructure development principles</article-title>
          .
          <source>In: 2018 IEEE 9th International Conference on Dependable Systems</source>
          ,
          <article-title>Services and Technologies (DESSERT)</article-title>
          .
          <source>IEEE</source>
          (
          <year>2018</year>
          ). doi:
          <volume>10</volume>
          .1109/dessert.
          <year>2018</year>
          .8409149
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          11.
          <string-name>
            <surname>Kovalchuk</surname>
            ,
            <given-names>L.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kaidalov</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Nastenko</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Rodinko</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Shevtsov</surname>
            ,
            <given-names>O.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Oliynykov</surname>
          </string-name>
          , R.:
          <article-title>Decreasing Security Threshold Against Double Spend Attack in Networks with Slow Synchronization</article-title>
          .
          <source>In: IEEE INFOCOM 2019 - IEEE Conference on Computer Communications Workshops (INFOCOM WKSHPS)</source>
          .
          <source>IEEE</source>
          (
          <year>2019</year>
          ). doi:
          <volume>10</volume>
          .1109/INFCOMW.
          <year>2019</year>
          .8845301
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          12.
          <string-name>
            <surname>Nurmi</surname>
            ,
            <given-names>H.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Salomaa</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          :
          <article-title>Conducting secret ballot elections in computer networks: Problems and solutions</article-title>
          .
          <source>Annals of Operations Research</source>
          .
          <volume>51</volume>
          ,
          <fpage>185</fpage>
          -
          <lpage>194</lpage>
          (
          <year>1994</year>
          ). doi:
          <volume>10</volume>
          .1007/bf02032763
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          13.
          <string-name>
            <surname>Bondarenko</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Liliya</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Oksana</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          , &amp;
          <string-name>
            <surname>Inna</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          :
          <article-title>Modelling instruments in risk management</article-title>
          .
          <source>International Journal of Civil Engineering and Technology</source>
          .
          <volume>10</volume>
          (
          <issue>1</issue>
          ),
          <fpage>1561</fpage>
          -
          <lpage>1568</lpage>
          (
          <year>2019</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>
          14.
          <string-name>
            <surname>Runovski</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Schmeisser</surname>
          </string-name>
          , H.:
          <article-title>On the convergence of fourier means and interpolation means</article-title>
          .
          <source>Journal of Computational Analysis and Applications</source>
          .
          <volume>6</volume>
          (
          <issue>3</issue>
          ),
          <fpage>211</fpage>
          -
          <lpage>227</lpage>
          (
          <year>2004</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          15.
          <string-name>
            <surname>Tkach</surname>
            ,
            <given-names>B.P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Urmancheva</surname>
            ,
            <given-names>L.B.</given-names>
          </string-name>
          :
          <article-title>Numerical-analytic method for finding solutions of systems with distributed parameters and integral condition</article-title>
          .
          <source>Nonlinear Oscillations</source>
          .
          <volume>12</volume>
          ,
          <fpage>113</fpage>
          -
          <lpage>122</lpage>
          (
          <year>2009</year>
          ).
          <source>doi:10.1007/s11072-009-0064-6</source>
        </mixed-citation>
      </ref>
      <ref id="ref16">
        <mixed-citation>
          16.
          <string-name>
            <surname>Chornei</surname>
            ,
            <given-names>R.K.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Daduna</surname>
            <given-names>V.M.</given-names>
          </string-name>
          ,
          <string-name>
            <given-names>H.</given-names>
            ,
            <surname>Knopov</surname>
          </string-name>
          ,
          <string-name>
            <surname>P.S.</surname>
          </string-name>
          :
          <article-title>Controlled Markov Fields with Finite State Space on Graphs</article-title>
          .
          <source>Stochastic Models</source>
          .
          <volume>21</volume>
          ,
          <fpage>847</fpage>
          -
          <lpage>874</lpage>
          (
          <year>2005</year>
          ).
          <source>doi:10.1080/15326340500294520</source>
        </mixed-citation>
      </ref>
      <ref id="ref17">
        <mixed-citation>
          17.
          <string-name>
            <surname>Kuznetsov</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Shekhanin</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kolhatin</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kovalchuk</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Babenko</surname>
            ,
            <given-names>V.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Perevozova</surname>
            ,
            <given-names>I.</given-names>
          </string-name>
          :
          <article-title>Performance of Hash Algorithms on GPUs for Use in Blockchain</article-title>
          .
          <source>In: 2019 IEEE International Conference on Advanced Trends in Information Theory (ATIT)</source>
          .
          <source>IEEE</source>
          (
          <year>2019</year>
          ).
          <source>doi: 10.1109/ATIT49449</source>
          .
          <year>2019</year>
          .9030442
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>