We radically simplify blockchain development, even with no previous DApp experience.
Modex BCDB enables blockchain adoption for enterprises. It connects a custom blockchain infrastructure with a traditional database engine.
Modex BCDB is blockchain agnostic with a plug and play interface layer. The overall network speed, synchronization and consensus are given by the blockchain engine of your choice. Integrations are available with multiple BC engines.
Modex BCDB is designed for both existing projects looking to move to a blockchain environment or completely new projects. The infrastructure can be connected to any relational or NoSql database engine of your choice.
A platform that enables
What is Modex BCDB
Modex Blockchain Database (BCDB) is a game-changing platform which enables blockchain adoption in enterprise software development. It connects the blockchain infrastructure with traditional database storage engines, while still allowing programmers to work in familiar remote database engine environments such as MongoDb, MySQL, etc.
Data security revolution has arrived
How Modex BCDB works
Modex BCDB implements a series of blockchain and database adapters over which the core engine orchestrates the CRUD operations, providing a REST API and TCP language specific drivers. Data is organized into entities (similar to database tables). An entity maps data from blockchain and database.
On the database level, the blockchain metadata is also stored, as well as the full data payload, based on the specific field configurations on entity creation.
On the blockchain level the metadata of a record for a specific entity is being stored, containing information such as the record ID, the signature of the record stored in the database, the owner of the record, the original node of the record and additional configurable data.
A platform that simplifies
Modex BCDB Features
Modex BCDB (Blockchain Database) is a platform which enables blockchain adoption in enterprises software product development. It connects the blockchain infrastructure with the traditional database storage engines. The BCDB workbench is familiar to developers who are already used to working with traditional remote database engines like MongoDb, MySQL, etc.
The blockchain component (Blockchain Ledger framework) can be swapped at any time with other supported blockchain frameworks (like Ethereum) – Modex BCDB is currently integrated with HyperLedger Sawtooth and Tendermint. HyperLedger Fabric and Ethereum integrations are in the testing phase.
Defaulted with MongoDB database engine for data storage. The database component can be switched and changed with a different remote database engine, traditional or NoSQL.
Each group of nodes or network can be configured specifically to the data synchronization rules within the entire Modex BCDB network. This way, one network can be RESTRICTED NETWORK or OPEN NETWORK. A RESTRICTED NETWORK will collect data received from any OPEN NETWORK but will not send any data of its own. An OPEN NETWORK will fully synchronize all the data available in the system (Send and Receive everything)
A node can be FULL NODE, PARTIAL NODE or PRIVATE NODE. A FULL NODE will collect all the data circulating in the entire network and it will make it available to any node if a request is submitted. A PARTIAL NODE will collect only data which was introduced within its own exposed APIs. Other nodes’ data will be collected and stored when required, but it will provide data to any nodes requesting it. A PRIVATE NODE will collect data from its own exposed APIs and from other nodes when required, but it will never provide any data from its storage.
Data stored within network nodes can be encrypted or not. It is a matter of configuration and business requirements which data makes sense to be encrypted and which data should remain unencrypted. The encryption mechanism allows configurations to instruct the system to encrypt entire entity records or just particular fields within a record.
Modex BCDB accepts regular file upload and offers developer interfaces for file retrieval as well. The data storage mechanism is designed to split the file in chunks and distribute them all over the network to ensure file availability but also to increase the data retrieval speed.
Modex BCDB read operations can be done by accessing the database components directly. They can also be performed through optimized blockchain core queries to obtain records with a confirmed and valid integrity check. All write operations are blockchain transactions which store references to database records location and payload hashes for integrity checks.
All data records are stored together with their historical versions since their time of creation. Every read operation can be done with a version parameter attached. This instructs the system which record version to retrieve to its caller. Record deletion happens only at the database level, meaning the actual blockchain references to records and records’ hashes are never lost. The delete operation is also marked in the blockchain trail of historical versions.
Every system user who writes data in the system can encrypt and decrypt it by using their private key which is generated at the user creation stage. The system administrator can also access this private key to unlock/decrypt system user data in case of an emergency. Traditional database engines provide access to users who can operate the data but there is no exchange mechanism between these users to access or share data between them. The Modex BCDB Blockchain Database core engine allows data exchange between its system users. The process takes place at the record write level. Each record write request is associated with a security parameter which instructs the system what is the record visibility in regards to other system users. Each record creation can have the security parameter set to PRIVATE, PERMISSIONED or PUBLIC.
A PRIVATE record will not be available to other users, while a PUBLIC record will be available to all users. A PERMISSIONED record will be available to other users to see its existence but in order to access the record, a permission request must be performed. Permission requests are sent together with the record access level (READ/WRITE) to enable the data owner to reject the request, delay the request-response or grant read/write access to the data permanently or temporarily. As soon as permission is granted, the record owners list is extended and the decryption mechanism is facilitated to the new owner accordingly. This mechanism will offer greater flexibility to client applications which can use the existing implementation as well as the classic PRIVATE data access to manage permissions at the business components level. All sensitive security operations are stored on audit trails in the blockchain.
Modex BCDB offers its client applications access via low-level API endpoints. API Interface offers data access through HTTP and/or TCP protocols secured by the OAuth2 service.
Modex BCDB has a built-in OAuth2 server which could transform the Modex BCDB beneficiary into an OAuth2 authentication provider. Integrated apps in Modex BCDB use the OAuth 2.0 single sign-on protocol to authenticate, and generate tokens for use with APIs. Modex BCDB nodes also use the same protocol to authenticate in order to join the network.
Modex BCDB OAuth2 server supports two flows for authentication: Authorization Code (used with server-side Applications) and Password (used with trusted Applications, such as those owned by the service itself)
GraphQL is a query language for API Interface, and a server-side runtime for executing queries by using a type system clients define for their data. GraphQL isn’t tied to any specific database or storage engine, instead being backed by Modex BCDB API Interface. It offers web developers a great interface to manage data access operations and serve them easy to understand front end query results.
The GraphQL endpoints are secured by the Modex BCDB OAuth2 service.
Modex BCDB provides the GraphiQL, with a graphical interactive in-browser GraphQL IDE to design data queries.
Nodes will only be started and accepted by the network if the system beneficiary licenses them. From the admin interface, licenses can be issued for each new node which is going to be added to the network.
The Workbench is an administration user-agent which supports the Modex BCDB beneficiary in maintaining the system. From the workbench interface, the beneficiary can monitor all network and network nodes, review data sharing operations, define data synchronization policies, view reports on system activity and audit trails, overwrite data access for special use cases, view blockchain records and access administration dashboard. Data owners and developers can create entities, indexes and operate stored data.
Every data record within the system can be associated with a filtered event listener which will initiate callback notifications to client software applications through HTTP/TCP channels. This functionality allows relevant data to be monitored, and trigger notifications/alerts will be raised when data is operated (modified).
A platform that simplifies
Build applications and functionalities as an extension of Modex BCDB engine. Instead of running a BCDB service in addition to a second application service on a node, encompass both functionalities, allowing fast creation of complex services on the blockchain. On top of immutable chain code benefits, SC functionality allows all customers to extend and improve BCDB core with their own custom preferences and APIs.
Java SDK for developers to allow smart contracts development using Modex IDE.
Java/Golang/C#/PHP/Python SDKs to provide Modex BCDB connection libraries for the most used development languages.
This module will allow Modex BCDB administrators to determine who will approve transactions before they are written in the blockchain/database.
A cloud infrastructure template to allow Modex BCDB networks creation and management utilities on the fly deploy. Targeted cloud providers are AWS, Azure and Digital Ocean.
Allows Modex BCDB system users to manage their private keys without having to save them in the Authorization & Licensing Network. All the private keys are stored in 3rd party secure storage environments (servers or personal tokens) accessible by the client application owners. This functionality is designed to serve highly secure organizations like military institutions or governmental software products.
Extend the SSO protocols to LDAP, SAML, external OAuth2 service providers.