MOAC Deployment Series: SCTC

Published in

MOAC

13 min readSep 10, 2018

SCTC provides an ecosystem for the auto industry which circulates value and shares data between chains. SCTC plans to combine Parity and Polkadot into a single collective. The technology is currently undergoing development and is planned to be released in the third quarter of 2019.

Polkadot is a scalable composite multi-chain platform (meaning multiple types of chains can connect to the network) that focuses on maintaining the validity of all state transactions so that the main chain (relay chain) can continuously process transactions. The Polkadot network provides a pooling security model (consensus and service) through the relay chain. The relay chain allows other Parachains (chains capable of parallelization) to connect to it and share in the network’s security (consensus).

Any parachain can send and receive transactions through the relay chain. A key component of the Polkadot network is its ability to simultaneously transmit value (tokens) and arbitrary data. For instance, a smart contract in the auto finance chain can send a transaction stating “this car has already been paid for,” allowing the manufacturer to begin production. In addition, Polkadot allows bridges (virtual chains) to be used on currently existing blockchains like BitCoin, Ethereum, and Hyperledger.

The diagram below explains the SCTC core chain’s infrastructure and different participants the SCTC ecosystem provides consensus and maintenance services for.

1. The SCTC core chain assists in connecting to chains in the SCTC ecosystem and the bridge chain (virtual chain) that connects SCTC to the Polkadot network.

Above is a real-world example of the SCTC core chain in action, connecting parachains in the SCTC ecosystem, and the bridging chain (virtual Parachain) that connects the SCTC backbone to the Polkadot network. Below is a description of the components and participants shown in Figure 1. Figure 1: The SCTC core chain, which assists in connecting chains in the SCTC ecosystem, and the bridge chain (virtual chain) that connects the SCTC main chain and the Polkadot network.

1. The SCTC Core Chain

The SCTC core chain is a state and account-based system that features a transaction counter. The SCTC core chain will maintain main accounts in the network. The SCTC core chain won’t contain traditional smart contracts created by network users. Rather, these user-created smart contracts will be stored and used in parachains. The SCTC core chain will have fundamental smart contracts to facilitate functionality, for instance equity interfaces, shareholder bond management and parachain registration. Fees in the SCTC core chain are already set, and therefore won’t change depending on network requirements. If the scale needs to be expanded, the relay chain can join the network, becoming a second-order relay chain.

2. Parachains

Parachain refers to a custom state machine (the brain of the system which can change the chain state to a new state). It features user-defined attributes, customizable feature, and uses the SCTC core chain to reach consensus. Parachains can be added to the SCTC core chain by network users, and are estimated to be capable of 1,000 transactions/second. Adding parachains will incur costs in SCTC tokens. SCTC tokens can be locked in a smart contract or destroyed depending on the situation, which will be determined by the managing system. A few examples of parachain state machines include:

(1) Zero-Knowledge Proof chains (ZKP) like ZK-SNARKS or ZK-STARKS, which achieve anonymity/privacy

(2) An alliance chain where only the auto manufacturer can send transactions or create smart contracts

(3) Licensed A.I., which can simulate inventory management data to detect fraudulent activity and send messages to other chains in the SCTC ecosystem.

3. Bridges (Virtual chains)

Bridges are a two-directional communications systems that are useful in inter-network interactions. Once the SCTC core chain finalizes a block, it can use the transaction to pass the block to the network bridge. Custom bridges to transfer value and arbitrary data from the SCTC system to other networks have been developed for other types of blockchains. In addition, SCTC will use the Polkadot network to transmit messages and values to the Polkadot bridge through the SCTC’s core chain if needed. Private chains can also be linked through bridging, like the IBM Hyperledger chain and Hyperledger smart contract, in addition to accessing authenticated data sources It also provides smart contracts in the SCTC ecosystem.

4. Participants in the SCTC Core Chain

Participants join in the 3rd stage after economic analysis.

5. SCTC Core Chain Consensus

The consensus engine will facilitate submission of the final block to the SCTC core chain. The SCTC core chain’s consensus engine locks the SCTC core chain’s blocks as well as the blocks of all parachains. It also simultaneously confirms that all blocks can provide high-data availability while minimizing latency for the entire system. The SCTC core chain will use a customized DSC format (Dynamic State Consensus) and the Tendermint Engine for its consistency algorithms. These are BFT consistency algorithms currently being developed by Penta and Tendermint. Details concerning the methods DSC and Tendermint currently use to achieve consensus is are given below:

(1) DSC uses the random classification algorithm RSA to select stakeholders in the network to provide consensus for the target parachain and relay chain.

RSA is an algorithm that can randomly select objects from a random sample. For instance, if the target sample lists the numbers 1–1,000, then the RSA can randomly select a number from between 1 and 1,000 every time its used.

(2) A verifier is used to conduct voting during the consensus process, but every verifier only has one vote during the consensus process, while the verified stakeholder determines the weight of the vote. This method increases the fairness of the system, allowing stakeholders with smaller revenues to participate in the voting process, thereby increasing the decentralization of the process.

(3) Using the Tendermint method to submit blocks implements voting and submitting transactions to block (see Figure 2).

(4) According to Figure 2, above, The verifier group is selected through RSA to end the blocks on the parachain and form candidate blocks for the SCTC core chain.

(5) Verifiers run the following procedure to submit the final block of the relay chain. The consensus process is as follows:

If two-thirds of the verifiers vote to advance in the same round and pre-submit a block (requires two rounds), the new block will be submitted to the blockchain. Tendermint assumes that one-third of the verifiers are Byzantine, ensuring Tendermint’s security while not submitting two blocks at the same block height. If the block can’t be submitted, the protocol will proceed to the next round, and different verifiers will recommend blocks for the next block height.

The number of stakeholders participating in the SCTC core chain consensus process will but will still be further developed depending on how many verifiers participate in the network’s consensus. Verifiers and incentives of other stakeholders in the system will represent their personal interests, and will depend on their role in the consensus process. Consistency algorithms will promote finality while avoiding forks. The ability to reset the consensus process (restarting the consensus process if malicious activity is detected or no consensus is reached within a specified time frame) provides a way to avoid incorrect behavior that may occur during the block consensus process. RSA will be used to select a new random sample of verifiers when the reset function is used.

The SCTC custom consistency algorithm will provide a highly decentralized BFT consensus engine for the SCTC core chain, which will supply participating stakeholders in the system with a scaled reward for SCTC equity. In addition, by voting instead of directly connecting to the shares of consensus participants, the ability to use the reset function to recover the block increases fairness if incorrect behavior is detected. With the upcoming release of Polkadot technology, SCTC’s implementation of DSC and Tendermint will be further refined to provide consistency with the Polkadot system and SCTC ecosystem user experience.

SCTC Chain Data Storage System

The lower-layer storage system that was chosen to be integrated into the SCTC blockchain ecosystem is called BigchainDB. BigchainDB was originally a blockchain-based intellectual property (IP) authentication system that provides an interface for registering and transferring assets on the BitCoin network. BigchainDB combines key advantages of the corporate distributed database system MongoDB with the BFT consensus Tendermint to provide a truly immutable, low-latency, high-performance, secure and decentralized trading system.

Structured and Unstructured Data

Data entering the SCTC ecosystem exists in different forms and data structures. In general, we refer to data that can be stored and queried into structured data and unstructured data (Figure 3).

Besides the physical storage of data (for example, a set of linearly contiguous data that isn’t fragmented for storage like in a file system where hard disks can be fragmented), we need to understand how data entering the SCTC ecosystem is created and defined so that our system can query and process the information contained therein. An example of structured data is an excerpt describing the car mode of a car that serializes associated data using a JSON-based format as shown in Figure 4. The car structure is a sample data model that can be used to populate assets and metadata. In contrast to structured data which uses standard data models to facilitate information sharing and system interoperability, unstructured data is encapsulated in binary rather than live data objects. The database management adds a generic data structure which stores a collection of unstructured binary data as a single entity called a BLOB, with a BLOB representing a large binary object. Blobs are typically multimedia documents (e.g., images, videos and other document files stored as binary files) and need to extract and convert the underlying information stored within the binary object.

The car data model shown in Figure 4 is defined by the W3C Automotive Working Group, which was established in 2015 to promote the use of concept sharing structures over networks. This philosophy is part of W3C’s network standardization. Standard classification systems are provided to classify files for interoperability and information sharing. SCTC will use the web standards published and used by the automotive industry to exchange and store structured data in BigchainDB.

2. Integration into the SCTC Ecosystem

The first step in writing data into BigchainDB is accessing the BigchainDB network. The example transaction mentioned in this section was made using the BigchainDB test network, but we expect to incorporate a private BigchainDB cluster in Phase 1 of SCTC implementation. No matter which BigchainDB network you use, there are many drivers and tools available to help connect and trade on the BigchainDB network.

The BigchainDB network consists of a set of 4 or more BigchainDB nodes (BFT requires at least 3 nodes to be online at any time), where each node is managed independently by a member running an instance of the BigchainDB server. Members are the party responsible for establishing their own nodes. Nodes in the BigchainDB network consist of three components: the BigchainDB server, the Tendermint core and the MongoDB (Figure 5). In addition to protecting and locking the infrastructure of each node, the node is required to open BigchainDB’s API to the public by configuring its firewall to accept inbound connections on ports 9984, 9985, and 26656. Each node is identified by its host name, the node ID, and the server’s public key.

Figure 5: This depiction of a BigchainDB 4-node network consists of three parts: MongoDB, the BigchainDB server and the Tendermint core, all installed on a Linux system. Source:https：//www.bigchaindb.com/whitepaper/

BigchainDB HTTP API provides an interface for HTTP GET transactions, transaction output, transaction assets, transaction metadata, verifiers and block retrieval. Here’s a short example of sending and retrieving two transactions to the BigchainDB test network. Figure 9 shows the application API credential settings and requirements for trading on the BigchainDB test network.

Using API credentials and the selected driver, the payload is created by defining the information (crypto assets and metadata) to be sent to the BigchainDB network, then the transaction is signed using our private key. We prepare the transaction by populating the prepare_creation_tx object, which is then sent back to the BigchainDB network.

Then the transaction is sent to the BigchainDB test network.

>>> sent_creation_tx= bdb.transactions.send_commit(fulfilled_creation_tx)

BigchainDB has two types of transactions, Create and Transfer, which have the following characteristics:

{

“id”：id，

“Version”：Version，

“Input”：Input，

“Output”：Output，

“Operation”：Operation，

“Asset”：Asset，

“Metadata”：Metadata}

id indicates that a typical blockchain transaction ID uses the transaction hash value SHA3–256.

Version indicates the BigchainDB transaction for verification purposes (version 2.0, beta 5 was released on August 1, 2018).

Input represents a list of transactions inputs — similar to the BitCoin UTXO model — where the ownership of the asset is based on the output of the previous transaction.

Output contains a list of transactions and business standards that must be evaluated to allow the output to be used or transmitted. The output contains the conditions, public key list and the amount, representing the number of shares associated with a particular output.

Operation indicates the type of transaction (“create” or “transfer”), which determines how the transaction will be verified.

Assets represent physical or digital objects in BigchainDB. Example assets include examples of the above-described cars in Figure 7, which represent the car itself, claims, tokens, versioned documents and state machines, such as role-based admission control (RBAC) and the like.

Metadata allows supplementary data to be added to the transaction. In contrast to data stored in the asset field, metadata can be updated with future transactions.

3. Adding Structured Data to BigchainDB

Allow us to assume that Clark registers his car digitally on BigchainDB in a “create” transaction, and the vehicle is transferred several years later to Louis in a “transfer“ transaction. The “Create” transaction input contains information that Clark (shown by his public key) contains in his car registration. As expected, the transaction contains an associated digital signature generated by Clark’s private key for verification information and registration from Clark (Figure 7).

Figure 7: Example of a “create” transaction for a car registered on BigchainDB.

The assets in the transaction provide a numerical representation and summary of Clark’s car, including the Vehicle Identification Number (VIN) and other information defined in the JSON representation of the asset object. Metadata shows any additional information that the application developer designed and integrated into the API for submitting the transaction.

For instance, it may include the vehicle’s historical maintenance data, total mileage, complete maintenance record data, and any incidents or police records associated with the VIN.

The metadata in the “create” transaction shown in Figure 7 represents a historical overview of Clark’s vehicle maintenance record. The transaction ID is a hash of all the information contained in the transaction (i.e. the input, output, operations, assets, and metadata fields) that will be used as a reference for the transaction in future transactions. The “create” transaction’s output specifies that Clark (specified by his public key = display) is the official owner of the registered car.

If Clark wants to transfer ownership of the vehicle to another user, Louis, the input to the “transfer” transaction will contain reference information for the “create” transaction’s output. The reference essentially confirms that this is the amount that Clark will spend when transferring the vehicle to Louis. It contains a signature with Clark’s private key to prove that Clark is fulfilling the conditions for transferring ownership of his vehicle to someone else. The “transfer” transaction’s output specifies that Louis (represented by his public key) is now the official owner of the registered car (Figure 7).

Figure 8: Example of a “transfer” transaction for a car registered on the BigchainDB. Note that the metadata has been updated (including other maintenance records and the second owner) and the output contains the name and key of the transmission.

The asset field is immutable, and also contains the same information contained in the “create” transaction (i.e.VIN and other fields related to the car haven’t changed). The metadata may also change abruptly. Several years have passed in the example shown in Fig 8, and thus the vehicle maintenance and history information are updated accordingly.

4. IPFS

The Interplanetary File System (IPFS) provides the ability to store unstructured data, such as files, videos, and other metadata. Originally developed by Juan Bent, IPFS provides an addressable distributed storage system for P2P content. Content undergoes hash processing when uploaded to IPFS. A hash file then converts the file into a fixed string that represents the original content. When searching for files in an IPFS network, a hash is requested by broadcasting a request to surrounding nodes instead of a file name to a legacy system (eg HTTP). Using hashes instead of file names reduces reduplication and creates a high integrity system (by changing the hash if the file changes). In IPFS, Raft 41 is a consistent algorithm used to ensure that each node within an IPFS cluster is consistent over the same chronological state transition series. The Raft consensus runs outside of other SCTC algorithms, and is primarily used to maintain consistent reduplication of log entries across all nodes in an IPFS cluster.

SCTC will utilize IPFS clusters to provide SCTC ecosystem users with access to local information on the SCTC network, such as information from oracles (weather information and traffic reports) as well as carpool history, vehicle history and user reputation scores. If SCTC’s BigchainDB users want to further back up their data, the IPFS cluster can also be used as a backup system for BigchainDB. Users of the SCTC ecosystem can also choose to participate in the SCTC network from home by providing disk storage from their home computers.