high-level overview of system architecture

System Architecture locked

The P2P Voucher System Architecture

Let's begin with a diagram:

Infrastructure3.jpg (173.10 Kb)

Next, let's define some nomenclature. On the diagram you will see all of these:

  • The Issuer: this is the party who stores the assets backing the vouchers. The Issuer is responsible for keeping track of all vouchers in circulation, assigning their serial numbers, and ensuring that the aggregate weight or value of all vouchers does not exceed the backing. The Issuer knows nothing about users or owners, only voucher amounts and serial numbers.

  • The Voucher Publisher (VP): the VP processes all voucher transactions, signs all vouchers with its private key, and encrypts each with the public key of the owning voucher safe (VS). It also issues signed usage tokens (bought with vouchers) and permits other system components to redeem accumulated tokens for vouchers.

  • The Secure Data Store (SDS): the SDS is a place to store vouchers, tokens, payments, receipts, and VS login records. The records stored on it are always encrypted and opaque to the SDS. The SDS earns tokens for storing data.

  • The Distributed Hash Table (DHT): the DHT is a place to store temporary data (defined as one week or less). It is used as an out-of-band communications medium for messages between voucher safes, or between the VP and a VS. Like the SDS, the DHT earns a token for each record it stores, and only stores opaque blobs which are public-key encrypted.

  • The Public Key Server (PKS): the PKS is a repository for two things: the public key certificate of each voucher safe in existence, and a Certificate Revocation List (CRL), upon which revoked certificates are placed when their safes are closed. It allows key lookup from any peer, while update transactions (adding or revoking certificates) can only be performed by the VP. The PKS is the house elf of its associated VP, and does not earn tokens.

  • The Openfire Server (OFS): this is the end user's doorway into the system. It is, first and foremost, a Jabber server, and handles normal chat traffic in addition to voucher system-related traffic. It has a plugin which extends XMPP to support p2p voucher messaging. The OFS manages VS logins, and once a safe has logged in successfully, provides it with network discovery so that it can access the PKS, SDS, and DHT directly. The OFS also acts as a firewall for the VP, to which users never speak directly. The OFS earns a portion of tokens paid to perform various voucher operations.

  • The Voucher Safe Client (VSC): this is a Java Web-App invoked through a JNLP file, which allows a user to log into a voucher safe and perform voucher operations.

Created by kevinw. Last Modification: Saturday 29 of March, 2014 03:46:21 UTC by admin.