Application specific Cosmos zone

Nobody has claimed this yet.

One possible solution to reduce the costs of interacting with the Livepeer smart contracts is to create an application specific blockchain just for Livepeer that would be a zone connected to the Cosmos hub. Below are some notes summarizing my current understanding of what this might look like with some open questions just to kick off action around this research topic.

# Background

Within the Cosmos network, the Cosmos hub is a blockchain that maintains the global invariance of the total amounts of various tokens across all zones, which are blockchains running Tendermint, "out of the box" blockchain infrastructure that includes things like networking and a BFT consensus algorithm (safety as long as >= 2/3 of nodes are honest). Users can transfer tokens that they own from one zone through the Cosmos hub to another zone connected to the hub. The Cosmos hub is secured by a set of validators that use Tendermint consensus with PoS economic incentives including delegation and slashing conditions overlaid on top. Zones have the option of using their own validator set OR relying on the shared security of the Cosmos hub by using the global Cosmos hub validator set. In the latter scenario, the Cosmos hub validator earns fees for validating blocks in the zone and if it violates a slashing condition in the zone (since the zone is presumably also using the same PoS consensus algorithm if it is using the shared security of the Cosmos hub validators) its staked Atoms in the hub will be slashed.

Another project in the Cosmos ecosystem is Ethermint which is a EVM based chain using the Tendermint consensus engine internally that is compatible with most Ethereum tooling (i.e. Truffle, block explorers, Metamask, etc.).

# How would this work?

The Livepeer smart contracts could be deployed onto a Ethermint chain that represents a Livepeer zone connected to the Cosmos hub.

There are a number of options for migrating LPT to the Cosmos ecosystem
- Rely on the creation of an Ethereum peg zone that connects the Ethereum main chain to the Cosmos hub. The existence of such a peg zone would allow Ethereum users to move LPT from the Ethereum main chain into the Cosmos hub and then into the Livepeer zone to use for staking. The peg zone would rely on witnesses to attest to events emitted by a contract in the Ethereum main chain, signers to use the Ethereum signature scheme (secp256k1) to sign transactions such that they can be validated in an Ethereum contract and relayers to relay batches of transactions that can be posted to an Ethereum contract. The assumption is that Cosmos hub validators would play all of these roles, but I'm not sure yet how proofs of incorrect behavior under these roles to slash a validator would work...
- Issues
- Transferring tokens from Ethereum to Cosmos via peg zones will be slow until Casper FFG is implemented in Ethereum because Ethereum lacks finality with PoW. As a compromise to achieve "pseudo-finality", the peg zone defines a finality threshold of 100 blocks to wait until a token transfer is finalized in order to be reasonably sure that a reorg in Ethereum won't cause the transaction to disappear
- The peg zone will not be available upon the launch of Cosmos and will only be added later
- Snapshot all LPT balances on the Ethereum main chain and include the snapshotted balances in the genesis block of the Livepeer zone aka a "hard spoon"
- Issues
- Technically speaking, the tokens in Cosmos would be distinct from the tokens in Ethereum - they just share the same distribution. One of them would have to be renamed in order to avoid confusion and one might be the canonical version of Livepeer (or there could be two versions)

At the moment, ETH is the fee token in the Livepeer system. However, after the Cosmos launch and before the creation of an Ethereum peg zone, ETH will not be available in Cosmos. The closest alternative would be Photons which will be minted as block reward at a constant rate of 500 per hour for validators AND will be claimable by any Ethereum user after the Ethereum account balances are hard spooned into a zone created specifically for claiming Photons (all Ethereum users will be able to claim an amount of Photons equivalent to their ETH balance at the time of the hard spoon). The easiest solution here might just to be wait for the creation of an Ethereum peg zone before creating a Livepeer zone.

Under the shared security model, what fee tokens will be used to pay Cosmos hub validators? At the beginning, probably photons. Or maybe the existence of an Ethereum peg zone, maybe ETH - Cosmos hub validators would need to accept ETH first. The same choices probably apply to the self sovereign security model (define own set of validators for a zone) as well.

The easiest way to bootstrap an application specific zone is to use a shared security model and rely on the Cosmos hub validators to validate the chain. However, if many application specific zones use the strategy wouldn't the Cosmos hub validators be flooded with blocks that they must validate for each zone? As a result, I would think that given the limited set of validators especially at the beginning (100?), the fees that the validators accept for validation across zones would rise over time making transactions within zones more expensive over time. Is this just another version of the congestion problem on Ethereum except in this case, the individual zones are not congested with transactions (since unlike in Ethereum there might be only a single application running), but since the same validators are validating multiple zones, there would be consistently rising demand for a fixed supply of validation resources (at least until the Cosmos hub validation set grows in size, but even then it sounds like the size will always be limited)

No repository files, tests, or entry points are identified. Start by validating the described Cosmos hub, Ethermint, Tendermint, peg-zone, and shared-security assumptions, then document decisions on token migration, fee tokens, validator load, and security; done means a reviewed feasibility plan.

Written by the indexing model from the issue text.