Add peggy on the hub

[zmanian]

Decision an analysis of whether or not Peggy should be instantiate via shared security or via direct integration with the hub.

The intent is to use this analysis to drive a governance proposal on the Hub.

Rendered

[taariq]

I think there's some missing indication of momentum of interest in Peggy's release.

1. I would add the last date of Peggy discussion which was the previous Gaia ATOM meeting and what was concluded
2. I would also ask what's the next date of the process of this decision. Let's get the dates on the board.

[jackzampolin]

I think an argument could be made that because ATOM holders have paid for Peggy dev that it should be deployed on the hub as that would drive the most value for the atom holder.s

[Hyung-bharvest]

I agree. Most growth potential of peggy should be redistributed to Atom holders, except for some fraction to the operational institution who build, manage and operate peggy backend/frontend&interfaces/community/governance/branding&marketing. The fraction can be the institution's payoff over operating cost and opportunity cost.

[jackzampolin]

It would be interesting to see how many of the top 20 would be interested in the increased governance load. one thing that might help here is https://notifications.lunie.io/

[jackzampolin]

Depending on ETH gas prices this might be a deciding factor?

[jkilpatr]

The difference between 3 and 100 signers is ~5x gas cost. So very sublinear thanks to our optimization work. Although I would like to do a much more detailed study before recommending any decisions.

[Hyung-bharvest]

is the integration of althea-peggy into main branch of peggy not included in the job description from ICF?

I think the integrated full cycle of peggy branch is necessary for us to bring it to production level, although it can be done by others. but because it is already funded to althea it seems like natural to complete the integration work by althea.

[jkilpatr]

this problem is more complex than it seems at first glance. We tried to address it more in this blog post.

https://blog.althea.net/solid-foundations-for-peggy/

Peggy master (currently) is targeting Option 1 in this proposal using different means than the CosmWasm based system described. In short a peg zone with little stake of it's owned governed by stake on another zone.

In the process of engineering this system some components of Peggy (master branch) are too immature to deploy in production.

Althea Peggy is focused on a lower level of security, but having all the components ready to deploy (the relayer and Ethereum contract specifically). These improvements can and should be integrated into Peggy master but more will have to be done to achieve a system where another zone governs the peg zone.

[Hyung-bharvest]

Thank you for the explanation! So we need a team to bring these two branches into an integrated production level peggy!

[Hyung-bharvest]

I am not sure why each option has different ways to implement?
I understand that the only difference between option 1 and 2 is how security is provided.
Implementation methodology seems another independent issue.
Maybe because the hub is not likely allow CosmWasm adoption?

For implementation methodology, I am also not sure about CosmWasm utilization for implementing peggy.
Isn't it reducing failure point if we directly implement it as a new module without CosmWasm?

So I think it would be nice if we can seperate the issues here.

1. a pegzone with shared security OR hub(gaia) adoption
2. a new module OR CosmWasm smart contract --> the peggy main branch is implemented with the new module and it does not utilize CosmWasm so I think we can remove CosmWasm option here?

[Hyung-bharvest]

Overall, i think althea's peggy is still in designing phase, and it will be very difficult to expect the finish line i think.

There exists quite a good possibility of failure to bring it into production level in 6 months, from my opinion.

I think we need more detailed and proper documentation of implementation roadmap from althea to at least consider this discussion.

(Edit) From reviewing the main branch of peggy, I found that the bidirectional peggy is PoC ready, so the progress is not a blocker to discuss this matter. Sorry for confusion.

[zmanian]

I'd like to merge this with a decision in favor advocating for Option 2 as part of the ATOM 2021. I need some gas estimates for a hub sized validator set @jkilpatr.

[jkilpatr]

If you would like to verify these numbers you can simply clone the repo and run the solidity as outlined in the readme

as you can see here the test used replicates the Cosmos Hub validator set as of 7/14/2020

There are two functions of interest here. updateValset which updates the contracts representation of the Cosmos validator set and submitBatch which would submit a batch of ERC20 transactions to be sent by the contract. As such the cost of sending a transaction across the bridge is the cost of the 'submitBatch' operation divided by the number of transactions in the batch (arbitrary within block size constraints) plus the base cost of an ERC20 transfer.

To the cost of sending a batch across the bridge on the hub today @ 50gwei would be about ~0.025 ETH or $10. A base ERC20 transfer is about 0.0025 ETH or $1.

If we could bundle 100 bridge transactions the cost per transaction for the Peggy bridge would be 10c each.
This would consume 5.5 million gas or about half of a blocks worth.

Obviously a lower volume bridge is linearly more costly.

Validator set updates similarly cost about $10 (because confirming the validator set is the dominating cost by far) but they only need to occur when a significant portion of the voting power of the hub changes. The amount would have to be decided by governance. But we propose 1% of voting power change hands before a validator update is submitted. With that consideration an update would only need to be submitted once every 2 days or so (based on observations of the Cosmos hub). It should also be noted that timing validator set updates during periods of low activity (when not made impossible by large validator set powers changes) will result a ~50% cost reduction. This needs to be studied further.

As a final note we outline some additional possible optimization here. It is not an immediate development focus but we believe that through some bitpacking and signing tricks we can further reduce the base gas costs of these operations by as much as 50%. Bringing these operations to $5/each.

[jkilpatr]

I have an update to my estimate. After modifying the Peggy tests to actually generate and send a 100 transaction batch the actual gas usage is 4.194 million rather than 5.5 million. This would cost about ~5c per transaction on top of normal ERC20 transfer costs. Despite this I will keep my estimate at 10 cents since I believe we may be getting EVM efficiency improvements from calling the same ERC20 contract for every transfer an unrealistic case in the real world.