The following principles embody the XDEX architecture strategy:
- Accelerate development by decoupling / exposing the XDEX Network and XDEX Features functionality as a reusable set of APIs for consumption.
- Innovate with digital applications or rapid deployment and quick creation of a system of engagement to new channels.
- Provide secure and controlled access to XDEX APIs in a hybrid cloud environment where the likes of mobile or IoT applications on a public cloud can also consume exposed APIs.
- Enable a consortium association ecosystem with a wider community of external developers and partners who will publish and consume XDEX Network and Features APIs beyond enterprise boundaries.
- Monetize existing and new data and algorithms while enabling new business models.
The Public Network contains the Internet, peer cloud systems, and edge services.
Edge services allow data to flow safely from the Internet into the XDEX Core and into the enterprise. Edge services also support end-user applications. Edge services include:
The DNSS resolves the URL for a web resource to the TCP-IP address of the system or service that can deliver that resource.
The CDNs support end-user applications by providing geographically distributed systems of servers deployed to minimize the response time for serving resources to geographically distributed users. This ensures that content is highly available and displayed to users with minimum latency. Which servers are engaged will depend on server proximity to the user and where the content is stored or cached.
The firewall controls communication access to or from the XDEX network, permitting only traffic meeting a set of policies to proceed and blocking any traffic that does not meet the policies. Firewalls can be implemented as separate dedicated hardware or as a component in other networking hardware, such as a router, or as integral software to an operating system.
Load balancers distribute the XDEX network and application traffic across many resources (such as computers, processors, storage, or network links) to maximize throughput, minimize response time, increase capacity, and increase application reliability. Load balancers can balance loads locally and globally. They should be highly available without a single point of failure. Load balancers are sometimes integrated as part of the provider cloud analytical system components like stream processing, data integration, and repositories.
Users are the parties of the XDEX network who create and distribute applications, smart contracts, and perform operations using XDEX.
XDEX Users include the following:
- Developers – XDEX developers create applications for end users (client side) and develop new smart contract templates that interact with the system and are used by XDEX users to initiate transactions. They also write code to enable the blockchain to interact with legacy applications.
- Administrators – XDEX administrators perform administrative activities related to the XDEX network and applications such as deployment and configuration of the XDEX network or applications.
- Operators – XDEX operators are responsible for defining, creating, managing, and monitoring the XDEX network and applications.
- Auditors – XDEX auditors are part of the business network and are responsible for reviewing the transactions or access control lists and validating the integrity of those transactions from a business, legal, audit and compliance perspective.
- Business Users – Business users operate within the XDEX network and interact with the blockchain using the XDEX applications. Other than knowing the conceptual idea of XDEX being a blockchain application, business users are not aware of the blockchain itself.
Now that we have established who is using XDEX, let’s look at how the different roles access the XDEX platform and interact with the components.
The applications in the XDEX network are used to present (business) capabilities to end users of the system. This is particularly the case for business users, where capabilities need to be presented in terms that relate to the application area with concepts and processes familiar to those business users.
Applications may also exist to serve other users with different roles including administrators, operators, and auditors.
The various XDEX applications will take many forms including web applications (with code centralized on a server closely associated with the XDEX blockchain node), or applications running on the end user device(s), potentially connected to server-side application services.
Applications and services interface with the XDEX platform using the APIs offered by the platform. The applications may have access to other server-side resources such as databases and services, as needed, to implement their capabilities.
Blockchain applications are built to benefit the business networks within specific industries including financial services, healthcare, insurance, energy and utilities, public sector, and retail. Blockchain will also enable cross-industry networks to help revolutionize supply chains, secure, and integrate Internet of Things (IoT) applications, and reduce cost and risk.
XDEX API management capabilities publish catalogs and update APIs in a wide variety of deployment environments. This enables developers and end users to rapidly assemble solutions through discovery and reuse of existing data, analytics, and services.
XDEX applications need to interface with the XDEX Network as part of their operation. They achieve this by using the programming interfaces provided. XDEX will offer various APIs that are programming interfaces the applications use to interface with the core XDEX platform components to achieve business transaction outcomes.
The XDEX platform supports essential capabilities for blockchain solutions in a blockchain network node or enterprise. While each blockchain platform is set up and implemented a bit differently, these core capabilities should be considered in blockchain platforms and solutions.
Enables a consensus process used by the nodes within the blockchain network to agree on the validity and order of transactions appended to the ledger. The consensus process maintains a consistently replicated ledger within the network.
A ledger is a sequence of cryptographically linked blocks that contain transactions.
These services manage identity, privacy, confidentiality, and auditability on the network.
Membership only applies to the permissioned parts of XDEX. Permissioned blockchains only allow business use case-specific actors to submit transactions or validate the network. In a permissioned blockchain, the actors may be given different roles granting them permission to perform a specific set of operations.
In non-permissioned, public blockchain, participation does not require authorization and all actors can equally submit transactions or attempt to accumulate them into acceptable blocks. There are no distinctions of roles, which quickly becomes problematic for most enterprise use cases.
Transactions are records that are appended to the ledger. They can record the exchange of ownership for anything of value such as stocks, bonds, commercial paper, diamonds, etc. Other use cases include event logging anything, for example: changes to medical records or critical device status in an IoT example.
Events are notifications of significant changes or operations that occur in the blockchain network. For example, events result from execution of a smart contract or the creation of a new block. Events are of interest to participants taking part in the blockchain network.
Event distribution assigns listeners to receive the events from the blockchain. Events will have event producers and event consumers. Producers publish events of interest to the blockchain network, and consumers of events subscribe to events of interest and process the events as they receive them.
In an atomic broadcast, the sender of messages in a blockchain network sends messages to all connected peer members in the same order of sending sequence. This concept is also termed total- order broadcast or consensus in the context of distributed blockchain network systems.
This protocol is the mechanism by which participating computer systems communicate with each other in the blockchain networks. Typically, the participating computer network members use peer-to-peer protocols, such as gRPC, to communicate with each other in blockchain networks.
The XDEX Cryptographic Services component provides the blockchain with access to the necessary cryptographic algorithms, either directly or by providing an interface to hardware or software that implements the algorithms. Hash functions and digital signatures are examples of algorithms that are commonly used in blockchains.
Hash functions are used to protect the ledger from modifications. Any change to information in the ledger will result in a computed hash that is different from the hash that was previously computed and stored for the ledger. A new hash is computed each time a transaction is added to the ledger.
Digital signatures ensure that the receiver receives the transactions without intermediate parties modifying or forging the contents of transactions, while also ensuring that the transactions originated from senders (signed with private keys) and not imposters.
Smart contracts, sometimes termed chain code, are computer programs that execute in a secure environment within the blockchain platform of any node in the network. Smart contracts encapsulate business logic involving contract terms and conditions between agreeing participants.
The smart contract code determines what transactions are recorded into the blockchain and what information they contain. Smart contracts can be written in a programming language that depends on the blockchain platform.
The smart contract code is stored in the ledger. Transactions can invoke smart contract functions, which can be stateless or stateful, to perform business logic. If required, the code can access external information and systems, via the system integration component. This is called an external oracle.
Smart contracts help to make decisions and automate relationships – all possible outcomes of the contract must be explicitly specified in advance.
During runtime, a blockchain transaction may invoke smart contract functions requiring a secure environment. A secure runtime environment is a hosting environment for server-side blockchain business logic.
An example is the use of a secure container that contains a set of signed runtime components such as a secure operating system, libraries for blockchain-supported programming languages, their respective runtimes, and the like.
Typical integration methods include application programming interface (API) adapters and enterprise service bus (ESB) connections between the XDEX platform and enterprise systems.
This capability enables secure connections to enterprise systems and the ability to filter, aggregate, or modify data or its format as it moves between cloud and XDEX components and enterprise systems (typically systems of record).
Within the blockchain reference architecture the transformation and connectivity component sits between the cloud network and enterprise network. However, in a hybrid cloud model these lines might become blurred.
The Transformation and Connectivity component includes the following capabilities:
- Enterprise Secure Connectivity – integrates with enterprise data security systems to authenticate and authorize access to enterprise systems.
- Transformation – transforms data going to and from enterprise systems.
- Enterprise Data Connectivity – enables cloud provider components to connect securely to enterprise data. Examples include VPN and gateway tunnels.
The enterprise network is comprised of the enterprise user directory, enterprise applications, and enterprise data.
The enterprise user directory stores user information to support authentication, authorization, or profile data related to the enterprise applications. The transformation and connectivity services use this to control access to the enterprise network, enterprise services, or enterprise-specific cloud provider services.
Enterprise applications are created or used by an enterprise that is interacting with the XDEX network. The enterprise applications may interact with XDEX smart contracts and ledgers. The smart contract may obtain data from the enterprise application, send data to the enterprise application, or request services from the enterprise application.
Enterprise data includes metadata as well as systems of record for enterprise applications. Enterprise data may flow directly to data integration or the data repositories providing a feedback loop in the analytical system for blockchain systems.
Enterprise data that relates to XDEX includes:
- Transactional Data – Data about or from business interactions that adhere to a sequence or related processes (financial or logistical). This data can come from reference data, master data repositories, and distributed data storage.
- Application Data – Data used by or produced by enterprise applications functionally or operationally. Typically, the data has been improved or augmented to add value and drive insight.
- Log Data – Data aggregated from log files for enterprise applications, systems, infrastructure, security, governance, etc.
The procedures and policies that govern the operation of the XDEX Network are known as governance. The network participants agree upon these policies.
Security refers to the security policy and standards to secure the XDEX platform. Security and privacy in XDEX deployments must address both information technology (IT) security as well as operations technology (OT) security elements. The XDEX protocol architecture relies on public-key cryptography.
Considering the previous high-profile programming errors leading to malicious theft of funds, security concerns are a top priority. XDEX stays abreast of current security issues and will only launch contract templates after extensive testing to mitigate attack. creates templates that mitigate the possibility of these problems.
XDEX defines a modular architecture with separated storage contracts that allow the functionality of your deployed assets to be upgraded as the platform evolves, while keeping your data preserved. All contracts start with our base, secure templates.
Private keys for a wallet address on the XDEX platform are stored in a locked vault that only the authorized end user has access. State management follows modern best practice hashing standards. The same standards for smart contract security are applied to the platform itself, which is continually monitored.
We plan to deploy monitoring tools to detect contracts and platform code that needs patched. This will help us deploy an automation process for streamlining updates and will be accompanied by an automated testing service that will continually stress test the contracts before deployment.
Before users can deploy our smart contracts, they must pass a due diligence process with XDEX itself. Aside from satisfying KYC/AML regulatory concerns, this will prevent the misuse of our platform. We are particularly concerned about users launching crowdfunding contracts and will take extra steps to ensure crowdfunding contracts on XDEX follow acceptable standards.
XDEX has embedded user authentication, but can also integrate with traditional IAM server. IAM provides XDEX users with the security necessary to protect their personal data by current and up-to-date security protocols.
XDEX has built-in support for two-factor authentication (2FA), enabling the highest levels of security already engineered into the product from the beginning as opposed to a later feature. XDEX will also require authentication via IAM before or during any transactions on the platform where value might change hands. XDEX users can trust that merely having access to the platform is not enough to transfer value—you must also re-authenticate, assuring the protection of any value stored on the platform.
The XDEX platform will also attempt to automatically lockdown an account with any unusual activity outside of specified parameters, while accommodating legitimate use. We do this by building up a security profile and can then make automatic decisions about when to lockdown an account, for investigation. XDEX personnel will also be notified of unusual activity such as a login originating from an unusual geolocation. We also log all failed login attempts and notify the user via email of the attempt. The user is then well informed and can take appropriate steps to protect their account.
The XDEX platform will always use the current best practices in identifying attacks and account takeover attempts (ATO) and lockdown the account before it can be taken over by an unauthorized party.
These capabilities include monitoring, analytics, and automation tools that are used to respond to changes in the platform and environment. This could include responding to changes in the required system capacity and error analytics.
The XDEX Network Management component provides visibility of the blockchain network operations including business process metrics and performance and capacity data. It also provides a management interface used to change configurations and other parameters.
This section describes a few additional concepts and components within the XDEX network and can clarify blockchain solutions and networks.
Permission-less networks are open to any participant and transactions are verified against the pre-existing rules of the network. Any participant can view transactions on the ledger, even if participants are anonymous.
Permissioned networks are limited to participants within a given business network. On permissioned blockchains, participants can view only the transactions relevant to them and are only allowed to perform operations for which they have permission.
When using XDEX to record transactions, only a relatively small amount of the data associated with a transaction is stored directly in the blockchain ledger itself. Other data associated with the transaction, which might be much larger, is stored separately from the entry in the blockchain ledger but is referenced by the entry. This approach is desirable to avoid overwhelming the blockchain ledger with large volumes of data.
As an example, consider an order for goods that is made by a customer to a supplier. The complete order might be a large document that includes a list of order items, quantities, prices, and ancillary information with details of the customer, delivery location(s), and so on. To record the transaction, the blockchain entry might reference an order number, a customer identity, and the total cost, plus a security token (such as a hash) relating to the complete order document. The complete order document itself is stored separately in an order database.
Ledger storage is the physical storage where the transaction data in the blockchain ledger is stored.
Data storage supports data other than the XDEX blockchain ledger itself and can take many forms depending on the nature of the data. It can take the form of a database – either an SQL database (particularly for record-oriented data) or a NoSQL database (particularly for document-oriented data). It can also take the form of an object storage service or a block storage service.
The choice of which form of data storage is used depends primarily on the nature of the data objects themselves and the operations that need to be performed on them. In some cases, multiple different forms of data storage might be used.
Separately, the matter of replication and backup of the data objects needs to be considered. For some data storage services, replication and backup are built into the service itself. In other cases, it is necessary to create replicas or backups through deliberate actions of the application
There are several ways that users can interact with the XDEX platform. Examples include command line interfaces (CLI) and APIs.