 |
| "Let us break their chains and throw off their shackles." ~ Psalm 2:3
|
| The proof of work consensus blockchain
is not suited for business applications.
The voting consensus blockchain is a fictional construct based more on buzzwords and hype than on sound technology;
it is a magical black box than can be and do anything
its creators determine.
|
| Anonymity and the absence of trust are the main benefits of crypto-currencies that are based on
a proof of work consensus blockchain, thus their appeal on the
Dark Web. Legitimate business transactions depend on trust; trust
in the people you are dealing with and trust in the legal system if something goes wrong. Legitimate business transactions cannot be carried out
in a system where there is anonymity and the absence of trust. Why is the previous statement so obvious to all but the most naive Libertarians?
|
| "JPMorgan Chase & Co. Chief Executive Officer Jamie Dimon said he would fire any employee
trading bitcoin for being 'stupid.' The cryptocurrency 'won't end well,' he told an investor conference in New York on Tuesday, predicting
it will eventually blow up. 'It's a fraud' and 'worse than tulip bulbs.' If a JPMorgan trader began trading in bitcoin, he said,
'I'd fire them in a second. For two reasons: It's against our rules, and they're stupid. And both are
dangerous.' "[ref]
|
| Do we really need a consensus mechanism at all? Is a consensus mechanism necessary for a distributed ledger to become a
cryptographically secure shared source of truth?
No, not if the participants in the distributed ledger can trust the digital credentials of all other participants. If a hash code is calculated for each section of
the distributed ledger and that hash code is signed by a trusted participant, that signature can be "chained" into the distributed ledger creating an immutable business/legal document.
|
| If trust can be established through cryptographically secure digital credentials,
distributed ledgers become a practical instrument of finance and business process management that will transform the world.
|
| With cryptographically valid digital credentials there is no need
for a convoluted consensus mechanism.
|
|
| Smooth Transition
|
| There will be a smooth transition to this new technology,
not a radical paradigm shift. Information technology managers and business managers will not be faced with a
decision to completely replace their existing IT systems; they will be given the opportunity to enhance existing systems with
greater security, collaboration and intelligent processes.
|
| Important note: In the system that we are proposing we are not attempting
to create a comprehensive ledger of all transactions or a new cryptocurrency, instead we are creating cryptographically secure distributed ledgers for
specific atomic business processes where all the participants have secure digital credentials that have been verified. Anonymity is
NOT a positive feature for legitimate business transactions. A comprehensive distributed database is NOT necessary.
|
| The focus on a specific atomic business process means that there will be a limitation in scope for the participants.
While it would be possible to create a blockchain for ALL automobile ownership or ALL home ownership, when I buy a car or a home I really only care about my purchase (and my privacy);
having a cryptographically secure distributed ledger with digital signatures of all the participants for my purchase will meet my needs.
|
| Think of a cryptographically secure distributed ledger as a blockchain with a specific limited scope.
Each section of the distributed ledger will have a cryptographically signed hash code that will chain it to the previous block.
Each link in the chain will be identifiable through a participant's cryptographically secure digital credential.
All participants will have a copy of the distributed ledger, but an uber blockchain will not be used as a distributed database.
|
| There is a use case where multiple distributed ledgers will be accessible in a read only mode.
Every time a patient picks up a prescription at a pharmacy the provenance (record of ownership/custody) of the medication could be made accessible
through a cryptographically secure distributed ledger.
Within the supply chain for all goods and services, each time the ownership/custody of an item or collection of items
(e.g., lot, shipment) changes, a record of the change would be entered into a cryptographically secure distributed ledger by the participants in the process.
|
| These individual distributed ledgers would be posted to a cloud based aggregation service that would be
easily searchable; this would be a far more efficient system then having every medical supplier maintain a version of the distributed database for all medical suppliers.
The really is no need for a distributed database.
|
|
| Details Details...
|
| In all the hype about distributed ledgers,
have you ever wondered what a distributed ledger looks like?
For one of the current leading "flavors of the month", Hyperledger Fabric, "A distributed ledger is a multi-party database with no central trusted
authority."[ref]
|
| For Hyperledger Fabric, every participant in the permissioned blockchain is responsible for maintaining their own version of the
distributed ledger, usually in some type of local database structure.
|
In all the hype about distributed ledgers,
have you ever wondered how a distributed ledger is validated?
For the current distributed ledger platforms, especially the ones that implement a multi-party database,
there is some type of parliamentary voting process to establish a consensus. The following "Example scenario" is from the Hyperledger documentation:
- Everyone in a room has a book with the instructions to write down entries as they get called out.
- Someone calls out item number one and everyone writes it down.
- Then two people call out item number two at the same time, but the item number differs.
- There needs to be a process
[truly byzantine]
for who wins, and the loser gets to try to call out item number three.
- When all agree on the outcome of an entry, the next link in that ledger can be written.
- Whether this happens in a small scale or the size of the internet, that is the spectrum for how a distributed ledger can work.
|
| The parliamentary voting process used by most of the current distributed ledger platforms is convoluted
(truly byzantine) and unnecessary.
|
| The next generation of distributed ledger platforms will be greatly simplified.
When members of a permissioned distributed ledger application have cryptographically secure digital credentials, their entries into the distributed ledger will be trusted.
The order of the entries will be determined by established rules of process management.
|
| How will it all work? Let's look at a conceptual demo:
Click Here
|
|
| Simplified Identification, Simplified Structure
|
| If distributed ledger technology is going to take off, the architecture must be simple and clear.
|
| How do we keep track of digital credentials, distributed ledgers and the organizations that issue them?
|
| How can independent entities create identifiers that are unique?
The traditional answer, implemented by credit card companies, governments and other organizations, is that each entity
receives a block of numbers and then assigns identifiers from their given block. When dealing with thousands of
organizations such a process would be problematic.
|
| A more pragmatic approach is to use significantly large numbers that have
a very low probability of being duplicates when selected randomly.
|
| "Universally Unique Identifiers" are truly magical.
"UUIDs are generated inexpensively by one of several standard methods so as to be practically unique, without requiring a central registration
authority or coordination between the parties generating them. 'Practical uniqueness' does not preclude all possibility of the
same identifier being generated more than once, but rather means that it is sufficiently improbable in practice that UUIDs
will be duplicated unintentionally when generated by the standardized
methods."[ref]
|
| "Thus, anyone can create a UUID and use it to identify something with near certainty
that the identifier does not duplicate one that has already been created to identify something else, and will not be duplicated in the
future. Information labeled with UUIDs by independent parties can therefore be later combined into a single database, or transmitted on
the same channel, without needing to resolve conflicts between
identifiers."[ref]
|
| The chances of two independently generated UUIDs being duplicates is incredibly small:
"The total number of possible version 4 UUIDs is 2122, or 5.3x1036 (5.3 undecillion). The odds of drawing the same UUID twice from
this large a hat of possible UUIDs can be calculated using the probability theory for the birthday problem. The chance of a single duplication
(or 'collision') rises to 50% only after 262 UUIDs have been generated. To put his number into perspective: at the rate of 1 billion UUIDs
generated per second, there would be a 50% chance of one collision after 146
years."[ref]
|
| For those who are extremely paranoid, prepending
a UNIX Epoch timestamp in milliseconds
(1/1,000 of a second) to the UUID when it is generated will allow you to sleep well at night:
|
| 16827393761234-9909D38B-BB7E-48CE-9CD4-A46159F573A1
|
|
| Data Structures
|
| All good system architectures begin with good data structures.
|
| The data structure for digital credentials and distributed ledgers will be based on
an established, widely accepted format, JSON.
JSON is, "an open-standard file format that uses human-readable text to transmit data objects consisting of attribute–value pairs and array data types
(or any other serializable value). It is a very common data format used for asynchronous browser/server communication, including as a replacement for XML in some AJAX-style
systems."[ref]
|
| The JSON data structures will enable easy interoperability with existing systems.
A distributed ledger will be acted upon by several different parties. Each time a participant makes a transaction to the distributed ledger, that transaction will be added to
the ledger (with a cryptographic signature) and the revised ledger will be transmitted to all participants (most likely, participants will parse the JSON
data structure into their own relational databases).
|
| We will begin with digital financial credentials which can be represented in a simple JSON structure,
Think of this structure as an extension of the x509 structure.
The final structure of digital credentials will evolve in a cooperative manner.
|
|
"financialCredential":
|
[{
|
|
"type":
|
"financialCredential",
|
|
"credentialProviderName":
|
"Community World Bank",
|
|
"credentialProviderUuid":
|
"6039258a-99ca-4611-8173-c551bb47ee46",
|
|
"credentialProviderInfoUrl":
|
"https://www.cwbank.com/rest/retrieveCredentialProviderInfo.action",
|
|
"credentialDisplayName":
|
"CWB Test 1",
|
|
"credentialType":
|
"com.cwbank.credentialtype.FINANCIAL_TEST",
|
|
"credentialUuid":
|
"1619253096000-3027B59F-BDE1-499D-B314-A955A0A20914",
|
|
"activationTimestamp":
|
"2023-01-13T16:21:10.888Z",
|
|
"expirationTimestamp":
|
"2023-01-13T23:59:59.999Z",
|
|
"publicKeyAlgorithm":
|
"RSA",
|
|
"publicKeyModulus":
|
"4096",
|
|
"publicKeyHex":
|
"30820222300D06092A864886F70D01010105000382020F003082020A0282020100E8CE2E53811369
6810A477715D4CF5A23203F1AE2EF8B1F7C5F434A98E86C70BAB05097FFBAF71B02C3ADEFDA364CC2
738203AFE1FDDE350471BF7BA577DA1CCE2EE8C980F990AA48D098D11CA763585F9801E8811A9608F
2F879C49488A4751412EB19CF8BBE4BA5F34D9F2A9667D659A660A3A77288FE8E50C19A944A3ED20E
6685E8EED34E31C90B9AE1A0210DF9DC2A5E7D13BD566B3102F56FA271E500574EADCBA18E8FD89BA
6CB66657552AF13E09F78FAF184B02DC8D4C3ED9C267A9E7225D54B2B35C1B3042BA89CCA79B03BCB
002E5AE3B1B090E7ECDDFEBE050EE678756BE7E83AA787970BB4F8B08B68390B020F00941CAB25419
957300FCF181035EA60FFB504FC357F7D081F53811588729283B837AAB396191DE5043D340FB20E9C
685717691BB7157EC7F85B4FDA4FA14A299C1D83F874B2431E6F53F43F98460996AC116C76A867D3A
ED79776C9E4A0D8DDE4496272FF0B536D48C47837CF0627C3721855A1C1F35AF721F5F6A3E53DE551
7C0C4DF1AAC6AA3E2DB3D00BE7D17507E9B587A2999DC95AF806B9AFA8AF338C5824471EF7EFD6607
381D5DA909DCAD8F7EA7F75DF13D4C5D09AFE9EE5F3E6A2A916D575B07F6E4308FF75D6EB42159D8C
07BFE9CC15D34F41F00EB9DE9E4AC9F79D3F836A8CCE48D70DF96E3CA5CAF3C9D66564F84201C3AF9
85A58C5C4AB77F1DDB8C2AD7EADCFFC1BE283270203010001",
|
|
"credentialData":
|
[{,
|
|
"lastName":
|
"Hansen",
|
|
"firstName":
|
"Mark",
|
|
|
}],
|
|
"credentialProviderSignatureAlgorithm":
|
"SHA512withRSA",
|
|
"credentialProviderSecureHashAlgorithm":
|
"SHA-512",
|
|
"credentialProviderHash":
|
"0A95F98A7FAD726E5C2B1CCA6503DF674755CBD5D861019921C85D85B559A3A4434120D2FDC706E6
F499382ED9CE1384AC74AA4EE5D2B78AE8896D14028CAE6F",
|
|
"credentialProviderSignedHash":
|
"11A9728E5484555903F971C72939D3C205CF8D613F6AA77FDE89564C2C84CB43E827C65FB8033F70
7FFABD090AD5EC91255866A2AF3F99726CB1A059A7D956DD07CEC40F9FF99E201EFD6355EF26FA3FE
B5659BB42A9B12E163AB4B59040AA509FCF9BBF91CF3B6EAF8BEEC5746B2A9A897F9149F230DA4923
6156B25A616A0304520F4711CA92A831E977B8F4075593FC1A677A49726132EAEB2A86A6296BAC65A
4D558A976BBD0FB351C9A37CE714DED25D4F380C7E07E1752E0C2012E1F2AB9DF9688550643DE0252
5DE329C3E389DDB5257C013807C63A7625FA26443E44622AE5349041A1291DAE492208151573DED85
3D117AB22A7520EF456F835F05CD3E8C8D061ED864DE90C0B397A61EF88D11CAC932436808AA694B9
E0A956E257E226785E7A0C23A4629F9A184723768D6DF55D2E6B101094E93782C68BBC70C4533D1FB
873DB32CDF78C17C146E6B273DDA00CBAA06D06E508C592E1E52C661925195695AB4AE92288466E64
D7E3D17E6A064C14D7D2122B74456DCC853E54B5532E2568C6483EB5D02AA439CD3A77DB24BFA003A
25B8A3D9B18DE7D979DC4960EC140308FFA5106CD68F5FF329C39D289C2EC356B3990963E6BB138E5
AFBA5A265C61BEED742F56F74E2847CAB70EE781ECE50D4D0B17A77EF6B1747ED43D0B6C686A9CE99
8BE6E40621739C6C0B0529A3C34F326A4933C1027248A52647C05"}]
|
|
| The "credentialProviderHash" value is a hash calculation of everything above
it in the financial credential. The "credentialProviderSignedHash" value is a signature of the "credentialProviderHash" using
the credential provider's private key. As long as you have a trusted reference to the credential provider's public key
you can trust the signature and trust the digital credential. We will discuss more about trusting credential providers
in the section, The Worldwide Distributed Ledger for Credential Providers.
|
| Also notice that this financial credential contains limited "credentialData".
There could be no "credentialData", just a"credentialUuid" associated with a "publicKey"
All the account information is maintained by the "credentialProvider" (e.g., the bank) based on an association to the "credentialUuid".
Your privacy can be protected when you present a digital financial credential.
|
|
In other types of credentials (e.g., driver's licenses and passports) there may be detailed "credentialData" including image data blocks for
photographs and signatures and possibly other data blocks for biometric data. In addition to identity and financial credentials, there may very well
be "marketing credentials" that will contain your consumer preferences and purchase history information that you wish to share.
|
|
| Financial Transactions
|
| If you come to my website or place of business and make a purchase request
I will send to you (to either your smart phone or business processing system or possibly your registered intelligent agent)
the financial credential from my bank and a financialTransaction JSON object; the JSON object will contain an
offerTransactionHash code signed with the private key associated with my financial credential.
|
| Once again, as long as you have
a trusted reference to the credential provider's public key
you can trust the signature and trust the financialTransaction JSON object.
|
|
"financialTransaction":
|
[{
|
|
"type":
|
"financialTransaction",
|
|
"transactionUuid":
|
"1619208021920-B42AEAA7-B439-4766-93D3-6336209982C8",
|
|
"activationTimestamp":
|
"2023-01-12T16:17:12.888Z",
|
|
"expirationTimestamp":
|
"2023-01-12T16:17:22.888Z",
|
|
"description":
|
"Samsung 28'' 4K Ultra HD Monitor",
|
|
"amount":
|
"314.96 USD",
|
|
"buyerData":
|
[{
|
|
"lastName":
|
"Hansen",
|
|
"firstName":
|
"Mark",
|
|
"accountUuid":
|
"1619228887425-2924A924-EE35-47C0-8AFA-A4C1D418A554",
|
|
|
}],
|
|
"sellersCredentialUuid":
|
"1619274000310-4F30305F-F592-4228-8798-5BB2038F4E51",
|
|
"offerTransactionHash":
|
"954593CDB0F1259F2036EFD8AAD0804ABCA310A5B63C249C839E4BE768D4CC119F99CA1814792153
763B662644D78507E70D6B6CF259BD4C5F471CBAAB9D9755",
|
|
"sellersSignature":
|
"30E060D43343BF76AB1C41251ADB8E46745B67F01939EC82A8C74895D3E0B342DA3218C13BB22A39
12748EA8A4CC07AB078EC2D38CE29889BF46936EE07C12A50A90312426B13ECB39362DF7FD63C50C6
BB1F8F7BB16C2C2FBE958E0F093CA64D5977D8848C9DF5055BE427F5CFCDB9CC2AE86A30C40406100
B20DBD613813B2D2993510B2EBD81165C8EB0EBAF402429D99ED73181070C0B00AEF48C315DBC77ED
D23652B0B92086D2557F4401C4008812B19F259D5F7EA3A89A9EFDE35C17BD85D23E2775FC3B4741C
AC94CD9711D5C007C7B48C027AF18668056C6D22ED20D6B6B5EA69ABCEC9DDA2DE2732A44434CC743
DB19262015D5BD9B273A7B20D3EB17B9B85523BC1191378B9A32C608C406C80AF513E6CE4C1D04DD1
A6D612FF34975FDFDB3F8BC2CA23C4DB9CADF8AF3C7EEB26F2E4F33CDA595FF0B2E63773FB2BD5A6D
3232FBEBD7789D689731723F70A6070249D0BF76A88D6FEA69425694C9DEB0CE7BFECA46F6BCF2BB4
6E9312B9F88105320D78FCE12A0577EF14BFA9C03820317C5593D21105E0CB301A97AD88F32EE62B1
23BB0A12B1DB2964E21652837ECEE6AAE6510639CA613C2ACF5DC8F669DFB719A2A80F0D897DE304E
E7767C10DBAC61D4C3D894F102A92BAA40430546B33BD4EF971FF8904CD16453CFCE10DAECAB49A68
172A74EB2EDF0A920450FBD519F705B84506D2496F6E8C961B1C4"}]
|
|
| Your smart phone will display the purchase information
and enable you to confirm the purchase with a One Touch action.
Your system will then calculate the acceptanceTransactionHash code and sign the hash code with the
private key associated with your banking credential.
|
|
financialTransaction =
|
{
|
|
"type":
|
"FinancialTransaction",
|
|
"transactionUuid":
|
"1619208021920-B42AEAA7-B439-4766-93D3-6336209982C8",
|
|
"activationTimestamp":
|
"2023-01-125T16:17:12.888Z",
|
|
"expirationTimestamp":
|
"2023-01-12T16:17:22.888Z",
|
|
"description":
|
"Samsung 28'' 4K Ultra HD Monitor",
|
|
"amount":
|
"314.96 USD",
|
|
"buyerData":
|
[{
|
|
"lastName":
|
"Hansen",
|
|
"firstName":
|
"Mark",
|
|
"accountUuid":
|
"1619228887425-2924A924-EE35-47C0-8AFA-A4C1D418A554",
|
|
|
}],
|
|
"sellersCredentialUuid":
|
"1619274000310-4F30305F-F592-4228-8798-5BB2038F4E51",
|
|
"offerTransactionHash":
|
"954593CDB0F1259F2036EFD8AAD0804ABCA310A5B63C249C839E4BE768D4CC119F99CA1814792153
763B662644D78507E70D6B6CF259BD4C5F471CBAAB9D9755",
|
|
"sellersSignature":
|
"30E060D43343BF76AB1C41251ADB8E46745B67F01939EC82A8C74895D3E0B342DA3218C13BB22A39
12748EA8A4CC07AB078EC2D38CE29889BF46936EE07C12A50A90312426B13ECB39362DF7FD63C50C6
BB1F8F7BB16C2C2FBE958E0F093CA64D5977D8848C9DF5055BE427F5CFCDB9CC2AE86A30C40406100
B20DBD613813B2D2993510B2EBD81165C8EB0EBAF402429D99ED73181070C0B00AEF48C315DBC77ED
D23652B0B92086D2557F4401C4008812B19F259D5F7EA3A89A9EFDE35C17BD85D23E2775FC3B4741C
AC94CD9711D5C007C7B48C027AF18668056C6D22ED20D6B6B5EA69ABCEC9DDA2DE2732A44434CC743
DB19262015D5BD9B273A7B20D3EB17B9B85523BC1191378B9A32C608C406C80AF513E6CE4C1D04DD1
A6D612FF34975FDFDB3F8BC2CA23C4DB9CADF8AF3C7EEB26F2E4F33CDA595FF0B2E63773FB2BD5A6D
3232FBEBD7789D689731723F70A6070249D0BF76A88D6FEA69425694C9DEB0CE7BFECA46F6BCF2BB4
6E9312B9F88105320D78FCE12A0577EF14BFA9C03820317C5593D21105E0CB301A97AD88F32EE62B1
23BB0A12B1DB2964E21652837ECEE6AAE6510639CA613C2ACF5DC8F669DFB719A2A80F0D897DE304E
E7767C10DBAC61D4C3D894F102A92BAA40430546B33BD4EF971FF8904CD16453CFCE10DAECAB49A68
172A74EB2EDF0A920450FBD519F705B84506D2496F6E8C961B1C4"}
|
|
"buyersCredentialUuid":
|
"1619228835187-292BA924-EE35-47E0-8AFA-A4C1D418D190",
|
|
"acceptanceTransactionHash":
|
"B20DBD613813B2D2993510B2EBD81165C8EB0EBAF402429D99ED73181070C0B00AEF48C315DBC77E
F4401C4008812B19F259D5F7EA3A89A9EFDE35C17BD85D23",
|
|
"buyersSignature":
|
"226276072FEF5E02E2DC58DEE0EE72DA4661115CA93CEB75D2AFE4E72C3139B1BF5319B090285B31
24AB729CA8C3AF9D8A7116930C77F37D88F195540F73D061905A13A3C1B090BCA6D76E41935D62E04
BFDA6B09368D5E5D43C5B8F83F568FF8EF4F7127E7435729F583F612D9CDEA6B7F1541757C3EB05C4
4320DB820953B428090577F0399A102FC571A538C383E0D56F1E41CCA274FC618457C2DC11948BE5C
14B80FB45840CB86B68BE1A4257C00B70A2CCF79A899171E43271E2AE64BE3FC256E060A1C1A3BDC8
B48EAA8C597362981D6507D12671223ED878306878B2C3FFED960305BF47801B48904E9C332A1FB57
28222AEAC254E6B2E438976963E457B587B38A6EC24BBACC900C5D6B008156BED27EF128A4A0A6F10
0A525752C0D10CCD1AF32873E598F0D9F741E73461B6D95F5B3E83BA0FCFD4BFE709446AFB0845805
4EF624DE87B8F5DF3309379D803ED7EC531CD9A8AF014F1186F8AAE13245C4BAC80E49AD1D2698981
AACE32C9691B0E600D4D8011F16EACCDB22DC0CBDB3A529A7CDA7272503F078C5EAC9BA5EDC9592F7
6AD10BA9B803A989721452DBCCD532A489873BC6706787E7F86A4C1C2387CE73159ECA805276129D7
37858781BCDE17B4BB87B5145DC3AB2C45BA3CEC0970369E9542A32623C6BDA7D601FCE91B12D1F62
BE35DDF86ECCD895A109D99AFC6AF9F8D198217C97AA2DCD7F8BB"}
|
|
| Your system will return the dual signed financialTransaction
object to my system with your banking credential. The dual signature insures
non-repudiation for both parties;
neither party can deny at a later time that they did not agree to the transaction.
|
| My system will first check an application service within the
Trust Nexus to insure your banking credential and the credential provider that
issued your credential have not been revoked. If all is well my system will verify the hash code and then verify
your signature. If both verifications pass, my system will send a commit message to your system.
My system will then send the dual signed financialTransaction object and both banking
credentials (buyer/seller) to my bank.
|
| My bank will verify the credentials, and the hash codes and signatures of
the financialTransaction object. If all goes well my bank will engage in a standardized
transaction process with your bank (a process which may include a shared ledger where only the net amount at the "end" of the day
is transacted). Once the transaction between my bank and you bank is complete, we will each receive a confirmation message from our bank.
The time for entire process will take just a few hundred milliseconds (less than one second).
|
| Instantaneous payment processing will be a reality
(with no unnecessary intermediaries).
|
| The simple financial transaction above can be extended to a generalized
Trusted Distributed Ledger that will encompass the efficient transfer of value for any financial asset,
any type of intellectual property (music, videos, books, etc.), any type of services, any type of material goods... everything.
The Internet of Value will become a reality.
|
| Trusted Distributed Ledgers will
encompass every process involved in the transfer of value (finance, shipping/tracking, insurance, licensing, conditional contracts, etc.).
Different industries will establish standardized types of distributed ledgers for different processes. It will also be
very easy to transfer funds and anything of value from consumer to consumer with only their banks as an intermediary.
|
| It would be a natural extension of their existing functions for banks to play
a central role in creating the Internet of Value. Failing to capitalize on this opportunity
will have dire consequences. With the right technology and consumer focus, any one of a number of players in the
"FinTech Revolution", the mobile network operators,
Facebook, Apple, Microsoft, Google, or Amazon (aka FAMGA), could disintermediate the banks.
|
| "A CEO of one of the big banks said recently, 'We're in the business of transferring value,
and because of that, we can store value, lend value, exchange value, and fund and invest value and insure value and account for value.
If you take away that movement of value function, you deeply undermine our entire raison d'etre and our foundation for existence, so this is
both an existential threat to the financial services industry and an historic opportunity.' "
[ref]
|
| Key Insights: If the bankers do things right, the "permissioned network" for the Internet of Value will be comprised of all bank customers with secure digital credentials. All financial transactions will be processed by banks. All distributed ledgers will be trusted because everyone will be able to trust the secure digital credentials issued by banks.
|
| Go to page 3 for more.
|
|
|
|
|
|
|
|
