Full Consensus and Distributed Ledger Hardware Acceleration

Way back in October 2016, I authored a blog called BlockChain Virtual Machines with Consensus in Silicon. Some considered the concepts too forward looking or too avant-garde, especially for the #HealthIT industry.

People, the train has left the station. Full acceleration of consensus and distributed ledger processing in hardware is here now.

We just issued this press release: PokitDok Advances Healthcare Smart Contracts with Intel® Blockchain Technology.

In this announcement, I said,

"Blockchain is fundamental to the next computing cycle and will introduce new dimensions of compute power, speed, and security. In the healthcare sector, protecting patient data is paramount, as is sharply reducing blatant inefficiency, which is why we chose to work with Intel to do business on the blockchain."

Please let me elaborate:

Over the past couple of decades, there has been a confluence of technologies that lend themselves to advancing the world of distributed computing. New business models are emerging, with respect to this confluence, across the board within the areas of algorithms, software architectures, and hardware architectures. Though none have existed in one package like blockchain... .it is unprecedented.

PokitDok has been in deep methodical design and development since deploying our APIs into the healthcare market, bringing seamless enterprise development to #HealthIT. This methodical approach has focused not only on seamless development for third parties, but also on how platform as a service (PaaS) connects to the underlying blockchain architectures. We knew from the founding of the company that PokitDok would run on top of a distributed ledger technology. We also surmised the technology would need to be accelerated with core specific functionality at both the software and hardware level.

Since timing is everything, we had to wait for the appropriate time to unveil the PokitDok Platform running on blockchain technology. This was amplified by our bet as a #Python house as both Ethereum and Hyperledger, at the time, were mainly Python-based (Serpent is a variant of Python albeit I do wish Serpent had list comprehension... but I digress...).

When Sawtooth made its debut, we knew it was time to move into coding action. With Sawtooth's version 0.7 incarnation, most of the processor requirements were readily available, so we were able to create simulation compatible code. That being said, we are not satisfied with simulations. We initially developed on version 0.7 even though we knew that 0.8 was in the works. We could not delay until version 0.8.

Given there might be some folks out there who have no idea what Sawtooth is, let me highlight this quote from the embedded GitHub link:

"Sawtooth is an enterprise distributed ledger (aka blockchain) project. The design targets keeping distributed ledgers distributed and making smart contracts safe - particularly for enterprise use."

While the framework is both a software and a hardware implementation, there are interfaces that allow for different configurations for a variety of use cases. For example:

  • A permissioned network with domain-specific Non-Turing complete execution support via a business rules transaction processor. For an explanation of why this is a great idea, see our blog on Non-Turing Domain Specific Languages here
  • An open network with a combination of "static" transaction formats and on-chain bytecode using a "virtual machine" implementation (like EVM).
  • A virtual machine with opcode accounting and bytecode stored in smart contracts.
  • No currency or asset type setting.
  • Figure 1.0 The Version 0.8 Blocks of Sawtooth (via Intel)

    Figure 1.0 The Version 0.8 Blocks of Sawtooth (via Intel)


    The core of the architecture is responsible for message handling, block validation, and block publishing as well as consensus. The state management is essentially handled via global variables.

    A Family of Transactions:

    The concept of transaction families is particularly appealing because PokitDok has several different types of transactions across a wide range of data types and behaviors.

    • Transactions are wrapped in batches which provide an atomic unit of commit for multiple transactions (which can span transaction families).
    • Transactions declare input and output addresses (including wildcards) to allow for state access isolation calculations (topological sort on DAG) in the scheduler.
    • These inputs and outputs are enforced by the Context Manager on the context established for the transaction.
    • This allows parallel validation and state delta aggregation across a potentially large number of transactions (and across blocks).
    FIGURE 1.1 Transaction Processor via Intel

    FIGURE 1.1 Transaction Processor via Intel


    A Rhyme with PoET

    Although the architecture supports pluggable consensus models, the main instantiation for a consensus algorithm is Proof of Elapsed Time (PoET). The PoET consensus provides a random leader choice with the following attributes:

    • Fairness. The function should distribute leader election across the broadest possible population of participants.
    • Investment. The cost of controlling the leader election process should be proportional to the value gained from it.
    • Verification. It should be relatively simple for all participants to verify that the leader was legitimately selected.

     

    For the near term this was sufficient because DokChain is a private enterprise network with validated purchased nodes. As such, we can control the asset issuance as well as the consensus mechanics. The probability of election is proportional to the resources contributed (in this case, resources are general purpose processors with a trusted execution environment). An attestation of execution provides information for verifying that the certificate has been created within the enclave (and that the validator waited the allotted time) which also includes the code for the respective contracts.
    Given the emphasis on execution and time to market, we believe this is sufficient for most engagements. PoET uses a trusted execution environment - Intel Software Guard Extensions (SGX) - to ensure the safety and randomness of the leader election process without requiring the costly investment of power and specialized hardware. Intel claims that this algorithm scales to thousands of participants and will run efficiently on any Intel processor that supports SGX.
    Further, the performance of Sawtooth is extended with SGX. As the name implies, its main use is to guard against malicious activities. Alas, it would be nice not to have to guard against those that are malicious, but wetware currently still has malicious tendencies when there is monetary gain to be accessed.

    It is paramount to have security mechanics built into the underlying deployment and operational aspects of the respective system. However, these deployments could very well prove to be adversarial environments. We believe they will be addressed with secure enclave technologies at the processor level.

    For those unaware, the Sawtooth architecture encompasses many aspects of the trusted computing architectures from years ago. You have a hypervisor-like environment with rights management signal streams with the ability to lock the streams to the respective processor.

    At its root, Intel SGX is a set of new CPU instructions that can be used by applications to set aside private regions of code and data. Much of the motivation for Intel SGX can be summarized in the following eight objectives.

    1. Allow application developers to protect sensitive data from unauthorized access or modification by rogue software running at higher privilege levels.
    2. Enable applications to preserve the confidentiality and integrity of sensitive code and data without disrupting the ability of legitimate system software to schedule and manage the use of platform resources.
    3. Enable consumers of computing devices to retain control of their platforms and the freedom to install and uninstall applications and services as they choose.
    4. Enable the platform to measure an application's trusted code and produce a signed attestation, rooted in the processor, that includes this measurement and other certification that the code has been correctly initialized in a trustable environment.
    5. Enable the development of trusted applications using familiar tools and processes.
      Allow the performance of trusted applications to scale with the capabilities of the underlying application processor.
    6. Enable software vendors to deliver trusted applications and updates at their cadence, using the distribution channels of their choice.
    7. Enable applications to define secure regions of code and data that maintain confidentiality even when an attacker has physical control of the platform and can conduct direct attacks on memory.

     

    So, as you can see, we are extremely focused on the consumer's private data as well as the respective enterprise data.

    So what did we build?

    We have created smart contracts that are now hardware accelerated with hardware-based consensus and distributed ledger transaction processing that is fully validated and secure within a blockchain network.

    Please re-read the above and let that sink in for those that say blockchain is 3,5, 10 years out in the making. This is at the processor level.

    At @PokitDokdev we are only satisfied with fullmetal code. We also know that execution is everything and that #storyware or #slideware easily turns into #vaporware. For the MVP for DokChain, just as we did for the Ethereum instantiation, we started with an eligibility check to retain parity. Also, Identity and Eligibility go hand in hand. In the early spring of 2016, we demoed an eligibility check. For completeness, consider this flowchart:

    Figure 1.2 DokChain Eligibility Check Flow Diagram

    Figure 1.2 DokChain Eligibility Check Flow Diagram


    We knew the Sawtooth processors on the client side were compatible with the enterprise suite and available in certain models of pro-sumer laptops. For instance, if you are running a 2017 ThinkPad Lenovo, you have an enabled Sawtooth system from a hardware perspective. The chips have already been shipping at the production level.

    Here is the basic Logical Architecture we have implemented for the DokChain Sawtooth Platform. We will cover each block in detail with respect to the platform:

    Figure 1.3 Logical Architecture

    Figure 1.3 Logical Architecture


    There are five types of "actions": request for requesting authorization, authorize for giving authorization, revoking authorization, fulfillment for performing the transaction, and publishing the results of the transaction.

    Validator

    The validator should require little configuration and comes out of the box with docker containers ready to be deployed.

    Global State Store

    Sawtooth, the "state of the world," is managed by global variables. This is accomplished through a key-value store for version 0.7 and a merkle tree in version 0.8, in which messages are "applied" to the global state within the transaction family. Within DokChain, the global state store is used to manage the following:

    Temporary Request Message

    The message to request authorization is temporarily stored at the address of its nonce. This is done as a convenience for the approval process, after which it is removed from the global store. Note, however, that the message is still persisted in the immutable transaction log.

    "Work" Queues

    So that clients don't have to look at every transaction to determine relevancy, queues are used to keep track of which messages action from a certain user.

    Pending Queue: The pending queue is a list of message nonces that the entity needs to act on.
    Processed Queue: A list of nonces that the entity has taken action on.

    Wallets

    For this MVP, on-chain wallets will contain the access grants to data that the entity has authorized in much of the same tokenized methods that were used for our previous implementations.

    Transaction Families

    The transaction class must implement the following:

    • TransactionTypeName class attribute.
    • TransactionStoreType class attribute.
    • MessageType class attribute.
    • An __init__() method which implements deserialization.
    • A __str__() method.
    • A check_valid() method which throws an exception if the transaction is not valid.
    • An apply() method which updates the store.
    • A dump() method which implements serialization.

     

    Eligibility

    • Action: Available options are "request," "revoke," "approve," "fulfill," "result."
    • Nonce: Unique ID for the message
    • Member: Public key for the consumer
    • Provider: Public key for the provider
    • Clearinghouse: Public key for the clearing house
    • Activity ID: PokitDok activity ID for getting eligibility request response
    • Expiration Time: Timestamp after which the authorization expires.

     
    I want to emphasize that this provides temporal based access to the information of the identity of the user. This is extremely important as we believe that context relevant identity is key to the success of blockchain technologies.

    Behavior By Action Value

    The behavior of the transaction family is determined by the value of the action field. This behavior is fundamental to our data roadmap as we believe that behavior and what you do is essentially who you are, from a context standpoint.

    Request

    Adds the nonce as a key with the message as a value into the global key value store. The request also adds a nonce to a pending queue list at the member's address.

    Authorize

    • Retrieves the request by nonce from the global key value store.
    • Checks that the sender of the authorize message is the same as the member in the request.
    • Adds an access grant to the member's wallet and to the provider's wallet.
    • Pops the request nonce from the member's pending queue and adds it to the processed queue.

     

    Revoke

    • Retrieves the request state by nonce from the global key value store.
    • Checks that the sender of the revoke message is the same as the member in the request state.

    • Removes the access grants from the member's and provider's wallets.
    • Pops the request nonce from the member's pending queue and adds it to the processed queue.
    • Removes the request message from the global state.
    • Adds the nonce of the revoke message to the provider's processed queue.

     

    Fulfill

    • Checks that the sender of the fulfill has a valid access grant in their wallet.
    • Adds the request nonce to the clearinghouse's pending queue.

     

    Result and Logging

    • Adds the nonce of the result message to the provider's processed queue.
    • Adds the nonce of the request state to the clearinghouse's processed queue.
    • Pops the nonce of the request off of the clearinghouse's pending queue.

     

    Secure Wallet Off-Chain Store

    The secure wallet off-chain store is responsible for providing only the information needed to perform the requested clearinghouse transaction. We do see a time when this will be stored at the chip level in the secure ID process. The secure wallet service takes as inputs:

    • Public key of the entity about which to retrieve the data.
    • Public key of the requester used to encrypt the Personal Identifiable Information of the consumer.
    • The type of clearinghouse message to build the final data payload.
    • The scope of how to view the entity for the current request. For example, a health provider would return a National Provider Identifier (NPI) or a consumer would return the health ID of the respective payer or trading partner.

     
    With these parameters, the secure wallet off-chain store then:

    • Checks to see if the public key for the entity matches a PokitDok identity.
    • Retrieves the data for that PokitDok identity based on the scope.
    • Forms a JSON representation of the entity's data pursuant to the PokitDok API for the specified clearinghouse message type.
    • Returns the formatted data encrypted using the requester's public key.

     
    Clients

    The PokitDok client is the bridge between DokChain and the clearinghouse world. The client, in this case, waits for any type of transaction with respect to our platform. In the future, this will be an interaction with the SDK:

    • Ask the secure wallet off-chain store for the data needed to do an eligibility check - in this case, for both the member and provider based on public keys.
    • Submit the request to the clearinghouse platform, attached to the provider's PokitDok account, and get back the activity ID. Submit the result message with the activity ID back to DokChain.

     
    End User

    The end user client is how patients and providers interact with DokChain. They are processes that check to see if any message nonces have been added to the end user's pending queue at their address (public key) and present them with actions to "work" with the messages in DokChain. Once again, in the future, available within our SDK.
     
    Consumer Client

    • Checks for any requests in the consumer's pending queue at their address on DokChain.
    • Presents the user with the option to accept or reject the request. Sends the accept or revoke message to DokChain.

     
    Provider Client

    • Allows provider to send a request message to DokChain.
    • Displays the result of the consumer accepting or rejecting access.
    • If the request is accepted, allows the provider to send a fulfill message to the clearinghouse.
    • Links to the activity in the provider's PokitDok account that contains the eligibility data.
    Figure 1.4 Code Snippet

    Figure 1.4 Code Snippet


    The Road Ahead:

    For the healthcare industry we believe smart contracts, as they relate to identity, autonomous auto-adjudication, and supply chain management, are essential use cases for the success of blockchain and the assets that are processed. We see a massive opportunity in the assets of both the services and the content within smart contracts. We believe Sawtooth will allow acceleration and protection of these assets now and in future revisions.

    In addition, in the coming months, we will be publishing swarm performance metrics with respect to multi-node chain networks with full SGX protection enabled on the DokChain network. Furthermore we will be extending this functionality in various ways and will be publishing and discussing these core code developments in the near future.

    We are at the beginning of a revolution.

    Stay tuned, won't you?

    @tctjr

    References:

    Resources on Sawtooth:

    Code: https://github.com/hyperledger/sawtooth-core
    Docs: http://IntelLedger.github.io
    Slack: http://slack.sawtooth.me/

    Resources on Secure Enclaves:

    Arm's TrustZone:
    https://www.arm.com/products/security-on-arm/trustzone

    Demystifying Secure Enclave: https://www.blackhat.com/docs/us-16/materials/us-16-Mandt-Demystifying-The-Secure-Enclave-Processor.pdf

    Apple's Secure Enclave:
    https://www.apple.com/business/docs/iOS_Security_Guide.pdf

    Resources on Dokchain: All The Dokchain Blogs

    About Ted Tanner

    Ted Tanner is co-founder and CTO of PokitDok. Ted is an engineering executive with extensive experience ranging from startups to public corporations. Focused mainly on growth scale computing he has held architect positions at both Apple and Microsoft and has held instrumental roles in several start-ups, including digidesign (IPO and acquired by Avid), Crystal River Engineering (acquired by Creative Labs), VP of R&D at MongoMusic (acquired by Microsoft) and Co-founder and CTO of BeliefNetworks (acquired by Benefitfocus). He was also the CTO of Spatializer Audio Labs (NASDAQ: SPAZ), a company specializing in digital signal processing solutions. He is on the IAB for the University of South Carolina Computer Science Department as well as the Center for Intelligent Systems and Machine Learning at the University of Tennessee. Mr. Tanner has published numerous articles in leading technical magazines and holds several patents in the areas of semantics, machine learning, signal processing and signal protection.

    View All Posts

Leave a Reply

Your email address will not be published.