Topic: Proof-of-Strategy / ChainsAtlas: A Multi-Chain Interoperability Network (Read 34 times)

This article is an overview of the whitepaper. The full version is available in the official repository: https://github.com/ChainsAtlas/whitepaper.​

https://miro.medium.com/max/700/1*sCDoaqzxYwZ0brouqM2Zew.png

ChainsAtlas is a new technology to create a cross-chain decentralized homogeneous network for distributed software and data processing. It accomplishes this by leveraging virtualization and multiple distributed ledger technologies (for simplicity in this document, often referred to as blockchains) with a smart contract feature.
The combined infrastructure that powers existing blockchains allows for running decentralized complex software, building a reliable Web3 infrastructure. The ChainsAtlas network brings this vision into reality using two types of structures: nodes and units. The latter, in essence, are smart contracts running on several blockchains that, among other features, create a virtual machine. The virtualization unit simulates a specific instruction set, allowing the same software to run on different chains regardless of the underlying smart contract implementation. Further, the virtualization approach allows much of the existing software (not developed for a blockchain context) to run on a decentralized network, just like a smart contract. Consequently, this brings a massive amount of existing software to the blockchain ecosystem.
ChainsAtlas use a dual consensus protocol, Proof-of-Stake (PoS), and a novel class of useful Proof-of-Work (PoW), called Proof-of-Strategy (PoSg). In the context of PoSg, strategists provide the optimal execution strategy for a given bytecode under a variable set of constraints, and they operate nodes called Pythians that validate these strategies. With PoS, Pythians enable cross-chain communication and provide constant updates on the supported blockchains state.​
Network components overview​
∎ Athena: The governance token that gives voting rights and staking rewards in Hermes (utility token).
∎ Hermes: The utility token generated by the staking of Athena and used to pay for smart contract execution on the network.
∎ Client: The user who wants to execute software under a set of preferences and conditions in exchange for an amount of Hermes.
∎ Strategist: The entity that supplies the management unit with an execution strategy that matches the clients’ settings while minimizing the processing cost in exchange for Hermes.
∎ Pythia: A node operated by a strategist. It enables cross-chain communication between various units and evaluates and oversees strategy execution. To run a Pythia node, one must stake Athena.
∎ Management unit: The smart contract that manages Hermes and Athena balances, verifies consensus over the optimal strategy, oversees elections and controls the virtualization units.
∎ Virtualization unit: Smart contracts that handle the execution of the client’s bytecode. They are deployed on various blockchains.
∎ Proof-of-Strategy: A novel useful Proof-of-Work where the strategist (the Proof-of-Strategy equivalent of the miner) earns Hermes by providing the optimal strategy for executing the client’s software under a set of constraints.
∎ Chain profile: A set of characteristics that define each of the supported blockchains in the network in a standardized manner.
∎ Election cycle: A time-limited event for Pythians to vote and update the chain profiles of supported blockchains. All non-measurable characteristics of a given chain profile can be updated (such as the decentralization score). Pythians can also vote to exclude existing blockchains or to include new ones in the network.
∎ Agora DAO: A decentralized autonomous organization that regulates the ChainsAtlas ecosystem based on the voting of its members. Every Athena staker, e.g., Pythia, is a member of the Agora DAO and has a right to vote.
∎ OLYMPUS treasury: A reward pool that collects part of the Hermes paid by the client to distribute among Pythians and the grant fund at the end of a 28 days period. Each Pythia’s reliability score dictates its share of the OLYMPUS treasury. The use of the grant fund is decided through the Agora DAO, in which all Pythians have a vote.
∎ Gerousia: An assembly of developers that decides over final approval of changes to the code base under strategic goals set by the Agora DAO. The Gerousia is elected in regular intervals.​

Chains characteristics​
Each blockchain used in the network must have a smart contract feature and a “chain profile” and be Turing complete. The chain profile is a set of characteristics that define it from the point of view of the management units. These profiles serve as standardizing structure that allows for a unified approach to comparing the different blockchains of the network and validating the compatibility of a given strategy with a given underlying blockchain.​

https://miro.medium.com/max/700/1*y2ta_PWO12_5VZ1RTh-hBQ.png

Measurable and Elected characteristics
There are two categories of chain characteristics: measurable and elected. The management units verify the consensus of Pythians before validating the recommendation of both types. The difference is that measurable ones are defined autonomously while elected ones are defined actively through voting.
​
Distributed Decentralized Processing Network​
The Distributed Decentralized Processing Network (DDPN) leverages the best features of each blockchain implementation to execute software through management and virtualization units. These units are smart contracts deployed on multiple blockchains. The management units are responsible for managing transactions, wallets, and communication with virtualization units to guarantee the proper execution of the client software with an optimal strategy. The virtualization units create a distributed Runtime for software, including those not designed to run on a blockchain, by deploying smart contracts that simulate a specific machine instruction set. Further, as explained in more detail in the following sections, the DDPN allows users to (1) run code that surpasses the transaction size limit and (2) asynchronously execute bytecode via segmentation and execution transfer.​

https://miro.medium.com/max/700/1*gu_cgcbMm5QM5Ri7S2kAsg.jpeg

Bytecode segmentation

The transaction size limit is one of the possible diverging characteristics among smart contract implementations. Considering virtualization units, this translates to a limitation of the size of the client’s bytecode to be run on the blockchain. The DDPN addresses this limitation by segmenting the bytecode to run it within the limits of each virtualization unit’s underlying blockchain.

Execution transfer
The execution transfer process handles the bytecode segmentation. Each bytecode is considered a transaction, and splitting occurs when a given transaction size exceeds the underlying Blockchain limit.
Synchronous and asynchronous execution
The execution of a bytecode that uses multiple transactions can occur in two manners, Synchronous or Asynchronous. The advantage of the latter, when possible, is that it requires less time for completion.
When the execution is synchronous, the bytecode segmentation is subject to:​

https://miro.medium.com/max/700/1*-HYo417q-tdBFFvIVmdqiw.png

∎ Examples of sync v. async execution strategies:
https://miro.medium.com/max/700/1*w-lTkVYQvetsIOaZ3fC6sw.png
​
Proof of Strategy​
Offer: Clients can define a set of constraints and preferences, such as the priority level given to latency versus cost, providing a value α ∈ [0, 1]. If α ≥ 0.5, the network will prioritize a strategy that minimizes the execution time rather than cost as long as the total cost is within the cost range indicated in the offer.
Chained submission: If a given offer size surpasses the transaction size limit, the bytecode can then be supplied in chunks as long as the size of each chunk, except for the last one, is equal to the transaction size limit. This approach minimizes the number of necessary submissions to the management units.​

https://miro.medium.com/max/700/1*LHvkODVasVX8oODH_gX9Nw.png

​
Strategy: The Proof-of-Strategy is a novel class of useful Proof-of-Work in which the reward (see section 11 of the whitepaper) goes to the first strategist to provide the optimal valid execution strategy that meets the constraints set by the client. This protocol incentivizes the strategists to provide the most cost-efficient strategy as the level of cost optimization directly impacts their reward while also incentivizing them to optimize in terms of execution time as it is the primary factor for selecting the optimal strategy. Often the strategist will use a stochastic optimization algorithm as this implies that the more iterations the strategist runs, the more likely this would result in a strategy with a higher profit margin. However, this also increases the risk of another strategist submitting their proposal earlier and effectively winning the bid.​

Management units​
The management units are smart contracts deployed on all the supported blockchains, each holding the same state information. In order to maintain synchronization of state and the strategy order book, management units verify consensus among Pythians before validating requests to update its state or submit a valid strategy.
As the core management component of the network, management units hold multiple responsibilities.​
Virtualization units​
The virtualization units are smart contracts composed of three components:
∎ Virtualization manager: manages the execution flow of the unit and receives/transmits data as indicated in the joined metadata supplied by the management units;
∎ Logger: documents the transaction by computing hashes of the variable parts of the transaction and storing the results in the immutable memory of the underlying blockchain;
∎ Simulator: interprets and executes the bytecode.
The simulator is a 32bit machine simulator based on a modified version of the DLX instruction set, a RISC processor architecture. It has an ephemeral memory that includes a general-purpose memory and registers. Registers are usually a specialized data set with memory that may hold an instruction or a storage address. Additionally, some instructions in the bytecode specify registers as part of the instruction.

​Operational protocol​
Chains characteristics’ election protocol: ChainsAtlas provides the necessary technology and procedures to constantly expand the number of blockchains supported or update the characteristics of the existing ones. In order to submit a new profile or update an existing blockchain profile, one must send the management unit a request for an election in which eligible Pythians will vote to validate the proposed profile, determining how much and under which constraints it will contribute to the network.
Voting eligibility: To be eligible to participate in the election protocol, one must have Athena staked on a Pythia node, and the stake cannot be in the On-Ramp or Off-Ramp (see section 8.2 of the whitepaper) phase to be valid. All valid Athena managed by the Pythia, including those delegated to it, count as voting units for the Pythia’s address.
Elections consensus protocol: With each new smart contract implementation brought into the network, an election based on Proof-of-Stake will determine if the contract gets deployed or rejected. The network computes the hash sums (SHA256) for each implementation bytecode and, if approved, immutably stores it in the underlying blockchains, adding it to the ChainAtlas processing network.​

    See section 7 of the whitepaper for more details about the voting factors and weights​

​
Tokenomics​
Dual Token System: The network tokenomics is separated into two intrinsically connected coins to protect its governance structure from influence induced by interaction with tokenomics of external blockchains:​

    Athena: A governance token that, when staked, grants voting power and rewards in Hermes;​
    Hermes: A utility token used to pay for cost of execution and receive rewards through operating Pythians, staking, or delegating Athena.​

Staking and Stake Delegation
∎ Directly: the strategist stakes a minimum of 100 Athena tokens and collects all the Hermes rewards.
∎ Delegation: the Athena owner delegates its tokens to an existing Pythia node. In this case, the Pythia can charge a fee of up to 10% of the rewards associated with the delegated Athena, and the remaining reward goes to the Athena owner’s address.
​
Governance Protocol​
Agora DAO: Agora DAO is the public space for the ChainsAtlas community to engage in relevant decisions of the ecosystem, including but not limited to transaction fees calculation, voting factors weights, codebase updates, and grant fund disbursement.
The Gerousia: The Gerousia is the development governing committee, and its members are selected based on the results of an election. These elections are held every six months.​

OLYMPUS treasury​
The OLYMPUS treasury comes to strengthen the ecosystem in multiple ways. It is a path to obtaining and maintaining decentralization, transparency, and scalability. The treasury distributes its collected Hermes among the Pythians fund (75%), the Grant fund (15%), and the Agora fund (10%).​
Reward distribution​
The network can reward both Pythians and Strategists. Pythians receive Hermes rewards by staking Athena and remaining reliable and active on the network, and strategists receive Hermes rewards by providing optimal execution strategies for clients’ bytecode.
Slashing: Slashing occurs when the strategist presents a strategy with an incorrect estimated execution time or incorrect execution cost.​