The current issue and full text archive of this journal is available on Emerald Insight at:

https://www.emerald.com/insight/0960-0035.htm

IJPDLM
51,2 Risk identification and modeling
for blockchain-enabled
container shipping
126 Son Nguyen
National Centre for Ports and Shipping,
Received 31 January 2020
Revised 21 April 2020
Australian Maritime College, University of Tasmania, Launceston, Australia and
16 June 2020 Department of Maritime Transportation Economics, Vietnam Maritime University,
22 July 2020
23 July 2020
Haiphong, Vietnam, and
Accepted 9 August 2020 Peggy Shu-Ling Chen and Yuquan Du
National Centre for Ports and Shipping,
Australian Maritime College, University of Tasmania, Launceston, Australia

Abstract
Purpose – Although being considered for adoption by stakeholders in container shipping, application of
blockchain is hindered by different factors. This paper investigates the potential operational risks of
blockchain-integrated container shipping systems as one of such barriers.
Design/methodology/approach – Literature review is employed as the method of risk identification.
Scientific articles, special institutional reports and publications of blockchain solution providers were included
in an inclusive qualitative analysis. A directed acyclic graph (DAG) was constructed and analyzed based on
network topological metrics.
Findings – Twenty-eight potential risks and 47 connections were identified in three groups of initiative,
transitional and sequel. The DAG analysis results reflect a relatively well-connected network of identified
hazardous events (HEs), suggesting the pervasiveness of information risks and various multiple-event
risk scenarios. The criticality of the connected systems’ security and information accuracy are also
indicated.
Originality/value – This paper indicates the changes of container shipping operational risk in the process of
blockchain integration by using updated data. It creates awareness of the emerging risks, provides their
insights and establishes the basis for further research.
Keywords Container shipping, Blockchain, Operational risk, Risk identification, Directed acyclic graph,
Network analysis
Paper type Research paper

International Journal of Physical
Distribution & Logistics
Management
Vol. 51 No. 2, 2021
pp. 126-148
© Emerald Publishing Limited
0960-0035
DOI 10.1108/IJPDLM-01-2020-0036
1. Introduction
Maintaining the performance of container shipping systems is an essential topic of research.
Container shipping operational risks (CSORs) such as cyberattacks, cargo accidents and
payment disputes profoundly affect different flows of container shipping systems as well as
the whole supply chain (Nguyen and Wang, 2018; Ivanov and Dolgui, 2020). Among them,
information risks are gaining momentum along with the process of digitalization and
automation, which is observable in reality through the tragic events in the container shipping
industry (Ivanov et al., 2019; Nguyen et al., 2019; Dolgui et al., 2020; Nguyen, 2020). Hazardous
events (HEs) in the information flow of container shipping not only directly impact the
The authors are grateful to the editors of this special issue and three anonymous reviewers for their
valuable comments and suggestions for the early versions of this manuscript. This study is funded by
the Tasmania Graduate Research Scholarship, iMOVE CRC and supported by the Cooperative Research
Centres program, an Australian Government initiative.
system’s performance, but can also trigger other HEs, causing accumulative consequences. Blockchain
The possibility of multiple-event scenarios makes CSOR analyses much more complicated risks in
and uncertain.
Blockchain is mentioned by both academics and industrial professionals as a promising
container
solution for multiple existing CSORs (Christidis and Devetsikiotis, 2016; Ivanov et al., 2020). shipping
Startups, prototypes and initial commercialization of blockchain solutions are observable in
the field of container shipping, such as the smart Bill of Lading (B/L) solutions or platforms
for information sharing and collaboration. However, many industry stakeholders are still 127
keeping a skeptical view toward the operability of blockchain-enabled container shipping
systems (Christidis and Devetsikiotis, 2016; Savvides, 2018). Due to the technology’s
currently limited adoption, historical data of HEs are scarce, which creates a vicious circle of
less understanding about risks → limited technology in action → lack of empirical data.
This paper aims to lay the groundwork for operational risk management of blockchain-
enabled container shipping systems. Giving the scarce of data on this topic, a literature
review was conducted to identify risks based on a comprehensive database of journal articles,
special institutional and industrial reports. The causal relationships between CSORs are
mapped using directional connections (Figure 1). Ultimately, a directed acyclic graph (DAG)
risk model was derived, followed by a network analysis to reveal its topological features.

2. Blockchain and its application in container shipping

2.1 Blockchain technology
According to the Commonwealth Scientific and Industrial Research Organization (CSIRO) –
Australia, and the National Institute of Standards and Technology (NIST) – United States,
blockchain technology can be understood as the combination of mechanisms and
technologies to support the checking, execution and recording of information between
parties that involves two primary concepts: blockchain and distributed ledger (Staples et al.,
2017; Yaga et al., 2018). Data (e.g. transactions, shipments’ information) are agreed on and
then cryptographically signed by related parties before being organized into groups (blocks).
These blocks are cryptographically linked together to form chain of blocks, called the ledger.
Copies of the ledger are distributed across nodes of the network and exponentially increase
the effort needed to change the “truth” protected by the blockchain network’s tampering
resistance (Figure 2). Based on the differences in setting and operation, there are two main
types of blockchain networks: permissionless and permissioned.

Figure 1.
Conceptual single and
multiple-event risk
scenarios
IJPDLM 2.2 Application of permissionless blockchain
51,2 Permissionless blockchains, typically public blockchains, are freely available for any entity to
join and, therefore, have access to view and broadcast changes to the ledger (Yaga et al., 2018).
This type of blockchain has been implemented to deploy cryptocurrencies, e.g. Bitcoin,
Ethereum, usually considered as blockchain 1.0 (Li et al., 2020). The level of information
security provided by blockchain also allows the deployment of smart contracts, which is
considered as the second generation of blockchain application – blockchain 2.0. In smart
128 contracts, terms and logics of a traditional contract are expressed in codes using a
programming language following the if-then premises and will be automatically executed
upon receiving a specific predefined input (Dolgui et al., 2019). An example of permissionless
blockchain in container shipping is CargoX’s “smart B/L”, where the transfers of a digitalized
B/L are recorded into the ledger of Ethereum, a public blockchain (CargoX, 2018). The digital
B/L is digitally created, signed and transferred between parties following the same pattern as
traditional B/Ls. The ledger records each transfer as a transaction. Parties involved in the
transportation of the shipment interact directly with Ethereum using the Application
Programming Interface (API) or the application, both developed and maintained by CargoX
(Figure 3).

2.3 Application of permissioned blockchain

Permissioned blockchains, typically private or consortium blockchains, only open to
trusted and identifiable parties recognized by an authority, allowing the differentiation
between types of nodes as well as their responsibility and accessibility. In the container
shipping context, malicious acts of parties are, therefore, easier to be automatically

Figure 2.
Illustration of a
blockchain

Figure 3.
Operation of CargoX
smart B/L™
detected and punished, thus increasing the stake of the acts and lowering their motivation. Blockchain
Consortium-based blockchain is being considered by multiple industries as the most likely risks in
type of blockchain to be deployed in the business world, e.g. the financial and
transportation sectors (English et al., 2018; Hyperledger, 2019). A good example is
container
TradeLens – a collaboration between Maersk and IBM that provides a solution to creating shipping
a comprehensive flow of information among the parties involving in the logistics processes
of a container/shipment (Tradelens, 2019). TradeLens uses Hyperledger Fabric as its
blockchain platform (Figure 4). In this solution, the identity of nodes is recognized by their 129
X.509 digital certificates, allowing concurrent participation and permission setting in
different channels. Each channel has a Blockchain Document Store of all documents of the
shipment/container. Smart contracts are employed in Hyperledger Fabric, so-called
chaincodes, to digitally execute and enforce the agreed business models. The ordering
service nodes receive the proposals of updating the ledger from participants (e.g. the
container arrived at the port of destination, unloaded to container yard) with proper
endorsements, validates and then orders them into blocks that will be communicated back
to all nodes.

3. Methodology
Operational risks with blockchain-based systems and causal relationships among them were
identified based on reviewing the current blockchain literature. Two separate content
analyses were conducted to build a DAG model of single-event risk scenarios as a set of nodes
ðV Þ, and the causal relationships between them, as a set of edges (E), which was then used in
realizing multiple-event risk scenarios and calculating topological metrics. Figure 5
illustrates the methodology of this study presenting the process and methods used for risk
identification and analysis.

3.1 Primary data gathering and preprocessing

Literature review has been used by scholars as a method for the identification of CSORs
(Nguyen and Wang, 2018; Chang et al., 2015). This study looks into (1) The literature of
blockchain technical research; (2) The reports from blockchain adopters, solution providers

Figure 4.
Simplified operation of
TradeLens based on
Hyperledger Fabric
IJPDLM
51,2

130

Figure 5.
Methodology of risk
identification and
analysis
and specialized institutions; and (3) Observed incidents of blockchain applications and Blockchain
CSORs, to identify the potential HEs that may occur with blockchain integrated systems. risks in
The keywords “risk” AND “blockchain” were used for search in titles, abstracts and
keywords of conference papers and journal articles in English. The search returned a total
container
of 247 papers from Web of Science and 391 from Scopus. The database was aggregated to shipping
491 papers after discarding duplicated items. After a qualitative check of relevance to
exclude papers that do not align with the purpose of blockchain risk identification (e.g.
blockchain utilization to address risks), the final set of 52 papers was obtained in full texts 131
for content analyses. While risks related to the operation of blockchain-enabled systems are
identified in these papers, the actual application of solution providers in the field of
container shipping still needs to be reviewed (e.g. the underlying operations of the
Hyperledger Fabric platform) to provide reliable technical understandings and evidence in
supporting the existence of risks as well as the causal relationships. Other materials,
including technical explanation papers, industrial reports, special institutional reports and
documentation of the solution providers, are continuously identified and collected before
and during the content analyses (see Section 3.2). Multiple credible sources have been
included, i.e. websites of CargoX, Hyperledger Fabric; Microsoft; IBM Research; National
Institute of Standards and Technology, U.S. Department of Commerce; Department of
Industry, Science, Energy and Resources, and CSIRO of Australia; EU Blockchain
Observatory and Forum; and Lloyd List.

3.2 Identification of risks and causal relationships

Risk identification and risk network model building are conducted in three steps
(Figure 5). In the first step, risks were identified individually and inclusively from the
collected literature in the form of HEs and their potential consequences through scanning
the whole set of materials. A potential HE or a causal relationship that is impossible in a
system may be possible in others. The consistency across literature, therefore, was not as
prioritized as comprehensiveness and coverability, which is recommended by risk
studies for risk identification (Chang et al., 2015; Nguyen, 2020). The causal relationships
between single-event risks were identified when the HE of a risk can be triggered by the
HE of another risk as a consequence (e.g. cyberattacks on the Information and
Communications Technology (ICT) system of a company can cause unwanted exposure
of identity and business activities). Two processes α and β of content analysis were
carried out separately by the authors to ensure the intersubjectivity and reproducibility
of the results. The similar risk descriptions from them will be accepted directly in the
final result.
In the next step, the disagreements were resolved by the process of collective decisions
by the authors to decide the final risk list with the combined literature identified in α and
β, including additional materials collected in each process. The set of identified causal
relationships could then be remapped into the final risk list. The result of this step is a
network structure of jV j nodes and jEj directed connections, presentable in a Risk
Structure Matrix (RSM) (Figure 6). As the directionality of the connections is embedded in
the causal relationships, and the result of remapping showed no cycles in the structure of
the network, the final result can be considered as a DAG model. Risks can then be
categorized into three groups based on their position in the DAG model. Risks in Group 1
– initiative risks have no prior risks (no parent nodes in the DAG); risks in Group 3 –
sequel risks have no posterior risks (no child nodes in the DAG); and risks in Group 2 –
transitional risks have both prior and posterior risks. This labeling technique reflects the
pervasive effect of HEs from Group 1 to other HEs in Groups 2 and 3 in multiple-event
risk scenarios.
IJPDLM
51,2

132
Figure 6.
Illustration of risk
connections modeling
and causal
relationships
examination

Finally, an examination of relationships between risks was then conducted for each
instance of “alternative pathways” to accept or remove edges in the model using the
principle proposed by Fang et al. (2012). An example is illustrated in Figure 6, where R4
causes R5, R7 and R8, R5 causes R7 and R8. If R4 can trigger R7 and R8 without going
through R5 then the edges from R4 to R7 and R8 are necessary. Otherwise, they can be
removed.

3.3 Network analysis based on the established DAG model

Network analyses were conducted to gain insights into its structure, realizing multiple-event
risk scenarios. The DAG derived from risk identification can be denoted as H ¼ ðV ; EÞ with
V ¼ ðV1 ; V2 ; V3 Þ are the sets of nodes (risks) in Groups 1, 2, 3, respectively, and E is the set of
edges (direct causal relationships). Re is the set of all pathways in the network from one node
to another. The number of nodes, edges and pathways are denoted as jVi j; i ¼ 1; 2; 3, jEj,
and jRej, respectively.
3.3.1 Multiple-event scenarios realization. Different sub-networks consisting of nodes
and edges that connect to individual nodes are derived. Besides realizing multiple-event
risk scenarios, this analysis suggests event-tree diagrams for risks in Group 1, bow-tie
diagrams for risks in Group 2 and fault-tree diagrams for risks in Group 3, which are
crucial in risk mitigation and prevention planning. A bow-tie diagram can be
understood as containing an event of analysis ðAÞ; a fault tree contains potential
events that can lead to A; and an event tree contains potential consequent events that
can be triggered by A.
3.3.2 Topological metrics. In this study, 10 metrics were calculated for the derived network,
which is a DAG with unweighted edges.
(1) Network density ðρÞ and conditioned network density ðρs Þ of the whole network: These
metrics reflect the extent to which the connectivity in the network is saturated. They
report the overall connectivity (causal relationships) between risks in the model (Fang
et al., 2012). The general denominator of ρ is jV j 3 ðjV j − 1Þ (Eqn 1). In this study, ρs
is added using the adjusted denominator of ðjV1 j þ jV2 jÞ 3 ðjV2 j þ jV3 jÞ − jV2 j
since nodes in V1 and V3 do not have edges to nodes in the same set (Eqn 2). This setup
allows ρs to fluctuate in the range of ð0; 1, making the interpretation more
straightforward. A higher density suggests that HEs are more connected, thus the
higher potential of pervasiveness in case of a HE in Group 1 or Group 2.
 jEj Blockchain
ρ¼ (1)
jV j 3 ðjV jÞ1 risks in
jEj container
ρs ¼ (2) shipping
ðjV1 j þ jV2 jÞ 3 ðjV2 j þ jV3 jÞ  jV2 j

(1) Reachability ratio ðqÞ of the whole network: Unlike ðjEjÞ, which only counts direct 133
edges between nodes, jRej counts all possible pathways between all pairs of nodes.
The ratio of q ¼ jRej : jEj reflects the average number of pathways for each direct
connection, which is a measure of network complexity. A higher reachability ratio
suggests that there are more pathways to trigger one HE from another, thus the
higher overall difficulty of addressing multiple-event risk scenarios.
(2) In, out and total degree ðvI ; vO ; vÞ of each node: They measure the connected prior,
posterior and total immediately connected nodes of each node, respectively. vI reflects
the number of prior risks, which also is the number of immediately adjacent HEs that
might trigger the HE of that risk. Similarly, vO is the number of adjacent HEs that an
HE might cause. Total degree measures the local connectivity of each node and
v ¼ vI þ vO. vI can be calculated by the sum of each row, vO by the sum of each
column in the RSM as the example in Figure 6. Higher local connectivity suggests
more potential involvement of an HE in two- or three-event risk scenarios, where an
HE of a risk can immediately cause or be triggered by other HEs.
(3) In, out and total reachability – number of reachable nodes ðSI ; SO ; SÞ of each node:
These metrics are similar to vI ; vO ; v but instead of using the set of E, they use the
set of Re to take into consideration all the possible pathways, which can go through
other nodes. They measure the number of connected prior, posterior and total HEs
that cause or be triggered by a HE. Total reachability expressed as S ¼ SI þ SO
measures the global connectivity of individual risks in the model. Higher global
connectivity suggests more potential involvement of an HE in multiple-event risk
scenarios, where an HE of a risk can eventually cause or be triggered by other HEs.
(4) Betweenness centrality ðσ Þ of each node and each edge: This metric measures the
times that a node or an edge lies between the causal path from an event to another
event across all scenarios. Betweenness centrality can be calculated by counting the
appearance of nodes and edges in the set of Re. A higher σ suggests higher importance
of a risk or a causal relationship in addressing multiple-event risk scenarios.

4. Operational risks of blockchain-enabled systems

4.1 Identification of single-event risk scenarios
Denoting the set of risks identified processes α and β as Vα and Vβ, this study recognized the
numbers of single-event risks are jVα j ¼ 26; jVβ j ¼ 29 with 25 similar risk descriptions
between two processes jVα ∩ Vβ j ¼ 25. After the deliberative process, a final list of 28 risks is
established. It is notable that each risk can be considered as a set of potential HEs that share
the same description (e.g. characteristics, underlying causing factors). Therefore, multiple
risks can be grouped into a generalized risk. A risk can also be segregated to multiple risks by
supplementing additional information to be more specific (e.g. different vectors of blockchain
cyberattacks). The set of risks presented in this section is an inclusive list that can be
generally used for specific systems but needs careful consideration regarding the subjected
system’s setting before confirming the identified risks are applicable.
IJPDLM 4.1.1 Group 1 – initiative risks. There are five potential risks in Group 1. Most of the risks in
51,2 this group are from the internal, technical aspects of blockchain and external factors (e.g.
cyberattacks).
(1) Instabilities of the support platform (cloud computing) – 1_SuIn: Unlike public
blockchains, which is designed to decentralize the information management systems,
the business sector (e.g. financial institutions) seems to lean toward permissioned
134 blockchain because of its advantages in maintaining the privacy and facilitate trust
(English et al., 2018; Ivanov et al., 2020). Blockchain-as-a-Service (BaaS) is now being
provided by most of the cloud computing service providers (e.g. Amazon Web
Services, Google Cloud, Microsoft Azure) to support the deployment of private and
consortium blockchain solutions, in particular for node hosting and administration.
This point of centralization was indicated by Hebert and Di Cerbo (2019) as a possible
source of instabilities in blockchain operation such as lowering blockchain
throughput.
(2) Cyberattacks on the blockchain – 1_CyBC: This risk covers cyberattacks that aim at
the components of the blockchain (e.g. ledger, nodes, smart contracts, ordering
service, cryptographic algorithm). There are various attacking techniques mentioned
in the literature. For example, man-in-the-middle attacks aim to intercept and alter the
communication between nodes (so-called hijacked) to provide false information to
these nodes (English et al., 2018). The victim might receive a confirmation of
transaction when, in fact, it did not happen or already refunded. Ekparinya et al.
(2018) indicated the possibility of this attack in public, consortium and private
blockchains.
(3) Cyberattack on the local ICT systems – 1_CyLo: This risk contains cyberattacks that
aim at the connected local ICT systems of the parties on the blockchain (e.g. port,
shipping company). The ransomware attack on Maersk in 2017 is an example of how
impactful a cyberattack can be to container shipping operations (Greenberg, 2018).
Regarding blockchain-enabled systems, inaccurate information and data can be input
into blockchain from the neutralized system, causing further consequences. For
example, Denial of Service (DoS) might target the ICT infrastructure of one or
multiple members, the cloud service where the blockchain is deployed on or the
blockchain itself (Yaga et al., 2018).
(4) Smart contract erroneous understanding – 1_SCUn: If container shipping operations
are automated by smart contracts, there is a risk of mismatched understanding of the
smart contract between different parties (e.g. shipping company, shipper, consignee);
or the intended terms and conditions behind the contract are mispresented in the
transformation to a smart contract (Viriyasitavat et al., 2019). If the misunderstandings
cannot be detected and resolved before execution, the correctness of the physical
transportation or the execution of the payment processes can be affected. For example,
an if-then command in the smart contract cannot be executed to trigger the payment
process; or the payment command is executed, but the actual transport demand might
have not been satisfied.
(5) Fraudulence and exploitation of smart contract – 1_SCFr: This risk contains
fraudulent programming of smart contracts or exploitation of smart contract’s
weaknesses (e.g. logic expressions, unnoticed errors, unpatched bugs) to conduct
fraudulent acts (Iqbal and Matulevicius, 2019). Similar to that of traditional contracts,
these malicious acts can be conducted by both the party who prepares and offers the
smart contract (e.g. shipping service providers, platform providers, smart contract
 providers), and the parties agree to use it (e.g. shipping service providers, shipping Blockchain
service users). This risk was indicated in both permissionless (e.g. Ethereum) (Harris, risks in
2019) and permissioned blockchains (e.g. Hyperledger Fabric) (Yamashita et al., 2019).
This risk is also amplified by the absence of a clear legal framework to protect the
container
benefits of technology adopters (Simpson, 2018). For example, how technical shipping
exploitation of a smart contract should be considered, given that involved parties
agreed to use such a contract. In the market of container shipping, the current lack of
smart contract standardization and reliable templates in comparison to those of 135
traditional contracts are favorable conditions for this risk to emerge.
4.1.2 Group 2 – transitional risks. There are 14 risks in Group 2. HEs of risks in Group 2 can be
triggered by HEs from Group 1 or Group 2. There are also several HEs of traditional
information CSORs (e.g. cargo misdeclaration) that cannot be entirely eliminated by applying
blockchain solutions.
(1) Stolen identity (private key or digital certificate) – 2_StID: In permissionless
blockchains, the private key is the identification of an entity in the network that
connects with currency or asset possession and also works as a signing (endorsing)
instrument (Yaga et al., 2018). In permissioned blockchains such as Hyperledger
Fabric, an identity certificate is used to identify network members (Hyperledger,
2019). Key leaking and digital certificate infrastructure being attacked or exploited
to gain unauthorized access are mentioned widely in the literature (see, e.g. Kar et al.
(2019)). This risk will lead to various consequences for container shipping, such as
unwanted transactions and incorrect release of shipments/containers.
(2) Oracle being compromised – 2_OrCp: As the blockchain is connected with the real
world in the case of container shipping, operations of the blockchain rely on the flow
of information into it. Oracles are the set of infrastructures that provides these
inputs. With smart contracts, this risk is even more critical, as the inputs will directly
affect its behaviors (Yamashita et al., 2019). Sensors may be cyberattacked and have
technical issues, human operations might not be reliable and other scenarios of
failure (English et al., 2018).
(3) Smart contract errors in execution or non-realizations – 2_SCEr: Smart contract
misunderstandings or intentional fraudulent acts can lead to errors in executions (i.e.
being inexecutable or unexpected behaviors) of smart contracts (Yamashita et al.,
2019; Harris, 2019). This is the digitalized version of the traditional risk “unrealized
contract” in container shipping (Chang et al., 2015).
(4) Non-deterministic transactions – 2_NDTr: With permissioned blockchains such as
Hyperledger Fabric, the process of writing (committing) data into the ledger is
Execute → Order → Validate (Androulaki et al., 2018). It means that the actions (e.g.
transaction, movement) will be executed first, and then the records of these actions
will be ordered by the ordering service (see Section 2). The state of the object (e.g.
current position, balance) will then be calculated, validated and committed into the
ledger (Hyperledger, 2019). While prioritizing the finalization of the ledger, it also
creates the risk of mismatches between the states of the ledger in case of multiple
close operations (Atzei et al., 2017; Yamashita et al., 2019; Zhang et al., 2019). This
problem might result in a discrepancy between the information provided by the
ledger and the real-world situation.
(5) Unauthorized or unwanted transactions/orders – 2_UATr: Unexpected transactions
or orders being executed based on information retrieved from the ledger, or by the
IJPDLM auto-execution of the smart contract. This event can be triggered after the attackers
51,2 gained access to the blockchain network, erroneous data reported by the ledger or
errors of the smart contract per se (Xu et al., 2019; English et al., 2018).
(6) Unwanted exposure of identity and business activities – 2_UEID: Through
cyberattacks on the blockchain or connected systems, the identity and business
activities of the network members can be exposed. Points of data collection and
136 centralization (e.g. registration of services, the ledger) are the targets for these
attacks (English et al., 2018; Kar et al., 2019). This leakage of information can be
critical with container shipping service providers as beside business privacy,
leaking the applied freight rate policies or other critical operating information can
lead to severe reputational impacts, decrease of transport quantity, or problems with
the company’s compliance with information managing regulations (e.g. General
Data Protection Regulation).
(7) Unexpected forks of blockchain – 2_FoBC: Forking can be understood as the
divergence of different parts of the network following different versions of the
ledger, or the consensus protocols being applied, i.e. different versions of “truth”. It
is considered as usual for a transaction in Ethereum and Bitcoin as “reliably
confirmed” after several blocks, as the network scale creates latency, and the fork
might go on for several blocks before the whole network agree on a decisive version
of the ledger (Yaga et al., 2018; Christidis and Devetsikiotis, 2016). Incidents related
to blockchain forks are observed in permissionless blockchains (e.g. unintentional
Bitcoin forks). With permissioned blockchains, the non-deterministic transaction or
instabilities of the support platform can cause the difference between the versions
of the ledger at different members (Atzei et al., 2017; Yamashita et al., 2019; Zhang
et al., 2019).
(8) Business information asymmetry – 2_BIAs: This risk is a traditional CSOR, as
indicated by Chang et al. (2015), where one party has more or better information than
the other parties. This situation can be caused by leakage of critical information and
might cause disadvantages in negotiation as well as the potential decrease in
transportation quantity.
(9) Lowered blockchain throughput performance – 2_LwBC: This risk refers to the
scenarios in which the speed of the blockchain-enabled systems is lowered or cannot
match the demand of the container shipping information flow (Christidis and
Devetsikiotis, 2016). With permissionless blockchains, its performance in validating
and recording transactions has always been a concerned issue, in comparison with
other well-known, centralized systems such as Visa or Mastercard (BIS, 2018).
Permissioned blockchains such as Hyperledger Fabric are designed to ensure a
satisfactory performance (Androulaki et al., 2018). However, multiple factors and
HEs can still affect the solutions’ performance (e.g. smart contract errors,
cyberattacks, support platforms’ instabilities) (Zhang et al., 2019).
(10) Erroneous data reporting – 2_DaEr: This HE is the mismatches between the ledger
and the reality outside the blockchain, and between the ledger and the
communicated information to the users and connected systems. The errors can be
related to the content (e.g. cargo content, notify party, consignee) of the data or the
order of the recorded events in the ledger (Zhang et al., 2019; Kar et al., 2019).
Considering container shipping, this HE can trigger other HEs with or without the
presence of a smart contract, ranging from failures of transactions or shipment
rerouting to loss of shipment or payment.
 (11) Disputes related to smart contracts – 2_SCDp: This potential HE refers to the Blockchain
possible legal actions of involved parties of a smart contract that may interfere with risks in
or reverse the outcomes of smart contracts. The lack of a legal framework to support
and protect the adopters of smart contracts (Simpson, 2018) and the unstandardized
container
practice of using it in the container freight industry (Savvides, 2018) make it shipping
reasonable to put this as a risk that evolved from the traditional CSOR of contract
disputes (Tseng et al., 2013). The inflexibility of smart contracts in some applications
can also cause disputes regarding the outcomes of contract execution (Hald and 137
Kinra, 2019).
(12) Delays in smart contract execution or transaction – 2_DyET: This HE can be
triggered by different events. For example, the smart contract needs to be updated
with a new patch to mitigate a newly revealed bug, or to update the terms and
conditions to fit the new conditions of the transaction, or shipping processes (Zhang,
2019; Dolgui et al., 2019; Hald and Kinra, 2019). Another causing factor is the lowered
or inadequate ledger updating speed (i.e. blockchain throughput performance).
As the container shipping operations are mostly sequential, postponements in
updating the status of the ledger can delay the execution of the smart contract,
which relies on the continuous inputs to function.
(13) Incorrect cargo transfer or transaction between parties – 2_IcTr: This risk is
deduced and generalized from the risk of incorrect cargo release (Tseng et al., 2013).
The HE refers to wrong or deceitful communications and transfers/transactions of
payment/shipment/container between different parties involved. This HE can be
triggered by the erroneous data reported by the ledger, or unauthorized transaction/
transfer commands.
(14) Cargo misdeclaration – 2_CgMs: This risk, as indicated by Nguyen et al. (2019), is
posing a significant possibility of causing accidents originating from cargoes inside
containers. Multiple tragic fires and explosions due to failure in detecting hazardous
cargoes and applying needed safety protocols are observable (e.g. Tianjin port,
Maersk Honam). Although this risk can be reduced if blockchain is applied to
authenticate the origin and content of the shipment, the potential of erroneous data
reporting makes it still a possibility.
4.1.3 Group 3 – sequel risks. There are nine risks in Group 3, which are directly triggerable by
HEs in Group 2. The HEs of these risks mostly belong to either physical or payment CSORs.
(1) Delays of contract negotiation and agreement – 3_DyNA: Misunderstandings,
examining, revising and auditing smart contracts can be time- and effort-consuming
considering the current level of blockchain development, the generally high value-at-
risk of the shipment and the lack of standardized smart contracts (Rivas et al., 2018).
This risk indicates a demand for a new skillset for container shipping service
providers in understanding smart contracts as the intersection of law, regulation,
business and computer programming.
(2) Failures of transactions/payments – 3_TrFa: This risk has been long considered a
CSOR (Nguyen et al., 2019). Even with the application of blockchain and smart
contracts, the operations of payment and transaction can still experience failures or
difficulties in case of smart contract execution errors or disputes (Giancaspro, 2017).
This risk is affected by the degree of smart contract integration, the smart contract in
particular cases and the payment method (e.g. payment by cryptocurrency or using a
standard method with the involvement of banks).
IJPDLM (3) Cargo rerouting – 3_CgRr: This is a well-known risk in container shipping (Gurning
51,2 et al., 2011). Although the transparency of the information and data exchange
between parties enabled by blockchains can prevent this risk, the possibility of
erroneous data reporting still keeps this risk on the CSOR map.
(4) Loss of shipment/payment – 3_LoSP: With the automation of the transportation
process and its increasing reliance on the information flow, it is possible from the
138 technical aspect that these catastrophic events might happen (Christidis and
Devetsikiotis, 2016). Some factors can cause the loss of payment or shipment, such as
fraudulent smart contracts and smart contract errors. In reality, tragic financial
losses through smart contract exploitations are observable (Staples et al., 2017),
justifying the existence of this risk.
(5) Cyber ransom – 3_CyRs: Business entities are attractive targets for cyber ransoms.
The NotPetya attack on Maersk is a significant example of how the operability of a
container shipping service provider can be targeted as the hostage for ransom acts
(Global Maritime Issues Monitor, 2018; Greenberg, 2018). The attackers apparently
can conduct further ransom attacks or threats toward blockchain members after they
gained control over the data, the shipment, payment and even critical point of control
such as the ordering service of Hyperledger Fabric or local databases.
(6) Cargo degradation – cargo quality protection failed – 3_CgDg: Unexpected
degradation or related losses of the shipment due to failures of cargo condition
monitoring or cargo misdeclaration (Nguyen et al., 2019; Chang et al., 2015). This is a
risk typically attached with perishable, special (e.g. chemicals) or hazardous cargoes
as they require a higher level of monitoring, posing a significant level of potential
losses. It is still a justifiable risk, even though the likelihood can be reduced by
blockchain implementation due to the potential of failures inside and outside the
blockchain network, such as misdeclarations, delays or hardware failures (e.g.
sensors).
(7) Unexpected decrease in transport quantity – 3_QaDe: This CSOR was identified by
Chang et al. (2015) and can be triggered by the situation of information asymmetry as
the competitors might have better information to make their decisions in freight
offering.
(8) Detainments and other legal liabilities related to cargo content – 3_DmLi: Chang et al.
(2015) and many events, in reality, indicated that the content of cargo, when being
hidden or misdeclared could cause ship detainments, delays of voyages, port
skipping and other legal liabilities to ocean carriers or freight forwarders.
(9) Cargoes accidents – 3_CgAc: HEs related to cargoes inside containers are various.
Apart from well-known accident types such as fires and explosions, other phenomena
are also possible to happen, such as cargo liquefaction, leakage and corrosion (Tseng
et al., 2013; Nguyen and Wang, 2018).

4.2 Directed acyclic graph of risks and multiple-event scenarios realization

After the remapping of identified causal relationships onto the established risk list, the
examination of causal relationships was carried out. For example, the edge from 1_CyLo –
Cyberattack on the local ICT systems to 2_UATr – Unauthorized or unwanted transactions/
orders was omitted as there is no other causal vector from 1_CyLo to 2_UATr than going
through 2_OrCp and 2_StID were identified from the literature. On the other hand, the link
from 1_CyBC – Cyberattacks on the blockchain to 2_LwBC – Lowered blockchain throughput
performance was kept as there are techniques of attack that can cause the exhaustion of Blockchain
blockchain network’s resources (e.g. bandwidth, processing capability) such as Denial of risks in
service, rather than going through 2_FoBC (Atzei et al., 2017; Iqbal and Matulevicius, 2019).
The final DAG model of risk connections was derived with 28 nodes and 47 edges
container
ðjV j ¼ 28; jEj ¼ 47Þ, as in Figure 7. shipping
From the derived DAG, event-tree diagrams for risks in Group 1, fault-tree diagrams for
risks in Group 3 and bow-tie diagrams for risks in Group 2 can be separated, presenting the
potential prior and posterior HEs of each risk. For example, the bow-tie diagram of 2_UATr is 139
presented in Figure 8a. The diagram indicates potential vectors of triggering events such as
local systems of blockchain members being attacked (1_CyLo). The attackers, after gaining
unauthorized access into the system, can steal or neutralize the usefulness of identity
evidences – 2_StID (i.e. private key or digital certificate); or falsify data provided by the
member to the blockchain (oracle problems) – 2_OrCP (Yaga et al., 2018; Hebert and Di Cerbo,
2019). 2_UATr can then trigger other HEs including disputes related to the unwanted
transactions (2_SCDp), incorrect release of container and shipments (2_IcTr) or ransom
acts (3_CyRs).
The potential consequences of 1_CyLo are demonstrated in its event-tree diagram
(Figure 8b) with the reachability to 19/28 (68%) of all identified risks. Not only does it have the
potential to expose and manipulate the data stream from members of the network, causing
potential mismatches between the ledger and the real world, but it also can affect the
blockchain performance through delaying information submission or refusing the
endorsement of transactions (Conti et al., 2018). This result indicates the limits of
blockchain-enabled information systems in only providing protection of truthfulness
inside the boundary of the blockchain network. Meanwhile, cybersecurity of all members in a
blockchain has to be taken into account in the safety and reliability of the whole network
(English et al., 2018; Global Maritime Issues Monitor, 2018).
Figure 8c illustrates the fault tree of failures of transactions or payments (3_TrFa). The
fault tree suggests the potential failures of automated transactions if it is to be implemented
as a feature of blockchain solutions and smart contracts (or “chaincode” as called by
Hyperledger Fabric). The fact that multiple vectors can trigger this HE through smart

Figure 7.
The DAG of connected
risk derived after
relationship
examination
IJPDLM
51,2

140

Figure 8.
The bow-tie diagram of
2_UATr (a), event tree
of 1_CyLo (b) and fault
tree of 3_TrFa (c)
contracts’ HEs partly explains why this feature is yet considered by solution providers in Blockchain
container shipping and logistics as a focused function of their products. risks in
4.3 Topological metrics analysis
container
To calculate the network metrics in Section 3.3.2, a series of functions were built and run in shipping
MATLAB, version R2018a. The RSM from a spreadsheet (.xlsx) was imported as the initial
data (the set of E) for a directed graph object. The core of our calculation is a recursive
function that can find and list all possible pathways from any node to another, which was 141
applied to build the complete set of Re. By obtaining E and Re, all 10 metrics can be calculated
using counting arguments and basic mathematical operations.
Using Eqn 1, the derived DAG has ρ ¼ 0:0622, which reflects a relatively high density of
the risk network in comparison with the risk model of Fang et al. (2012). This result confirms
the connected character of operational risks in blockchain-enabled container shipping
systems, which has not been investigated by previous CSOR studies. This number, in reality,
can be even higher, considering the fact that there might be more causal relationships that
have not been identified due to the limitation of the literature in respect of blockchain
operational risks. This potential is measured by the conditioned network density ρs ¼ 0:1111
using Eqn 2, meaning that the network density is at 11.11% of the saturated network. A ratio
of q ¼ 7 pathways per direct connection reports a high level of reachability from one risk to
another, suggesting that HEs are more likely to be triggered through indirect pathways of
multiple other HEs instead of being directly triggered. These outcomes confirm the
assessment of Eling and Lehmann (2017) that information and cyber risks pose a higher level
of pervasiveness than other fields, obstructing the efforts of the insurance industry to cover
more aspects of their consequence. In the CSOR context, this high level of connectivity
between potential HEs suggests the gaining importance of risks in the information flow if
blockchain is applied, agreeing with the remark of Nguyen et al. (2019) that information
CSORs needs more attention regarding their potential of triggering other HEs in all flows of
container shipping.
The results of the degree and reachability of nodes are presented in Figure 9. For example,
the vI ; vO and v of 2_UATr are 5, 3 and 8, respectively, which can also be counted in Figure 8a.
The average in and out values across groups of risks are presented in both Figures 9a and 9b.
Regarding the local connectivity ðvÞ, transitional risks (Group 2) have more connections to
both initiative and sequel risks (Groups 1 and 3), exhibiting a higher overall level of local
connectivity than other groups with an average total degree of 2:43 þ 2:5 ¼ 4:93 (Figure 9a).
Additionally, the average out-degree of Group 2 (2.5) is higher than that of Group 1 (2.4), and
its average in-degree (2.43) is also higher than Group 3 (1.44). The higher local connectivity of
transitional HEs suggests the criticality and uncertainty of risks in Group 2, as the multiple-
event risk scenarios that involved them can be much more difficult to circumscribe. This
finding emphasizes the need for mitigation and prevention barriers from Group 1 to Group 2
and between layers of Group 2 to limit the potential of multiple-event scenarios.
The global connectivity is expressed in the number of reachable nodes (SO ; SI and S)
(Figure 9b). The average out-reachability of Group 1 (17.2) is the highest, followed by the
average total-reachability of Group 2 (13.85), and the average in-reachability of Group 3
(10.44). These results show that an HE from Group 1 can trigger a higher number of other HEs
than Group 2. Similarly, HEs in Group 3 can be triggered in more scenarios in comparison
with those in Group 2. This finding suggests a spectral characteristic of risks from Group 1 to
Group 3, especially in a relatively well-connected network as in this case. Group 1 contains
risks with many out-reachable nodes, thus might have a lower likelihood, but higher,
accumulated and more uncertain consequences from pervasive multiple-event risk scenarios.
Meanwhile, risks in Group 3 are likely to have higher aggregated probability as they can be
triggered by other HEs, but lower, disjointed consequence. The result also predicts a higher
IJPDLM
51,2

142

Figure 9.
The degree and
number of reachable
nodes in the DAG
level of epistemic uncertainty with risk analyses, especially the consequence level of risks Blockchain
from Group 1, and the likelihood of risks from Group 3 as these tasks are more complicated risks in
with more potential scenarios.
Among risks of Group 1, 1_CyBC is the most connected risk with the highest degree and
container
second-highest reachability. Cyberattacks directly aiming at the blockchain components shipping
threaten not only the productivity of the blockchain but also the accuracy and privacy of the
data it protects. Although proved feasible from the technical aspect, the resistance of
permissioned and even permissionless blockchain solutions against different techniques of 143
attack is still unclear at the moment, not to mention whether or not the disruptions will be
significant toward the container shipping systems. For example, 1_CyBC can cause 2_LwBC,
which is also a high-degree risk, but this scenario can be insignificant considering the well-
known tolerance of the industry with different types of delays, which can take up to days or
weeks (Nguyen et al., 2019). 1_CyBC can be followed by 2_DaEr, another highly connected
risk. Erroneous data reporting defeats the very purpose of blockchain in protecting the
accuracy of data and might cause cumulative damages, depending on the level of integration,
automation and the contents being affected (e.g. merely data sharing and monitoring, using
data for automated tasks or fully integrated with smart contracts). 2_SCEr can cause various
types of consequences. This risk is depicted by the analysis result with the highest local
connectivity (8) and the second-highest global connectivity (19). This finding is in line with
the studies of Rivas et al. (2018), Hebert and Di Cerbo (2019) and Yamashita et al. (2019), who
suggested that the integration of smart contracts requires more developments and security
insurance to be viable, especially from the technical and legal aspects. The high value-at-risk
of the container freight industry can make this concept even more difficult to be adopted.
The top ten risks and causal relationships with the highest value of betweenness
centrality ðσ Þ are highlighted in Figure 10, showing that the most central edges connect the
most central nodes. The ðσ Þ value of these nodes and edges is also presented, indicating the
times that they are included in the causal path between nodes (i.e. multiple-event risk
scenarios). Being the most likely HE in multiple-event risk scenarios, 80% (4/5) causal
relationships from 2_DaEr are included in the top ten lists. This result, again, emphasizes the
dominant criticality of information inaccuracy with container shipping systems, in
comparison with information delay (e.g. 2_DyET and 3_DyNA) and information leakage

Figure 10.
Top ten risks and
causal relationships
based on betweenness
centrality
IJPDLM (e.g. 2_UEID and 2_BIAs). The current unattractive status of smart contract application in
51,2 the business sector is observable in 2_SCEr, 2_NDTr, 2_UATr. Meanwhile, inputs received
from oracles outside of the blockchain protective boundary (2_OrCP) are vulnerable to
traditional threats such as sensor errors, being manipulated or even incorrect human inputs.
In the container freight industry, such HEs in the information flow are well-known and
observable in automated terminals, reefers or smart containers (Staples et al., 2017; Nguyen,
2020). Another prominent risk perceived from the DAG is the forks of blockchain (2_FoBC).
144 This risk can cause not only erroneous data reporting and the discrepancies between the
ledgers of blockchain members but also disputes in the operation of smart contracts.
The performance of the blockchain solutions (2_LwBC), affected by multiple factors,
including the high volume of transactions, cyberattacks, contract errors and disputes when
the network scales up, is a significant concern from the users’ perspective (Savvides, 2018).
For example, a conjecturable scenario is that the public blockchain in use is operating under a
certain level of centralization. A major mining pool then continuously refuses to validate
transactions of B/L from specific addresses unless the victims pay an amount of fee (Conti
et al., 2018). For permissioned blockchains, the cloud-service platform can provide an extra
layer of configuration and security (English et al., 2018), but its own stability and performance
is another impacting factor of blockchain solutions (Hebert and Di Cerbo, 2019). Cargo
misdeclaration (2_CgMs) and incorrect cargo transfer or transaction (2_IcTr) seem to be the
most common gateways for HEs from the information flow to other flows of container
shipping. These risks are repeatedly indicated by CSOR studies as posing high-risk level in
physical and payment flows, from shipment rerouting, degradation, detainments and
additional liabilities to as catastrophic as fires and explosions (Chang et al., 2015; Nguyen
et al., 2019; Nguyen, 2020). This analysis shows that they might continue to be notable risks
even with the adoption of blockchain solutions.

5. Conclusion
The potential of blockchain technology adoption in strengthening security and improving
efficiency in container shipping operations is not an illusion. The ability of the technology is
not only proven through the bloom and survival of cryptocurrencies but also the emergence
of multiple blockchain solutions in the container freight industry that are now being
implemented (e.g. Hyperledger Fabric, CargoX, TradeLens, RoadLaunch). Understanding the
changing situation of operational risks in the current transitional phase of the industry not
only is useful to a sustainable and manageable technology application but also can provide
insights into the possible barriers of adoption. This study aims to fill this gap of the current
literature by providing necessities for risk analysis, including risk concept, operations
explanations, risk identification and analysis of risk causal relationships. Overall, several
factors are nurturing the formation of risks including unestablished legal frameworks,
increasing potential of cyberattacks, dependence and fixation on legacy systems and
operational issues such as system flexibility, throughput performance and low
interoperability.
The contribution of this paper is threefold. Firstly, this study indicates operational risks as
a barrier to technology application. Both the potential HEs, their consequences and the
epistemic uncertainty attached to these risks hinder the blockchain’s industrial adoption. On
the other hand, the current overall infrastructure of the container shipping’s information flow
is fragmented and traditionally slow in catching up with modern ICT solutions, making it
more difficult for solutions providers to develop their products. Additionally, early adopters
have to stake in choosing between different solutions, which are, at the moment, still having
their framework of standardization in building. Considering these factors in container
shipping, this study suggests significant improvements in information management,
including standardization, technological and human resource developments and potential Blockchain
realization to reduce risks and uncertainties, if blockchain is to be extensively applied. risks in
Secondly, by reviewing blockchain and CSOR literature, this study identified 28 single-
event risks and categorized them into three groups. Risk identification is well-supported by
container
an updated knowledge on blockchain, its applications in container shipping and observed shipping
HEs across multiple fields. To the literature of container shipping and supply chain risk
management, this study opens a new realm of research regarding the potential operational
disruptions of blockchain-enabled solutions by the identification, explanation and analysis of 145
new CSORs which is an important area that needs more attention from the research
community.
Thirdly, 47 potential triggering connections between individual risks were also indicated,
constructing a DAG model of multiple connected HEs at different levels of operation. The
usefulness of the DAG is illustrated through a topological analysis, providing insights into its
structure, revealing notable risks and triggering connections. Not only can it help realize
multiple-event risk scenarios and the pervasiveness of information risks, but it also can be
further developed and supplemented with quantified data to deeper analyze the identified
risk scenarios. To the knowledge of the authors, the causal relationships between multiple
CSORs have not been addressed in previous studies and this study addresses this gap. To the
application of blockchain in container shipping, the finding of these connections suggests a
different situation of CSOR than the previous studies depicted, featuring a spectrum of higher
and more uncertain consequence for initiative risks (Group 1), higher and more uncertain
likelihood for sequel risks (Group 3) and multiple intermediate states of transitional risks
(Group 2). The pervasiveness of CSORs in the information flow, especially information
inaccuracy, is emphasized with multiple-event scenarios where their consequences pervade
to physical and financial flows.
The current research has several limitations. Firstly, although scientific literature is a
reliable source of information, using it exclusively in analyzing risk has drawbacks. The
latency between the blockchain solutions in their continuous development and their versions
in literature can be significant. For example, a risk, or a security weakness can be quickly
solved by patches and setting changes of blockchain networks, making it difficult for
literature-based risk analysis to catch up and reflect state-of-the-art risk situations. This
characteristic calls for clarification of risk context (e.g. solution, configuration, boundary) in
the future, more in-depth risk analysis studies. Secondly, the general scope of this study in its
current version barred it from gathering fundamental data needed for more meaningful
assessment of risk scenarios. Future studies can supplement inputs such as the strength of
risk connection (e.g. probability of occurrence and concurrence), and specific risk
assessments regarding parameters to deeper investigate operational risks of blockchain-
enabled container shipping systems using more powerful analyses. Thirdly, while the DAG
network derived is directed and acyclic, the actual incidents can still happen that may involve
series of multiple-event risk scenarios (e.g. a cyberattack to steal identity followed by a
fraudulent smart contract). Therefore, modeling them with suitable probabilistic tools such
as Dynamic Bayesian Network or Markov chain is a research direction that is worthy of
attention.

References
Androulaki, E., Barger, A., Bortnikov, V., Cachin, C., Christidis, K., Caro, A.D., Enyeart, D., Ferris, C.,
Laventman, G., Manevich, Y., Muralidharan, S., Murthy, C., Nguyen, B., Sethi, M., Singh, G.,
Smith, K., Sorniotti, A., Stathakopoulou, C., Vukoli, M., Cocco, S.W. and Yellick, J. (2018),
“Hyperledger fabric: a distributed operating system for permissioned blockchains”, Proceedings
of the Thirteenth EuroSys Conference, ACM, Porto.
IJPDLM Atzei, N., Bartoletti, M. and Cimoli, T. (2017), “A survey of attacks on Ethereum smart contracts
(SoK)”, in Maffei, M. and Ryan, M. (Eds), Principles of Security and Trust, Springer Berlin
51,2 Heidelberg, Berlin, Heidelberg, pp. 164-186.
BIS (2018), Cryptocurrencies: Looking beyond the Hype, Bank for International Settlements, Basel.
CargoX (2018), CargoX: Business Overview and Technology Bluepaper, [Online]. CargoX, available at: https://
cargox.io/CargoX-Business-Overview-Technology-Bluepaper.pdf (accessed 20 August 2019).
146 Chang, C.H., Xu, J.J. and Song, D.P. (2015), “Risk analysis for container shipping: from a logistics
perspective”, International Journal of Logistics Management, Vol. 26 No. 1, pp. 147-171, doi: 10.
1108/Ijlm-07-2012-0068.
Christidis, K. and Devetsikiotis, M. (2016), “Blockchains and smart contracts for the internet of
things”, Ieee Access, Vol. 4, pp. 2292-2303, doi: 10.1109/Access.2016.2566339.
Conti, M., Kumar, E.S., Lal, C. and Ruj, S. (2018), “A survey on security and privacy issues of Bitcoin”,
Ieee Communications Surveys and Tutorials, Vol. 20 No. 4, pp. 3416-3452, doi: 10.1109/Comst.
2018.2842460.
Dolgui, A., Ivanov, D., Potryasaev, S., Sokolov, B., Ivanova, M. and Werner, F. (2019), “Blockchain-
oriented dynamic modelling of smart contract design and execution in the supply chain”,
International Journal of Production Research, Vol. 58 No. 7, pp. 2184-2199, doi: 10.1080/00207543.
2019.1627439.
Dolgui, A., Ivanov, D. and Sokolov, B. (2020), “Reconfigurable supply chain: the X-network”,
International Journal of Production Research, Vol. 58 No. 13, pp. 4138-4163, doi: 10.1080/
00207543.2020.1774679.
Ekparinya, P., Gramoli, V. and Jourjon, G. (2018), “Impact of man-in-the-middle attacks on Ethereum”,
IEEE 37th Symposium on Reliable Distributed Systems (SRDS), Institute of Electrical and
Electronics Engineers, Salvador, pp. 11-20, doi: 10.1109/SRDS.2018.00012.
Eling, M. and Lehmann, M. (2017), “The impact of digitalization on the insurance value chain and the
insurability of risks”, The Geneva Papers on Risk and Insurance - Issues and Practice, Vol. 43
No. 3, pp. 359-396, doi: 10.1057/s41288-017-0073-0.
English, E., Kim, A.D. and Nonaka, M. (2018), Advancing Blockchain Cybersecurity: Technical and
Policy Consideration for the Financial Services Industry, Microsoft Corporation, Washington.
Fang, C., Marle, F., Zio, E. and Bocquet, J.C. (2012), “Network theory-based analysis of risk interactions
in large engineering projects”, Reliability Engineering & System Safety, Vol. 106, pp. 1-10, doi: 10.
1016/j.ress.2012.04.005.
Giancaspro, M. (2017), “Is a ‘smart contract’ really a smart idea? Insights from a legal perspective”,
Computer Law & Security Review, Vol. 33 No. 6, pp. 825-835, doi: 10.1016/j.clsr.2017.05.007.
Global Maritime Issues Monitor (2018), Global Maritime Issues Monitor 2018, Global Maritime Forum,
Marsh, International Union of Marine Insurance, Copenhagen.
Greenberg, A. (2018), The Untold Story of NotPetya, the Most Devastating Cyberattack in History
[Online], WIRED, available at: https://www.wired.com/story/notpetya-cyberattack-ukraine-
russia-code-crashed-the-world/ (accessed 29 November 2018).
Gurning, R.O.S., Cahoon, S., Nguyen, H.O. and Achmadi, T. (2011), “Mitigating maritime disruptions:
evidence from the Australian-Indonesian wheat supply chain”, International Journal of Shipping
and Transport Logistics, Vol. 3 No. 4, pp. 406-429, doi: 10.1504/ijstl.2011.041135.
Hald, K.S. and Kinra, A. (2019), “How the blockchain enables and constrains supply chain
performance”, International Journal of Physical Distribution & Logistics Management, Vol. 49
No. 4, pp. 376-397, doi: 10.1108/ijpdlm-02-2019-0063.
Harris, C.G. (2019), “The risks and challenges of implementing Ethereum smart contracts”, IEEE
International Conference on Blockchain and Cryptocurrency, Institute of Electrical and
Electronics Engineers, Seoul, Korea, pp. 104-107, doi: 10.1109/BLOC.2019.8751493.
Hebert, C. and Di Cerbo, F. (2019), “Secure blockchain in the enterprise: a methodology”, Pervasive and
Mobile Computing, Vol. 59, doi: 10.1016/j.pmcj.2019.101038.
Hyperledger (2019), Hyperledger Fabric Documentation [Online], Hyperledger, available at: https:// Blockchain
buildmedia.readthedocs.org/media/pdf/hyperledger-fabric/latest/hyperledger-fabric.pdf
(accessed 19 October 2019). risks in
Iqbal, M. and Matulevicius, R. (2019), “Blockchain-based application security risks: a systematic
container
literature review”, in Proper, H. and Stirna, J. (Eds), Advanced Information Systems Engineering shipping
Workshops, CAiSE 2019, Lecture Notes in Business Information Processing, Springer, Cham,
Vol. 349, doi: 10.1007/978-3-030-20948-3_16.
Ivanov, D. and Dolgui, A. (2020), “A digital supply chain twin for managing the disruption risks and 147
resilience in the era of Industry 4.0”, Production Planning & Control, pp. 1-14, doi: 10.1080/
09537287.2020.1768450 (forthcoming).
Ivanov, D., Dolgui, A. and Sokolov, B. (2019), “The impact of digital technology and Industry 4.0 on
the ripple effect and supply chain risk analytics”, International Journal of Production Research,
Vol. 57 No. 3, pp. 829-846, doi: 10.1080/00207543.2018.1488086.
Ivanov, D., Dolgui, A., Das, A. and Sokolov, B. (2020), “Digital supply chain twins: managing the ripple
effect, resilience, and disruption risks by data-driven optimization, simulation, and visibility”, in
Ivanov, D., Dolgui, A. and Sokolov, B. (Eds), Handbook of Ripple Effects in the Supply Chain,
Springer International Publishing, Cham.
Kar, S., Kasimsetty, V., Barlow, S. and Rao, S. (2019), “Risk analysis of blockchain application for
aerospace records management”, SAE Technical Paper, 2019-01-1344. doi: 10.4271/2019-01-1344.
Li, X., Jiang, P., Chen, T., Luo, X. and Wen, Q. (2020), “A survey on the security of blockchain
systems”, Future Generation Computer Systems, Vol. 107, pp. 841-853, doi: 10.1016/j.future.2017.
08.020.
Nguyen, S. (2020), “A risk assessment model with systematical uncertainty treatment for container
shipping operations”, Maritime Policy & Management, pp. 1-19, doi: 10.1080/03088839.2020.
1729432 (forthcoming).
Nguyen, S. and Wang, H.Y. (2018), “Prioritizing operational risks in container shipping systems by
using cognitive assessment technique”, Maritime Business Review, Vol. 3 No. 2, pp. 185-206, doi:
10.1108/Mabr-11-2017-0029.
Nguyen, S., Chen, P.S.L., Du, Y.Q. and Shi, W.M. (2019), “A quantitative risk analysis model with
integrated deliberative Delphi platform for container shipping operational risks”,
Transportation Research Part E-Logistics and Transportation Review, Vol. 129, pp. 203-227,
doi: 10.1016/j.tre.2019.08.002.
Rivas, A.G., Tsyganova, M. and Mik, E. (2018), “Smart contracts and their identity crisis”, International
Conference on Information Systems, Association for Information Systems, San Francisco.
Savvides, N. (2018), Blockchain: Is Shipping Prepared? [Online], Safety at Sea, IHS Markit. available at:
https://safetyatsea.net/news/2018/blockchain-is-shipping-prepared/ (accessed 19 October 2019).
Simpson, A. (2018), “Australian regulation of blockchain and distributed ledger technology in banking
and finance”, Journal of Banking and Finance Law and Practice, Vol. 29 No. 2, pp. 73-91.
Staples, M., Chen, S., Falamaki, S., Ponomarev, A., Rimba, P., Tran, A.B., Weber, I., Xu, X. and Zhu, J.
(2017), Risks and Opportunities for Systems Using Blockchain and Smart Contracts,
Commonwealth Scientific and Industrial Research Organisation, Sydney.
Tradelens (2019), Solution Brief: Edition Two [Online], IBM Corporation and Maersk, available at:
https://www.tradelens.com/platform (accessed 20 October 2019).
Tseng, W.-J., Ding, J.-F. and Li, M.-H. (2013), “Risk management of cargo damage in export operations
of ocean freight forwarders in Taiwan”, Proceedings of the Institution of Mechanical Engineers,
Part M: Journal of Engineering for the Maritime Environment, Vol. 229 No. 3, pp. 232-247, doi:
10.1177/1475090213513755.
Viriyasitavat, W., Xu, L., Bi, Z.M. and Pungpapong, V. (2019), “Blockchain and internet of things for
modern business process in digital economy-the state of the art”, Ieee Transactions on
Computational Social Systems, Vol. 6 No. 6, pp. 1420-1432, doi: 10.1109/Tcss.2019.2919325.
IJPDLM Xu, X., Lu, Q., Liu, Y., Zhu, L., Yao, H. and Vasilakos, A.V. (2019), “Designing blockchain-based
applications a case study for imported product traceability”, Future Generation Computer
51,2 Systems, Vol. 92, pp. 399-406, doi: 10.1016/j.future.2018.10.010.
Yaga, D., Mell, P., Roby, N. and Scarfone, K. (2018), Blockchain Technology Overview. NISTIR 8202,
National Institute of Standards and Technology, U.S. Department of Commerce’, Gaithersburg,
MD. doi: 10.6028/nist.Ir.8202.
Yamashita, K., Nomura, Y., Zhou, E., Pi, B. and Jun, S. (2019), “Potential risks of hyperledger fabric
148 smart contracts”, in Tonelli, R., Marchesi, M., Ducasse, S. and Bracciali, A. (Eds), International
Workshop on Blockchain Oriented Software Engineering, Hangzhou, China, Institute of
Electrical and Electronics Engineers, Hangzhou, pp. 1-10, doi: 10.1109/IWBOSE.2019.8666486.
Zhang, J. (2019), Enterprise Blockchain Protocols: A Technical Analysis of Ethereum vs Fabric [Online],
Kaleido, available at: https://kaleido.io/enterprise-blockchain-protocols-ethereum-vs-fabric/
(accessed 17 August 2019).
Zhang, S., Zhou, E., Pi, B., Sun, J., Yamashita, K. and Nomura, Y. (2019), A Solution for the Risk of Non-
deterministic Transactions in Hyperledger Fabric, Institute of Electrical and Electronics
Engineers, Seoul, pp. 253-261, doi: 10.1109/BLOC.2019.8751453.

Corresponding author
Yuquan Du can be contacted at: yuquan.du@utas.edu.au

For instructions on how to order reprints of this article, please visit our website:
www.emeraldgrouppublishing.com/licensing/reprints.htm
Or contact us for further details: permissions@emeraldinsight.com