MOAC Deployment Series: SCTC

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. Where to Find Us Website: https://moac.io/ GitHub: https://github.com/MOACChain/moac-core Twitter: https://twitter.com/moac_io Reddit: https://www.reddit.com/r/MOAC/ Medium: https://medium.com/moac Steemit: https://steemit.com/@moac-official Telegram(International): https://t.me/moacblockchain Telegram(Developers): https://t.co/8m3m9RD5ix Telegram(China): https://t.co/73rU9sHWLH YouTube (Event Channel):https://www.youtube.com/channel/UCBU405W7vfOPBicLwW9-QOA Youtube (Technical Channel) : https://www.youtube.com/channel/UC_U54wsGNrm_Yivj5bH9i7Q?view_as=subscriber Facebook: https://www.facebook.com/moacchain/