Introduction

A blockchain is a system for maintaining distributed ledgers of facts and the history of the ledger’s updates. A blockchain is a continuously growing list of records, called blocks, that are linked and secured using cryptography.

This allows organizations that don't fully trust each other to agree on the updates submitted to a shared ledger by using peer to peer protocols rather than a central third party or manual offline reconciliation process. Blockchain enables real-time transactions and securely shares tamper-proof data across a trusted business network.

Oracle Blockchain Platform is a permissioned blockchain, which provides a closed ecosystem where only invited organizations (or participants) can join the network and keep a copy of the ledger. Permissioned blockchains use an access control layer to enforce which organizations have access to the network.

In order to read from or update the ledger, clients invoke corresponding chaincodes that are deployed on the blockchain platform. In many cases, backend systems or other clients are only interested when data is updated/created or deleted from the ledger. Instead of actively fetching the state of the ledger on a regular basis, chaincode events can be used to immediately notify subscribers.

Hyperledger Fabric “HLF” has a built-in events service that backend systems can utilize to subscribe and listen to emitted events; however, backend systems must use HLF client SDKs (Java, NodeJS) in order to utilize the events service. Oracle Blockchain Platform simplifies things by providing a REST API endpoint that allows backend systems to subscribe with events and provide a callback URL that will be invoked with the event payload.

Although this model works, but it has some limitations. As mentioned in documentation, clients can only subscribe to events through a “Founder instance” REST Proxy; and in many cases this is not desirable as it require clients that belong to other participant organizations to have credentials defined in founder instance. In addition, you have no control on ensuring event delivery for clients, if a client missed an event for a reason or another, then there is no mechanism to receive that event back when client is back online.

In this Blog posts series, I explain how you can leverage Oracle OCI services and more specifically “OCI Streaming Service” and “OCI Functions” to manage Oracle Blockchain Platform events. The solution will also leverage “OCI API Gateway”, “OCI Key Management” and “Registry 'OCIR'” services in addition to “OCI CLI” and “Cloud Shell”.

Blog Series Parts:

• Part 1: Introduction
• Part 2: Prepare OCI Environment 
• Part 3: Build the Oracle Functions "Event Producer"
• Part 4: Provisioning your Infrastructure.
• Part 5: Configuring Blockchain
• Part 6 (Building a Consumer)

Solution Architecture

The below diagram layouts the building blocks of the solution proposed; the core of the solution is the “OCI Streaming” service which provides a fully managed, scalable, and durable storage solution for ingesting continuous, high-volume streams of data that you can consume and process in real time. Oracle OCI Streaming service is mostly API Compatible with Apache Kafka, hence you can use Kafka APIs to produce/consume from/to OCI streaming service. This leads to the next building block, Oracle Serverless offering “Oracle Functions”.

“Oracle Functions” is a fully managed, highly scalable, on-demand, Functions-as-a-Service platform, built on enterprise-grade Oracle Cloud Infrastructure and powered by the Fn Project open source engine. With Functions; you only need to focus on writing code to meet business requirements. You don't have to worry about the underlying infrastructure because Oracle Functions will ensure your app is highly available, scalable, secure, and monitored. The proposed solution utilizes Oracle Functions to host a custom developed Streaming Producer “events producer” that utilizes Apache Kafka Producer APIs, and is exposed as a secured REST endpoint using OCI API Gateway.

In order for the producer to connect to OCI Streaming service, it requires a username/password, server port, address…etc. So rather than hard-coding these in the producer code itself, Oracle Functions allows defining custom configurations “key-Value” pairs at the function level that can be fetched and read at runtime. However to properly ensure the credentials are not exposed to anyone who inspect the function configuration, the solution utilizes  “OCI Key Management Service 'KMS'” to encrypt/decrypt these credentials at runtime.

To summarize the solution flow, when an event is emitted from Oracle Blockchain platform, the Oracle Functions “Producer” is triggered through its exposed API Gateway Endpoint. The producer function kicks-in and reads the associated runtime configurations, calls out to OCI KMS to decrypt credentials and eventually connect to OCI Streaming service and publish the event. This requires you to initially subscribe the Producer function Endpoint with Oracle Blockchain Platform so it can receive the event.

In these Blog posts series, I will walk you through the steps needed to build the solution and hook it with Oracle Blockchain Platform.

Assumptions

In order to implement the solution, you need access to:
•    Oracle Blockchain Platform Instance.
•    Access to Oracle OCI Services with “Administrator” privileges.
•    Awareness with Oracle Blockchain platform features 

OCI Architecture

As explained above, the solution will utilize different OCI services (API Gateway, Functions, Streaming, KMS and OCIR), and as these services live inside Oracle Cloud Infrastructure “OCI”, you need to build the underlying infrastructure (Virtual Cloud Network ‘VCN’, Subnets, Route Tables, security Lists, Internet Gateway and NAT Gateway) and then provision these services. Below is the architectural diagram for the artifacts that needs to be provisioned.

All your components live within a Compartment which is a virtual grouping of your artifacts. You start by creating a Virtual Cloud Network ‘VCN’ to spec your network CIDR space. Within your VCN, there are two subnets, a public subnet that clients/users can access and trigger form internet; hence is configured with an internet gateway, and a private subnet that is only accessible from within the VCN, however it needs internet access to download libraries, hence a NAT Gateway is configured, but keep in mind that clients/users can’t directly access any component provisioned inside it. The public subnet will host your API gateway so you can access it over the internet, and your Function producer will live within the private subnet and will be accessible from API Gateway only.

The subnets are configured with Security Lists, which are your network firewalls to govern the access to the solution artifacts. Routing tables are also configured to steer the incoming and outgoing traffic correctly.

Within this solution, I have prepared a set of terraform scripts that will automatically provision and configure the infrastructure for you, so you don’t have to configure it manually.

Next Step

Part 2: Prepare your OCI environment