As the Kinesis team has designed and built out their Kinesis Cryptocurrency, the true objective and vision has remained front of mind; that this is to be a globally accessible, usable and reliable digital currency forming the basis of a new Monetary System.
As a result, a number of core characteristics were a top priority, with one of the highest focusing on security and reliability. This involved careful design and configuration around the way the Kinesis systems would be hosted and supported.
The KBN is hosted in the cloud, on Amazon Web Services, in doing so makes full use of all security factors and hardware redundancy that the cloud solution affords. Hardware failure and redundancy is handled seamlessly in AWS as part of their IaaS (infrastructure as a Service) offerings, as is the quality of the hardware used. Cloud hosting provides access to advanced infrastructure strategies that would otherwise not be rapidly possible or cost-effective to achieve independently.
For the KBN, the AWS platform has been architected specifically to ensure robust network stability and uptime assurances. To ensure this, not only is the Kinesis ecosystem hosted in the cloud on redundant high-quality hardware but additionally, the network is is designed to be distributed over 3 global regions of the AWS global network. This provides triple redundancy in the network for fail-safe operations.
With the KBN being a fork of the Stellar network, the consensus model forms the mechanism through which the network is propagated. In the KBN design, 5 nodes are required to reach consensus to propagate any change to the network. Additionally, the network is configured such that only 3 trusted nodes exist in each region which means that at least 2 regions need to contribute trusted nodes for consensus to occur. This not only provides triple redundancy using 3 regions to protect against any failure or breach but also means that in order for the control to be lost of the entire KBN, an external entity would need to coordinate an attack on 2 regions simultaneously to incur any disruption to performance.
Additionally, the loss of one entire region will have no effect on the network operation, with a rapid restore being automatically initiated in the failed region. In the highly unlikely event that 2 regions of AWS fail or are unable to contribute nodes to the consensus process, the transactions will be safely queued for consensus until two regions and 5 nodes are again available to participate, thus preventing data corruption.
This combination of configuration and IT strategy ensures Kinesis the ability to commit to its high standards of system up-time and reliability, along with presenting a network infrastructure with an exceptionally low chance of compromise.
