RFC-000-039: 2FA for App Chains

Name: 2FA for App Chains
Category: Protocol
Status: Draft
Scope: Increase Ren’s economic security by letting app chains provide a second signature on their own assets.
Disclaimer: I do not work for Ren Labs and have not confirmed the feasibility of anything below. These are just ideas.

Overview

This proposal introduces multichain wallets for app chains, which would be the third addition to Ren’s suite of multichain products alongside RenBridge and RenChain. Assets are secured by 2/2 multisigs shared between a gateway shard of randomly-sampled Darknodes and an app chain composed of third-party nodes. Safety is guaranteed unless 1/3 of the app chain and 1/3 of the gateway shard or 2/3 of the app chain alone are adversarial and coordinating. While Darknodes provide additional security, it is impossible for them to steal any assets.

Instead of renting security from third-party bridges, app chains could secure their own multichain assets and internalize that revenue for token holders. As each app chain scales its own value locked, more volume and fees accrue to Ren without increasing its TVL, making it an effective way to increase economic security across all of Ren’s products.


Graphic adapted from Why Solana?

Discussion

A multi-chain world full of tradeoffs creates a large design space for all kinds of interoperability. For example, smart contract applications run by a virtual machine cannot communicate with other blockchains and require a third party like Ren to do so. RenBridge and RenChain are designed for applications in this domain. In the Cosmos ecosystem, though, applications have a unique superpower: they control their own large-scale blockchains. How is this relevant to Ren? Well, RZL (Ren’s MPC algorithm) is specifically designed for use by large-scale blockchains.

This means that app chains could use RZL to secure their own multichain assets. Why would they want to do this? First, to guarantee to their users that assets are as safe as the app chain itself. Second, to internalize protocol revenue for token holders that would otherwise be leaked to third-party bridges.

“The real value of L1 tokens is just the MEV they can capture. So as an app developer, why are you leaking that value to some L1 token instead of capturing that as protocol revenue for your token holders? By having an app chain, you can internalize that MEV into your protocol.” - Sunny Aggarwal, EthCC[5]. Source

Why would Ren want app chains to secure their own multichain assets? In short, because it is volume that does not increase TVL. Since it would be impossible for Darknodes to steal assets, app chains would be strictly safer by layering their security atop Ren’s. So, this would look more like two-factor authentication for app chain wallets in which two decentralized custodians are safer than one but only one (the app chain) can convince the other (the gateway shard) to sign.

This security model would let each app chain safely scale its own value locked, regardless of how much value were already locked by Ren. If Ren were to take a fee on each mint and burn across many app chains without taking unilateral custody (TVL), it would strictly increase economic security for all of Ren’s products. The key would be to scale volume and fees horizontally across as many sovereign app chains as possible.

IBC vs. MEV

It seems like this product would create an opportunity cost for app chains to compose with IBC tokens minted by non-IBC bridges. If renting IBC tokens from non-IBC bridges leaks value that could now be internalized as protocol revenue by taking direct ownership of multichain assets, then a tradeoff may need to be made. I’d be interested to get people’s opinions here.

Safety

Safety is guaranteed under the following properties:

  1. That 1/3 of an app chain AND 1/3 of its gateway shard are not adversarial and coordinating
  2. That 2/3 of an app chain alone are not adversarial and coordinating

The first condition requires 1/3 of an app chain and 1/3 of its associated gateway shard to each reveal their underlying ECDSA private key and produce a cosignature out-of-band. Note that sampling into 1/3 of a specific gateway shard would be more expensive than sampling into any gateway shard, made even more expensive by the increased value accrual to REN from this product.

The second condition requires 2/3 consensus from the app chain to request a cosignature from the gateway shard. If this request is made in-band, the gateway shard will honor it and produce a cosignature.

Even if 2/3 of the Ren core (aka the coordination shard) is adversarial and coordinating, it cannot compromise any app chains. App chains can check their own wallet’s balance before minting and trust their own consensus before producing a release cosignature. And if it were possible to engage app chains in RNG as an additional source of randomness, Ren could prevent a corrupted core from manipulating shard selection. It might be in both Ren and app chains’ interests to decentralize that responsibility from the core.

Put simply, this layered security model is safer than either decentralized custodian acting alone.

Case Study


Source

Consider the now-defunct Compound Chain, which suffered from inadequate public infrastructure when it was attempted. If Compound Chain were to resurrect as a Cosmos SDK app chain with a Ren module, it would have consolidated interest rate markets for every native asset from AVAX to ZEC on its own chain with a multichain wallet that its own nodes would earn revenue for securing.

Conclusion

With a module built specifically for app chains, Ren could scale its economic security and become the default substrate upon which to build the best and most secure multichain experiences for all kinds of DeFi applications, whether they simply use Ren tokens, live on RenChain, or control their own app chain.

13 Likes

Very interesting proposal… thanks for the write up @chicobermuda!


It does sound like the safety guarantee of 2/3 of an app chain could have the potential to be an easily exploitable attack factor. Unless I’m missing something here.

Suppose I launch the latest ElonDog app chain, the app chain validator nodes are secured by EDoggo coins which I of course fully control myself. I generate lots of hype with 1000k% APY in EDoggo coins, which pulls in millions in renAsset liquidity. After which, because I control more than 2/3 of the app chain nodes, I can drain all renAsset liquidity on the app chain.

Anything I’m missing that would actually prevent me from doing this? Do you think creation of app chains should be permissioned through DNO governance, or it is completely permissionless and each app chain has to work on their own reputation and credibility?

Of course I could do something similar right now on Ethereum by launching a nefarious smart contract with admin controls, but in the app chain model you are actually using the consensus rules to steal the funds as opposed to using (legit but nefarious) smart contract code.

Thanks for the gigabrain submission, Chico. Ngl- most of that went over my head, but the value prop is spelled out clearly, and I can’t wait to observe the discussion abt it in the community. Thanks again for this :slight_smile:

5 Likes

Actually, a 2/3 safety threshold means that an attacker could neither produce nor forge an MPC signature to steal funds without corrupting 2/3 of the entire app chain. Today, RenVM’s safety threshold is 1/3. So, not only would this increase safety, but it would allow blockchains to produce their own MPC signatures with the same safety and liveness thresholds as Tendermint itself! The key is that even if an attacker were able to corrupt 1/3 of the chain and reveal its private key, they would not be able to get the gateway shard to produce a cosignature to move any funds.

A few points to make in your ElonDog example. First, the safety threshold of ElonDog would be no less than what is considered standard in PoS, even though unlike all PoS chains, it would be able to produce its own MPC signatures. So, users would need to understand the risks. Second, any compromises would be isolated to ElonDog. If any funds were stolen, no other app chains would be affected. Third, this means that ElonDog can only increase Ren’s economic security. It still generates volume and fees that accrue to REN without affecting the safety of any other app chains.

1 Like

Interesting proposal, seems well thought out. I would love to see some input from the devs and Loong as well as from some of the current applications built on REN. What soes VarenX and ZeroDAO think about this? As a general point I would like to see Varen and ZeroDAO consulted or active in REN governance as I think their perspectives can be very informative in addition to that of darknode holders.

5 Likes