Infrastructure
Last updated
Last updated
All components within OceanChain, each with diverse roles ranging from ensuring network integrity and monitoring for malicious activity to governance representation and technical oversight, all of which collectively contribute to the platform's robust functionality and security:
At the core of OceanChain lies the Interlink Layers, serving as the foundational infrastructure that ensures network security, consensus, and cross-chain interoperability. These layers achieve low-level consensus over a set of mutually agreed valid blocks.
The algorithm under Interlink Layers is inspired by simple and efficient consensus protocols, as well as more involved algorithms that provide fault-tolerant consensus over defective network infrastructures, given a set of mostly benign validators or authorities.
While a proof-of-authority (PoA) style network would be sufficient for the consensus mechanism, OceanChain is designed to be deployable as a fully open and public network without any particular trusted authority required to maintain it. To achieve this, OceanChain utilizes a Nominated Proof-of-Stake (NPoS) scheme to determine and incentivize a set of validators.
Validators are elected infrequently, perhaps once per day or even less frequently. They are incentivized through a pro-rata allocation of funds coming from a token base expansion, as well as any transaction fees collected. While token base expansion typically leads to inflation, since all token owners have a fair opportunity to participate, no token holder would need to suffer a reduction in value of their holdings over time, provided they are willing to take a role in the consensus mechanism.
Validators stake a significant portion of their tokens as collateral, ensuring they are heavily bonded. Exiting validators' bonds remain in place for an extended period after their duties cease, allowing for future misbehavior to be punished. Misbehavior results in punishment, such as reduction of reward or, in cases that intentionally compromise the network's integrity, the validator losing some or all of its stake to other validators, informants, or stakeholders as a whole.
To prevent long-range attacks, OceanChain employs a "checkpoint" mechanism that prevents dangerous chain reorganizations beyond a particular chain depth. Regular "hard forks" occur to ensure newly-syncing clients are not fooled onto the wrong chain by hard-coding recent checkpoint block hashes into clients.
OceanChain features Island Chains, independent blockchains within the ecosystem, each capable of tailoring functionality for specific purposes and hosting its own tokens. These Island Chains are afforded similar security guarantees as the Interlink Layers, with their headers sealed within the Interlink Layers blocks, ensuring no reorganization or "double-spending" is possible following confirmation.
OceanChain also provides strong guarantees that the Island Chains' state transitions are valid. This is achieved through the set of validators being cryptographically randomly segmented into subsets, one subset per Island Chain, with the subsets potentially differing per block. This setup generally implies that Island Chains' block times will be at least as long as that of the Interlink Layers.
The subsets of validators are required to provide an Island Chain block candidate that is guaranteed valid. Validity revolves around two important points: firstly, that it is intrinsically valid—that all state transitions were executed faithfully, and that all external data referenced (i.e., transactions) is valid for inclusion. Secondly, that any extrinsic data, such as external transactions, has sufficiently high availability so that participants can download and execute the block manually.
Validators work alongside a gossip protocol with collators—individuals who collate transactions into blocks and provide a non-interactive, zero-knowledge proof that the block constitutes a valid child of its parent, earning any transaction fees for their trouble.
OceanChain features Bridges, dedicated blockchain entities enabling the platform to establish connections and communicate effectively with external networks. These Bridges facilitate seamless communication and value transfer between OceanChain and other blockchain ecosystems, fostering an interconnected and interoperable environment.
Ensuring the security and integrity of the Interlink Layers within OceanChain are the Validators. These are entities that stake their tokens as collateral to validate proofs from collators and participate in the consensus mechanism alongside other validators.
Validators play a crucial role in securing the network against malicious activities while maintaining transparency and accountability. They are incentivized through rewards earned by validating blocks and participating in consensus.
However, validators are also heavily bonded by their staked tokens. If they engage in misbehavior that intentionally compromises the network's integrity, such as attempting to ratify conflicting branches of a fork (known as a "short-range" attack), they can be identified and punished severely. Punishments may include reduction of rewards or, in egregious cases, the validator losing some or all of their staked tokens to other validators, informants, or stakeholders.
This system of bonding, incentives, and punishments helps align the interests of validators with the health and security of the OceanChain network, discouraging malicious behavior and ensuring they act in good faith.
Validators are an integral part of OceanChain's decentralized security model, working alongside the other components to create a robust and trustless ecosystem.
A critical component of OceanChain is interchain communication, allowing transactions executing in one Island Chain to effect the dispatch of a transaction into a second Island Chain or the Interlink Layers. These interchain transactions are indistinguishable from externally signed transactions, with an origin segment identifying the source Island Chain and an address of arbitrary size.
Interchain transactions do not come with any associated "payment" or fee; any such payment must be managed through negotiation logic on the source and destination chains. A system similar to that proposed for Ethereum's Serenity release could be a simple means of managing such cross-chain resource payments, although other solutions may emerge over time.
Interchain transactions are resolved using a simple queuing mechanism based on a Merkle tree to ensure fidelity. It is the task of the Interlink Layers maintainers to move transactions from the output queue of one Island Chain into the input queue of the destination chain. The passed transactions are referenced on the Interlink Layers but are not transactions themselves.
To prevent an Island Chain from spamming another with transactions, a transaction can only be sent if the destination's input queue is not too large at the end of the previous block. If the input queue is too large after block processing, it is considered "saturated," and no transactions may be routed to it within subsequent blocks until the queue size is reduced below the limit.
The Interlink Layers of OceanChain will likely be a chain broadly similar to Ethereum, with a state mapping addresses to account information, primarily balances and transaction counters (to prevent replays). Accounts on the Interlink Layers fulfill the purpose of providing accounting for which identity possesses what amount of stake in the system.
However, there will be notable differences from Ethereum:
Contracts cannot be deployed through transactions, following the desire to avoid application functionality on the Interlink Layers.
Compute resource usage is not accounted for, as the only functions available for public usage will be fixed, allowing for more performance from any dynamic code execution and a simpler transaction format.
Special functionality is supported for listed contracts that allow for auto-execution and network message outputs.
If the Interlink Layers have a virtual machine based on the Ethereum Virtual Machine (EVM), it would have modifications to ensure maximum simplicity, with a number of built-in contracts to manage platform-specific duties like consensus, validators, and Island Chains.
Alternatively, a WebAssembly (Wasm) backend is a likely option, with a similar overall structure but without the need for built-in contracts, as Wasm is a viable target for general-purpose languages.
Other potential deviations from the present Ethereum protocol include a simplification of the transaction-receipt format, allowing for the parallel execution of non-conflicting transactions within the same block, similar to the proposed Serenity changes for Ethereum.
