blockchain discussion paper -...
TRANSCRIPT
Blockchain Discussion Paper
1
Page 1
Kurt Wayenberg
Blockchain
Discussion
Paper
Blockchain Discussion Paper
2
Page 2
Kurt Wayenberg
TABLE OF CONTENTS
Table of contents ..................................................................................................................................... 2
Blockchain - Hype, innovation and make over ....................................................................................... 4
1 Blockchain - The hype is over ......................................................................................................... 4
2 Blockchain - The innovative part ..................................................................................................... 6
3 Blockchain - The make over ............................................................................................................ 9
3.1 Building Blocks ........................................................................................................................ 9
3.1.1 Hashing .............................................................................................................................. 9
3.1.2 Asymmetric Keys (Signing) ............................................................................................. 10
3.1.3 Chaining ........................................................................................................................... 11
3.2 Putting the pieces together ...................................................................................................... 12
3.2.1 Parties ............................................................................................................................... 12
3.2.2 Wallets ............................................................................................................................. 12
3.2.3 Transactions ..................................................................................................................... 13
3.2.4 BlockChains ..................................................................................................................... 14
3.2.5 Smart Contracts aka 'Batch Jobs' ..................................................................................... 15
3.2.6 to 'pay' or not to 'pay'........................................................................................................ 15
3.3 http://trueandauthenticated.com .............................................................................................. 16
3.3.1 Users ................................................................................................................................ 16
3.3.2 Parties ............................................................................................................................... 18
3.3.3 Wallets ............................................................................................................................. 19
3.3.4 Transactions ..................................................................................................................... 20
3.3.5 Full Example: The 'Kudos' use case ................................................................................. 21
3.3.6 Access via SOAP V1.1 XML (classical applications) ..................................................... 30
3.3.7 Access via JSON (mobile applications) ........................................................................... 30
3.4 Examples and use cases .......................................................................................................... 31
3.4.1 Livestock Traceability...................................................................................................... 31
3.4.2 Energy Companies ........................................................................................................... 33
3.4.3 Notary organizations ........................................................................................................ 34
Blockchain Discussion Paper
3
Page 3
Kurt Wayenberg
3.4.4 Voting .............................................................................................................................. 35
3.4.5 Fidelity points, Mileage, 'Hours used' and other cryptocurrencies .................................. 36
3.5 Some final design decisions .................................................................................................... 37
3.5.1 Anonymity ....................................................................................................................... 37
3.5.2 Privacy ............................................................................................................................. 37
3.5.3 The Distributed / Decentralized Autonomous Organization / Company ......................... 37
3.6 DXC.Portal Prototyping Platform ........................................................................................... 39
3.7 DXC.Portal Development Platform ........................................................................................ 40
3.8 .Net DXC Crypto-ledger: Value Proposition .......................................................................... 41
Appendix A: Additional documentation on ...................................................................................... 42
http://trueandauthenticated.com ........................................................................................................ 42
User Registration Process ............................................................................................................. 42
1 User registers and gets a blockchain account ......................................................................... 42
2 Upgrade the user account ....................................................................................................... 43
3 e-Mail Verify the account ...................................................................................................... 43
4 Advanced verification of the accounts ................................................................................... 44
5 Future extensions ................................................................................................................... 45
Appendix B - Asymmetric Key Pairs ............................................................................................... 46
John Doe Private key .................................................................................................................... 46
John Doe Public Key .................................................................................................................... 46
System public key ......................................................................................................................... 46
Jack Doe Public Key ..................................................................................................................... 46
Jack Doe Private Key .................................................................................................................... 46
Troy Private Key ........................................................................................................................... 47
6 Appendix C - Lorum Ipsum Text ................................................................................................... 48
Appendix D - Other Blockchain Solutions ....................................................................................... 49
IOTA ............................................................................................................................................. 49
IBM Blockchain ............................................................................................................................ 50
Corda ............................................................................................................................................. 50
JD.com .......................................................................................................................................... 50
Appendix E: Integrating Legacy Information Systems ..................................................................... 52
1 Making documents immutable ................................................................................................... 52
10.2 Making images immutable .................................................................................................... 54
10.3 Making data tables immutable .............................................................................................. 55
Blockchain Discussion Paper
4
Page 4
Kurt Wayenberg
BLOCKCHAIN - HYPE, INNOVATION AND MAKE
OVER
1 Blockchain - The hype is over
Blockchain has been the most hyped technology throughout 2016 and 2017. Although today, new
'blockchain vendors' still pop-up, and try to attract millions of dollars of investment money, the top of
the hype has been passed and, as Gartner predicted, the technology is sliding into the 'Through of
Disillusionment'. Online searches & tweets are dropping, governments are issuing restrictive
legislation, and communities get confronted with the many drawbacks of decentralizing control: lack
of accountability, problems with security, safety and privacy, sorrows with efficiency, ...
Ferdinando Ametrano, professor in Milano, was a bit too hopeful in predicting that 2017 would prove
that 'Blockchain' was a bad idea.
But today, March 2018, we are confronted with:
The lost illusion that one 'blockchain' would solve all business problems
The unreadable scientific documents full of mathematical explanations of questionable
algorithms that try to justify all kinds of new blockchain technology
The observation that the energy consumption is massive and completely unsustainable
as soon as blockchains grow from small to medium
The reflexion that nothing is more vailed than the crypto-platform's large initial wallets and
their owners, and this despite the 'transparency' claim
However, there definitely is some decent stuff in the whole hype and throwing it all away would be
incorrect...
Blockchain Discussion Paper
5
Page 5
Kurt Wayenberg
Unfortunately, the debate is very much burdened by the fact that a lot of secondary innovations are
included to promote solutions and best practices. These designs range from supporting tools in the phase
of 'ideation' or 'design thinking', over the support of 'proof of concepts’ & ‘rapid prototyping' , to full-
featured 'business configurations & workflow' development environments.
In this discussion paper, we stick to the essence of blockchain technology and try to unravel the knot of
expensive words and obscure technology to extract the innovations, albeit scarce but important...
Blockchain Discussion Paper
6
Page 6
Kurt Wayenberg
2 Blockchain - The innovative part
Blockchain has been called a 'game-changer'... And although it is, the statement was followed by an
endless list of 'benefits' and 'characteristics' that have nothing to do with blockchain. Let's cut the crap
and come to the core.
The uttermost important benefit of a 'blockchain' is that it is a 'System of Records' that is tamper resistant
and trustworthy
The impact of this benefit is that a 'blockchain' is de-facto answer to dispute-resolution.
All other 'components' can be considered as secondary benefits, as rather irrelevant features or even as
'smoke and mirrors' to fake importance. Let's discuss a few of these elements:
As secondary benefits, as rather irrelevant features or even as 'smoke and mirrors' to fake importance.
Let's discuss a few of these:
The 'Initial Coin Offerings' (ICO's) have some beauty in making the 'validation process' a bit
easier but they are by no means a necessity. On the contrary, these ICO's add scarcity to the
'product' and, as such, were an excellent trick to attract investments via crowdfunding ('Token
Sales'). Speculation, greed and the fear-of-missing-out, seed the sky-rocketing stock market
price. Always keep in mind that ICOs should represent an investment based on the existing or
new business an enterprise will generate. However this business model is often unclear and
not transparent, if there is a business model at all...
The 'Distributed Ownership' have some beauty in making communities less dependent from
one specific company, authority or organization. By thoughtlessly creating and maintaining
thousands of copies of the 'blockchain' database, we indeed have some reassurance that the
database might outlive some individual solutions but let us not underestimate the fact that
there always was a solitary 'foundation' or company controlling the code. Nor should we ever
forget that these financial models are never solid and always lead to a collapse if it keeps
growing
The 'Proof of Work' (POW) hashing has some beauty in that it requires more time to
reconstruct an alternative version of the blockchain, but for the rest POW is a weak argument
that never, ever will justify the inefficiencies of the POW.
The Ghost protocol in Ethereum (Greedy Heaviest Observed Subtree) is an ugly, overly
complex and entirely non-transparent attempt to overcome stale blocks and orphan
transactions. It also fails to avoid mining pool domination.
The 'Smart Contracts' are appealing because they can help implement some use cases on the
blockchain in a very fast manner. However, the concept is seriously flawed:
o Smart Contracts bring sloppiness, obscurity and non-transparancy to the blockchain,
which, from a governance point of view, is evolving blockchain to an opposite
direction of what it was designed for.
o Smart Contracts suffers from the same myopia than did early expert systems. Your
contracts need to have a view that reaches well beyond the current transaction details.
The trick they use is to open it up via an 'Oracle' but in an uncontrolled context the
combination 'Smart Contract' & 'Oracle' is nothing more than Pandorra's box...
o The validation of 'every transaction' in a trustless decentralized distributed blockchain
is extremely inefficient in terms of computing power. Whereas this process
theoretically still had some possibilities to exploit parallelism, however with the non-
transprancy of smart contracts this is completely impossible and today there is NO
parallelism in for example an EVM (Ethereum virtual machine).
Blockchain Discussion Paper
7
Page 7
Kurt Wayenberg
o Because of smart contracts Ethereum has created an overly complex transaction
payment scheme based on transaction complexity, gas price that users are willing to
offer to get their transactions executed first, and maximum-spent levels that is
completely lost when a transaction fails.
o In Ethereum you only can create a new 'cryptocurrency' (~ a seperate blockchain)
only via a smart contract. Why not via a standard transaction invocable by anyone
having the rights and / or funds to do so. What could be a possible reason? Other than
reserving this functionality to the creation of ICO's only?
o To my opinion most smart contracts are either in the category 'hello world' or are
supporting an 'ICO token' sales. I am not so sure it is as successful as it claims...
The use of the Digital Signature Algorithm (DSA) has some beauty in that it is a bit faster for
signature generation, but overall it is not really justifiable that this algorithm should be used
over the more secure and more successful RSA algorithm. DSA was the open source
alternative in the period that the RSA algorithm was patented. But today this algorithm is
freely available and by far the more widely used.
The blockchain addresses are most of the times a hash of the public key, made more readable
by clipping a part of it and/or by converting it to Base58 or Base32 and/or by adding a
(number of) check-digit (s) and/or by adding prefixes / suffixes. Despite all attempts to
improve better readability and decrease the manual errors, these approaches have limited
practical usage. In addition they open up a religious, decades old, debate, as to whether
primary keys should be intelligent (natural) or surrogate. To my opinion, most blockchain
keys today are the worst combination you can have: natural and unintelligent. The world
would be far better off with wallets and parties having more meaningful natural keys (IBAN
& BIC numbers, RRNs,...) or simpler surrogate keys (even a GUID is a relief compared to
these blockchain address). Also a combination of the two (party - natural key in combination
with a simple wallet surrogate key) can be a powerful option.
The wallet being fully anonymous and autonomous has its power, yet, in many situations an
explicit relation between parties and wallets might prove its superiority in permissioned
blockchains or in real business scenario's. At least both scenarios should be supported...
The required energy by the 'Proof of Work' and the massive distribution caused by the financial model
is what ultimately kills blockchain usage from a 'durability perspective'.
The massive up-front validation (aka the inefficiency of the 'distributed consensus') prohibiting swift
and immediate processing is what ultimatly killed it from a 'usability perpective'
The blockchain vendors already recognized these two points as the Achilles heel, and as a result are
making mining optional and are proposing alternatives for the distributed consensus. But hack - that is
85% of their code and whitepapers that can be flushed...
So the 'real innovation' is open and transparent, cryptographically secured, ledgers'
To be honest, even the degree of innovation is relative...The first (tax) ledgers were used in ancient
Egypt. The RSA algorithm dates from the seventies. The Secure Hash Algorithms (SHA-family) date
from the nineties (Hashing itself dates from the fifties). Even the 'chaining' (using hash codes) is not
new. Since 25 years, hash trees or 'Merkle trees' have been used, mostly to ensure that data blocks
transmitted from other peers in a peer-to-peer network are received undamaged and unaltered. So even
this incredible blockchain hype was more an evolution than an innovation.
Blockchain Discussion Paper
8
Page 8
Kurt Wayenberg
Nevertheless, blockchains in general and Bitcoin in particular, inspired the world, to bring data-
immutability (tampering resistance) and proof (dispute resolution) to the world of business transactions.
And that is the true innovation of this technology!
Today, it is time to be critical on the designs and to see how simpler and more transparent models are
more effective.
The big question is, will distributed DAPPS really break through? Well I think they do have some
usefulness, but their usage is quite limited. As already said, their number one usage remains
crowdfunding and attracting naive investors, but that area is going down. Other investment focusing
applications still our quite popular (????) There are a few message services of which no message never
ever can be deleted (voluntarily nor censored), and then there are a few basic games which never ever
leave the blockchain. Will distributed apps be attractive to business groups? They might if the people
in the group do not trust, nor cooperate, but the cost of ownership is significant ...
One of our main DXC colleagues focusing on Ethereum / Bitcoin like blockchains is Faisal Siddiqi
( [email protected] ) - feel free to contact him if you want to explore this route further.
My basic conviction is that none of the elements discussed in this section are of some importance in the
basics of blockchain technology: trust and immutability. You should disregard them and just live
without them and doing so probably makes your life easier... Just read-on and see what this approach
can do for you...
Blockchain Discussion Paper
9
Page 9
Kurt Wayenberg
3 Blockchain - The make over
A good programming practice is to refactor stuff rather than rebuild it. However, the coupling of
components and concepts in today’s blockchain implementations is so high that changes to a single
element cannot be isolated from the functioning of the system, nor from other components. The
technology stack is often polluted with all kind of 'other' innovative technologies (Swarm, IPFS,...)
which might help the implementation but do not add in the basics of the solution.
Probably the best strategy is tearing it down and than building it up after altering and improving some
flaws or design inefficiencies...
3.1 Building Blocks
When tearing it down you see we only get to 3 important building blocks: Hashing, Signing and
Chaining.
In this section we propose to use a standard hashing algorithm (SHA256), to use the widely used RSA-
asymmetric keys and we explain the principle of chaining
3.1.1 Hashing
The table underneath shows the essentials of hashing. We choose for a well-accepted SHA256 hashing
function and use BASE64 encryption.
https://approsto.com/sha-generator is a very nice online Hash calculator. The table shows the hashes as
if you were typing the sentence 'Hello World'.
The last hash is the hash for the Lorem Ipsum text (see the two pages in appendix).
47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=
H RL165g9Hj64QYeEadzn0uU0dr5F5gtM7b8igGmP4nCE=
He MO/ftS/2f4Dat8uJ3P4O7IQSlmz+WDJJk2dLRhbWvRE=
Hel t4nCTc22jEQ3sEwYa/I5pyB+dXP7GyKnSf4ae42W0pI=
Hell jVhvi2DfGtdQK1L8UNLgttDZtWQ4dcBU2CHf2OZnK+0=
Hello GF+NsyJx/iX1Yab8k4suJkMG7DBO2lGAB9F2SCY4GWk=
Hello World pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=
Lorem Ipsum C1IJ2yxejWJ1TQ5njR2HpLysVdEcCk56u8aqkj1xrh4=
The table illustrates nicely some characteristics of our SHA256 hashes:
All hashes are 44 bytes in BASE64 (256 bits = 32 bytes = 44 bytes in BASE64) irrespective
of the length of the hashed data
Even the slightest difference between two texts creates a completely different hash
Given a certain hash it is impossible to find the original text from the hash
Blockchain Discussion Paper
1
0 Page 10
Kurt Wayenberg
The same hash tests can be done on the DXC Signing Portal
(http://trueandauthenticated.com/portal/Encryption/Sign) but only for the SHA256 + BASE64
conversion. The portal also shows an additional nice technique that is very useful when criticists would
question the security of hashes or would utter the probability that multiple documents theoretically can
have the same hash. An alternative to moving to a higher hashing function in that case is generating the
hash for the inverse text extended with the length of the encrypted text (the RTPL hash = the 'Reversed
Text Plus Length' hash). This is like putting a double or even triple lock on top of your hashed text...
and although not mathematically proven probably will also assure no two documents share the same
hash + RTPL hash
3.1.2 Asymmetric Keys (Signing)
In RSA every person has a private key (for signing) and a public key (for other to check the signature).
The following scenario illustrates how it would work:
Example 1:
Suppose John Doe wants to borrow 100€ from Jane Doe and promises it to pay it back in 2019. He
could create the text:
I, John Doe, received 100€ from Jane Doe and I will pay it back in 2019
And he could sign it with his private key. This would give:
Lmawfae7EEMvx5zo59D9FCY0zMqAQwjt3vEeJh85lnZhmDbUAIdh0j88Y2fONznbt2Skzw
RYX/gkGA6qfbbTCgJW12Ds5P+1yFOTUuluSqTnYBAPSqINMjuVsxICtwCIofV8ByXuVw
s0fejn5DNC9uCeEaABV059OdgKV6gJRrw=
From now on John can never deny that he borrowed 100€, that it was to Jane Doe and that he will pay
it back in 2019. Anyone with a public key can check if indeed John did sign this transaction and the
transaction cannot be tampered with.
However, the requester is not the only one that can sign a transaction. The platform is aslo also a
candidate for signature usage !
Example 2:
Suppose John Doe sends this information to a ‘blockchain’ platform and suppose the blockchain
platform replies:
I, Blockchain platform, declared that I received, validated and processed the message < I, John
Doe, received 100€ from Jane Doe and I will pay it back in 2019 > signed as <
Lmawfae7EEMvx5zo59D9FCY0zMqAQwjt3vEeJh85lnZhmDbUAIdh0j88Y2fONznbt2Skzw
RYX/gkGA6qfbbTCgJW12Ds5P+1yFOTUuluSqTnYBAPSqINMjuVsxICtwCIofV8ByXuVw
s0fejn5DNC9uCeEaABV059OdgKV6gJRrw= > and I Inserted is as transaction number 1
Than the platform would sign it as:
lMwwIZ12cJpd12KOma9tup0XsEhLIFs0fslOE/z2ixpTRJQavf2GbtgpwHjXWBGQa8mwkxca
LC0aK9KFDAN4cGka9u4lUYGE9puORpVeJVv5Zp6y5sLzwhMZOZ73d4Pe7/svUcpMkTG
6/2vVIXlsnMckV/BT43PKJ/EP+TdD1NI=
Blockchain Discussion Paper
1
1 Page 11
Kurt Wayenberg
From now on the blockchain platform cannot deny anymore that it received the message, validated it,
processed it and added it to the database. Rather than receiving a classical 'your request number was
12345' you now receive a signature that proves your submission to the platform.
The blockchain platform also takes a hash from the previous transaction. That hash is:
0Xf1HyT9V6BdmVT7June09F0T5vvtMjstLImwivdbYY=
And we use it in the next section on 'chaining'
3.1.3 Chaining
Now suppose the blockchain platform receives another message, one from Jack Doe who also borrowed
money from Jane Doe. The received message was:
I, Jack Doe, received 80€ from Jane Doe and I will pay it back in 2020
And Jack signed it with his private key as follows:
A+9PJQOAXdCLDKjK22FSYpPe46dZBWun8Y2PBEfYZcovfkF/au5QzH7RokHWZs5vRS5
y6ue8ThkItxD1kDUapI/lGxrRF20f5U1gdy3C+6b0vucgD34LtoH1laTWg0VeSeKxuSJfte6x7
No92rI3Ux4F0xhONCFVcfl0S97ePZg=
Now as the platform calls itself a blockchain platform it cannot ignore the obligation to chain the
transaction. The platform now answers:
I, Blockchainplatform, declared that I received, validated and processed the message < I, Jack
Doe, received 80€ from Jane Doe and I will pay it back in 2020 > signed as <
A+9PJQOAXdCLDKjK22FSYpPe46dZBWun8Y2PBEfYZcovfkF/au5QzH7RokHWZs5vRS5
y6ue8ThkItxD1kDUapI/lGxrRF20f5U1gdy3C+6b0vucgD34LtoH1laTWg0VeSeKxuSJfte6x7
No92rI3Ux4F0xhONCFVcfl0S97ePZg= > and I Inserted is as transaction number 2, chaining it
to record 1 with hash < nmk8Ggv15rx0p5bYwFxPd5DZqqN9KVw3aLtYRsWcIkU >
And signs this message as
e3/jb5W5nNFJSZrYEUR+Aj+/94PiWooGgUQc3yurW9QgQ38reCuq1VQdEspuXaT7XHR9L
EMdxpw2jitXX4cqVUPIdevDsc1SHkyCpj0cw7CC8KJ4GqF2Wjz0KLWSUwb2yqyPgP7LA
FtIi8iWvolsE3KBfAyVhxPJPUlrKdQ8z8E=
What has happened now? The transactions are 'chained' together !!!
Not only are transactions 1 and 2 immutable. They are also linked together and as such the platform can
not alter the transaction number nor the transaction sequence in time. Nor can it add a transaction in-
between. The whole ledger has become 'immutable'
We will add some structure into the transactions later, but the principle should be clear
You can play around with signing and hashing using
http://trueandauthenticated.com/portal/Encryption/AsymmetricKey
Blockchain Discussion Paper
1
2 Page 12
Kurt Wayenberg
3.2 Putting the pieces together
And that's it - those are the basic ingredients to set-up a blockchain. We will now build up a new and
simple 'blockchain' or better a 'cryptographically secured ledger'. And we focus on integrating it with
current systems and business processes.
We will bring a bit of structure in managing the data and the signatures
And we will focus on integrating it with current systems and business processes.
But at first, we want to do some explicit modeling of the relations between parties and wallets. We also
will discuss whether or not to give up some anonymousness at the benefit of more usability and user-
friendliness...
3.2.1 Parties
If we learned something over the past 50 years in IT it is that the cornerstone of many systems is the
central party file. For organizations this has the form of a central customer file and a list of the business
partners. For government authorities the list is made up of citizens and registered companies. In the
blockchain and bitcoin community there were no formal parties. Only wallets. However, with every
transaction some of the identity is revealed as the sender of a transaction (hopefully) knows to whom
he sends some currency...
Party design principles that should be recommended to service provider and platform designers:
1. Put parties in the center of your registration process
2. Give parties a rich identity, a free string, even allow GUIDs (nvarchar 38)
3. Give parties a color code for easy recognition
4. Give parties a a QR code for easy administration
5. Allow multiple wallets to be attached to a single party
6. Rather than attaching private keys to wallets, attach private keys to parties and allow a party
to use his central key to sign transactions (at least by default)
7. Link user registration to 'new blockchain party' creation (at least by default as it should
also be possible to have multiple logons per party / company)
8. Decide on how anonymous a user can remain and decide on how to maintain its status:
Completely anonymous? email verified? SMS-verified? Confirmed by commercial
organization? Confirmed by institution? Self-checked?
9. Confirm transactions by emailing the inserted transaction to the party, together with a 'signed'
receipt
10. Creation of a party is a standard transaction on the blockchain.
11. On publishing a party, its public key gets published too
12. On publishing a party, the party gets automatically assigned a transaction balance wallet
13. A party is validated when all its wallets on the blockchain are validated. Keep track of its last
validation date-time.
3.2.2 Wallets
Wallets are the cornerstone of any blockchain. They are the address from and to an amount of currency
or information is transferred.
Blockchain Discussion Paper
1
3 Page 13
Kurt Wayenberg
How to validate the wallets is open to much debate. Pure blockchain validation (BitCoin) requires
redoing all transactions in order to determine the balance. Others (like Ethereum) store intermediate
state allowing for faster recalculation. The state, continuously changing, is maintained at the expense
of significant amounts of storage.
Wallet design principles that should be recommended to service provider and platform designers:
1. A wallet is attached to a party and this relation will never change
2. A wallet is attached to a blockchain and this relation will never change
3. A wallet is attached to the blockchain currency and this relation will never change. This is
important for managing assets.
4. Give wallets a rich identity, a free string, even allow GUIDs (nvarchar 38)
5. Give wallets a color code for easy recognition
6. Give wallets a a QR code for easy administration
7. By default keys are assigned to parties but when a seperate key is kept on the wallet, this key
must be used to sign transactions
8. All the transactions need to be signed using the (sending) party / wallet key (exception:
transaction administration and payments; these are added by the platform)
9. Keep a balance on the wallet
10. Creation of a wallet is a standard transaction on the blockchain
11. On publishing a new wallet, the 'owning' party and the linked 'blockchain' are also published.
12. A wallet is validated when all its wallets on the blockchain are validated. Keep track of its last
validation date-time.
3.2.3 Transactions
Transactions are the essence of any transaction system and as such of blockchains too.
The difference with these blockchain transactions is the usage of the hashing, the signing and the
chaining!
Transaction design principles that should be recommended to service provider and platform designers:
1. The transaction adds owning party, owning wallet, target party and target wallet, blockchain,
currency and amount as basic info (whenever relevant)
2. Every transaction keeps an owner reference which is a unique identifier for the owning party
and prevents double booking
3. Every transaction is chained to the previous one. The transactions maintain their 'location' in
the chain on three levels: platform-sequence, blockchain-sequence and owner (=party)
sequence. Because wallets are optional, do not maintain a wallet transaction sequence.
4. A transaction creating a new blockchain only specifies owning party, target wallet and target
currency
5. A transaction creating a new party is done by the System Account (either by self registration
or by a platform administrator)
6. A transaction adding information to the blockchain does only need a party, yet can specify
two parties as well as two wallets
7. A transaction transferring currencies always specifies both wallets as well as both parties
8. A transaction can never specify a negative value
9. A transaction cannot result in an overspent wallet
10. A transaction keeps a copy of the request and the requests signature
11. The request can be minimally specified (e;g. wallets only when transferring currency,
blockchain referred without currency)
Blockchain Discussion Paper
1
4 Page 14
Kurt Wayenberg
12. The request however needs to specify a date-time and this datetime cannot deviate
significantly from the platform's datetime or else the transaction fails
13. The datetimes of the transaction are the date times assigned by the platform, not the date time
specified in the request
14. A transaction is linked to the previous via a standard hash as well as a RTPL-hash
15. The transaction hash and RTPL-hash always include a transaction hash + an RTPL-hash of
the stored information too. When no stored information is added, use the hash string
VKkJezNPsTj7+V5/HI3ZhZQQQThRfVW6HLKqp7xgpP0= for the empty string and the
RTPL-string 29W2sjbS2If7cI/lJ2DYuuwhyANbrQRrLbtiUem/SJY= for the empty (0 length)
RTPL string
16. The transaction base description is also added to the database so everyone can easily verify
the hash at any time
17. For every transaction a transaction result out is created in the form:
<blockchainplatformsequence>-<blockchainsequence>-<ownersequence>:<transactionhash>-
<RTPL transactionhash>. By communicating this result, the platform basically recognizes the
transaction's existence, defines its exact position in the chain, makes all these transactions
immutable, and confirms their linking
3.2.4 BlockChains
As already discussed above. The illusion of 'one global blockchain' is completely dissolving. The open
question is what products will remain and in what form will they implement all kinds of use cases. The
only certainty is that there will be a lot of 'blockchains'
Countries will store there identity records in governmental ledgers
Assets and (notary) contracts will be stored by notary groups
Frequent flyer miles and other fidelity cards will be stored in the ledgers of the companies
issuing them
Et cetera for voting rights, energy/water/gas/ consumption, stock positions, energy
production, passages over toll-roads, our certificates / degrees / accomplishments / kudos /
contracts, jobs, paid taxes & social security, orders and deliveries, reservations
And in some cases transactions (or transaction summaries or transaction extracts) might be replicated
in multiple ledgers. e.g.
Countries might store (certain?) identity records also in pan-european or global ledgers,
Assets and (notary) contract summaries might also be stored on notary association ledgers or
government ledgers. ,
Frequent flyer miles and other fidelity cards might be of interest to industry groups
Et cetera for voting rights, energy/water/gas/ consumption, stock positions, energy
production, passages over toll-roads, our certificates / degrees / accomplishments / kudos /
contracts, jobs, paid taxes & social security, orders and deliveries, reservations
Blockchain design principles that should be recommended to service provider and platform designers:
1. Allow for multiple blockchains on your service platform
2. Give a lot of freedom in naming different blockchain, even GUIDS (nvarchar 38)
3. Assign an owner (party) to a blockchain
4. Assign (optionally) a payment blockchain and a payment schedule so that users of the
platform will need to pay a certain amount of cryptocurrency for every transaction they do. In
my opinion a transaction price should be fair, constant, deterministic and identical perhaps
with some variation on the type of transaction.
Blockchain Discussion Paper
1
5 Page 15
Kurt Wayenberg
5. Allow any party in the system (with the proper rights / funds) to create a blockchain
6. Allow (optionally) to assign a payment schedule so that users of this blockchain have to pay a
certain amount of cryptocurrency for every transaction they do. This can be used to back up
the transactional payment for platform usage
7. Link a wallet to one and only one blockchain
8. Only allow transactions between wallets on the same blockchain
9. Define a blockchain as either fluid or discrete ( for currency-like transactions respectivey
assets)
10. For fluid blockchains there is only 1 currency (the name is syntactic sugar) and wallets can
transfer anything between 0.00000001and 1000000000) to one another
11. For discrete blockchains the 'asset' is the currency and a wallet can either contain the
asset with an amount of 1.0) or not (amount of 0.0) by nature of the blockchain technology an
asset will also be posessed by one and only one wallet
12. Allow any blockchain to receive information posts as information
13. Creation of a new blockchain is a standard transaction on the blockchain
14. On publishing the new blockchain also publish the 'costing scheme'
15. A blockchain is validated when all transactions on the blockchain are validated. Keep track of
its last validation date-time.
3.2.5 Smart Contracts aka 'Batch Jobs'
I already criticized the sub-standard scripting environment like technology such as Solidity or other
'smart contract' technology.
In my opinion good old batch jobs can do a perfect job in this in that:
They can run online just on top of your blockchain
You can exploit good basic techniques like adding multiple transactions in one 'technical'
transaction
You don't need Oracles
What batch jobs however have to learn from 'smart contracts', is that they should be set-up in a sense
that it is easier and faster to add new logic... But that is just a matter of architecture and creativity. You
do not need 'Solidity' or other ill-designed, bug sensitive, scripting languages
3.2.6 to 'pay' or not to 'pay'
We already discussed the technique and process where one optionally account for transactions on the
blockchain. An advantage of 'accounting' for transactions is that Denial of Service attacks are either a
lot less effective or else a lot more expensive to conduct for attackers
Blockchain Discussion Paper
1
6 Page 16
Kurt Wayenberg
3.3 http://trueandauthenticated.com
Meet our crypto-ledger platform 'True And Authenticated' platform. So far it still is a 'discussion' and
'try-out' platform. But it is very successful in its purpose.
At the end there are some suggestions on how to get your use cases entered via manual registration or
via upload using Excel.
When facing issues please contact [email protected]. When having questions on how to
optimally model your use case please contact [email protected].
3.3.1 Users
The simplest way of getting started is by using one of our test users.
The full experience obviously comes with self-registration
3.3.1.1 Test-users
To use a test user, use the following steps:
Open a browser and go to http://trueandauthenticated.com
Click LogOn
Enter a user name. There are 31 users to pick from. Use the n'th user where n = your birthday
- day index.
o Mike Mukesh Amy David Sachin
o Mariano Peter Manoj Meg Robert
o Skreekanth Pierre Marilyn Bill Michael
o Eric Stephen Howard Dan Maruf
o Jo Seelan Eugene Troy Art
o Kurt Nick Sven Erich Nicolas
o Gijs
Enter the password. All test users have the same password:
o DXC.R0CK5 (with a zero)
Blockchain Discussion Paper
1
7 Page 17
Kurt Wayenberg
You are now in the trueandauthenticated application
3.3.1.2 Self-registration
Appendix A, chapter 1 gives some details on how to self-register yourself on the new platform
The basic steps are very straightforward:
Go to http://trueandauthenticated.com
Cick on the Register link
Enter your data
Submit
An email validation email is sent and after clicking on it, your account will be upgraded to an
'email verified' account.
You now are a registered user, and a blockchain party was automatically created.
When doing self-registration and a valid email was available, there are some advanced steps that might
be of interest that more or less catapults you directly in the blockchain discussion: You can fill in your
basic information (Address information) and then publish it in combination e.g. with your SSN/RRN id
Blockchain Discussion Paper
1
8 Page 18
Kurt Wayenberg
or your driver’s license and then publish it in the blockchain. You now can prove that you are (linked
with) this account.
The steps are:
Open your profile (link on top or via menu)Complete your address data
Enter your address information
Enter your SSN/RRN id or your driver’s license
Save your information
When now checking your SSN/RRN or drivers license information there are some options to
put this information on the encrypted ledger.
Submit both of them
Use the hashing tool to verify your information hash and understand why the hashing is an
adequate proof that you own this information
3.3.2 Parties
By clicking on My Blockchain Party (on the main menu) the party information window opens
This gives you access to the party info (1), the wallets (2) and the encryption keys(3)
3.3.2.1 Searching Parties
To see other parties, one just clicks the 'search blockchain party' information
Another possibility is to just paste the following JSON call in a browser
Blockchain Discussion Paper
1
9 Page 19
Kurt Wayenberg
http://trueandauthenticated.com/portal/Api/FlexibleReporting/RPT6702?Identity=&SecurityToken=G
Bc6CT4lPdMiOVCYdOvMbsrH2nuRQ3pSrf1iaM7A8aM%3D
The JSON call allows to get all this data in an electronic form. It is also quite handy to be viewed in a
Firefox browser....
At this moment, we .allow all users to view all party (and wallet) information in the system. Obviously,
by using permissions the access can be more limited.
3.3.2.2 Setting the party's mail address
There are 2 pieces of Party information for which an update can be interesting.
By adding a mail address, you get a confirmation by email on every transaction done by this Party
You can also clear the security kays keys and add your own keys. Or you can just enter your public key
while keeping your private key 'private'. This is interesting especially if you use the application out of
your own application (using SOAP) or via your smartphone application (using JSON-services), but you
can at every submit add sign the transaction yourself
3.3.2.3 Looking at My-Party
Inspecting your 'Party' information is straightforward:
Go to the main menu
Click 'My Blockchain Party'
You can now see:
o your party identification
o the QR-code
o the default wallet for 'paying' transactions (currently new parties get by default a
budget of '500' worth of transactions)
o your other wallets (if available)
o your public and private key
3.3.3 Wallets
To see your wallets, just clicks the 'my Party' link
There is no online screen to see all wallets. However, searching for a specific wallet is possible via the
Search Party screen. This retrieves you the owning party. In its wallet overview you than should see the
wallet you are looking for.
One possibility to get access to all wallets is to just paste the following JSON call in a browser
http://trueandauthenticated.com/portal/Api/FlexibleReporting/RPT6703?BlockChainCode=&Currenc
yCode=&PartyIdentity=&WalletIdentity=&SecurityToken=ssIVBUoHyR5SFf32IsUeq4iPH11GVJxn
hXiF%2BHM%2FLFI%3D
Blockchain Discussion Paper
2
0 Page 20
Kurt Wayenberg
The JSON call allows to get all this data in an electronic form. It is also quite handy to be viewed in a
Firefox browser....
At this moment, we allow all users to view all wallet information in the system. Obviously, by using
permissions the access can be more limited.
3.3.4 Transactions
Transactions are the essence of our cryptographic ledger
The type of transactions are
Blockchain creations (Blockchains for assets, for currencies or for registration
Party creations
Wallet creations and initial balances
Registering text (public or private)
Transferring currencies or assets
Depending on the transaction type, the transaction defines owning party, owning wallet, target party
and target wallet, blockchain, currency and amount as basic info. The schema underneath details the
possible combinations
Creating a transaction is just a matter of filling in the corresponding fields.
Blockchain Discussion Paper
2
1 Page 21
Kurt Wayenberg
When submitting the transaction, it has to be signed by the owner's private key. In that way nobody can
dispute it's content, nor its initiator.
When adding the transaction to the database it is linked to the previous transaction,
The inserted transaction (location + transaction hash) is returned to the submittor thereby giving the
submitter a proof of submission that the platform will never be able to deny.
3.3.5 Full Example: The 'Kudos' use case
The best way to get a clear understanding on how it all comes together, we explain a simple but very
nice use case. The use case was defined by Mariano Silva (Chile) ([email protected]). He
presented his idea on our global DXC-blockchain community (to join this community contact
[email protected] - US)
Mariano Silva had a full range of suggestions but basically speaking it boils down to the following
simple process:
Employees get a number kudos
When employees are happy with some service, they send a colleague a number of kudos to
thank him
Your balance of received kudos is used to pay out some financial reward
This process of gamification of commitment, motivation and remuneration should be yearly
repeatable
Let's see how we can capture a great part of this use case in a crypto ledger solution using our portal
solution. The use case is uploaded so it can be easily expected online.
3.3.5.1 Step 1 Create the blockchain
The person creating the blockchain is the administrator for the blockchain.
As such Mariano is the one that should create the BlockChain.
The transaction underneath is the way how the Kudos blockchain is created.
The XML representing this transaction is as follows:
Blockchain Discussion Paper
2
2 Page 22
Kurt Wayenberg
After submitting the transaction, the blockchain is created!
3.3.5.2 Step 2 Create the Wallets & set the initial balances
Mariano now creates a wallet for every other person.
In the transaction underneath Mariano is initializing a new wallet for Mike and initializes it to 100
kudos:
The XML representing this transaction is as follows:
And this is repeated for every person
For a better administration it is better to assign a different wallet for receiving the kudos. So Mariano
just repeats the same exercise and gives each person an extra wallet yet with a zero balance
3.3.5.3 Step 3 Creating transactions
Every one can now send Kudos.
In real life we would avoid working with the complex identities and we would hide them behind some
meaningful names. In the test application we added some 'friendly names' to the identities for kudoo
blockchain, parties and wallets.
Blockchain Discussion Paper
2
3 Page 23
Kurt Wayenberg
The example underneath shows the transaction where Kurt sends over 5 Kudos to Meg
The XML representing this transaction is as follows:
When entering the transaction, it get signed:
With each entry in the ledger, a confirmation email is delivered too:
Blockchain Discussion Paper
2
4 Page 24
Kurt Wayenberg
3.3.5.4 Step 4 Checking the balances
You can check your party and its wallets. Every wallet shows the balance.
Via search party one can access other parties and wallets.
Another way to access the parties and the wallets is by just clicking the parties in the
transaction overview
3.3.5.5 Step 5 Checking the transaction
You can now go to an overview of the transactions and open the last transaction that is added.
All detail of the transaction can be verified: The owner-info, the target info, the request and its signature.
Blockchain Discussion Paper
2
5 Page 25
Kurt Wayenberg
An interesting tab is the chaining tab (see above)
It shows:
The hash (and RTPL hash) of the previous transaction
The summary of this transaction containing
o The previous hashes
o The transaction data
The newly created hash (and RTPL hash) effectively linking both transactions
The proof info is the result delivered by the platform. The first part is the sequence information of the
inserted transaction (nth Tx on the platform, n2th Tx on the blockchain, n3th Tx by the owner) and the
hashes.
Blockchain Discussion Paper
2
6 Page 26
Kurt Wayenberg
The second part is the signature of this result
3.3.5.6 Explicit Signing
In the section on blockchain parties it was shown that each party had both a publik key and a private
key. The private key was stored in the database (in an encrypted form) and all signing was 'implicit',
meaning that the platform took the party's key for signing transactions.
Now consider user Troy. He does not keep his private chain in the application. If he tries to submit a
transaction he gets the error:
Parameter User Block Chain Party is not specified Please enter private key pair or sign the data
yourself
And he gets presented a screen where he can either put its private key in (the key is used for signing and
not stored in the platform) or he can sign himself (either as described further in the paper or by just
using the signing functionality
For example via the sign-functionality:
Blockchain Discussion Paper
2
7 Page 27
Kurt Wayenberg
Obviously, when you do not store your 'private key' in the application (out of principle, or
because you do not trust the system, or for whatever reason), you should not pass it to the
system either to help you with signing. Instead you should use some commercial or own-
developed application (as long as it is trusted) to sign your transaction, and then you only
should pass the signature.
The code underneath lists the 'signing' code. It can be freely integrated in your own applications
Integrating it into your applications can be done via a number of channels. The 2 most important
ones are via SOAP 1.1 and via JSON (Java Script Object Notation).
SOAP 1.1 is particularly popular in integration with classical platforms.
JSON is especially popular for integrating mobile applications. Karl Verstraelen (Belgium) dDid an
end-to-end integration-POC with the platform on a mobile application. The essentials of his
solution are:
Private key is kept and stored on the smart phone
The signing is done on the smartphone more or less as described with the signing code above
Submitting the transaction is done over JSON.
Blockchain Discussion Paper
2
8 Page 28
Kurt Wayenberg
The POC was created with XAMARIN forms. A few screen shots can be found underneath:
Another technique that can be used are XML streaming but this approach is not dicussed in this paper.
3.3.5.7 Conclusion
So do blockchains then fix it all?
Well, it should be clear that blockchain-like platforms are a very nice solution to get
currency-transfer-like use cases up and running quite fast. At the same time data
immutability is added to the register leading to an out-of-the-box realization of
dispute resolution.
However, we still need business rules and application
intelligence especially when your concept turns into a real process.
Suppose we start to give 'financial benefits' based on the kudos in your wallet and how
well one participates....
Blockchain Discussion Paper
2
9 Page 29
Kurt Wayenberg
That might trigger unwanted behavior which should be managed, either in the application or
in the process. i.e.
What if people grant them selves their kudos?
What if people / teams start ping-pong-ing (resending) kudos to one another? It might
not affect the balance but the team might get kudos because they send so many
kudos...
What if people accidentically use their received kudos rather than their kudos for
sending?
Is it ok that someone transfers all his kudos to someone else and ask that person to be
Santa Claus?
etc...
As said, you get a jumpstart, but you still need to make it a real application
Blockchain Discussion Paper
3
0 Page 30
Kurt Wayenberg
3.3.6 Access via SOAP V1.1 XML (classical applications)
For integration over SOAP 1.1 you need to discover the structure using the Web Service
Description Language (wsdl) describing the web service defined at:
SOAP http://trueandauthenticated.com/DXC_Portal_WebServices/PortalServices.asmx
Once you created the stubs in your application and you created the string to be signed the code is pretty
straightforward:
3.3.7 Access via JSON (mobile applications)
For integration via JSON, you need to start from the web api at:
JSON http://trueandauthenticated.com/portal/Api/PortalBlockChainSOAP
http://trueandauthenticated.com/DXC_Portal_WebServices/PortalServices.asmx
Once you created the string to be signed the code is pretty straightforward too:
Blockchain Discussion Paper
3
1 Page 31
Kurt Wayenberg
3.4 Examples and use cases
The previous chapter discussed in quite some detail a typical example of transfer of crypto currencies.
There are lots of other use cases imaginable. In this section we discuss a number of them. Livestock
management, Energy companies, Notary organizations, Voting,...
We do have available an extensive use case around payments and around integrating payment
information crossing different 'ledgers' but discussing this one in detail is deemed inappropriate for
this discussion paper.
3.4.1 Livestock Traceability
A possible way to set-up a cryptographically secured ledger could be as follows. Remark that any
similarity with an existing, good working system is purely coincidental.
3.4.1.1 Parties
A prerequisite in getting good traceability is defining all players in the food chain. i.e. all organizations
and their roles in the food chain. This role can be all kind of roles like farmer, dealer, cattle assembly
place, transporter, market, and slaughterhouse
Suppose we give all parties a Party-Identity and a key-pair. Whether or not we maintain a company
'profile' in the blockchain or in our classical applications is for now irrelevant.
Let's give the parties an identity like CC1234567X with CC a country prefix, 1234567 a number
identifying the party and X a control digit to avoid manual errors
3.4.1.2 Moving individually tagged Livestock around
In Europe all Bovines are individually tagged and we can reuse their earmark identifications. Their
structure is CCX123456789012 with CC a country prefix, 123456789012 a number identifying the
animal and X a control digit to avoid manual errors
3.4.1.2.1 Ownership
We set-up an asset Blockchain with each 'Animal' as a possible 'Asset' (currency). Every farmer receives
for every owned animal a wallet on the Bovine ledger with as asset (currency) the owned asset.
A 'transfer' of an animal ownership can now be easily done by transferring the asset to the new owner
(another farmer)
Advantages for the food chain:
The ownership of an animal is at al moments crystal clear and cannot be claimed nor denied
As part of the standard receivable process information of the transfer is confirmed by mail
If the current owner does not wish to finalize the administration he can give the private key of
the animal wallet to the new owner so that this one can do it himself, probably as fast as
possible as you never know who else receives the private key
The animal ownership history in time is transparent and it is guaranteed that the information
has never been tampered with.
Blockchain Discussion Paper
3
2 Page 32
Kurt Wayenberg
There is no dispute possible whether the mentioned events / actions have been taken place in
the specified form on the specified date
3.4.1.2.2 Whereabouts
Whereabouts are a bit more difficult to organize. One could set up a complex scheme of wallets but as
whereabouts information is less formal one might consider to just set-up some information scheme. e.g.
We set-up an Animal Information Blockchain, this time with each 'Animal' as a possible 'Wallet'. Every
party registers the whereabouts of this animal depending on his role. The ledger for animal
CCX123456789012 might look like
PARTY DATE EVENT
FARMER1 DATE2 OUT
FARMER1 DATE1 BORN
FARMER2 DATE3 IN
FARMER3 DATE4 IN
FARMER2 DATE5 OUT
MARKET1 DATE6 IN
MARKET1 DATE6 OUT
SLAUGHTERHOUSE1 DATE7 IN
This information approach can be extended to various other approaches. I;e. Registration of other
animal information like:
Veterinary actions
Diseases
Inspections
Slaughtering observations
...
The advantages for the food-chain are:
Complete traceability where an animal has been
All information at a glance
The actions might serve as formal reminders of batch process actions that need to be
taken The animal ownership history in time is transparent and it is guaranteed that the information
has never been tampered with
There is no dispute possible whether the mentioned events / actions have been taken place in
the specified form on the specified date
3.4.1.2.3 Import / Export
In fact the platform scales perfectly to any chosen level
1. One blockchain used by all countries in the food chain
2. One blockchain used by a number of countries in the food chain
3. One blockchain per country
Blockchain Discussion Paper
3
3 Page 33
Kurt Wayenberg
4. One blockchain per region
Obviously in cases 1 & 2, it is clear that either one of the countries or otherwise an independent platform
provider needs to host the blockchain for a defined period of time
In cases 1, 2 and 3 some clear arrangements need to be made for import and export of animals and the
equivalent transfer / sharing of these animals
The advantages for the food-chain are:
Imports and Exports totals as well as details open and transparent
Information can be trusted and has not been tampered with
There is no dispute possible whether the mentioned events / actions have been taken place in
the specified form on the specified date
3.4.1.3 Moving herds around
Tracing herds is a bit different than tracing individual animals yet there is a lot of similarity
Per type of animals (goats, sheep, pig, ,...) a blockchain is setup. Every party keeping herds of this type
of animal receive a wallet initialized with the initial count of the numbers of animals. Once the
blockchain is initialized, the business as usual state can be achived:
Numbers of animals that are moved to a herd of another party are simply registered
New-born 'notifications' or population 'adjustments' make sure the number of animals in the
chain is tracked.
Information as above (veterinary actions, diseases, inspections and slaughtering observations
can be easily added on the herd wallet
The advantages for the food-chain are:
All animal numbers in and out are tracked
Running totals of the newborns still can be verified based on earmarks
Whereabouts of (parts of) the herd are visible at any moment in time
Special 'quality meat' can be traced that livestock is only traded between parties having that
special label
Animal movements and information is transparent and it is guaranteed that the information
has never been tampered with
There is no dispute possible whether the mentioned events / actions have been taken place in
the specified form on the specified date
All information readily available at a glance
3.4.2 Energy Companies
Energy companies have a few challenges today. Especially with green-energy certificates, solar panels,
group-investments, et cetera, some interesting developments take place
Crypto ledgers can again be of great help here.
This is how it could be set-up on the consumer side:
Blockchain Discussion Paper
3
4 Page 34
Kurt Wayenberg
Every energy supplier has a blockchain to measure the consumption
Every period (15 minutes? hourly? daily? weekly? monthly?) the consumption is registered
Every period (15 minutes? hourly? daily? weekly? monthly?) the production of solar panels is
registered
Per group investment (set of solar panels) a blockchain is set-up
The blockchain defines the percentages how the gains should be divided
A simple batch job takes the periodic production result and distributes the green certificates
pro-rata to the 'owners'
Advantages for the energy market
At any moment in time full transparency is offered about how production of the solar panels
are distributed to the stakeholders
Green certificates can be transferred (sold) to other persons/wallets opening up a new
produced energy market
Participation can be altered as apartment owners transfer their part to new apartment owners,
or others.
There is no dispute possible whether the mentioned events / actions have been taken place in
the specified form on the specified date
This is how it could be set-up on the producer side:
Every energy distributor has a blockchain to project its expected consumption. They have one
wallet for every 15 minutes. And this for today, day+1, day+2, next days in week, next-days
in month(s)
Energy suppliers can offer their production volumes at a certain price
Contracts are formally accepted
Every period (15 minutes? hourly? daily? weekly? monthly?) the consumption is registered
Every period (15 minutes? hourly? daily? weekly? monthly?) the promised production is
registered
Every period (15 minutes? hourly? daily? weekly? monthly?) the realized production is
registered
A simple batch job takes the periodic production result and creates invoice-read summary
records.
Advantages for the energy market
At any moment in time full transparency is offered (to people who have access to the data) in
any status (projected, delivered, invoiced)
There is no dispute possible whether the mentioned events / actions have been taken place in
the specified form on the specified date
3.4.3 Notary organizations
Without any doubt, the impact of blockchain probably on this market will be dramatically. For
document-based administration (testaments, patents, certificates, degrees, job-history ...) the set-up is
straightforward:
Set-up a blockchain
Publish Texts and/or hashes of text
Optionally include person references in your content*
Blockchain Discussion Paper
3
5 Page 35
Kurt Wayenberg
Optionally have impacted persons confirm the content*
Advantages for the community:
Basically any person can put a piece of text in the blockchain
Adding it to the ledger makes its content immutable
Adding it to the ledger also sets its timing correct
The signature makes it clear; it is signed by the issuer and hence indisputable
Taking a hash from an image (ppt) and adding the hash into the ledger makes the image
immutable
Taking the hash of a set of legacy-db-records and adding the hash into the ledger makes the
set of legacy records immutable
For asset-management the basic set-up is slightly more complicated, yet it remains easy to manage
Define a blockchain with a 'currency' for every asset
Define the persons and their identities*
Assign a wallet with the asset as currency and a quantity of 1.0
Asset transfers is just a matter of transferring the asset to another party
The owner of the blockchain is the one introducing new assets if needed o
The owner of the blockchain is also the one intervening (e.g. how do you transfer a house
when the owner died).
Advantages for the community:
The community can self-manage its assets and asset transfers
Ownership is clear at all times, ownership trails are visible by default
There is no dispute possible whether the mentioned events / actions have been taken place in
the specified form on the specified date
* By far, identity management and key management, remain the cornerstones of any ledger solution
3.4.4 Voting
Voting and Elections
In essence this is a dream-use-case for cryptocurrency albeit that some tricks are needed to guarantee
the privacy on who voted for who.
First the basics:
Blockchains are set up for every 'election' (i.e. a blockchain for each local election on city
level up to 1 blockchain for e.g. the European elections
Each 'party' is a party in the system and per 'election' receives a wallet for the party in general
and/ or for each electable person in particular
Every citizen receives a voting wallet for each election in which it is allowed to participate
Every citizen can now place it's vote
Advantages for the community:
Blockchain Discussion Paper
3
6 Page 36
Kurt Wayenberg
Every citizen has one vote, and one vote only in each selection he can participate in.
Out of the box blockchain behavior would be that he can give to transfer this vote to 1 wallet
or to multiple wallets (even over the different parties). Probably some business rules will be
necessary to make choices between the wallets
All votes are non-disputable
It is clear who has not voted
The results cannot be disputed
The problem with the basic set-up is that the voting is not private. Everyone can see who voted for who
In order to fix this. It is necessary to do some extra steps. The choice is whether or not you 'hide' the
election result (encrypt it) but keep full traceability or whether you take some more drastic actions to
maintain the privacy with the risk that e.g. the 'traceability' / 'guarantee' has some holes. Techniques
are:
Encrypting the voting results and inserting them with a hashed key in a format which apart
from a period indication has no time available indicating when a certain vote has been added
so it cannot be linked to the voter
Every 10 minutes the available votes of that past set of 10 minutes is cryptographically
signed. The ledger now is immutable again.
The time in between has a potential for tampering on a selective set of votes for a selective
amount of time but that is the price for privacy
3.4.5 Fidelity points, Mileage, 'Hours used' and other cryptocurrencies
Cryptocurrencies are very natural use cases. Any 'measurement' can serve as cryptocurrency 'valuta'
ranging from hours parked, material consumed, to fidelity points earned or kudos given to other
colleagues
The set-up again is basic and simple
A blockchain for the cryptocurrency
The involved parties and their identity
A wallet for the owning parties initialized with an initial balance
Transactions are but a transfer of a certain amount of currency from one wallet to another
Advantages for the community
The community can self manage its wallets
currencies, kudos, fidelity points by default also can be freely transferred to other persons
(e.g. to relatives)
There is no dispute possible whether the mentioned events / transfers have been taken place in
the specified form on the specified date
Balances and totals visible at any time
Blockchain Discussion Paper
3
7 Page 37
Kurt Wayenberg
3.5 Some final design decisions
3.5.1 Anonymity
A new account is created by self-registration or by a platform administrator. There is currently a lot of
freedom and it might be sometimes difficult to balance between anonimity and privacy. We do think
this point should be looked at on an application level.
3.5.2 Privacy
As discussed in the previous section, it might be sometimes difficult to balance between anonimity with
privacy. As sayd, we do think this point should be looked at on an application level. In addition, there
is the GDPR guideline to be conform with. The GDPR guidelines as followed in this application can be
consulted via this
link: http://trueandauthenticated.com/Portal/nl/Information/Content/DATA%7CGDPR
3.5.3 The Distributed / Decentralized Autonomous Organization / Company
Until recently, the idea lived that one 'blockchain' would solve all business problems, and that everyone
would participate, yet that no one would be the ‘owner’ of the blockchain. This bubble of the distributed
autonomous corporation / decentralized autonomous organization is splashing. Where is the concepts
failing?
Besides the negative ecological impact of the economic model/mining and the impracticality
of distributed consensus, the simple distributing, sharing & storing of data over the
blockchain nodes has hit multiple technical boundaries, making the concept unworkable and
also terribly expensive from a total cost of ownership (hardware, software plus technical staff
and administrators)
The solution is very hard to scale. End of 2017 the total size of the top 3 blockchains (Bitcoin
+ Ethereum + Ripple(XRP)) represented less than 200 GB of storage -- resp. 150 + 32 (if state
history is pruned away) + 4 (#3 is already a lot smaller). 200 GB of storage is 40% of an
average hard disk or worse, is an average SD card for mobile-phones. The energy
consumption to keep this marginal ‘hard-disk’ operational in 2017 transcended the yearly
energy consumption in some countries in Eastern Europe...
Three thought experiments tell it all :
o Thought experiment #1: In 2014, the internet was estimated to be 10^24 bytes =
2000000000000000000 hard disks (https://www.livescience.com/54094-how-big-is-
the-internet.html). So even if I we could start ‘blockchaining’ and ‘uploading’ 60000
hard disks per day (= 1 hard-disk per second added to ‘the blockchain’) it would take
over 60 million year to finish that job. And then we only captured the internet
information in 2014. We are 2018 by now. So dream on that ‘one blockchain will rule
the world’…
o Thought experiment #2: 10-15 years from now we all will have dozens of blockchain
wallets: our identity records, our assets and (notary) contracts, our frequent flyer
miles and other fidelity cards, our voting rights, our energy/water/gas/ consumption,
our stock positions, our energy production using green technology, our passages over
toll-roads, our certificates / degrees / accomplishments / kudos / contracts, mortgages,
our jobs, our paid taxes & social security, our orders and deliveries, our reservations
and even our last will. So how will that all work? Will all ++7.6 billion of us have
dozens of blockchains to manage? Will we turn to trusted organizations and pay them
to run all these blockchains for us? Or will we just use urls URL’S (organizations /
Blockchain Discussion Paper
3
8 Page 38
Kurt Wayenberg
institutes that are here today and open up their portals) just as today, except that the
services offered by these portals/URL’s are cryptographically secured by then?
o Thought experiment #3: Suppose something goes wrong, terribly wrong, for hours,
for days, for weeks. To whom do you turn? For help? For complaints? For
compensation? How do you organize insurance in this context? A considerable
problem in a decentralized / distributed structure ‘everyone is responsible’ but
‘nobody is accountable’. This problem easily outshines other problems like
effectiveness and efficiency costs. It is the worst nightmare when things need to be
fixed.
Now, whatever the outcome and future of these overhyped products and technologies, the most
important point is that the game hás changed.
Today we demand from service providers and platform responsibles a lot more transparency, the usage
of mechanisms to cryptographically secure the data, the access by auditing authorities to check if the
data cannot be tampered with, etc…
Blockchain Discussion Paper
3
9 Page 39
Kurt Wayenberg
3.6 DXC.Portal Prototyping Platform
Our DXC Portal solution brings a full portal solution as your baseline for prototyping your [blockchain]
project requirements. It is only when designing Crypto-Ledger solutions that people start to realize the
impact on systems design. Let's study the difference between the classical and the new approach by
means of an example in the 'Energy market'.
Classical approach (aka Old way)
o Define the entities: Energy providers, energy production equipment, energy
consumers, group purchase, participation, production certificates, energy regulatory
authority,…
o Define the relations: energy consumers consuming energy from energy providers,
participants are energy consumers working together in a group purchase
o Define the transactions: register consumption, register production, distribute
certificates according to participation
o Build Db, build screens, prototype application, re-build, iterate
Crypto-ledger / Blockchain approach (aka New way)
o Define the parties: Energy providers, energy consumers, energy regulatory authority,
…
o Define the wallets: produced energy, consumed energy, participation, the sun
o Define the transfers of crypto currency energy: production equipment energy
(production every 15 minutes, daily division of certificates between participant)
o Upload in blockchain via excel tool, discuss and refine the concepts
The solution and approach is backed by a community of business experts. They bring to the table:
Business Expertise
Blockchain Expertise
Proprietary Model
Coaching Model
Train the Trainer
Development Individuals
In addition, base implementations and discussion models exist for a number of already 'prototyped' use
cases
Transfer of fluid assets
Consumption
Voting
Registration of public and private information
Text and documents
Track and trace
Asset management
Payments & Positions
Integrating multiple ledgers
Blockchain Discussion Paper
4
0 Page 40
Kurt Wayenberg
3.7 DXC.Portal Development Platform
Our DXC Portal Technology is a lot more than just blockchaintechnology: It is a platform for building
enterprise applications and has the following strong points:
Used, Stable, Efficient, Secure, Auditable
Rapid development and deployment
As stand-alone portal or integratable with legacy or COTS applications
Migration & Integration of existing ledgers
Zero license costs
DXC Open source
Development community
To learn more about the technical aspects, please consult the documentation on Architecture, Security
and Hosting, System Design And Development, Database Standard, Unit / Integration Testing, Best
Practices and Code Analysis.
To learn more about some horizontal business functionality, please consult the documentation on
Internet of Things, Decision Tables, Workflow, Reporting and GDPR.
The documentation can be accessed via the default menu (lower side information links)
Blockchain Discussion Paper
4
1 Page 41
Kurt Wayenberg
3.8 .Net DXC Crypto-ledger: Value Proposition
As a conclusion of this chapter we try to summarize the advantages of the .Net DXC Crypto-ledger:
Value Proposition in terms of 3 main benefits: It can help with assessing opportunities, it gives a major
jumpstart in application build, and it guarantees stability and performance regarding he application run.
The value proposition can be summarized as follows:
Opportunity Assessment
Identify, discuss and prototype blockchain opportunities with customers
Structured facilitation of audience
Identify quick wins, business case driven
Blockchain / Crypto consultancy
Application Build
Quickly deploy new solutions
Agile methodology
Rework existing solutions
Start small (POC), then expand
IP is with DXC
Leverage of existing code / assets
Application Run
24/7 proven, stable and performant
Compliant, secure, documented and auditable
Multiple hosting models
Multiple service models
When having questions regarding 'Opportunity Assessment' , please contact [email protected]
When having questions regarding 'Application Build' or 'Application Run', please contact
Blockchain Discussion Paper
4
2 Page 42
Kurt Wayenberg
Appendix A: Additional documentation on
http://trueandauthenticated.com
User Registration Process
Identity is one of the building blocks in our modern society. Without going into debate on all different
possibilities. Passports, electronic identities, bank cards, hardware tokens or [software] certificates or
without discussing about passwords, public and private keys, biometrics, n-factor authentication, etc...
So our solution also has a default basic user / identity management. It can be replaced by / integrated
with whatever solution you currently have implemented, yet for a matter of discussion or prototyping
the out of the box solution can be very useful. Especially when your solution needs to be open to user
groups currently NOT in your identity management system: suppliers, partner / customer companies,
(self-registering) end-users Á communities...
So find included a description of the out of the box user management process
1 User registers and gets a blockchain account
Account has been created
And user gets an account including a blockchain account and has status registered and can do a number
of things
Blockchain Discussion Paper
4
3 Page 43
Kurt Wayenberg
2 Upgrade the user account
So far one can work with the account anonymous. You can enter bogus data, a fake email address etc...
User can update that information as he gets more trust in the system, or if he wants to unlock more
functionality
It is only when your public information is filled in (last name, first name, street, zip, country) and when
the email is verified that your profile becomes public
User can issue an email verification (read: upgrading the account / going for full activation) by hitting
the upgrade account button
3 e-Mail Verify the account
A mail is send to the email account to verify the email
Status is now email verified
And the user can start filling up his ‘personal data’
Blockchain Discussion Paper
4
4 Page 44
Kurt Wayenberg
4 Advanced verification of the accounts
Based on the user data to be filled in, a registration in the blockchain can be initiated
There are 4 icons:
An action to get the string data as if it were to be put on the public blockchain: The string is:
o <Tx><LastName>Wayenberg</LastName><FirstName>Kurt</FirstName><Street>
Veldstraat</Street><HouseNumber>99</HouseNumber><Zip>2570</Zip><City>Du
ffel</City><BlockChainParty>99e7eac9707c499782fef562bf8e1502</BlockChainPa
rty><650526 421 37></650526></Tx>
The transaction to put publicly it on the blockchain
An action to get the string data as if it were to be put on the public chain: The string is:
VfgQycwzMKCA8I6S5rQQVaJ+4Es=
The transaction to put privately it on the blockchain
Blockchain Discussion Paper
4
5 Page 45
Kurt Wayenberg
Saving the tx gives an entry on the blockchain. The ‘public info’ is now validated and proven
5 Future extensions
Currently it is proven by logged on party and there is no logic yet as to the quality of the approvers or
to what the status of the user is following some approvals.
However, for starters… There is some status field that can be maintained…
Blockchain Discussion Paper
4
6 Page 46
Kurt Wayenberg
Appendix B - Asymmetric Key Pairs
John Doe Private key
<RSAKeyValue><Modulus>p7J7PVqyPEpiGKL++i8ptVMQD5oBiV0e06T7NW3uaTy3CaufluPnzAl8AlpKB0rV+LU/oA
Z7qQAcbRTLJJbjcXYa3ciaasWv44DU53QIb/aHnkmB8RPFbizCrlUIR0f0iGijYDz/2DSRkeBVJXbF1+l0VBKTlgt2uLbh8
riAB38=</Modulus><Exponent>AQAB</Exponent><P>6Lyvf+F5/0BtDYOtQwxscwL9bSfyS5zM7zT5icKsJM6lHHj1tzA
PuS14OtHmcOoihwLSXvCG7MH+dvsmwBDUkw==</P><Q>uHWLi3P9APzWhYQkghiVcao1O11ZPYKFMMccFRySQ
3bhXfv+85PcRqw5M21njdWKO71YeNpKJ+GKzE92bNKg5Q==</Q><DP>vGoEqkKfwUUnBAnV+rHUGkgRYo00WoJ
WZlE8s4omUqX4hVRnmCYQlJl6/CNxq3fg++wM409V69Yha7FnbZYygQ==</DP><DQ>oZz7YneBWHguTFT217VKW
ohSk2y6X5YXtCD/jc+2pr1lv76mJiuKd7E1fMWCUVajAqxm85vuFPsbbN7CV55DsQ==</DQ><InverseQ>MQf+4ISm4h
8JbR3xCVfJ39Suv2eFe8MaFIg0u25NLhocRqJcxbFx1wCCtlK6aXtpfBPMD24viVOnii8Dh0Hy8g==</InverseQ><D>HoO
OgzJ+nhPW167JAJMWXsUXdg9K2kjUdCRgBW/UYtfGYn8VEeq0Yd8T7oWpVLxcRN4ODrs/QxgfFAYllKnUBqRSFF
KmOkkiO1GU8K4a+gtLmCv57NFWumHkvSLgQpoZCRvi3HYGa0uIbdG0gbl4Pd/UBnCI2bYj5U1+KvW1bqk=</D></R
SAKeyValue>
John Doe Public Key
<RSAKeyValue><Modulus>p7J7PVqyPEpiGKL++i8ptVMQD5oBiV0e06T7NW3uaTy3CaufluPnzAl8AlpKB0rV+LU/oA
Z7qQAcbRTLJJbjcXYa3ciaasWv44DU53QIb/aHnkmB8RPFbizCrlUIR0f0iGijYDz/2DSRkeBVJXbF1+l0VBKTlgt2uLbh8riAB38=</Modulus><Exponent>AQAB</Exponent></RSAKeyValue>
System public key
<RSAKeyValue><Modulus>xssq6jvpJTUvwBGnYNnAEenShaBZqBwArxjScI/+jYUoXousTAzs2lNnbR0yxvnNl08qWttE
92WCk+qVlNWRHGD1eB8AtzbEK28lVCWuT32bT6QOwhuxMITubntlC7BU/ODU6tcigAqDimZ2hj6FajIYgiZl3WGSywqmJ8eEml8=</Modulus><Exponent>AQAB</Exponent></RSAKeyValue>
Jack Doe Public Key
<RSAKeyValue><Modulus>kDPN9LYmUATkYKASDyebF7OQ5K7+goJ1q2xRAtO1/eFM+UJ1WmQzII9FriU5SFfJ4p5
X8rqoEDFtUCpVeM/bu3xwJRtJcGJiYoVSAo7h14ShTZUSOw2b0OTAJJLGwVTKApMihuxGnsdgVpeb6/043iwgX6SLV
FlcH7d5LyATCfE=</Modulus><Exponent>AQAB</Exponent></RSAKeyValue>
Jack Doe Private Key
<RSAKeyValue><Modulus>kDPN9LYmUATkYKASDyebF7OQ5K7+goJ1q2xRAtO1/eFM+UJ1WmQzII9FriU5SFfJ4p5
X8rqoEDFtUCpVeM/bu3xwJRtJcGJiYoVSAo7h14ShTZUSOw2b0OTAJJLGwVTKApMihuxGnsdgVpeb6/043iwgX6SLV
FlcH7d5LyATCfE=</Modulus><Exponent>AQAB</Exponent><P>xy25dt9/Nd+ZJIzkRQ3jlbTJANSY35ZVEfToDBTnr5
BXuEcWG2k5FoRFr6DJ9FNcP4pLFsDwxRvtEuuRQX2a3Q==</P><Q>uVcXos54SmNjog/kTOacPsxP++5+v59iBM5M
mEl9A3kPgAlswdX+JQDusluUe24qvRVedrJMst4aLp38QzvIJQ==</Q><DP>w+JXJO52yD/n98dMdBFNwpyylct/sVzCu0
81qzQgC0yUyJm4xyp7x4Y8lpY2J8CX17GlWXJVGDT3ugTMrTDfTQ==</DP><DQ>ZL1oBYBAdf6L2zzUFNCMQL4
BA6jgj/tr5bzUeToIj2iv+iIlUT6lgyt8ksmgbW62IEyLKe1ELzz18jzBLzJBWQ==</DQ><InverseQ>iaFIWyfHDfNGJqQbjw
VaxR5SivewPWeJMlIOtN5evQkJ8DXerzsc6ku6Bja2cXvUZr0viCVrRJN29WzezrIMlA==</InverseQ><D>HIFRFi2nlyvQ
ZVVfHIXMv7usSbhZ8TyOvCs2PGPTVvNhfuhnQE4MWURZFtqe3zETZGu+oOnK7SCIJk+oA7C7E6G73ChRLm0snbU8J9FarXnQc/Ujt7JMFo/Ejz1GfgEvjMZAO7Mo2Iwp7jJBbv7m92IZhGU+Ss+Uz5cInp6R81E=</D></RSAKeyValue>
Blockchain Discussion Paper
4
7 Page 47
Kurt Wayenberg
Troy Private Key
<RSAKeyValue><Modulus>xqJvoMECg2Kj+M9SkjDeUK58sKJpvE1F2Nz2HyKNroCYJWo3Q1CHDkUneRa8oYvJcHo
hWhDotLQV8qFS3hNUDSGdJfLVV7RdG0LJ0Rrh423hJWQW5k3bbKvBtaTqT14ReBNXiOZ+AVNs3nCaXAGUX5SA
UdTjoti4sSxz3wUHYL0=</Modulus><Exponent>AQAB</Exponent><P>+G4ZilQwSCq1I0Z7aq8SIGNDnQbvRvfTYZ9L
H2ALVJsU42klscgCKflys3CpQ8f8Cc+7Rp4pX2HPmD6s5FAN/Q==</P><Q>zK/m1n0TrhsMQGImIp1LoOEelqOuTkUJ
mEuSQji1EvrqCBXP+ztfr3tmt6pqal2w5JcVwK1DRSa3lEgXqSW5wQ==</Q><DP>z80wme+v7z2iBJ65L1S/wc2mSdv6H
A/Chb771IO/FoceItbaC+p0PO4GDqinPSYz4XUcfoZfrwQe5IdQkS2RdQ==</DP><DQ>o+XR5DvBD2+PDtrIiH0FOuwn7
x1fjELRnQYeNjJsI6eQ0CqPIC95ve0E4dpuXX9qDpBAFclnDS8kXnKfp4ySwQ==</DQ><InverseQ>tgIFxaevdFpxkTzUE
/G1X+MHPL+20YRLUV3oHOSvr4cGaQK2nZiQ5oCbt7IhzTdxqNp2hNNfFON22JPfOiwmfQ==</InverseQ><D>HinMib
zFhO4VuFLDVy/Ukqvsg2YmaFHTqXrkZRX6LeWZNRVMDwzLdX9K3zh0rJNto4boSaUHsWknbBDTZKXKvW7uX+Y
seFMFeMBJac82RXZQ19Minmhqq6d12KFgYTVMyrkiSjkQRedfomOTUIha5wYSGV0fIBwMtFQIzVwa4AE=</D></RS
AKeyValue>
Blockchain Discussion Paper
4
8 Page 48
Kurt Wayenberg
6 Appendix C - Lorum Ipsum Text Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Aenean commodo ligula eget dolor. Aenean massa. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Donec quam felis, ultricies nec, pellentesque eu, pretium quis, sem. Nulla consequat massa quis enim. Donec pede justo, fringilla vel, aliquet nec, vulputate eget, arcu. In enim justo, rhoncus ut, imperdiet a,
venenatis vitae, justo. Nullam dictum felis eu pede mollis pretium. Integer tincidunt. Cras dapibus. Vivamus elementum semper nisi. Aenean vulputate eleifend tellus. Aenean leo ligula, porttitor eu,
consequat vitae, eleifend ac, enim. Aliquam lorem ante, dapibus in, viverra quis, feugiat a, tellus. Phasellus viverra nulla ut metus varius laoreet. Quisque rutrum. Aenean imperdiet. Etiam ultricies nisi
vel augue. Curabitur ullamcorper ultricies nisi. Nam eget dui.
Etiam rhoncus. Maecenas tempus, tellus eget condimentum rhoncus, sem quam semper libero, sit amet adipiscing sem neque sed ipsum. Nam quam nunc, blandit vel, luctus pulvinar, hendrerit id, lorem. Maecenas
nec odio et ante tincidunt tempus. Donec vitae sapien ut libero venenatis faucibus. Nullam quis ante. Etiam sit amet orci eget eros faucibus tincidunt. Duis leo. Sed fringilla mauris sit amet nibh. Donec
sodales sagittis magna. Sed consequat, leo eget bibendum sodales, augue velit cursus nunc, quis gravida magna mi a libero. Fusce vulputate eleifend sapien. Vestibulum purus quam, scelerisque ut, mollis
sed, nonummy id, metus. Nullam accumsan lorem in dui. Cras ultricies mi eu turpis hendrerit fringilla. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia Curae; In ac dui quis
mi consectetuer lacinia.
Nam pretium turpis et arcu. Duis arcu tortor, suscipit eget, imperdiet nec, imperdiet iaculis, ipsum. Sed aliquam ultrices mauris. Integer ante arcu, accumsan a, consectetuer eget, posuere ut, mauris.
Praesent adipiscing. Phasellus ullamcorper ipsum rutrum nunc. Nunc nonummy metus. Vestibulum volutpat pretium libero. Cras id dui. Aenean ut eros et nisl sagittis vestibulum. Nullam nulla eros, ultricies
sit amet, nonummy id, imperdiet feugiat, pede. Sed lectus. Donec mollis hendrerit risus. Phasellus nec sem in justo pellentesque facilisis. Etiam imperdiet imperdiet orci. Nunc nec neque. Phasellus leo dolor, tempus non, auctor et, hendrerit quis, nisi.
Curabitur ligula sapien, tincidunt non, euismod vitae, posuere imperdiet, leo. Maecenas malesuada. Praesent congue erat at massa. Sed cursus turpis vitae tortor. Donec posuere vulputate arcu. Phasellus
accumsan cursus velit. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia Curae; Sed aliquam, nisi quis porttitor congue, elit erat euismod orci, ac placerat dolor lectus quis
orci. Phasellus consectetuer vestibulum elit. Aenean tellus metus, bibendum sed, posuere ac, mattis non, nunc. Vestibulum fringilla pede sit amet augue. In turpis. Pellentesque posuere. Praesent turpis.
Aenean posuere, tortor sed cursus feugiat, nunc augue blandit nunc, eu sollicitudin urna dolor sagittis lacus. Donec elit libero, sodales nec, volutpat a, suscipit non, turpis. Nullam sagittis. Suspendisse
pulvinar, augue ac venenatis condimentum, sem libero volutpat nibh, nec pellentesque velit pede quis nunc. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia Curae; Fusce id
purus. Ut varius tincidunt libero. Phasellus dolor. Maecenas vestibulum mollis diam. Pellentesque ut neque. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas.
In dui magna, posuere eget, vestibulum et, tempor auctor, justo. In ac felis quis tortor malesuada pretium. Pellentesque auctor neque nec urna. Proin sapien ipsum, porta a, auctor quis, euismod ut, mi.
Aenean viverra rhoncus pede. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Ut non enim eleifend felis pretium feugiat. Vivamus quis mi. Phasellus a est.
Phasellus magna.
In hac habitasse platea dictumst. Curabitur at lacus ac velit ornare lobortis. Curabitur a felis in nunc fringilla tristique. Morbi mattis ullamcorper velit. Phasellus gravida semper nisi. Nullam vel sem. Pellentesque libero tortor, tincidunt et, tincidunt eget, semper nec, quam. Sed hendrerit. Morbi ac felis. Nunc egestas, augue at pellentesque laoreet, felis eros vehicula leo, at malesuada velit leo quis
pede. Donec interdum, metus et hendrerit aliquet, dolor diam sagittis ligula, eget egestas libero turpis vel mi. Nunc nulla. Fusce risus nisl, viverra et, tempor et, pretium in, sapien. Donec venenatis
vulputate lorem.
Morbi nec metus. Phasellus blandit leo ut odio. Maecenas ullamcorper, dui et placerat feugiat, eros pede varius nisi, condimentum viverra felis nunc et lorem. Sed magna purus, fermentum eu, tincidunt eu,
varius ut, felis. In auctor lobortis lacus. Quisque libero metus, condimentum nec, tempor a, commodo mollis, magna. Vestibulum ullamcorper mauris at ligula. Fusce fermentum. Nullam cursus lacinia erat.
Praesent blandit laoreet nibh.
Fusce convallis metus id felis luctus adipiscing. Pellentesque egestas, neque sit amet convallis pulvinar, justo nulla eleifend augue, ac auctor orci leo non est. Quisque id mi. Ut tincidunt tincidunt
erat. Etiam feugiat lorem non metus. Vestibulum dapibus nunc ac augue. Curabitur vestibulum aliquam leo. Praesent egestas neque eu enim. In hac habitasse platea dictumst. Fusce a quam. Etiam ut purus
mattis mauris sodales aliquam. Curabitur nisi. Quisque malesuada placerat nisl. Nam ipsum risus, rutrum vitae, vestibulum eu, molestie vel, lacus.
Sed augue ipsum, egestas nec, vestibulum et, malesuada adipiscing, dui. Vestibulum facilisis, purus nec pulvinar iaculis, ligula mi congue nunc, vitae euismod ligula urna in dolor. Mauris sollicitudin
fermentum libero. Praesent nonummy mi in odio. Nunc interdum lacus sit amet orci. Vestibulum rutrum, mi nec elementum vehicula, eros quam gravida nisl, id fringilla neque ante vel mi. Morbi mollis tellus
ac sapien. Phasellus volutpat, metus eget egestas mollis, lacus lacus blandit dui, id egestas quam mauris ut lacus. Fusce vel dui. Sed in libero ut nibh placerat accumsan. Proin faucibus arcu quis ante. In consectetuer turpis ut velit. Nulla sit amet est. Praesent metus tellus, elementum eu, semper a, adipiscing nec, purus. Cras risus ipsum, faucibus ut, ullamcorper id, varius ac, leo. Suspendisse feugiat.
Suspendisse enim turpis, dictum sed, iaculis a, condimentum nec, nisi. Praesent nec nisl a purus blandit viverra. Praesent ac massa at ligula laoreet iaculis. Nulla neque dolor, sagittis eget, iaculis
quis, molestie non, velit.
Mauris turpis nunc, blandit et, volutpat molestie, porta ut, ligula. Fusce pharetra convallis urna. Quisque ut nisi. Donec mi odio, faucibus at, scelerisque quis, convallis in, nisi. Suspendisse non nisl
sit amet velit hendrerit rutrum. Ut leo. Ut a nisl id ante tempus hendrerit. Proin pretium, leo ac pellentesque mollis, felis nunc ultrices eros, sed gravida augue augue mollis justo. Suspendisse eu
ligula. Nulla facilisi. Donec id justo. Praesent porttitor, nulla vitae posuere iaculis, arcu nisl dignissim dolor, a pretium mi sem ut ipsum. Curabitur suscipit suscipit tellus.
Praesent vestibulum dapibus nibh. Etiam iaculis nunc ac metus. Ut id nisl quis enim dignissim sagittis. Etiam sollicitudin, ipsum eu pulvinar rutrum, tellus ipsum laoreet sapien, quis venenatis ante odio
sit amet eros. Proin magna. Duis vel nibh at velit scelerisque suscipit. Curabitur turpis. Vestibulum suscipit nulla quis orci. Fusce ac felis sit amet ligula pharetra condimentum. Maecenas egestas arcu
quis ligula mattis placerat. Duis lobortis massa imperdiet quam. Suspendisse potenti.
Pellentesque commodo eros a enim. Vestibulum turpis sem, aliquet eget, lobortis pellentesque, rutrum eu, nisl. Sed libero. Aliquam erat volutpat. Etiam vitae tortor. Morbi vestibulum volutpat enim. Aliquam
eu nunc. Nunc sed turpis. Sed mollis, eros et ultrices tempus, mauris ipsum aliquam libero, non adipiscing dolor urna a orci. Nulla porta dolor. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos hymenaeos.
Pellentesque dapibus hendrerit tortor. Praesent egestas tristique nibh. Sed a libero. Cras varius. Donec vitae orci sed dolor rutrum auctor. Fusce egestas elit eget lorem. Suspendisse nisl elit, rhoncus
eget, elementum ac, condimentum eget, diam. Nam at tortor in tellus interdum sagittis. Aliquam lobortis. Donec orci lectus, aliquam ut, faucibus non, euismod id, nulla. Curabitur blandit mollis lacus. Nam
adipiscing. Vestibulum eu odio.
Vivamus laoreet. Nullam tincidunt adipiscing enim. Phasellus tempus. Proin viverra, ligula sit amet ultrices semper, ligula arcu tristique sapien, a accumsan nisi mauris ac eros. Fusce neque. Suspendisse
faucibus, nunc et pellentesque egestas, lacus ante convallis tellus, vitae iaculis lacus elit id tortor. Vivamus aliquet elit ac nisl. Fusce fermentum odio nec arcu. Vivamus euismod mauris. In ut quam
vitae odio lacinia tincidunt. Praesent ut ligula non mi varius sagittis. Cras sagittis. Praesent ac sem eget est egestas volutpat. Vivamus consectetuer hendrerit lacus. Cras non dolor. Vivamus in erat ut
urna cursus vestibulum. Fusce commodo aliquam arcu. Nam commodo suscipit quam. Quisque id odio. Praesent venenatis metus at tortor pulvinar varius.
Blockchain Discussion Paper
4
9 Page 49
Kurt Wayenberg
Appendix D - Other Blockchain Solutions
The above discussion focused primarily on the top 2 blockchains: Bitcoin & Ethereum. There are
however other blockchain solutions, probably over 100... Some of these solutions claim they got rid of
the problems with performance, efficiency and energy-greed, issues central to BitCoin & Ethereum.
Some systems just focus on setting-up a private blockchain e.g. between 5 nodes and even 'skip' the
consensus algorithm. That obviously solves a lot of problems but that solution comes creepily close to
the solution discussed in this paper. Except that it uses a software solution of which 85% of the
functionality is not used.
There solutions by no time also require a distributed database to store the data not in the blockchain but
shared by everyone.
The final challenge than is that every 'node' needs a 'front-end / back-end solution' that uses the
blockchain but hides all the integration complexity. A lot of solutions come these days all installing the
same application / application API and e.g. an Ethereum EVM. The question you should pose is whether
this solution still is the distributed solution you look for or whether it is a lousy and inefficient
implementation of a portal...
Some solutions also claim they do something fundamentally different: We take a look at a few of them...
IOTA
IOTA claims to be an alternative to blockchain. They have set up a tangle. They also dumped the 'block'
in blockchain and went to 'transaction by transaction' chaining.
Allthough they claim that one day they will be fully decentralized but as long as they remains small
(they don’t really define what that means) they still have a strong centralization component or even
central copies of the transactions)
TheIr prerequisite is that everyone that submits a transaction has to validate two more transaction. This,
at first looks interesting as a nice solution against DDOS but will give problems when confronted with
non-professional behavior at the edges of the tangle. As expected there indeed is a problem with a lot
of unconfirmed transactions there… see this link
Even worse, it suffers from hackers behavior and misuse… I did found some horror posts a.o. see link
(https://github.com/iotaledger/wallet/issues/734)
Another very strange design is their address key generation: IOTA address generation
This is a nightmare to get build in in real business systems. In addition it is really insecure and as a
result has led to the rule that after every receipt you should generate a new address. See link:
https://www.reddit.com/r/Iota/comments/6hm9uc/what_is_the_point_of_generating_new_address_to/
The security is not dramatic as far as I know – although also other people have some concerns (see link:
https://www.reddit.com/r/Iota/comments/6gzkd2/iota_sounds_great_but_hows_the_security/divsnh7/)
One specific concern has to do with tip selection algorithm and what the designer himself calls the
parasite chain attack (see https://iota.org/IOTA_Whitepaper.pdf p. 20) - see also
https://iota.stackexchange.com/questions/tagged/tip-selection
Blockchain Discussion Paper
5
0 Page 50
Kurt Wayenberg
IBM Blockchain
I am still not sure about this one. Not at all. For sure it has a very strong central component (which I
obviously consider it a good solution) and as such it has a very performant solution. Nevertheless the
distribution context is still very dominantly present. I am not sure what the added value is as their nodes
resemble replication, more than distribution
Corda
The unique difference with CORDA is that they limit the consensus algorithm to involve only the parties
that are impacted by the transaction.
The platform seems to be successful. It is closer to a central solution as discussed in this paper including
the integration part with other parts (blockchains). Besides focusing on characteristics like validity,
uniqueness, immutability and authentication, they still have a component of 'consensus' in them.
I do think this is a nice extra although for me it is not clear if it is part of the transaction or more as an
action taking place in the aftermath of a transaction. By all means, Corda itself claims that it is not a
blockchain (see link). And neither is it a word that you will find in the popular Azure marketplace
infomercial (see link here)
JD.com
Chinese ecommerce giant JD.com announced that they are partnering with the Australian beef exporter
InterAgri to launch a blockchain-enabled traceability system aimed at providing greater transparency
about the provenance of beef sold in China.
The blockchain system will only be implemented later 2018, but it is astonishing to see how very basic
the scope will be:
it will enable consumers to track each piece of 'Pure Black Angus' beef back to the farm in
Australia where it originated
For that a cooperation between 4 parties is set-up: Walmart, JD.com, IBM, and Tsinghua University
National Engineering Laboratory for E-Commerce Technologies
The four companies will work together to create a standards-based method of collecting data about the
origin, safety and authenticity of food, using blockchain technology to provide real-time traceability
throughout the supply chain. This will encourage accountability and give suppliers, regulators and
consumers greater insight and transparency into how food is handled, from the farm to consumers. This
has traditionally been challenging due to complex and fragmented data sharing systems that are often
paper-based and can be error-prone.
An interesting discussion... it is clear that this team is still in its infant state about food chain traceablitiy.
The organization puts forward a blockchain without any details on how they will realize it. They still
have a long way to go if I compare it with the Federal Food Agency in Belgium whho has done this
exercise already and has a full platform in place. Anyhow, I doubt that they will have a 'blockchain'
solution a few months from now.
Blockchain Discussion Paper
5
1 Page 51
Kurt Wayenberg
Important however, safety for the food chain is a very important concern for the community, so it is no
wonder that things are in motion and that people look at 'blockchain' technology to add transapacrancy,
proof & dispute resolution to their solution.
Today DXC is studying with the Belgian Federal Food Agency how cryptographically signed ledgers
can further improve the confidence to even the most cynical persons
Blockchain Discussion Paper
5
2 Page 52
Kurt Wayenberg
Appendix E: Integrating Legacy Information Systems
In this appendix we give three examples on how certain data can be made immutable: Documents,
images and data-tables.
1 Making documents immutable
Consider a document system which allows to manage (HTML) documents. It maintains versions,
manages text frgment copying, numbering schemes and sorting, security, etc...
Now as a version gets published, it cannot be changed anymore. But how sure are we?
By putting the 'hash' of the document in the blockchain the docoment becomes immutable.
In order to initiate this action, hit the icon 'Publish in BlockChain' in the top right tool bar. (The image
underneath shows the action as done on a previous version of this document)
Hitting the button extracts the full document as html and creates a hash. That hash is then put in the
blockchain. Study the 'content' record that is being created. It specifies that the 'resource':
with url: http://trueandauthenticated.com/Portal/en/Document/Browse/11198
of type: 'Html'
Has Base64Sha1: yYqJcw/OBn/mQcnGE1pz2YAJ92EGnTUik5qmA8MNn/M=
The submission in the blockchain database is confirmed via mail, together with the 'proof' that it has
been submitted.
Blockchain Discussion Paper
5
3 Page 53
Kurt Wayenberg
The document is now made immutable.
Suppose there is a flaw in the system allowing you to change a character somewhere, or suppose there
is a hacker that has corrupted a part of the text. With every 'check' by the resource the 'completely
different hash' will signal that the resource has been changed!
Only the unchanged document will generate the correct hash.
Blockchain Discussion Paper
5
4 Page 54
Kurt Wayenberg
10.2 Making images immutable
What about images? A similar story.
The overview shows the images. How can you assure the image has not been tampered with? You
publish its hash in the blockchain!
In order to initiate this action, hit the icon 'Publish in BlockChain' in the top right tool bar.
Hitting the button reads the image and converts its contents to a base64 string and creates a hash. That
hash is then put in the blockchain.
Study the 'content' record that is being created. It specifies the 'resource' URL, the type (IMG) and the
hash. This information allows the blockchain transaction to check if the image still returns the expected
hash.
From now on the image is immutable. Changing eve a pixel generates a completely new hash and so
any change is detected.
Blockchain Discussion Paper
5
5 Page 55
Kurt Wayenberg
10.3 Making data tables immutable
For making the contents of legacy tables immutable, one has to define a good process and a number of
criteria that help you define when and how to make a certain part of a table unique.
In the example underneath we make the table which measures the customer's SLAs immutable. What
the batch process does is iterate through all days for which no immutability record does not exist yet.
For that specific day all records (based as a combination of ordered records and some selection of
critical fields) are taken and a 'hash' is constructed.
The blockchain database lists the hash for each day. The hash is put into the blockchain and the
table now has become cryptographically secured against tampering.