Technology
Learn what drives Peer Mountain’s powerful decentralized trust ecosystem and maximizes the benefits of blockchain technology
The Peerchain™ protocol, architecture, and system design are protected by the 9 October 2017 European Patent filing 17195509.9 – “Method and system for decentralized messaging and data access”.
We have also filed trademarks for the Peer Mountain and Peerchain™ brands with EUIPO trade mark numbers 017282931 and 017350182, respectively. It is our intent to release the Peer Mountain client SDK for Android and iOS as open source, and to open-source the Peer Mountain Attestation Engine SDK. It is also our intent to submit the Peerchain™ Protocol for RFC in order to develop an open standard that can be used as widely as possible in any economic context.
Peerchain™ Protocol
Every operation in Peer Mountain is defined by a message type. These messages are wrapped in an envelope that provides the basic common information about all operations. The messages themselves contain the specifics about their respective operation. Messages that alter the state of the system are hashed and timestamped in an immutable blockchain layer.
Service providers, or other external entities (e.g. regulators), may run blockchain nodes without necessarily running Message/Object storage nodes.
Only the message identifier and hashes related to the content of the message is stored on the blockchain layer. All other information is kept in a high-performance database.
Cross-Chain Compatibility
Different blockchains are not compatible across chains, and are incapable of handling cross-chain transactions across multiple chain instances.
Peer Mountain overcomes this challenge. Chains and storage make up the operating layer of each instance. The patent-pending PeerchainTM Protocol then enables Peer Mountain users to communicate across instances, so they can transmit digital assets across chains. In addition, digital signatures recorded in one instance remain legally binding throughout the Peerchain™
Efficient, Transparent Transactions
Latency in communication between a blockchain’s nodes nodes as it establishes consensus across the chain limits its transaction capacity. This means that blockchains seem unable to process transactions at the speed required for large-scale transaction processing systems.
We’ve taken an innovative approach to addressing this limitation. We believe that a blockchain does not need to operate globally on every possible node. Instead, Peerchains™ can co-exist and work in harmony, each focusing on a part of the larger ecology of trust.
Each Peer Mountain instance operates a Peerchain™ that we can deploy to a service provider, their regulator, their auditors, and any appropriate industry watchdog or consumer protection group. Anyone wishing to review the integrity of the chain can access a publicly available chain explorer.
Peerchain™ Technology
Clients see Peer Mountain instances transparently.
Attestations are portable across instances.
Instances are deployed by service providers operating in regulated industries.
Storage
Blockchains are not meant to store large amounts of data, which makes perfect sense: the smaller the data structures, the more efficient the blockchain.
Peer Mountain chains store hashes that refer to, and retrieve, encrypted information held in off-chain storage. A Peer Mountain instance can store encrypted objects on Storj, IPFS, HDFS, TahoeFS, Amazon S3, or any other available storage solution that delivers consistent, high-level read/write performance.
High Scalability
Due to their consensus mechanism, blockchains require a higher data throughput. However, blockchains don’t have the capacity to handle large quantities of transactions simultaneously.
Peer Mountain allows for secure and transparent service segmentation across blockchain deployments. This means an organization can deploy services that require a high volume of real-time transactions on a dedicated Peer Mountain blockchain, while deploying the rest of their services on a common Peer Mountain blockchain.
For example, a bank could run separate instances for current accounts, specific types of credit cards, and auto loans. This setup splits the transaction volume across instances, enabling the bank to achieve higher cross-service data throughput, as well as cross-instance data compatibility. This means the bank can use information from a customer’s credit card dossier in the auto loan and current accounts instances.
