Kaleido Resource Model
The Kaleido platform exposes several key resources that function in tandem to create bespoke blockchain networks. The orchestration is a logical hierarchy, where provisioned resources maintain a one-to-one relationship with their parent resource and inherit any configurations or specifications defined by the parent. This document summarizes these resources and maps their relationship within the scope of a bootstrapped network. The diagram below shows the Kaleido object model against each of the two available membership approaches - centralized and decentralized.
Centralized and decentralized are not consortia parameters. Instead, they are arbitrary terms used in this document to delineate the ownership orchestration of the consortia's memberships.
Organizations
An organization is a top-level resource that can access the Kaleido platform and is a prerequisite for any administrative operations (e.g., environment creation, node generation, etc.). Dependent on the consortium membership approach, resources in a blockchain network exist within the purview of either a single organization or multiple organizations.
Via the Kaleido console, organizations can generate “admin credentials” (aka an APIKEY), which can be leveraged to perform administrative resource management ops through the Kaleido API. An organization's administrator can extend invitations to additional users, whereby they are granted the same level of administrative authority. Note that these invitations should be provisioned carefully, as any on-boarded users will possess the same root privileges as the organizational admin.
NOTE: Resource limitations are bound to an organization's chosen plan. The following choices are available: Starter, Team, Business, and Enterprise. Please refer to the table at the bottom of this page for the enumerated limitations
Consortia
At its core, a consortium is simply a grouping of member organizations participating to some degree in the blockchain network (referred to in the platform as a "Network"). The key configuration of a consortium is the ownership of its underlying memberships. Here we see two types of consortia, or networks, develop:
"Centralized" consortia have a single Organization which manages ALL network resources on behalf of the consortium’s memberships, granting access to the blockchain through the disbursement of node and service endpoints and their corresponding application credentials. In other words, this organization will serve as a root admin that can proxy access to the network as it sees fit. The memberships still have a direct relationship to core resources (nodes, services, and app credentials). However, the true control of these resources lies with the Kaleido organization managing the consortium. Centralized ownership means that no invitations have been extended, and all existing memberships are bound to the founding Kaleido Organization.
"Decentralized" ownership entails collective control of the consortium, where the memberships and provisioned resources are managed separately by the individual Kaleido Organizations in the consortium. An organization cannot take resource management actions against another consortium organization and has no purview into their application credentials and API Keys. In a decentralized orchestration resources are independently managed. External organizations must be invited to the consortium by the founding Kaleido Organization or an existing member with the privilege to extend invitations.
Memberships
A consortium comprises a grouping of member organizations (i.e., memberships), with each membership existing as a unique entity within the context of the consortium. Organizations come with a default membership bound to their organizational name. However, additional memberships can be provisioned as needed (e.g., separation of business units).
Memberships are used as the distinct identifier when creating nodes, services, and application credentials (the member resource ID is in the body of the API call) and can be definitively linked to a digital x509 certificate to verify the identity assertion. A consortium must contain at minimum one member,
A helpful phrase for understanding memberships - A Kaleido Organization is represented in a consortium through a single membership or a collection of memberships.
Environments
An environment is an isolated domain within a consortium that is used to host nodes and services, and provision application credentials. The declaration of an environment is when an actual blockchain is deployed and made available to memberships within the relevant consortium. Environments inherit the consortium’s membership list, meaning that any organizations defined within the consortium configuration are whitelisted to the environment. As such, nodes, services and application credentials can be provisioned against any of the consortium’s memberships. Environments have three pieces of configuration:
- Blockchain protocol - Ethereum , Hyperledger Fabric or Corda
- Client protocol - Geth, Quorum or Hyperledger Besu
- Consensus algorithm - PoA, Raft or IBFT
- Cloud & region - Ohio, Frankfurt, Sydney, Seoul, Washington or Paris
Nodes
Nodes are the network entities that maintain the blockchain ledger and accept connections from external applications. The node runtime inherits the protocol and consensus configurations specified in the environment. Every node is created against a specific consortium membership, and every node is isolated to the environment within which it is created. Nodes have:
- a name
- a unique Kaleido node ID
- a unique Ethereum node ID
- RPC and web socket endpoints for external connection
- a webhook endpoint for simplified external connection to the Kafka backed Eth-Connect messaging layer
- Kafka reply/request topics and broker IDs for direct interaction with the Kafka cluster
- a private address (if Quorum is chosen as the protocol)
- an Ethereum account for sending/signing transactions
- optional configurations with native AWS or Azure resources (e.g., KMS or S3 Buckets)
Organization -> Consortia -> Environments -> Nodes
Application credentials
Application credentials, specified as username:password, are a basic authentication security mechanism to protect external access to a node’s ingress. App creds are created against a membership in the consortium and are isolated to the environment within which they are created. The Kaleido platform does not store the authentication password, ensuring that the secret is owned solely by the member organization that generated the credentials. Nodes and member services will accept connections from any credentials correlating to their membership, meaning that credentials can be cycled regularly to ensure strong security practices.
One of two approaches can be exercised to access a node with app credentials. They can be bundled with a node endpoint and passed to an Ethereum accessible API (e.g. web3.providers.HttpProvider) to send blockchain specific calls. Alternatively, they can be passed as a base 64 encoded representation in the Header Authorization and used alongside common REST methods via cURL or a preferred REST client. Services are also compatible with either approach.
Organization -> Consortia -> Environments -> app creds
Services
Services in Kaleido exist as one of two types - member or utility.
Member services are bound directly to one of the consortia's memberships and are under the full control of the Kaleido Organization managing the membership. They are secured via member-specific application credentials (i.e., inaccessible by fellow members of the consortia) and can be unilaterally managed/deleted by the Kaleido organizational admin. Examples of member-type services include IPFS nodes and HD Wallets.
Utility services are environment-wide resources that provide collective shared value to all participants in the environment. They are accessible by all members, configurable by privileged members (i.e., ability to manage environments), and can only be deleted in centralized environments (i.e., all nodes owned by the same Kaleido Organization). Examples of utility services include the Public Ethereum Tether and the ID Registry. Some utility services are currently provided as always on services, meaning they are provisioned by default, are free-of-charge, and do not count against your plan limits.
Billing Information: Utility services are charged per node in an environment where the utility service is present. For example, all nodes inside an environment leveraging the Public Ethereum Tether will be billed for the use of the service.