White Paper on Blockchain v2

discussion of Blockchain use in the international supply chain and expanding it to include the
relevance of other advanced technologies such as the Internet of Things (IoT) and Artificial
Intelligence (AI). This forum could support Senior Managers responsible for making decisions
about international supply chain applications, particularly in government. It could also help
UN/CEFACT to identify areas where its work could facilitate the use of these advanced
technologies in support of trade facilitation.
The Project team supported a proposal to establish an Advisory Group on Advanced
Technologies in the international supply chain2 which would support the implementation of the
UN/CEFACT programme of work areas related to the use of digital technologies for
exchanging trade information. Its main task would be to identify emerging strategic issues and
international best practices for senior public and private sector officials on this topic. One of
the first activities of this Advisory Group would be to look at specific issues raised within the
sectoral analyses and the case studies in this White Paper. On the basis of this work, the
Advisory Group would advise on recommendations for future work as well as guidelines and
information papers for consideration and possible adoption and publication by UN/CEFACT.

2 What is Blockchain and what should you know about it?

2.1 History and background
Although some of the principles incorporated in Blockchain technology were already described
in earlier cryptography papers, the basis for the Blockchain technology used today was first
published in an October 2008 White Paper on a cryptography mailing list. The paper was
called, “Bitcoin: A Peer-to-Peer Electronic Cash System” and was published by an author, or
a group of authors, under the pseudonym Satoshi Nakamoto. Interestingly, the term
‘Blockchain’ was never used in the original paper, but rather expressions such as ‘chain of
blocks’ and ‘blocks are chained’. The first use of “block chain” appeared on the same mailing
list in subsequent discussions linked to the original Nakamoto paper.
On 9 January 2009, Satoshi Nakamoto released Version 0.1 of the Bitcoin software, which was
the first software to implement the principles described in the October 2008 paper. This was
done on an open-source software site called SourceForge.
Satoshi Nakamoto continued to collaborate with other developers on the Bitcoin software until
mid-2010. Around that time, he handed over control of the source code repository and updates
to Gavin Andresen, transferred several related Internet domains to other prominent members
of the bitcoin community, and stopped his involvement. Up until this day, and in spite of much
speculation and detective work no one has discovered the identity of Satoshi Nakamoto.
Another important milestone in the development of Blockchain technology was the
development of Blockchains that could implement small computer programmes called smart
contracts that are written in computer languages having a complete set of programming
capabilities (these are called “Turing complete” computer languages).
Smart contracts have given Blockchains the ability to implement a varied set of business
functions involving the transfer of information and/or value, while leaving transparent and
reliably auditable information trails. More about smart contracts can be found later in this text.

2
See the proposed “Mandate and Terms of Reference of the Advisory Group on Advanced Technologies”
ECE/TRADE/C/CEFACT/2019/22.

UNECE – UN/CEFACT P a g e 9 | 158

White Paper on Blockchain v2

The first Blockchain to use smart contracts was Ethereum which was invented by Vitalik
Buterin. He first described the use of smart contracts on a Blockchain in a White Paper in late
2013. Then, when he failed to gain agreement on this concept within the Bitcoin community,
he proposed the development of a new platform called Ethereum. This new network, launched
on 30 July 2015, is today the Blockchain with the largest number of transactions and is among
the top three in market capitalization.3

2.2 Blockchain: how it works

At its heart, a Blockchain is a cryptographic protocol that allows separate parties to increase
the trustworthiness of a transaction because the ledger entries in its database cannot be easily
falsified (i.e. once data is written it is extremely difficult to change, albeit provided the data
was correct from the outset). This “immutability” is due to a combination of factors including
the cryptography used in a Blockchain, its consensus/validation mechanism and its distributed
nature. As a result of this immutability, Blockchain systems can be used as an independent
umpire in processes that might otherwise expose participants to the risk of one party not living
up to its contractual obligations (counterparty risk) and where third-party guarantors are
reluctant to intervene and assume part of that risk.
This text does not aim to provide an in-depth review of Blockchain technology—there are
plenty of web resources to help readers achieve that goal. Rather, it will cover the core concepts
which are needed to understand the potential application of Blockchain in international supply
chains.
First, some nomenclature:
a) Block: Data that is appended to the ledger after validation. Once a block is written to
the chain, it cannot be changed or deleted without replacing all subsequent blocks.
b) Consensus: An important characteristic of Blockchain systems which allows users to
know that transactions have been executed and to evaluate the trustworthiness of the
information about and in those transactions (for example, the date/time of execution
and content). In the case of public Blockchains, the umpire that decides consensus is
the society of all nodes that choose to participate. In the case of private Blockchains,
the umpire is the consortium of nodes given permission to create consensus. There will
be more about the different ways in which consensus can be reached in the text below.
c) Fiat or Fiat Currency: These are currencies backed by a central bank such as dollars,
euros, yen, etc.
d) Hash: The result of mathematical operations carried out on the numeric representation
of data—all data in a computer consists of numbers that are deciphered in order to create
the words and images you see on a screen. This result has a fixed size and is a unique
cryptographic fingerprint of the underlying data. A hash is a one-way function; this
means that given the data, it is easy to verify that the hash is the correct one for that
data. This is done by performing the pre-defined mathematical operations on the data
that supposedly created the hash—if the result is the same, the data is the same. This is
a key feature because it allows users to quickly confirm that no changes, at all, have
been made. For example, even an additional space or empty line in a text would change
its hash. At the same time, and this is what makes it a one-way function, it is almost
impossible to recreate the original data if all one has is the hash (i.e. reverse engineer
it).

3
According to https://bitinfocharts.com/ (as of February 2020).

P a g e 10 | 158 UNECE – UN/CEFACT

 White Paper on Blockchain v2

e) Node: A system that hosts a full copy of the Blockchain ledger. In some Blockchains,
such as Bitcoin and Ethereum, all nodes participate in the consensus process, in others
it may be only be selected nodes.
f) On-chain transaction: An automated procedure that creates or updates the status of a
Blockchain asset in the Blockchain database by appending new data to the ledger.
Examples include digital asset exchange, or execution of an automated business
process.
g) Validation: Work performed by nodes, in parallel, that verifies transactions using a
consensus algorithm. Different networks may use different consensus algorithms.
When mutual validation results in a consensus, then the nodes all commit (record) the
verified transactions onto their Blockchain as a new block.

2.2.1 Blockchain is a distributed ledger technology (DLT)

Ledgers are lists of records where transactions are recorded once and cannot be subsequently
updated. This means that any changes must be recorded as new transactions (book-keeping
entries). Digital ledgers may be stored as a database, also known as a journal database. Each
record can be read many times but written only once. The term ledger comes from accounting
where entries, once written into a ledger (accounting journal), cannot be changed. A
Blockchain database is a ledger because it uses hashes to ensure that none of the data it contains
has ever been changed.
A Blockchain ledger database is described as being distributed because there are multiple
copies kept on different nodes. The multiple copies are updated with new data blocks in a
coordinated way that ensures that they remain consistent with each other, using a consensus
algorithm of which there are different types.
In summary, the content and sequence of the data blocks in a Blockchain are determined by a
consensus of the participating nodes and each block contains a fingerprint (hash) that can be
used to recursively verify the content of all previous blocks.

2.2.2 It writes transactions

Each block of data written to a Blockchain ledger contains at least one record of a transaction,
although most blocks contain many records of transactions. A simple example of a transaction
would be “debit one coin from account A, and credit one coin to account B”, although many
other kinds of transactions are possible. Some Blockchains support a limited sub-set of
transactions (operations or algorithms) such as this simple double-entry bookkeeping
operation. Some Blockchains support a much wider set of transactions covering any solvable
algorithm (i.e. a Turing-complete computer programming language4). These types of
transactions are variously called smart contracts, chaincode, transaction families, or other
equivalent terms. In summary, all Blockchains support a variety of data operations on their
chains, but not all Blockchains support Turing-complete transaction languages.

2.2.3 These transactions are written to a cryptographically signed block

Blockchains implement two kinds of cryptographic technology: hash functions and

4
A Turing complete programming language can solve any mathematical problem computationally (if you know
how to program it). In general, this means it must be able to implement a conditional repetition or conditional
jump (while, for, if and goto) and include a way to read and write to some storage mechanism (variables).

UNECE – UN/CEFACT P a g e 11 | 158

White Paper on Blockchain v2

public/private key cryptography. Hash functions are used to construct the fundamental proof
that links each block to the rest of the chain before it. Hashes, in a different context, can also
be used to provide proof of validity for data that is referenced by blocks and they are used in
Proof-of-Work consensus algorithms where a hash with a specified number of leading zeros
serves as the “difficult problem” that nodes must solve in order to reach consensus.
Public/private key cryptography is used for identifying parties to a transaction and controlling
access to data. An analogy is email, where the public key is your email address which others
can use to send messages to you, and the private key is your password which gives access to
the private material, which is your messages. So, on a Blockchain, a public key can be used,
for example, to implement a transaction that sends a document or a payment to a party, but
only the party with the private key can access those documents or payments after they are sent.
A critical aspect to keep in mind when designing Blockchains is the management and security
of users’ private keys, given that there is no centralized management system. If a user loses
their private key, all assets related to that key are lost as well, unless a way to recover that key
has been put in place. On the other hand, the classic solution to this problem, the creation of a
centralized key management system, would most likely create a single point of failure, and
such a system would no longer meet the basic principles that a distributed, decentralized model
is based upon. As a result, creative solutions are needed.

2.2.4 Independent nodes must verify the cryptographically signed block

There are various consensus algorithms used by different Blockchain systems. For example,
Bitcoin, a public Blockchain, uses Proof of Work algorithms which allow data miners to
recover the cost of computationally expensive work in exchange for transaction fees and these
fees also provide a way to initially put electronic coins into circulation. Permissioned ledgers
use a consortium of nodes to agree on the output of a consensus process—which is generally
cheaper and faster than Bitcoin’s Proof of Work. All consensus processes require a mechanism
to settle disputes, or uncertainty, about which block should be written next. Most of these
mechanisms are based upon using the block, which is agreed upon by more than 50 percent of
the nodes. A more detailed description of public and permissioned Blockchains can be found
below.
The nature of the consensus mechanism determines some key characteristics of a Blockchain
system. For example, mining the creation of blocks has deliberately been made expensive. This
protects the Blockchain by making the cost of capturing more than 50 percent of the nodes—
the number needed to approve a block, and thus to manipulate the Blockchain—prohibitively
expensive. To compensate for this cost, miners are rewarded both an amount of Bitcoin for
each block they create and fees for each transaction written to the Blockchain.5 Each block has
a size limit and transaction costs are determined on a free-market basis, so the more transactions
are requested, the more the price increases for each transaction. This is necessary for the Bitcoin
economic operating model, which seeks to obtain an honest consensus in an unregulated market
of potentially anonymous and economically rational operators (i.e. operators who might, being
anonymous, and having no costs for doing so, steal assets). As an additional incentive, if a
node/miner does not accept the block voted on by over 50 percent of the other nodes, it is
effectively kicked off the Blockchain, thus losing the possibility of earning future Bitcoins and
transaction fees. Consequently, Bitcoin has extremely low bandwidth due to the cost of

5
Bitcoin is designed so that, over time, mining rewards are reduced with the objective of eventually having all
mining rewards come from transaction fees.

P a g e 12 | 158 UNECE – UN/CEFACT

 White Paper on Blockchain v2

generating blocks with transactions taking on average 10 minutes to be confirmed. In addition,

its very large number of nodes and users, generating large amounts of data, together with its
block-size limits, makes storing data on the Bitcoin Blockchain expensive as well as being
inefficient.
Given the duplication of information across all nodes on a Blockchain, it is generally inefficient
to store significant amounts of data on Blockchains. Bitcoin still supports many billions of US
dollars’ worth of Bitcoin and other high-value transactions, but its speed and volume
limitations make it unsuitable for many enterprise applications and the direct implementation
of small-value transactions.
Permissioned ledgers strike a different balance between bandwidth, capacity and
trustworthiness. For example, because they have more control over who participates,
permissioned ledgers can use other consensus mechanisms—even if some of them are
somewhat less robust than the Proof of Work used by Bitcoin. For example, there are consensus
mechanisms based on the amount a node has invested in a network (called Proof of Stake), or
where a consensus by a subset of nodes is verified by a larger group.
In addition, there is a great deal of research by foundations, universities and companies looking
to identify and test other consensus mechanisms. Some of these alternative consensus
mechanisms will allow ledgers to support hundreds or even thousands of transactions per
second, rather than an average of one new block per 10 minutes, as with Bitcoin. There is also
research going into the maintenance and accessing of data on petabyte-scale (i.e. truly gigantic)
databases.

2.2.5 The block is written to the ledger after it is verified

When consensus is reached, which includes agreeing that a block contains legitimate data, and
that it is the block that should be written next, each node adds the agreed block to their local
copy of the ledger. In this way, all nodes maintain an identical copy of the ledger each time a
block is written. This is proven by the next block to be written, because it will contain a hash
of the block before it.

2.2.6 The new block is linked to previous blocks—creating immutability

Remembering that a hash is a one-way function that produces a unique fingerprint of selected
data and also noting that a hash function produces a fixed-size fingerprint regardless of the
amount of data being hashed it can be assumed that as a result, there is no way to know from
looking at the hash if the data was a single, small document or a database holding many billions
of records.
Each block in a Blockchain contains some transaction data plus the hash of the previous block,
which is always the same size no matter how much data it represents. Given a consensus that
this new block forms part of the chain, it is possible to verify the previous block from its hash—
and from the previous block, the block before it, and so on all the way to the first or genesis
block in the chain. The hash of the previous block is said to be anchored in the subsequent
block.
Tampering with the contents of any block in the chain will change the hash of that block, which
will change the hash of the block after it, and so on for every subsequent block in the chain. If
this occurs then the tampering is easily detectable by any node, and the consensus algorithms
will prevent new blocks from being written to the chain because the hashes don’t match.

UNECE – UN/CEFACT P a g e 13 | 158

White Paper on Blockchain v2

This characteristic is the origin of the word “chain” in “Blockchain” because each block is
anchored to the previous block and proves the existence of all the data it references going back
to the first “block” of data in the “chain”.

2.2.7 Some time is needed before the existence of a new block can be “confirmed”
Each node creates new blocks based on the information available to it at a specific point of
time. Because of network latency, whereby nodes may receive information at different times,
this can result in different nodes publishing different blocks at the same time, without this
being caused by errors or inaccurate data. This can, temporarily, result in differing versions
of a Blockchain ledger existing which is called a “ledger conflict”. For example, in a
Blockchain-based digital currency system, the same money could show as spent and unspent,
depending on at which Blockchain ledger version we were looking. However, these conflicts
are resolved automatically as the longest chain available becomes the official Blockchain. Any
data that was in a shorter block and is not included in the longest, selected block, is returned
to the unused transaction pool to be included in a later block.
Because of the possibility of ledger conflicts resulting in a processed transaction being
returned to the unused transaction pool (because the block it was included in turned out not to
be the longest one), a concept called confirmations is deployed for users to measure the
probability of a transaction being permanently present in a Blockchain. A transaction’s
confirmation is the number of blocks present after the block where the transaction is found.
For example, in the Bitcoin network 6 confirmations are considered very safe as it would be
extremely difficult for so many blocks to be rejected due to ledger conflicts or for a forking
to happen before the block containing the said transaction if it is followed by six new valid
blocks. The number of confirmations considered to ensure that a transaction is safe is different
for different protocols based on the block creation time and whether the Blockchain is
permissioned or permission less.

2.3 Blockchain types

2.3.1 Public ledgers

Public ledgers can be read by anyone. They are also permissionless because anyone can
participate and utilize the consensus mechanisms without needing permission to do so and
without depending on a regulator to enforce acceptable behavior. Bitcoin, Ether and a range of
other cryptocurrencies with market capitalizations going up to 59 billion United States dollars6
operate this way, allowing any transaction that is logically valid between any parties on the
network, including anonymous and pseudonymous parties.
One of the fears about Blockchain technology is that, if a malevolent actor were to control a
majority of the nodes, then they could decide to reach a consensus in contradiction of the
interests of other stakeholders. This threat is called a Sybil, or 51 per cent attack in
cryptographic literature. A successful Sybil attack on a public Blockchain cryptocurrency could
result in a catastrophic redistribution of assets and/or double spending. Other possible
consequences include:
• Not recording transactions from specific users, nodes, suppliers or even countries;

6
https://bitinfocharts.com/ (as of February 2020).

P a g e 14 | 158 UNECE – UN/CEFACT

 White Paper on Blockchain v2

• Creating an alternate chain that is longer than the original chain which nodes will switch
to because they will automatically think that the longer chain has had the most
verification work done to it; and
• Disrupting how and where information is distributed by thwarting or not transmitting
blocks to other nodes.
Public Blockchain ledgers are designed to operate according to rules that do not require
governance or regulatory mechanisms to intervene in order to prevent antisocial transactions,
because those mechanisms might themselves be exploited for antisocial outcomes—for
example, if a governance mechanism were to be hacked by a third party or abused by a
regulator. Public Blockchains operate with absolute assurance in their algorithms and are
designed to avoid any need to trust any counterparties. Public Blockchains are sometimes
referred to as being trustless.
Public ledgers typically compromise other aspects of performance in order to achieve a strong
resistance to Sybil (51 per cent) attacks. They also rely on the transparency of the public ledger,
and on the transparency of the open-source software involved.
Public Blockchain systems, which typically have thousands of users, are difficult to manage
and maintain because of the need for consensus (being 51 per cent or more of users) in order
to make changes. This can also be true of permissioned Blockchains, depending upon their
governance structure. Within Blockchains, changes are implemented through forks, of which
there are two types:
• Soft forks - These represent software changes that do not prevent users from using the
changed Blockchain system.
• Hard forks - These are software changes that prevent users who have not adopted the
change from using the changed Blockchain system. This requires a decision from users
to either upgrade and stay with the main fork or continue without the upgrades and stay
on the original path. Users on different hard forks are prevented from interacting with
each other, which helps to avoid conflicts between ledgers.
As with all information technology systems, developers are responsible for changes to the
underlying software. These developers maintain some level of control over the direction of the
Blockchain on which they are working, primarily the power of proposal. For example, a group
of developers may recommend a change in the hashing algorithm or changes to the block
structure. In public and some permissioned Blockchains, these proposed changes will then
require a majority of the nodes (validators) on the network to agree and require a hard fork. It
is very difficult to obtain the permission of a majority of nodes for a hard fork, resulting in an
underlying difficulty in maintaining and updating Blockchains. It is therefore important to look
at the governance mechanisms in place when selecting a Blockchain and at the trade-offs
involved between stability and the ability to evolve over time.

2.3.2 Permissioned/Private ledgers

Like conventional databases, the contents of a private Blockchain ledger may be a guarded
secret that is only available to selected users, and node operators, through a role-based access
control mechanism. Some examples of access control include restricting some users so they
can only: write to the Blockchain under specific, defined instances; perform certain queries;
and/or interrogate a limited set of data. Various roles that could be specified include: miner,
validator, administrator and auditor. Likewise, a private Blockchain can be set up so that
everyone can read the data, but only designated nodes can add new data. This can also be done

UNECE – UN/CEFACT P a g e 15 | 158

White Paper on Blockchain v2

on a public database using smart contracts, however, authorities might be concerned that there
is a greater security risk since anyone who wants to could see (and try to hack) the smart
contracts in question. Such a database might be desirable for official records such as land deeds,
licenses, certificates, etc. Unlike a traditional database, a private Blockchain ledger is
immutable (i.e. cannot be updated) and transactions are verified by a consensus mechanism
that is established by the network operators.
Private ledger technology is typically applied in enterprise use cases where immutable
transactions are required that can be verified by a closed community of nodes. These nodes
may be independent of parties to the transactions on the Blockchain and may be subject to
oversight and governance that is not possible, or considered desirable, in a permissionless,
public Blockchain system.
Permissioned ledgers operate with a different threat model to the public ledgers. The operators
of permissioned ledger nodes are not anonymous; they are subject to some kind of governance
controls and are collectively trusted by the users. Antisocial behavior by a node or participant
could result in that party being evicted from the network and their transactions blocked. The
expectation of users of a permissioned ledger is that the operators will intervene in antisocial
behavior but not commit antisocial behavior themselves.
On permissioned ledgers, the level of security, and the confidence that users can have in the
immutability of the data, varies depending upon the rules established for that permissioned
ledger, including its consensus mechanism. Permissioned ledgers can also create a false sense
of security because only known participants are allowed to maintain nodes and participate in
verification. At the same time, even known participants can become untrustworthy upon being
hacked; permissioned ledgers with single points of failure are also vulnerable should anything
happen to that single point, and poorly tested smart contracts can create bad consequences for
participants—even if no harm was originally intended—especially if the Blockchain network
does not have adequate controls in place.

2.3.3 Accessing external (off-chain) data

Because of space limitations and the cost of storing data directly on a Blockchain, it is often
more efficient to include in a Blockchain only a link to the appropriate data and a calculation
(i.e., hash) in order to prove that the content of the data has not been changed. Linked data uses
hashes and may also use digital identifiers and public key cryptography. This will work as long
as the rules are used consistently across the Blockchain and the system(s) the linked data is
stored on. This implies that the more standardized the use of public-key cryptography, the
easier and less expensive it will be to link data—and the same can be said for the semantics
defining the data. The use of common semantics (i.e. data definitions) greatly simplifies the
job of interpreting data from different sources and the UN/CEFACT Core Components Library
plus its reference data models (SCRDM and MMT RDM)7 is a very complete source of globally
harmonized trade-related semantics and their relationship to each other which would be
beneficial to be reused in this context.
Blockchain references (also known as anchors) which point to external data can also contain
information, such as hashes, to be used to prove the existence or unchanged nature of the data
referenced. This is different from a hyperlink or Uniform Resource Locator (URL) on the
Internet where the information at an address may change depending on the time it is accessed.

7
See for example the Buy-Ship-Pay Reference Data Model Business Requirement Specification:
http://www.unece.org/fileadmin/DAM/cefact/brs/BuyShipPay_BRS_v1.0.pdf (as of February 2020)

P a g e 16 | 158 UNECE – UN/CEFACT

 White Paper on Blockchain v2

For example, if you click on a link on a television news website, which changes on a regular
basis as it is updated, what you find tomorrow may be different from what you find today. With
a Blockchain anchor data link, the information in the Blockchain is a guarantee (proof of
existence) that the data being pointed to has not been changed.
The location for data found in a Blockchain anchor data link is identified with a Universal
Resource Identifier (URI). The URI can be registered as part of a Blockchain transaction or
referenced in (or used by / created by) a Blockchain smart contract. The URI may point to data
in public/open distributed data systems such as those located on the Internet and accessed using
standard protocols (i.e. FTP, HTTP, HTTPS, or IPFS8) or it may reference data in private
databases that are selectively available to permissioned ledger users. With private off-chain or
cross-chain references, it is possible for network operators to know that some data exists, but
to have their access limited by additional controls (for example, with a technique called zero-
knowledge proofs). This can be very interesting from a privacy standpoint as it is possible to
access data in order to know that, for example, someone is over 21 without giving their age, or
that they live in London, without giving their address.
These sources of external data are sometimes called oracles which are described in more detail
below.

2.3.4 Interledger: implementing transactions across Blockchains

Today, many different Blockchains exist and in the future, there will be even more. Already, a
supply chain transaction, from beginning to end, could involve writing or reading data from
multiple Blockchains. For example, an exporter might need to use a bank Blockchain, one
Blockchain per transportation mode, a Blockchain used for traceability by the importer and one
or more used by regulatory authorities. In addition, it is easy to foresee an increasing need for
the exchange of information and the implementation of transactions across Blockchains (i.e.
interledger). As described in the previous section, Blockchains have the possibility to reference
data outside of that Blockchain. This includes data in other Blockchains as well as from non-
Blockchain systems.
Interledger (Blockchain-spanning) transactions use cross-chain references and smart contracts
(see description below) on both Blockchains that interact in a coordinated way. This is an
emerging field, however there are mechanisms that already exist and are in use. These are
primarily focused on exchanging value (i.e. digital assets) between ledgers, for example Ripple
Interledger and the Lightning Network.

2.4 Other things you should know

2.4.1 Smart contracts

Smart contracts are self-executing computer programs that encode business logic. They execute
when pre-defined conditions are met. In other words, their execution is not launched, or at least
not directly, by human intervention. These can be as simple as “transfer specific amount of
asset from account X to account Y.” Smart contracts are based on the conditional If-This-Then-
That (IFTTT) model where some activity is automatically executed when certain conditions
are met. These conditions can be a certain period of time, a specific value (for example the

8
FTP = File Transfer Protocol, HTTP = HyperText Transfer Protocol, HTTPS = HyperText Transfer Protocol
and IPFS = InterPlanetary File System. For not too technical explanation of IPFS see
https://medium.com/wolverineBlockchain/what-is-ipfs-b83277597da5 (as of February 2020).

UNECE – UN/CEFACT P a g e 17 | 158