WO2019090346A1

WO2019090346A1 - Portable blockchain system

Info

Publication number: WO2019090346A1
Application number: PCT/US2018/059479
Authority: WO
Inventors: Andrew Weinstein; John Terrell DAVIES; Justin Handville
Original assignee: Velo Holdings Limited
Priority date: 2017-11-06
Filing date: 2018-11-06
Publication date: 2019-05-09

Abstract

A limited scope blockchain system supports onboarding and payments via linked databases including an append-only database and a secondary database holding transaction requests that have not been applied to the blockchain.

Description

PORTABLE BLOCKCHAIN SYSTEM

Background

[0001] The background description provided herein is for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent it is described In this background section, as well as aspects of the description that may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure.

[0002] Blockchain technology may be applied to many transaction types. In some cases, such as an anonymous digital currency, a work function is added to slow down transactions to prevent double spending. However, transactions between known and auditable entities may be less concerned about double spending and have a greater interest on scalability.

Summary

[0003] A blockchain-based ledger uses a PKS base and a custom virtual machine for interpreting contracts and attestation rules. The root block may be self-signed and include the public keys of entities allowed to create transactions on the blockchain. As opposed to the proof-of-work mechanism that establishes trust in a public blockchain the disclosed ledger uses non-repudiation to establish trust. The virtual machine allows cross-platform consistency and language independence by supplying logic operations for parsing fields in certificates stored in the ledger, comparing fields, and computing cryptographic operations. The instructions of the virtual machine may be embedded in smart contract certificates and may be used when creating transactions within the ledger. Brief Description of the Drawings

[0004] The figures depict a preferred embodiment for purposes of illustration only. One skilled in the art may readily recognize from the following discussion that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles described herein.

[0005] Figure 1 illustrates a TLS site certificate suitable for use with the current disclosure;

[0006] Figure 2 illustrates a three-way web of trust;

[0007] Figure 3 illustrates an embodiment of a bfockohain;

[0008] Figure 4 illustrates a certificate tuple: and

[0009] Figure 5 illustrates data in a certificate used to compute a signature.

Detailed Description

Public Key Infrastructure

The most common form of a chaine i-r\ ptogmpSik iiruoJiuo bulay is inund in PK1. Ptiblh e\ Inirastruetrint provides a um haiiis m which dot s. van b_*· e ix-d ut nt ceil ibcoU riiu s that «us e v i iSiifl in anuiit'',

A ΡΚΪ system is made of chains of certificates starting from a self-signed certificate authority root certificate and extending out to public certificates which can be walked back to one of these root certificates through process known as certificate attestation.

Bach entity within a PKI system lias a key pair consisting of a public and private key. The private key is known only to this entity. The public key is embedded into a public certificate which is signed by an agent within the system that lias been granted signing authority. When one entity wishes to validate the credentials of another entity, it walks that entity's public signed certificate back to root·, recursively verifying the signature of that entity’s certificate and the signatures of all certificates back to root. As part of finis attestation process, the explicit authority granted to each signor is also verified using a contract built into the attestation library.

Figure 1 shows a typical example of a TLS site certificate. Each weh browser has n set of Certificate Authority «"^•tlikatos built in that act as the roots of certificate chains. When a browser ia¾ot hues no SSL eosmoet ion. it receives a signed cer ifica e from the web server that has been signed by a number of iut*-i mediate authorit ies that have ultimately beet) signed by one of the CAs that it has.

Fix_', -« i.-tn work;, \> «>11, hut ;i xigmiie. it clt aw Kick u· the- *\v.i»xa N tlui anthoritv Ι» <Ί·ΙΙΜ:Ι1ΙΛ>*1 A dti ioii.b _I'orrifieaie .«fitiioritk*-* "iR he t.d(i« *l i; wu b the - em Ί^ΛΊ ti_> rc i¾ni.¾· t hese «m hot h x s, As .motim urmvb;tek, it is very dtitlruk if not impossible. to :'ί'\ ιΐ\ι' (vmiu.ju am horn it' u li hitt ibis svstont if a _l ortifiiOU vu bnri; .· s ould become <-οι«ρι·' muse , f jji'u tii<- n ift s stem et risii, Rew* mion ».>f the certificate!· ot^' othu’ e nts wh iu ϊ b*. s s m js problematic, but cut im o-tobje by u ing a een ifiento Huocet ion list tu iti t;ip! g f fowevn . f!«^■·'•uct<unnl measu es introduce euniplerity and potential sealing issues that must be accounted tor witlmt the system.

Web of Trust

A ncept relate t I’KI n the W-'h m^' IVusi . I^'jihke Ph i. a ¾'<'!> of trust doe,-· not h.¾\v a e unalu i d authority. In tead, t he st cut us< s t he ini- of poem and a i-hot signing of public ket s· in tem t o dt-fcc-ume the level of t rust utibnied to a particular maty within the syste .

Figure 2 shows a simple web of trust involving three individuals. Eaclt Individual has signed the public certificates of the other individuals, demonstrating a truer relationship between theta, A fourth, individual, .John, is not a member of this web of trust. However, if .John trusts one of the oilier members, such as Alice, then Joint may assign a secondary trust metric to any eertiih ate that Alice has signed, allowing John to participate in this web of trust by adopting the trust of this existing network, wunjurd based on John’» own metrics. If one of the other individuals, su i as Jams, Alias, or Bob. sign John’s public key, then the other participants iu this network can assign John a trust metric.

One of the biggest drawbacks to the WoT system found in PGP/GPCi is that the trust tales are not well defined n aren’t well known to most «sets. Largely; these rales are based on loose concepts such as degrees of separation, which don’t provide a granular enough attestation process for deciding whether a given entity should lx_* trusted, and over which areas this trust should be extended, In practice, most WoT systems re uire human common sense and may therefore be susceptible to social engineering.

One common technique used for verifying a WoT certificate is the "signing party”. During such a party, people present alternative forms of identification, such as government-issued IDs or student IDs, Each person at the party verifies each other person’s alternative identification, and once satisfied, signs that person’s public key, signifying that this public key does, in fact, belong to this person. Through mutual signing, it is also verified that the person has knowledge of the private key, therefore demonstrating that the person is who he/she says.

Traditional Blockchain

A traditional blookdifiin. such as Bitcoiti , is a structure dr signed t«» *ol\\ the onok^ii-nuUng piobltsiu in a deeeat*afi»e<I system. In such a blockchain, any agent can append a block to I he bl_> « in-hum if certain eritei ta have been met. In order to ensure that these agents play fairly, a.» element of randomization is introduced by creating an mint ratify difficult problem that must be solved. This problem Is designed to reward a random winner, and to require a Umgo nusmnt of computational power to solve. In fixe case of cryptocnrren es such as Bit-coin, this generally involves finding a nonce value for a particular block that causes the cryptographic hash of the block to have a certain number of lei

hashes are unpredictable, an element of randomness is added with tins problem. The numoer m teumug zero mcs> ts amustaom to throttle the average time it takes to add a block to the block chain to about tea minutes per block. Tins throttle can he determined automatically by counting the number of blocks appended over a fixed interval of time.

Figure 3 sho s the traditional bloctehain. Each biockchain starts with a special root, stud each s«bsix|uent block in the hioekebain has a heavier entry that point» to the previous block in the chain. The hash can be created or verified by anyone, and covers the header, a Merkle hash of the entire biockchain at that point, and all of the transactions in this current block. Typically, there is a nonce value and a timestamp in the header as well, which provides data that- can be manipulated to create a hash that matches the current difficulty level in the biockchain.

For a decentralized system in which predictability is the enemy of safe transactions. the combination of throttling ami simple hashing makes sense. The hash can he computed ami verified by anyone, and the d t!iealty of the problem ensures that HO one can predict tile agent· that will add the next block to the hfoefccfiaki. However, th

agency manages to corner the market by being able to compute a significant percentage or URJCKS WIWIS VUK »wa «MI. on average, then that agency may be able to manipulate the source of truth in order to corrupt the eryptoctin'eney.

No solution is perfect. Biteoiirs blockchain has predictable limitations and the Biteoin team continues to iterate on stopgap measures to work within these limitations and: to prevent damage from a market that has be n significantly cornered by a. single agency,

Velo Ledger

As described in the previous section, the traditional blaekehnin is an oieeant s lution to tin* ooubk-.spetuhug ptobk n· m the case of a large decentralized system of many agencies. However, this solution mn s at tin- COM f botii c ollective campui foaai power and some: significant limitations.

Vein’s problems are not the same ns a decentralized eryptocurRiney such, as Bitcoin, As such, we do not have to use the same solutions within, our ledger,

Velo’s ledger synthesizes traditional P l with the append-only nature of a traditional blockdxara. The result is a system that provides onboarding for new agents, an extensible system for defining contracts that: can be used to verify blocks added to the biaekehaift, and a mechanism to embed private information into the bloekchain either directly, or through the use of tamper-resistant fingerprints and external transport,

The rest of this document will describe how this ledger works from the ground up.

Certificates

A certificate is a simple tagged binary data structure that is signed by an entity. Each certificate contains a standard set of fields that define the type of certificate, the cryptographic family used by the certificate, the contract. identifier used to validate the certificate, the unique certificate identifier, the signer of the certificate, and the certificate signature. Certificates abo contain other fields which are specific to the certificate type and verified by the certificate’s contract.

Each field in a certificate is a simple tuple consisting of a 16-bft field type identifier, a 16-b!t field size, and the raw field data. AH numeric values are encoded as Big-Endian unsigned integer values.

While it is common for certificates to be described in AS . l and encoded, in DER. this format is needlessly complex. This complexity is not just a systems concern; ASN.l and DEil parsers have suffered ftoiti crippling security vulnerabilities that largely stem from the eomptejaty of that format, Velo s tagged cert ificate format parser can be written in a way that is provable secure. It is possible to formally prove that our certificate parser will either successfully Sind fields in a certificate or enter a predict ibte emir state, even if the certificate la corrupted by a malicious agent. Even witli the constraint of a formally provable properties, it is possible to build very rich documents using this certificate format.

Field Types

The fire! 1024 field types (ϋχβυοο - 0jcik5FFl ot the certificate format are reserved by the system and axe hard-coded. The remaining A4S12 Held typos ore sisu-«ka d bas.-d on the certificate type. Externally, these field types are not directly seen by user code. Instead, user u>de »di jirilfo hold by a VOID, which is mapped to a 16- bit value by the certificate library. The mapping of user-defined seals d ^end on i he mapping table defined for file certificate type. This mapping table is also defined as a certificate, which may either be embedded into the blockchaiw for public extensions or referenced as a private extension whose fingerprints are embedded into the bl<x:keham. N OH- Repud i at!on

Hn>hs^> ran lx¹ mu»puu>ri by anyone. These ore useful for verifying thr^» Integrity of dai«. but since hash**» cm be computed by anyon . chert; nothing that premite someone from core: roll nig both tin; basil and the data. As such. hashing is ¾o«fi for int egrity. but Him* is no guarantee rega uling the provenance of any atofi rayv combinat ion of ata ami hash, hi a traditional hioekebahi . there is an implied relat-ionshtp bet.weea the hash of a block and the entity that originally hashed the bfodk, because it is difficult i;u find a hash that matches the difficulty, and more importantly, there is a market kteeirtlve for finding this hash. It ¾ unlikely that an entity that must perform an arbitrarily large amount of work to compute a hash would forgo the authorship of this block, bec use this would mean forfeiting the reward for finding a good hash value.

A cryptographic signature can be verified by anyon with access to the publi key. but it can only be computed by an entit i» possession of the private key. As such, this signature to a property of nou-rqnidi i n. As k>ng as the signing key remains private, then only the entity In possession of flits private key can create a signature using ibis private key.

Each certificate includes a signer field and a signature field, The first step in parsing a certificate is to search for the signer and signature fields. These fields set the boundary of fields that ean be verified by checking the signature. The certificate is truncated to these bounds, which ensures that the parser will not consider any fields which might be appended after the signature.

Figure 5 shows the data in a certificate used to compute the signature. The data in black is used fit the signature computation. The data in blue is the signature itself. After the signature has been verified, ail data in black can be trusted as being authored by the signer. This data includes the field type and size of the signature itself, although, for simplicity, this data is also truncated. The data in red is Distrusted, and truncated. Tims, ass attacker cannot append data to a signed certificate.

Vela Ledger

The Veto Ledges' is a special type of bloefcehain that combines «ternem* of she t radii k_> uai bfoekeha with ements of ΡΚΪ, This hsdger works on the principle of delegated authority, in which ora; root entity delegates explicit authority to other agents that grants them the capability of performing certain actions within the Mger.

Each block within the bkickchaisi is a certificate which contains additional certificates. A block is a special certificate that contains a link to the previous block in the blockdiain and is signed by an entity that lias been granted the authority to append blocks to the bkxskchain.

The root block in the btoc-kdmln is embedded into the Vein Low-Level API. This root block is the only block within the block chain that is linked to itself. This block is seif-signed by root and giants authority to tto entities, whose public keys are also embedded hi this block, to create transactions relevant to the blinkcitain. Biockchafii agents are entitles that have the authority to append records to the biockdudn. tocbcbain onboar^l!—^v v·' entities that haw the authority to onboard new bloekeha agents, which extends the network of available 1 1< < to h.«n .ua uis. Payment ««boarding agents are ant Sides that have the authority to onboard payors and payees. Contrac > _< nN .no * »« >* f« that have the authority to create new contract types that are appended to the biockcindn and may be used by entities that have the authority to use thorn. Certificate extension agents are entitles that have the authority to create new certificate extensions and can be appended to the blockchtin and may he used by entities that have the authority to us them. Payors utul payees ii.ro agents that may create and evolve payment transactions which can then be appended to the bioekehai»..

Additional blocks are discovered and cached by connecting to the? ledger network and attesting each block in tom. Each block added to the ledger evolves the state of the entire network, and each block attested by an entity connected to the network «wolves the entity's view of the network This evolution mclndes state changes for any transaction within the network, irons the life c cle of entities themselves to the life cycle of transactions that these entitles create.

Non- repudiation replaces the proof of work problem as the mechanism that keeps the ledger trustworthy. Only blodkchaia agents have the authority to append blocks to the ledger. An? entity, however, can verify the integrity of the ledger by verifying the signing b!ookeha agent’s signature for each block.

The lifetime for all artifacts within the ledger is limited. This includes entities. When an entity needs to be expired or revoked, a revocation transaction can be used to retire this entity. Periodically. bfoeMtahi agents are retired and now bkickdxain agents can be created. Tins can be done to scale up the ledger, to rotate keys, or to respond to a potential breach of trust in the lodger. Veto Smart Contracts

Although the lodger acts as

source of t ruth withfas fclie Vela system. every transact a v iritht ihe system should be vendable. Since eustom transactions or additional type* of tutswv t* or cert ificates may be embedded Into file ledger to support both payments and other relevant: transactions within tin· system, there iked,-; to he an extensible UR-etoimsUt Htal· allows any entity to verify any certificate that has been appended to the ledger.

In order to verify a certificate in a ΡΚΪ system, a fixed attestation proe is used. This attestation process walks the certificate chaiii tank to root and verifies fields in each certificate in this chain to trace both provenance and authority. A similar process can be used to verify certificates in a ledger, however, capturing the attestation rales for custom certificates would be problematic if these rules were just written in a typical programming language.

One of the difficulties· is choosing the language. A language like JavaScript is not well suited for performing attestation, because it was not designed tor that purpose, and different interpreters may yield slightly different results that could be exploitable. Picking a language like .lava, C#. or Py hon ay have or ability implications, sis these languages have certain platform requirements that may not be available on a smart phone or a hardware security module.

Veto make* use of a special high-level virtual machine for interpreting contracts and attestation rales. This virtual machine provides a subset of logic operations that can be used to perse fields in certificates stored in the ledger, compare these fields t other fields in other certificates, _«md < ompnte various cryptographic operations. The instructions in this virtual machine are encoded in a simple bytecode tomml that can be embedded in smart contract certificates that can be referenced when creating transactions within the ]«%< t . This virtual machine can be simulated on high-end servers in the cloud, using client-side .JavaScript in the browser, with software running in smart phones, or on special smart cards with embedded microeout roiters.

The structure of this virtual machine allows properties ul eouvraei'_* defined tu i bis hvtei ode term t< > b· te aily ven&ed us t a proof assistant such as Cop. Tims, it is possible to eSme a m.-teni contrnrl lot ts;.i κ-l s s hi I he hslie», .red t en tottnalH prove that spenlk propert ics of this smart contract will wva·, hol , \ddit mtuTv h is po sible t_> · pnm· Unit ret kfivn t m i smart contracts can be performed under certain operational oousi i aiuts inclu ing iioth ΠΛλί anti c 1⁵Γ ΐ ι·_{> 1η}ιπ tnesPs

The combination of a distributed ledger built on non-repud tion and smart con <Ur that tan be defined to extend the types of tKuisiictiojis possible in the ledger ensures that Veto’s distributed ledger caa .stale to meet the needs of high-volume banking s stems and can be extended to co new use eases in the future without sacrificing the security of the system.

Claims

We Claim

1. A bfockchain ledger system comprising:

a ledger built using a self-signed root block having a public key of each

authorized participant and one or more additional blocks that change a state of a transaction, each extension to the ledger including a nonrepudiation signature of one of the authorized participants; and a virtual machine used for interpreting contracts and attestation rules associated with the ledger, the virtual machine embedded in a certificate used for creating transactions in the ledger.