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.
NOTE: Centralized and decentralized are not consortia parameters. Rather, they are arbitrary terms used in this document to delineate the ownership orchestration of the consortium’s memberships.
An organization is the 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 are able to generate “admin credentials” (aka an APIKEY) which can be subsequently leveraged to perform administrative resource management ops through the Kaleido API. The administrator of an organization can extend invitations to additional users, whereby they are granted the same level of administrative authority. Note though 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
At its core, a consortium is simply a grouping of member organizations that will participate to some degree in the blockchain network. The key configuration of a consortium is the ownership of its underlying memberships.
“Centralized” means that a single Kaleido Organization will manage ALL network resources on behalf of the consortium’s memberships, granting access to the blockchain through the dispersement 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 lays 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 organization in the consortium 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.
Organization -> Consortia
A consortium is comprised of 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 for verification of 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.
Organization -> Consortia (memberships)
An environment is an isolated domain within a consortium that is used to host nodes and services, and provision application credentials. 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:
- client protocol – Geth or Quorum
- consensus algorithm – PoA, Raft or IBFT
- region – US, EU, AP (Sydney) or KO (Seoul)
Organization -> Consortia -> Environments
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 resources (e.g. KMS or S3 Buckets)
Organization -> Consortia -> Environments -> Nodes
Application credentials, specified as
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 in Kaleido exist as one of two types – member or utility.
Member services, as the name might suggest, 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 of an environment leveraging the Public Ethereum Tether will be billed for use of the service.
Kaleido resource limitations
The following table serves to outline the current resource thresholds across a Kaleido organization based on the selected plan. Nodes and services are billed at runtime, and with the exception of the Starter Plan, are only governed due to protocol/performance restrictions. The limitations of configurations and app credentials are stipulated per org/per environment.
|Number of Consortia||1||unlimited||unlimited||unlimited|
|Nodes/Environment||5||Raft: 30 nodes * PoA: 100 nodes (30 signers) * IBFT: 100 nodes (16 signers)|
|Configurations & Keys||10 & 5||25 & 25||50 & 50||100 & 100|
Node Size Rate Limits
The following table serves to outline the available rate limitations based on the provisioned node’s size. Refer to the Kaleido Pricing page for detailed information on plans and available node sizes.
|Requests per Second||5||100||1000|