Home
Authors: Delft University of Technology as initiator, possibly try to invite RvIG, Chamber of Commerce, Land Registry Agency. With a readable draft might aim to additionally include BC3 figurehead, DNB/AFM, banks, as an option even StartupDelta?
- July 10: first readable draft, distributed to partners
- July 16: partner feedback processed and alignment completed
- July 22: Scientific Journal submission!
abstract We present a blueprint to create a programmable economy, using blockchain technology as the main organisational principle, supported by key players within an existing economy. We claim that our blueprint is the first proposal based on experimental science, for each part of our design we crafted an operational prototype.
Current scientific work on economic organisation is often focused on helping society decide on the optimal allocation of our limited resources. Our proposal goes beyond the ambition of the European Union, which aims to build a European data economy linked to their "Digital Single Market" strategy. Our aim is to transform digital identity, money, trust, and markets. Each layer in our blueprint is designed to reinforce the strength, usability and profitability of the other layers. Our leading and illustrative use-case is the following value chain: the mortgage process, transfer of real-estate ownership, and selling on an open market of housing investments.
Our blueprint is ambitious, will take years to realise, and is impossible to implement by a single organisation. Like Email, GSM, and GPS, our programmable economy facilitates new business opportunities and alters existing business practices. First, we outline a solution for the digital identity problem using a blockchain and self-sovereign identity prototype with end-to-end cryptographic integrity checks, avoiding data honeypots, and void of central gatekeepers. Second, we outline our ideas to re-architect the existing banking system for sub-second electronic business transactions, beyond the current slow and costly money transfers. Third, we provide a realistic roadmap to upgrade the trust and two-way rating system used by renting platform Airbnb and other pioneers to a global public infrastructure with ability to rate any legal entity, offering full openness, and storage on our tamper-proof blockchain. Finally, based on trustworthiness reports, trust calculations, and sub-second money transfers we demonstrate our Internet-deployed decentral marketplace can trade any asset and can be applied to any value transfer network.
- General storyline.
- current 2nd generation stuff (bitcoin,ethereum)
- next generation vision: scalability and distributed database paradigm
architectural outline for BC3 vision. Existing proposals for Bitcoin and Ethereum aim to build an entire socio-economic ecosystem from cratch. So far they failed.
Stated in [REF]: "the present economic systems are highly centralised in nature. They are prone to single point failures, i.e. a failure by the central authority has a cascading effect on the whole economy. Moreover, due to the centralised nature of the setup, any failures have to be corrected by the central authority alone. Local solutions can only be temporary in nature. Thus, self-correcting mechanisms are lacking in a centralised (i.e a central bank) economic system."
First we need to address the digital identity problem. ToDo: expand.
Second we provide a roadmap to transform our usage of money. By reengineering and building upon existing antiquated payment systems we provide a realistic, legally compliant, and efficient overlay. Re-use the existing infrastructure and transform it into loosely coupled autonomous entities. We provide a proof-of-principle for making international money transfers with sub-second speed, near-zero commissions, instant clearance, and real-time settlement. No progress is possible without a transformation of our expensive transaction network build in 1970s (swift) using a programming language from the 1950s (cobol).
We propose to re-organise parts of the global economy by using the following three rules: replace central decision making with decentral supervision {e.g. in Dutch 'horizontaal toezicht'}, and digital ostracism for rule breaking economic actors. We propose a new decision making doctrine: uncompromising transparency, full openness, and radically decentralised. We believe our blueprint to take many years of effort, but still viable, realistic, and based on technology which is already partly implemented and validated.
Our programmable economy blueprint consists of a natively-digital economic system with self-governance to avoid any single-point-of-failure, security grounded upon the laws of physics (avoiding software), radical transparency, publically verifiable claims on economic actors within the blockchain, reputation tracking for each economic actor, elaborate mechanisms to establish trust between strangers, legally frinctionless enforcable contracts, and facilitate a single blockchain-regulated digital marketplace for generic economic value exchange and any-asset trading. Digital ostracism or ecosystem banning is our cardinal mechanism to incentivise each participant to contribute towards a global desirable outcome and protect against freeriding, fraud, and abuse.
We outline a trust-based blockchain architecture, present partial implementation results, and show the possible usage, for instance, land ownership transfer. The scope of our proposal is broad, it should be usable across sectors and possibly replace paper-based procedures. In August 2007 we launched a primitive fully distributed ledger. Based our ledger deployment experience of the past decade we present a global architecture of a third generation blockchain fabric. This technology stack covers the complete range from low-level hardware with our Physical unclonable function prototypes towars our blockchain-regulated decentral marketplace.
Traditionally, inter-organizational coordination is realized through one out of the following methods:
- by bilateral agreements: easy to arrange (sometimes within a single day), most often used for single transactions (buying a single product or service), not always the most economically efficient outcome; often along existing relations
- using tenders: for larger, more expensive and/or long-term contracts: more difficult to arrange (may take months), if broadly announced, possibility to obtain most economically efficient outcome; significant risk regarding trust issues
- through a specialized open market/platform (e.g. power market, AirBnB, eBay, expedia, AMT): if there is a market, this can be quite fast to arrange, and if the traded products are not too complex, often efficient matches are found: trust is taken care of by the market operator/authority; however it takes a lot of effort to set up such a specialized market place
Each of these existing methods perform poor on one of the following criteria: efficiency of allocation / time to agreement / trust-risk / initial set-up costs.
As processes within companies get more and more efficient by automation, there is also a strong demand for increasing the efficiency and reducing the time to agreement with other organizations. For example, a demand for high frequency transactions occur when:
- logistics: exchanging transportation tasks
- information exchange: coordination of charging slots: EV routing
- coordinating use of (scarce) capacity on an infrastructure: Frits, Rens, Joris
We present a feasible system architecture for efficient, fast, and secure usage of blockchain technology to coordinate existing businesses.
- ICO crash and ecosystem failure
- chronic darknet and tax evasion currency
- fancy Edifact,XML,json replacement
- underhyped: new paradigm for identity and global trust
The National Bank stated that if the blockchain is the answer what is the questions.
- cybercurrency versus blockchain database (.js)
- yet another distributed database model (Hierarchical, relational, NoSQL, graph-based,..)
- new: permissionless, no servers, no central governance
- new ownership model: nobody owns the blockchain-database
BAG register as currently open linked data [inspiration REF].
To be determined: offline identificatie van mensen die bepaalde rechtspersonen mogen representeren. Openbaar electronisch handtekeningen register; waarin elke bedrijf kan registreren welke natuurlijke personen bepaalde authorisaties of verantwoordelijkheden dragen. Bijvoorbeeld Onderneming X verklaart dat persoon Y tekenbevoegd is voor financiele verplichtingen tot bedrag Z.
Our BC3/Delft technology portfolio / stack / architecture consists now of:
- PUF (REF: Modeling SRAM start-up behavior for physical unclonable functions)
A physical uncloneable function (PUF) is a physical device that is easy to manufactor but practically infeasible to duplicate, due to process variation of the integrated circuit in the device. Their typical usage can be found in applications, requiring a high level of security, for instance, self-sovereign identity. The devices offers tamper-proof and safe storage of cryptographic keys. Each PUF device contains an unique fingerprint, determined by the randomness of embedded components. A PUF responds to challenges and leads to unique but unpredictable responses, together forming a challenge-response pair (CRP).
A key-storage system based on a PUF can be built in the following way. The mechanism proceeds in two phases, the enrollment phase, where a key, based on a PUF fingerprint is generated and stored and the reconstruction phase, which restores the secret key that was generated during the enrollment phase. This process is displayed in Figure x.
- Enrollment phase: first, the reference response of the targeted PUF is measured. This response is used as input for the Fuzzy Extractor, which consists of a privacy amplification module and ECC encoding. The privacy amplification module converts the PUF reference response to a usable cryptographic key. Additionally, helper data is computed using error-correcting code (ECC) encoding and stored in memory attached to the device. This helper data itself is not sufficient to restore the secret key and is used during the reconstruction phase.
- Reconstruction phase: reconstruction starts by measuring the PUF response, which is used as input for the Fuzzy Extractor. The helper data, generated during enrollment, is used to perform the information reconciliation and generates the PUF reference response. After privacy amplification, the programmed key is restored.
PUFs can also be used for identification purposes. An authentication mechanism based on CRPs works as follows. The entity that aims to verify users based on a PUF, produces the device and stores an initial set of CRPs securely in his database. Next, the device is given to the user. When the user wishes to authenticate himself, he presents the PUF and the verifying party, in possession of a set of CRPs unique to this device, sends a random challenge to the device. If the PUF provides the correct response, the user is authenticated. Since cloning or mathematical modeling of the device is non-trivial, this is a secure mechanism to use for authentication.
For TUDelft publication on PUF technology: "Modeling SRAM start-up behavior for physical unclonable functions"
- self-sovereign identity system for people, organisations and objects
- identity governance, claim verification and selective attribute revealing
- biometric-based authentication of people and legal representatives
We present a mobile biometric-based authentication system that does not involve any central authority or specialized, licensed hardware. An proof-of-principle mobile application has been developed for Android, capable of matching fingerprints using the built-in device camera. This work provides a solution for portable trust and our framework has been specifically designed to serve as a building block for a self-sovereign identity solution.
The algorithm for fingerprint acquisition is divided into three components. First, the user opens the application and takes a photo of his or her finger inside an elliptic-shaped area. TODO finish
https://arxiv.org/abs/1706.03744
Operational open source framework, with low accuracy (proof-of-principle).
- elastic persistent storage of data, metadata, and versioning services
- transitive trust and real-time incremental reputations for any entity
- TrustChain: transaction storage fabric and self-governance
The TrustChain transaction fabric is designed around the notion of agents performing transactions with each other. In comparison to traditional blockchain constructions like Bitcoin or Ethereum, each agent in the TrustChain network maintains and grows their own chain of historical transactions. We now discuss the creation, storage and dissemination of transactions recorded on TrustChain.
Figure x shows a transaction record which is the output of an interaction between user A and B. Both users cryptographically sign this transaction, acknowledging that they agree with the transaction. After the signatures are placed, both users persist the transaction data to their local storage.
A natural way to organize transactions is to chain them together. Transactions are stored in a blockchain data structure where each block contains exactly one transaction, both signatures of the interacting agents and a pointer to the prior block in the chain. This pointer is the hash value of the previous block in the chain (any secure hashing algorithm can be used for this purpose). This idea is illustrated in Figure x. Furthermore, each block is accompanied with a sequence number, uniquely identifying the specific block in the chain. Each user creates a genesis block and keeps track of their own transaction history. Every transaction block is present in the chain of both transaction participants.
The data structure in Figure x is void of any control by other users. As a consequence, a user is able to tamper with their chain of transactions by inserting, removing or reordering records, without being noticed. The integrity of this new transaction chain can be restored by recomputing all prior pointers. In this situation, users are unable to prove malicious modifications of one's chain. Users might also choose to not append a transaction to their local chain, i.e. if this transaction has a negative impact on this user.
This vulnerability is mitigated by including an additional pointer in each block, see Figure x. This pointer is a reference to the prior block in the chain of the other transaction participants. When two users are interacting, their chains get intertwined or entangled. This mechanism strenghtens the tamper-proof property of TrustChain. As presented in Figure x, each block has two incoming and two outgoing pointers. Note that this scheme can easily be extended to support transactions between more than two participants, by incrementing the amount of outgoing pointers in a block.
As users complete transactions with each other, they become quickly entangled with other users. Figure x shows a part of the distributed TrustChain ledger. Seven blocks, created by seven participants are displayed, together forming a directed acyclic graph (DAG). Again, note that each block contains exactly two incoming and two outgoing pointers.
Before a new block is added to a chain, a validation process takes place to verify the consistency and integrity of the local chain. This validation includes a verification of the pointers, hash values, transaction data, and signatures . Only if the aforementioned checks pass, the block is appended to the chain, committed to the local storage and optionally shared with other users.
Our approach differs from second generation blockchains in various ways. Instead of a global, consistent and distributed ledger, every user maintains a personal history of interactions where in most blockchain-based systems, there exists one ledger which is acknowledged by a majority of the network participants. Consistency is achieved by a consensus mechanism like proof-of-work or proof-of-stake. While network consistency is essential for a cryptocurrency system to prevent the double spending attack, it is not a hard requirement for a generic transaction ledger. In essence, we do not aim to prevent fraudulent operations but rather be able to detect them afterwards during the verification stage when appending new transaction records to a local chain. The absence of a global consensus mechanism allows for superior scalability with regard to transaction throughput since parallel transaction processing is inherently possible in TrustChain.
TrustChain blocks are designed to be disseminated and replicated in the network. In particular, this is important when using a transaction history as input for a reputation mechanism (see Section x). Additionally, this makes the system resistant against network churn where users go on- and offline at a fast rate. Each user operates on their own bulk storage of blocks, resulting in partial storage of the global graph. Collecting information of other users is challenging due to the vulnerability to various attacks, their limited resources and the burst of their interactions. Prior work investigates this problem and propose solutions for reliable and secure record collection .
TODO: misschien hier nog wat afsluitende woorden over TrustChain? Bijv: we envision TrustChain as a generic transaction ledger, used on a large scale bla bla...
-
Business primitives: legally binding identification, authentication, signatures, irrifutable notifications, business transactions, archiving, contracts, e-invoicing, e-factoring, and IFTTT logic.
-
real-time IBAN/BIC money transfer, conditional payments, currency conversion, clearing, and settlement
-
decentral blockchain-regulated markets
We present a feasible system architecture for efficient, fast, and secure usage of blockchain technology in existing businesses.
We now focus on the performance of TrustChain by quantifying the rate at which transactions are processed and stored. The transaction throughput of other blockchain-based ledgers is often constrained by the requirement for a consensus mechanism. For instance, the need for a consistent blockchain limits the theoretic transaction throughput of Bitcoin to around seven transaction per second. Financial service providers like Visa and SWIFT are processing thousands of transactions every second .
TrustChain has been implemented in the Python programming language, available as open source library and is built upon our network overlay Dispersy, providing primitives for network communication, persistency and data synchronization. To store records, an SQLite database is used. We integrated the TrustChain architecture in Tribler, our decentralized peer-to-peer file-sharing platform. The goal of this integration is to provide an accounting mechanism for bandwidth when users exchange data.
For this experiment, we process artificial transactions on personal computers, namely an iMac (2013), a MacBook Pro (2016) and a Dell Precision M4600 laptop. Additionally, we run TrustChain on aged Android devices, namely a Nexus 10 tablet (2012), a Samsung Galaxy S3 (2012), a Nexus 5 (2013), a Nexus 6 (2014) and a Galaxy Nexus (2011). We deliberately included older mobile phones in our experiment to assess the performance of TrustChain in an environment with constrained resources and computation power. The experiment proceeds as follows: on a single device, we initiate two sessions and start creating transactions between these session. In order to successfully create and store a transaction, communication between transaction participants is necessary due to the required digital signatures in a record. The experiment starts with an empty durable storage and we stop the experiment when there is a total of 25.000 processed transactions.
The experimental results are displayed in Figure x and y where Figure x shows the TrustChain performance on personal computers and Figure y considers transaction throughput on mobile devices running Android. In both figures, the horizontal axis denotes the time into the experiment in seconds and the vertical axis indicates the number of processed transactions. The slope of the line at a specific point in time denotes the transaction throughput speed. Comparing Figure x and y, we conclude that transaction throughput is significantly slower on Android devices due to their limited hardware capacities.
With subsequent database growth the insertion overhead somewhat increases. The most likely explanation for this behaviour is that each insertion requires a database query to fetch information about the latest block of a specific agent, an operation that slows down as the database size grows. Further database query optimization will most likely reduce this problem.
The differences in transaction throughput between Android devices is more significant than those of personal computers. The Galaxy Nexus phone gives the worst transaction throughput (on average, 1.6 transactions per second) whereas the throughput of a Nexus 10 tablet surpasses that of other mobile devices (on average, 4.9 transactions per second). The first 1.000 transactions are processed at a much quicker rate on all devices. On the Nexus 10, this averages to 54.8 transactions per second and on the Galaxy Nexus to 28.7 transactions per second. The slowest personal computer, the Dell Precision M4600, gives an average transaction throughput of 18.1 transactions per second.
We should note that this experiment does not provide knowledge about the network-wide transaction throughput but rather from the perspective of two interacting users. While systems like Bitcoin or Ethereum have a constant network-wide transaction throughput due to consensus mechanisms, the transaction throughput of our system scales with the number of users in the network. Concluding, TrustChain is capable of handling all current Bitcoin transactions on a moderate Android device or personal computer.
As an example of the broad applicability of a trust network, please consider the following coordination problem. Electric vehicles (EVs) have a limited driving range defined by their installed battery capacity, which is limited because batteries are large, heavy and costly. Consequently, for longer drives they need to recharge, in a way similar to the refueling of fossil-fuel-based vehicles. Very different, however, is the time it typically takes for such a refill: for EVs this can be anywhere from 30 minutes to several hours. This is a problem in particular when the capacity at recharging stations is limited: if a driver arrives at a charging station (with an almost empty battery) and has to wait for another car to be charged first, this has a significant effect on the total travel time. Apart from the solution to design such charging stations for peak capacity requirements, solutions have been proposed to better coordinate the time and location where vehicles charge.
For example, a charging station could offer a reservation system where drivers can book a charging slot in advance as soon as they know at what time they will arrive at the station []. Such a system would require only bilateral trust and systems like these have been around (without a blockchain) for many years, e.g., for administration purposes at governmental front desks, restaurants, etc.. However, this system leads to significant inefficiencies when arrival conditions are not completely certain. In particular this holds for travel times, since these may be very uncertain especially around peak times when such reservations matter. Reserving a larger time window introduces extra (lost opportunity) costs on the side of the charging station, or booking a later slot introduces extra costs on the side of the driver.
Another solution is a cooperative one where all drivers share and coordinate their charging plans among themselves []. Previous work has shown which algorithmic solutions can be used to combine stochastic information based on historic travel information with stochastic policies for routing and charging, and how this can be used for coordinating these policies. What is still missing, though, is a system to reliably exchange this information.