A Blockchain Approach to Support Digital Contracts
Victor H. Breder, Laurival S. C. Neto, Thiago F. Medeiros, Ivan M. Padalko, Guilherme S. Oliveira,
Vitor Venceslau Curtis and Juliana de Melo Bezerra
Department of Computer Science, ITA, Sao Jose dos Campos, Brazil
Keywords: Blockchain, Digital Contract, Digital Signature.
Abstract: Distributing computing that work with policies that flirt with democracy, in which parties can interact without
an intermediary, has gained strength. In this way, an attractive idea is to support digital contracts by removing
the third party and allowing the group to create and store contracts in a reliable and secure way, where
contracts are immutable and easily retrievable. We propose a Blockchain approach to aid the management of
digital contracts. The proposal considers contract encryption, digital signature, and protocols for chaining
blocks with data related to digital contracts. We develop a prototype to ensure the viability of our proposal.
We also present a case of use to demonstrate the prototype usage. We argue that proposal and implementation
together create an appropriate environment for research and education purposes.
1 INTRODUCTION
Although the technology continues to advance, in
recent years the computational capacity seems to been
reaching some barriers, such as the difficulty to
continuously scale down transistors and the problem
of energy efficiency (Borkar and Chien, 2011). Such
a scenario has found an alternative through
distribution and parallelization. Distributed systems
can be scaled up through the addition of more
machines, which brings a greater tolerance to failures
and allows resources’ sharing throughout the nodes of
the system. It’s not trivial to design and verify the
correctness of distributed algorithms. Fortunately,
groundbreaking and innovative results are emerging,
such as Google’s Spanner (Corbett et al., 2013) and
the revolutionary Bitcoin/Blockchain couple
(Nakamoto, 2017).
The need to scale up has required new ways of
thinking. Decentralized systems that work with
policies that flirt with democracy, in which parties
can interact without an intermediary, has gained
strength. For instance, P2P sharing technology (Ding
et al., 2004) and Blockchain technology (Miraz and
Ali, 2018). Blockchain, in principle, works as a form
of database. It assembles, in a specific order, blocks
that contains data. Furthermore, consensus
algorithms are be applied to create a distributed
version of Blockchain in a way that security is
guaranteed.
One interesting application of the distributed
Blockchain idea is digital contracts, which are digital
version of regular contracts (Cong and Zheng, 2017).
In regular contracts, a group of interested people
relies on a third party to validate a contract that verses
about rules regarding something valuable to the
group. After the approval of the involved ones about
the contract terms, they sign the document, validate
with the third party and store it. The idea of digital
contracts in a Blockchain is to remove the third party
and allow the group to create and store contracts in a
reliable and secure way, where contracts are
immutable and easily retrievable. Furthermore, it’s
even possible to create addendums to contracts stored
in the Blockchain.
Regarding the use of Blockchain technology
applied to contracts, literature explores the concept of
smart contracts. A smart contract is in fact an auto
enforceable code, running on top of a Blockchain,
with rules that dictate how parties interact with each
other. However, there is a lack of studies about
scalability, performance and security of presented
applications (Alharby and Moorsel, 2017).
Kalamsyah et al. (2018) work with the idea of digital
contracts, but they focus on the authentication process
of contracts between two parties and in the
importance of a witness process.
In this paper, we propose a Blockchain approach
to aid the management of digital contracts. The
proposal considers the contract encryption, the digital
446
Breder, V., Neto, L., Medeiros, T., Padalko, I., Oliveira, G., Curtis, V. and Bezerra, J.
A Blockchain Approach to Support Digital Contracts.
DOI: 10.5220/0007809804460453
In Proceedings of the 14th International Conference on Software Technologies (ICSOFT 2019), pages 446-453
ISBN: 978-989-758-379-7
Copyright
c
2019 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
signature of parties, the validation of digital
signatures, the storage of such information using
block chaining. It is possible to deal with distinct
contracts as well as with their possible addendums,
always in a distributed manner. While keeping
properties as integrity and authenticity of traditional
contracts, our approach based on Blockchain
eliminates the need of intermediaries and brings
security to the whole process. Section 2 describes our
proposal. Section 3 describes the evaluation of an
implemented prototype. Section 4 presents
conclusions and future work.
2 SUPPORTING DIGITAL
CONTRACTS
In our proposal, users can, after a consensus, create a
contract that is then inserted in the Blockchain. The
network consists of several nodes that are aware of all
the other nodes in the network, in other words, a
complete network. Each node represents an instance
capable of inserting blocks in the Blockchain. Each
user group that wishes to create a contract does so
through some node of the network. The proposal can
be summarized into three distinct parts: digital
contract creation and signing; Blockchain structure
and the network protocols.
2.1 Digital Contract Creation
and Signing
The digital contract is treated here as a pack of data.
It’s not necessarily needed to be stored in the
Blockchain, in fact it is stored somewhere else. Only
information that can be used to assert the contract is
the same for all parties is needed, in other words,
information that can assert the contract integrity.
Furthermore, the contract is sealed only after all
parties agree on its content with their respective
signatures.
Nowadays, an effective way of checking data
integrity is by using a hash function, a mathematical
function that maps the data in such a way that even
small changes to the original data causes a complete
different result from the hash function. Usually,
inverting the hash function isn’t possible and
collisions, when two different data contents are
mapped into the same value by the hash function, are
very rare, but can happen.
Figure 1: Signature generation scheme.
Figure 2: Signature verification scheme.
One of such functions is SHA-256, a hash
function that, given input data of arbitrary size,
produces a fixed 256 bit (or 32 bytes) word. Then,
using SHA-256 it’s possible for parties to check the
contract integrity. Once every party agrees upon the
contract, the hash of the document is used as a base
for the signatures. This process uses the typical RSA
authentication, where each party has a public key and
a private key.
The process to generate a signature of a contract
is depicted in Figure 1. Given the digital contract (for
instance a file named ‘contract.docx’), the SHA-256
function is used to generate a hash. The owner of a
A Blockchain Approach to Support Digital Contracts
447
private key then creates his signature of the hash by
the RSA algorithm.
Conversely, given a signature and the
correspondent public key, the signature can be
verified. The scheme is shown in Figure 2. If the
signature is authentic, operating with the public key
over data that has been encrypted with the
corresponding private key will decrypt and reveal the
original data. The original data should be the hash of
the contract that can be easily computed if the
contract is available. So, if the result is the hash, the
signature is valid.
2.2 Blockchain Structure
The Blockchain structure grows linearly as new
pieces (blocks) are added. There is only one entry
point for a new block. The addition of a block is made
in such a way that consistency of the structure can be
verified. The entire structure works as a register. The
Blockchain structure provides a simple way to store
data, but it’s potential and interesting features are only
apparent in the distributed form.
Figure 3: Block structure.
The block structure used in our approach is
presented in Figure 3. The components are: an index
that determines the position of the block in the chain;
the hash of the previous block (computed with SHA-
256 and using the block data); The timestamp; the
data length (number of bytes of data); and the data
itself. The data for our purposes consists only of a
signature. In other words, each signature of a contract
corresponds to a block in the Blockchain.
Figure 4: Blockchain formation scheme.
Regarding the chaining of blocks, the first block
is the ‘Genesis’ block, one that does not has the hash
of a previous block. After that, the chain can be built.
A block can only enter in the Blockchain if it has the
information about the hash of the last block added to
it. This property is useful when considering the
distributed case. Furthermore, the consistency of the
chain can be easily checked by starting from the last
ICSOFT 2019 - 14th International Conference on Software Technologies
448
added block and verifying if the hashes match block
to block until the ‘genesis’ block is reached.
A scheme of the Blockchain can be seen in Figure
4. Given a digital contract and its respective hash,
each party that signs the hash, creates a block in the
chain. It is important to remember that people can be
distributed, so blocks can be originated in distinct
nodes of the distributed system. The picture shows a
chain with N blocks in order; however they could be
in a different order given the distributed (and so out
of sequence) characteristic.
Following the idea of signature verification
shown in Figure 2, the verification process in
Blockchain presented in Figure 5. So, every signature
(inside a given block) can be verified using a public
key. A match in the result indicates that that person
(with the used public key) has signed the given
contract (using its hash in fact).
Figure 5: Signature verification in the Blockchain.
In case of contract addendums, the process is
similar, as presented in Figure 6. Parties need to sign
the hash of the addendum. New blocks are then
generated and added in the current chain. In the same
way, the Blockchain is up to register contracts and
addendums of distinct groups.
Figure 6: Contract addendums in the Blockchain.
2.3 Network Protocols
In our proposal, the system is a set of nodes in a
network. Blocks can be generated by different nodes.
Each node maintains a copy of the Blockchain. Here
we discuss how nodes enter in the system, how blocks
A Blockchain Approach to Support Digital Contracts
449
are propagated among nodes, and how to manage
eventual inconsistencies among chains in nodes.
Figure 7 shows a scheme for adding nodes in the
network. When a new node B desires to enter the
network, it must first establish a TCP connection with
any of the present nodes already in the network (in the
example, its node A). Node B sends a ‘PEER-
REQUEST’ with its ID and Address to node A. Node
A then acknowledge and store B’s presence on the
network (a local copy of existing nodes in the
network). After processing the request, node A
responds with ‘PEER-ACCEPTED’ and B can
register A’s presence (using its ID and ADDRESS) in
the network as well.
Figure 7: Protocol to add a new node in network.
The process of adding a new node continues until
all nodes recognize the presence of the new one. The
protocol is depicted in Figure 8. After the mutual
acknowledgment in Figure 7, B sends a ‘PEER-LIST’
message to A, asking for the addresses of other nodes
in the network. Node A, then, sends B sequentially
‘PEER-ADD’ messages. Each ‘PEER-ADD’
message has the address of a node of the network that
B must connect to, by doing the same ‘PEER-
REQUEST’ and ‘PEER-ACCEPTED’ iteration
(already described in Figure 7). By the end of the
process, the network remains a complete graph, in
other words, every node is connected to every other
node.
When a node (in the previous example, node B)
enters the network, it also requests from the first node
it connected (in the case, node A) a copy of the
Blockchain. This process is presented in Figure 9.
Node B sends ‘REQUEST-BLOCKCHAIN’ and A
replies with many ‘BLOCK-ADD’ messages. Node
A sends each block at a time on the same sequence it
is stored locally. After that, B will have a copy of A’s
local Blockchain.
Figure 8: Protocol to inform network about a new node.
Figure 9: Protocol to copy the Blockchain between nodes.
Other protocol responsible for distributing the
Blockchain is the broadcast of the addition of a new
block, as shown in Figure 10. After node A insert a
new block on its local Blockchain, it broadcasts the
added block to the rest of the network. In a receiver
node, if the new block fits as the next block (in other
words, when it has the correct hash for the last added
block on its local chain), then it is added at the end of
the local chain. If in any case it doesn’t fit the local
Blockchain of a node, the new blocked is discarded in
that particular node. Hence, it’s possible to have
inconsistencies on the consensus of the network about
the Blockchain while adding multiple blocks at the
same in different nodes and broadcasting it.
ICSOFT 2019 - 14th International Conference on Software Technologies
450
Figure 10: Protocol to broadcast a new block.
Lastly, to solve the pointed conflict of
inconsistency of the consensus of the network about
the Blockchain state, the nodes should follow a
specific protocol. When a node receives a block with
an index bigger than its own last inserted block, it
requests from the sender the Blockchain. Since the
Blockchain from the sender is longer, it gets
prioritized and overwrites the local Blockchain of the
requesting node. So, in the presence of a conflict, the
longest Blockchain gets prioritized and the smaller
chain is overwritten on the conflicting node.
This approach can lead to an exploit for malicious
attacks, like creating a fake long chain and forcing the
network to acknowledge it as the real Blockchain,
since it’s the longest. In fact, Bitcoin uses this
approach, but to maintain the security of network and
avoid this problem, it’s also implemented the so
called ‘Proof-of-Work’ or PoW (and there is a more
recent idea about a ‘Proof-of-Stake’ or PoS), where
the rate at which blocks are added to the chain is
controlled and limited by computational power in
such a way that trying to create a bigger chain in a
small time interval would require a prohibitive
amount of energy (Vashchuk and Shuwar, 2018). For
this paper purposes, this potential problem is left
unsolved for the sake of simplicity.
3 CASE OF USE
In a way to evaluate our proposal, we developed a
prototype from scratch. It was implemented in the Go
language and stored as an open-source project in a
GitHub repository (link: https://github.com/
impadalko/CES27Projeto). Here we describe a case
of use, presenting existing commands and the
demonstrating structures and protocols previously
described.
The application starts as a single node with the
‘Genesis’ block created, as shown in Figure 11. The
‘NodeId’ is a random string and ‘NodeAddr’ is the
address of node, so that other nodes can communicate
and connect to it. The application can also be started
with an address parameter. In this case, the node will
try to connect to a node with the given address. An
example is given in Figure 12, when the new attempts
to connect to a preexisting node (in the case, with
address 34369). The connection succeeds and it can
be seen that the ‘Genesis’ block data is copied.
Figure 11: First node instantiation.
Figure 12: Initializing a new node.
Figure 13: ‘peers’ command.
Figure 14: ‘conns’ command.
The ‘peers’ command (Figure 13) shows
addresses of peers connected to the current node. The
‘conns’ command (Figure 14) shows, in details, the
information of connections with current node. In
these examples, another node was added (not shown
./CES27Projeto
NodeId: WoQ57YZu
NodeAddr: [::]:34369
Index Hash PrevHash Timestamp Data
0 e3b0c442 00000000 1543547516
./CES27Projeto :34369
NodeId: W6GOogKr
NodeAddr: [::]:44713
Peer connected: WoQ57YZt
Block added:
Index Hash PrevHash Timestamp Data
0 e3b0c442 00000000 1543547516
peers
PeerId PeerAddr
62TtJ0rH [::]:38819
W6GOogKr [::]:44713
conns
RemoteAddr LocalAddr PeerId
PeerAddr
127.0.0.1:53042 127.0.0.1:34369 W6GOogKr
[::]:44713
127.0.0.1:53044 127.0.0.1:34369 62TtJ0rH
[::]:38819
A Blockchain Approach to Support Digital Contracts
451
in previous figures). Generating public and private
keys can be done with ‘genkey’ command followed
by user nickname. Keys are stored as ‘.pem’ files in a
local directory of the node. In this example, two pair
of keys are generated, one to Alice (Figure 15) and
other to Bob (similar to Figure 15).
Figure 15: ‘genkey’ command to Alice.
Figure 16: Alice enables her private key.
Figure 17: Alice creates the contract hash.
Figure 18: Alice signs the contract hash.
The process of signing a contract hash is
demonstrated below. In a given node, Alice uses
‘privkey’ command to enable its private key (Figure
16). Given a contract named ‘contract.dat’ stored
locally, Alice creates its hash (Figure 17) and signs it
(Figure 18). The signature is then stored as a block in
the local chain (named as ‘block 1’) and later
broadcasted to other nodes. In other node, Bob also
signs the contract hash (Figure 19), generating ‘block
2’ in Blockchain as well.
Figure 19: Bob signs the contract hash.
Figure 20: Blockchain in a node.
Figure 21: Alice enables her public key.
Figure 22: Alice verifies her signature.
Figure 23: Alice creates a block with data ‘1010’.
Figure 24: Bob creates a block with data ‘0101’.
Blockchain can be seen in Figure 20. In fact, it is
the chain stored in a given node, after adding Alice
and Bob signatures of the hash of ‘contract.dat’.
‘Data’ column shows the partial signature data.
Consider that Alice desires to verify its signature for
the given contract. Firstly, she indicates the use of her
public key (Figure 21). She then verify ‘block 1’
(created by her in Figure 18) against the contract hash
(Figure 17). As expected, there is a match and the
signature is authentic (Figure 22). In the same way,
Alice and Bob can verify signature from each other in
the Blockchain.
We demonstrate the process of tie breaking by
using the longest chain. Consider that Alice creates a
block with data ‘1010’ in a node. The block is stored
locally and not broadcasted (Figure 23). Similarly,
Bob creates a block with data ‘0101’ in a distinct node
genKey Alice
Generated private key Alice written to
Alice_priv.pem
Generated public key Alice written to
Alice_pub.pem
privKey Alice
Using private key: Alice
hash contract.dat
The SHA256 hash of the file given is:
e3b0c44298fc1c149af...
sign e3b0c44298fc1c149af…
The document with hash e3b0c442 was
signed with key Alice and added to the
blockchain in block 1
sign e3b0c44298fc1c149af…
The document with hash e3b0c442 was
signed with key Bob and added to the
blockchain in block 2
blocks
Index Hash PrevHash Timestamp Data
0 e3b0c442 00000000 1543547516
1 2f715cac e3b0c442 1543547787 bc27076c
2 1d9198e2 2f715cac 1543547832 d77b3c7b
pubKey Alice
Using public key: Alice
verify 1 e3b0c44298fc1c149af…
The signature is VALID
The document with hash e3b0c442 was
signed by Alice in the block 1
add 1010
Index Hash PrevHash Timestamp Data
0 e3b0c442 00000000 1543547516
1 2f715cac e3b0c442 1543547787 bc27076c
2 1d9198e2 2f715cac 1543547832 d77b3c7b
3 430c0c4e 1d9198e2 1543548033 1010
add 0101
Index Hash PrevHash Timestamp Data
0 e3b0c442 00000000 1543547516
1 2f715cac e3b0c442 1543547787 bc27076c
2 1d9198e2 2f715cac 1543547832 d77b3c7b
3 9dcf97a1 1d9198e2 1543548041 0101
ICSOFT 2019 - 14th International Conference on Software Technologies
452
(Figure 24). Both blocks are named as ‘block 3’ in the
local chains. When block with data ‘0101’ is
broadcasted to Alice’s node, it is ignored, since there
is already a block with pointing to ‘block 2’ (with data
‘1010’).
Figure 25: Alice creates a block with data ‘0110’.
Later Alice creates other block, now with data
‘0110’. It results in a bigger chain shown in Figure
25. Finally, broadcasting the longest chain causes the
overwritten of the other chain (with block ‘0101’).
Hence, the implemented application behaves as the
proposed idea of applying the distributed Blockchain
algorithm to digital contracts.
4 CONCLUSIONS
We proposed an approach to support the management
of digital contracts, motivated by the need to
guarantee contract integrity and signature
authenticity, and also to provide a trustable
environment without involving intermediaries as with
regular contracts. Our proposal is mainly based on
Blockchain technology, but also includes contract
hashing (using SHA-256 algorithm) and
authentication based on public and private keys
(using RSA algorithm).
The idea is that, after consensus about the contract
rules, every part emits a signature of the hash of the
digital contract. Each signature is inserted as a
different block in the chain. This process happens
inside a node of the network. When every party has
signed the contract, the new blocks are broadcasted to
the rest of the network. After some time, if the
Blockchain is not overwritten by some other block
addition, the agreement is done. If some signatures
cannot enter the Blockchain, the local chain is
updated and they are reinserted and broadcasted
again, until all signatures are part of the Blockchain.
We developed a prototype to ensure the viability
of our proposal. We also presented a case of use to
demonstrate the prototype usage. The current
examples can be easily generalized to any number of
nodes, parties, contracts, and addendums. Extensions
of our prototype are encouraged, in a way to facilitate
the proposal application, for instance by adding
facilities to communicate with processes across
different machines, and by establishing directives to
manage keys in a secure way.
Regarding the proposal itself, we intend to
investigate enhancements in the protocols, including
to deal with incomplete networks, and to add
consensus algorithms for new blocks in the chain. We
would like to study the proposal resilience to nodes’
failure and message losses. A web application to
access Blockchain data is also of interest to improve
the application usability. Both proposal and
implementation are then suitable to further
improvements, being an appropriate environment for
research and education purposes.
REFERENCES
Alharby, M., Moorsel, A. V., 2017. Blockchain-based
smart contracts: a systematic mapping study. Computer
Science & Information Technology (CS & IT), 7, 1-16.
Borkar, S., Chien, A., 2011. The future of microprocessors.
Communications of the ACM, 54 (5), 67.
Cong, L., Zheng, H., 2017. Blockchain Disruption and
Smart Contracts. SSRN Electronic Journal.
Corbett, J. C., et al., 2013. Spanner: Google’s globally
distributed database. ACM Transactions on Computer
Systems (TOCS). 31 (3), No. 8.
Ding, H., Nutanong, S., Buyya, R., 2004. Peer-to-Peer
Networks for Content Sharing. Technical Report,
GRIDS-TR-2003-7, Grid Computing and Distributed
Systems Laboratory. University of Melbourne,
Australia.
Kalamsyah, S. A., Barmawi, A. M., Arzaki, M., 2018.
Digital Contract Using Block Chaining and Elliptic
Curve Based Digital Signature. 6th International
Conference on Information and Communication
Technology (ICoICT).
Miraz, M., Ali, M., 2018. Applications of Blockchain
Technology beyond Cryptocurrency. Emerging
Technologies in Computing (AETiC), 2 (1).
Nakamoto, N., 2017. Centralised Bitcoin: A Secure and
High Performance Electronic Cash System. SSRN
Electronic Journal.
Vashchuk, O., Shuwar, R., 2018. Pros and cons of
consensus algorithm proof of stake. Difference in the
network safety in proof of work and proof of stake.
Electronics and Information Technologies, 9.
add 0110
Index Hash PrevHash Timestamp Data
0 e3b0c442 00000000 1543547516
1 2f715cac e3b0c442 1543547787 bc27076c
2 1d9198e2 2f715cac 1543547832 d77b3c7b
3 430c0c4e 1d9198e2 1543548033 1010
4 af340aa5 430c0c4e 1543548097 0110
A Blockchain Approach to Support Digital Contracts
453