Startups

Blockchain Research Group Home

The Blockchain Research Group (BRG) has partnered with industry to create two startups, Simba Chain, based from the group's Aladdin Tools, and Stealth Startup, based on the group's ChainTrail tools.

SIMBAChain

Ethereum uses Smart Contracts, which are programmable pieces of code that provide a Blockchain data and logic interface. SIMBAChain's functionality centers around Smart Contracts using automated techniques and tooling that supports needed features to implement production Blockchain applications. To achieve this, it provides a model for business processes, which drives generators for Smart Contracts and REST APIs to simplify engineering. The model uses Assets and Transactions to generate a Smart Contract and API for a specific Blockchain system, supports data file saving to third party data stores, and authentication and wallet services to tie things together, as shown below.

SIMBA has two core symbiotic platforms that support the following:

The Software as a Service (SaaS) dashboard that interfaces with public networks and private development environments.
The Smart Contract as a Service (SCaaS) enterprise environment in Microsoft Azure that uses the authentication, authorization, and elastic capabilities of their cloud services.

In the SaaS user interface, Solidity Smart Contracts can be created and in both environments, REST APIs can be generated for development, described in detail below. Smart Contracts that are created in the SaaS can be exported to the SCaaS system on Microsoft Azure, using a bootstrap key. The SCaaS system operates within a secure Virtual Private Network (VPN) and has full integration with Microsoft Active Directory, described in more detail below. The SCaaS has an ``Explorer'' interface, which enables the browsing, searching and viewing of all details of Blockchain transactions for each Smart Contract that is deployed and it allows a client to define conditional notifications, with parameters on a Smart Contract method forming a set of rules that result in an email being sent or a Webhook being called, to trigger further processes (e.g. generate an event for a particular order number).

At the backend, a set of stand alone APIs, which have been developed by the Center for Research Computing at University of Notre Dame, interface with the Blockchains and data stores. These APIs are licensed by SIMBA and enable the configuration of the specific Blockchain network and data store application needs. This API is written in Node.js and the underlying Blockchain and data API adapters implement common primitives, e.g. compile contract, deploy contract, generate payload and submit signed message, etc. These high level functions map to complex code interactions on the backend to provide resilience for transaction submission e.g. a chain watcher implements a rigorous algorithm to ensure asynchronously submitted transactions are processed by theBlockchain, releasing the task upon completion, and updating and caching transactions and state accordingly, for fast search and retrieval of information. In the SCaaS, the group interfaces with an Enterprise version of Quorum using the Azure Blockchain service.

Off-chain data is often achieved by taking a hashcode of external data, and binding it into a Blockchain transaction. Hashes are non-reversible and since the \emph{content} of that data is uniquely represented by a hashcode, a signed data hashcode transaction provides a non-repudiable record that a particular dataset was transacted at a specific time, by a specific user. This ensures data integrity to establish that external datasets were not changed since they were written. SIMBAChain is designed to make off-chaining data simple, where on-chain hashes represent (multiple) files being stored in the datastore. One or multiple files can be attached to a POST (multipart form data) and by using a bundling approach, each file is stored individually into the file system with a JSON Manifest being created, to store each file hashcode and its metadata. The manifest is also stored into a file system, with its hashcode stored on the Blockchain. The system can retrieve files by using the hashcode to retrieve the manifest, and then using each hashcode to retrieve the files. Currently SIMBA supports Ceph and IPFS for the SaaS and Azure Blob Storage in SCaaS.

Smart Contract Development Workflow

The core SIMBA engineering workflow involves three steps:

To specify your business rules; that is, to specify which assets you would like to track and how you would like to track them (translations).
To use the zero-code user interface to specify these graphically and auto generate the corresponding Solidity code.
To create a SIMBA app, which will deploy the Smart Contract and auto generate a REST API to those business rules.

Where:

An Asset is a physical entity, a document, a dataset, a binary, or media elements on the Blockchain.
A Transaction points to a previously recorded asset and provides new information, typically updating its state.

Collectively, this conceptualizes the business rules surrounding a particular class of Blockchain usages e.g. primarily focused on supply chain where physical objects need to be tracked from conception to consumption. The model is specified using a simple Web-based Graph-style user interface, shown on the left part of the figure below, which enables a user to specify Assets, relationships between Assets, Transactions that record the state of an Asset, and parameters that define their payloads, as shown on right. Upon completion, this model is converted into Smart Contract code for the selected language and version e.g. Solidity for Ethereum (see right part of figure below). Multiple versions of Solidity are currently supported and the system has been engineered to make it easy to create bindings for other Smart Contracts languages also.

Once a Smart Contract is saved, the developer can then deploy it within a SIMBA App, which performs two functions. First, it takes the Smart Contract and generates a schema and REST API that represents the various methods and structures in the Smart Contract (in lower part of figure below). Methods and method parameters are stored in a format compatible with the Open API specification used by Swagger [swagger]. Second, it deploys the Smart Contract onto the target desired blockchain network.

The Smart Contract Designer, Solidity and API Generated

The API generated is completely virtual. When a user browses to the the API endpoint, we use the specification to auto generate the Swagger documentation for the contract on the fly, where each contract method being a REST endpoint with two methods: a POST receiving a payload containing parameters for the method and converting this into a Blockchain transaction; and a GET providing a mechanism of retrieving transactions and searching multiple transactions, using query strings specific to the types of data being stored e.g. a string exposes “exact” or “contains” and an “int” allows less than, equals, or greater than style searching. Similarly, when a developer invokes an endpoint to, for example, POST a transaction, the backend system automatically looks up the call, retrieves the format, performs checks, and packages the payload and associated files for stored on the underlying Blockchain and data store. This on-the-fly approach the group has taken here means that all API code is virtual and more far more scalable, since we don't have to manage physical code at all.

Stealth Startup

The BRG is currently working with the Sciath group on employing the use of some of the ChainTrail tools in the application of Crypto Trading in a Stealth startup. Most Cryptocurrency, or indeed any trading systems, operate around the notion of a Candle. A Candle is a chart that is calculated for a specified period of time (1 min, 1 hour etc.) that shows the high, low, opening, and closing prices of a certain digital currency (or normal currency or stock). Many exchange APIs use Websockets to implement callbacks at the end of each Candle window to trigger automated trading strategies (e.g. Binance API).

Trading technical indicators, on the other hand, are heuristic or mathematical calculations based on the price, volume, or open interest of a security or contract used by traders who follow technical analysis. By analyzing historical data, technical analysts use indicators to predict future price movements. Examples of common technical indicators include the Relative Strength Index, Money Flow Index, Stochastics, MACD and Bollinger Bands.

More advanced indicators have also been developed, which use external events rather than simple exchange data, to provide information to BOTs for trading purposes. An example of such an indicator is the integration of natural language processing or NLP. In the cryptocurrency market, the price of the asset can change wildly as per fundamental news like articles, tweets, and other similar content. Using NLP programming, one can inform their bots how to programmatically interpret words and phrases and analyze the underlying sentiment e.g. partnership news is usually pretty bullish. NLP processing can automate the reading of articles e.g. “Company X partners up with company Y to boost mainstream adoption,” to help steer what Crypto assets the BOT should start accumulating.

The goal of this startup is to use ChainTrail’s analytics as advanced asynchronous indicators from Blockchain data. Exchanges deal with the transferring of Assets between Blockchains or between Blockchains and FIAT, but they do not have information about the transactions that are taking place within each Blockchain. Gaining insights into internal Blockchain data transactions can help understand when certain events will happen, much like the NLP use case, and react instantaneously to those events in order to trade more effectively.

At a technical infrastructure level, therefore, PREDICT is designed to be capable of collecting data from multiple blockchains and providing a pluggable architecture for embedding processing elements, called processors, where data analytics, machine learning, AI or graph-based algorithms, can be used to process the data and output advanced so-called “technical indicators” for use by automated trading strategies.

Need more information?

For more information on the Blockchain Research Group, please contact Ian Taylor.