Technology
If you are interested in our technology, then you are a multi-party consortium or a large non-profit with partners looking to add private and secure collaborative technologies to your existing digital infrastructure.
While adopting our technology does not pose a hurdle from a technical sense, we caution underestimating the multi-party legal, financial, social and other such softer concerns. In our experience, this type of change takes multiple years and can be expensive. Most distributed ledger projects have failed due to lack of continuing budget, and due to legal and financial disagreements between consortium members.
If you believe you have the need and committment for a large multi-faceted technology project, then please reach out to us. Please be aware that given the scale of committment and time we do not provide free proof-of-concepts, demonstrations, consultation, or pilots.
Architecture
Lets start with software.
Our span of our software extends from the API layer that interacts with the web-app/mobile app/desktop-app (app from now on) to the distributed ledger database. Within this span, the functionality of the system is delivered by scalable, fault tolerant, choreographed microservices. One can generally group these services into three loose groupings:
- The Distributed Ledger: a single node of the ledger, which is a NoSQL database and the associated microservices. The node communicates with other nodes in your consortium or multiparty group. As such our system can be used only for 'permissioned' blockchains.
- Application Services: these provide services to the app. These services include native capabilities that the technology provides such as secure data storage, sharing, and more. Also, these service deliver critical privacy and data security capabilities. Those who need web-application capabilities beyond those natively available will need to write custom microservices that fit into this grouping.
- Node Controller: These grouping of services lie between the application services and the distributed ledger. Similar to the ledger, these are distributed and will be hosted by multiple members (if not all) of your consortium or multiparty group.
There are a few critical aspects to note:
- The distributed ledger was developed in-house and can be tuned in multiple ways if you are looking for a full span custom implementation.
- The logical groupings of services are unaware of the existence of others. At a granular level, none of the services are aware of others.
- The backend is natively built for disintermediation and can massively scale. For those who are looking to custom develop, monolithic development is strongly discouraged. You may as well start from scratch if you adopt a heavy monolithic approach.
- Orchestration of microservices will generally not work (unless you are writing your own) as the out of the box microservices are choreographed.
- Microservices are expected to be just as the name suggests - Micro or better Nano.
Additional aspects of the software architecture such as languages used, databases, choreography implementation, and more are trade secrets. You will need to enter into legal agreements with us to discuss these finer details. Sounds like a shame, but we are a small company with a fully in-house built valuable product which we need to protect 😐
Hardware implementation: To generalize
- If you are hosting a node of the ledger, then the node needs to be deployed on-prem, in your private cloud, or some hybrid. You will need to deploy our specified security requirements (which meet or exceed financial IT security requirements).
- Similarly, the node controller services can be deployed either on-prem or in your private cloud, with stringent documented security specifications.
- The application services do need to interact with your enterprise systems; one example being reaching out for identity and authorization. These application services being closer to your existing enterprise services will require architecture design on your part to answer 'how to implement these?' Unfortunately, we can't make this 'easy' as enterprises follow a multitude of ways of hosting and walling-off vendor software.
Please note that we do not offer a cloud service implementation of any or all parts of our backend. You will either need to host in your datacenter or on your private or hybrid cloud, or some combination.
From a deployment standpoint, our microservices can be deployed like any other: the preferred option is using container based deployments, which we assume you already use in your existing infrastructure. Services can be deployed without using a container approach, but this is not recommended.
There's a lot more detail, which unfortunately cannot be listed here, due to previously listed trade secret reasons.
Authentication
We require that every app that interacts with our technology must use two-factor authentication. We natively provide two types of second factor: text message/call (not email) with code, and physical authenticator.
We do not support sign-in with Facebook/Google or similar services.
For your custom application, our service will need to securely communicate with your identity provider. We require identity tokens with a specified low duration ttl for every interaction between the app and our system, and low ttl token based communication for interaction between our services and your enterprise services. There are other security requirements in addition that are outlined later.
In the highly unlikely event that your implementation cannot provision an identity provider for any reason, then we can provision our custom secure identity provider for your implementation.
Authorization
Similar to identity provision, you will need to define roles and access rights for users. These will form the basis for tokens that determine access to services, paths, and other resources requested by users. Note that generally roles will need to be fine-grained. For example, a two role setup such as Admin and User will not be sufficient. This design needs to be performed early in your process. Note that this is a potential failure point and must be kept front and center. Always. 😐
Before we move forward it's important to mention that all messaging is encrypted and secure. You will need to either stand-up a certificate authority, use our native CA to stand one up, or (unlikely) use an external authority. We expect that all messaging between your enterprise services and ours are secured using (at a minimum) our standards.
Privacy - Keys and Administration
Administration and management of keys must be delivered by your inhouse Encryption service that at a minimum meet our specified standards. If you do not have a service that meets our standards, then you can use our custom Encryption service. The technology supports two methods for user private keys - one where the users store their keys on hardware they own - like a smart card or fob, and a second scenario where the user private keys are held by the Encryption service.
Note that In the first method, the client side app will need to perform the encryption (and decryption) on the client side on the device where the keys are stored.
Data Security
Our backend ensures that all data in any state is secured using symmetric cryptography. Security works in tandem with encryption to ensure that data can be accessed only by parties allowed into the transaction. Natively, the backend delivers secure and private foundational services for data, including where data is sent for storage, data is retrieved from storage, data is sent to one or more parties, data is received from a party, and data is signed (and verified) by a party.
Data Storage
We provide adapters to store already secure and encrypted data on your server, AWS S3, and Couch DB. We can develop custom adapters on request for services such as Azure and others. Note that we do not support data storage on services such as Google Drive, Dropbox, Box, and similar.
Application Database
We require that user credentials and other user sensitive data be managed by your Encryption service. Content security, for example, document hash, encrypted passwords will be stored and managed in a database at a layer closer to the distributed ledger rather than in an application database. Applications will not be able to access this data. This is a native feature of the technology and cannot be changed. Any other data that has a low security risk can be stored and managed by an application database.
Distributed Ledger
This is a custom developed ledger developed in-house from the ground up. At a single node level this is a NoSQL database, wrapped by services that use the ledger to provide content focused services. The ledger cannot be accessed directly by client applications. Services around the ledger deliver features appropriate for permissioned networks. We do not support proof-of-work, stake, or other mining or adjacent services. Also, we do not support smart contract or similar services. If you need these types of services in your network, then please pause and conceptually think if you really need them. There are other ways to get the same benefits using our backend without using up truly massive amount of electricity and other resources. There will be cases where distributed ledger and associated services may not work for you - public unpermissioned networks for one. For such cases, services such as Bitcoin-core, ethereum, or their clones should be investigated. We believe that we can deliver solutions for multi-party consortiums or large non-profits, who require permissioned networks.
There's a lot more we can work through in terms of our technology and implementation. Note that our approach to application development is opinionated. Please use the nav bar to read our manifesto.
If you've made it this far, then you are probably interested in learning more. If you have the financial capital and commitment to pursue a large multi-year distributed ledger supported application development project, then contact us using the button below.