https://ethresear.ch/t/forkable-reversible-roll-ups/16781

Tldr:
We are proposing a new kind of roll-ups that can reverse and recover from serious failures, such as bugs in smart contracts, all without relying on multi-signatures.

Motivation:

Cryptocurrency technology embodies the principle that “code is law,” establishing a transparent and open system for financial transactions. However, this “code” is not infallible, and sometimes unforeseen bugs and challenges emerge, potentially resulting in substantial financial losses.

To operate under normal conditions with the crypto ethos, but still address this weakness, we propose the development of forkable, reversible roll-ups that allow for the reversal of problematic transactions without depending on central trust entities, like multi-signatures. This means creating a system that can essentially “undo” errors and thereby protect users and their assets.

Design:

Forkable Roll-up:

In simple terms, a forkable roll-up is a roll-up with the ability to fork itself: it can create a copy of itself to isolate and address issues without affecting the original chain. For this, the original chain splits into two paths, each operating independently with their own unique identifiers (chain IDs) and continuing to record their own transactions. One fork will have a modified state – with a deployed fix for a bug – while the other fork will be the normal chain. Users can choose freely which fork to adopt: Either the one with a state update or without.

The value of each fork can then be assessed based on trading activities in the primary layer (L1), helping users to identify the more valuable option between the two.

Forkable Roll-up bridges:

There are two kinds of bridges for forkable roll-ups:

1. Majority Chain Bridge:

This bridge can hold any assets and after a fork, it automatically directs assets to the new fork with the higher value.

2. Real World Asset bridge:

RWA will be bridged into a forkable roll-up by a bridge from L1 with an owner – ideally the RWA issuer. After a fork, the bridge will send the funds to the new child bridge of the fork that is chosen by the owner of the bridge. It is expected that the owner will send the funds to the chain with the higher marketcap, unless an attack is started against the open interest of the chain. If the owner is the RWA issuer, there is no additional trust assumption for a user.

With these definitions, we can define a reversible forkable roll-up:

Reversible forkable roll-ups:

Reversible forkable roll-ups are roll-ups that are able to recover from severe smart contract issues. They will fork each time a hack has repercussions beyond a certain threshold measured in dollars.

Then they go through two phases:

Phase 1: Containment fork:

Bots are proposing a fork that contains the hack: E.g. they set the state of the chain to the state right before the hack and freeze the vulnerable contracts – maybe by setting the bytecode of the affected contracts to zero. This will prevent the hack + restore all funds that are not yet bridged away from the chain – which can be prevented by having a delayed bridge. Hopefully, these forks can be triggered by bots quite quickly. Users can then choose the most promising containment fork and use it for their business needs.

Phase 2: Resolution fork:

These forks will unfreeze the vulnerable contract and replace it with a fix. This for sure is much harder to organize than a containment fork and will take more time and coordination. However, it should eventually happen for each containment fork. Again users will have the choice of which fork they actually follow and RWAs issues will likely follow the chain with the highest market value.

Analysis:

The presented roll-up builds a framework that allows to change the state in a trustless – non-multisig – manner with the following assumptions:

• Assumptions for assets in the Real World Asset bridge: Assuming the users are trusting their RWA issuer – that is needed for any RWA – and this issuer controls the bridge, then the only additional trust in this construction taken by each user is that the RWA issuer is technically and legally able to choose the right fork for representing their RWA after a fork. In most cases this act of choosing a fork should be trivial: The market will likely decide which chain should be picked by forking and trading the forked native tokens on L1. Only in unexpected situations the market could fail and RWA issues would have to investigate the situation more deeply. Even a “wrong choice” by the issuer is not in all cases fatal as users in most situations withdraw the RWA assets to L1 from any fork.
• Assumptions for assets in the Majority Chain Bridge: For anyone holding non-forkable L1 native assets in the forkable chain that are deposited via majority-chain-bridge, there are also economic incentives securing their assets, as long as the value of all the deposited L1 native tokens is less than the market cap of the native token in L2. If the L1 native assets are less valuable than the L2 native token, then the cost of manipulating the value of the L2 forks is – in a market with perfect information – higher than any potential gains from stealing L1 tokens and thereby not worth any profit-oriented attacker.

1 post – 1 participant

Read full topic

https://ethresear.ch/t/forkable-stablecoin/15820

TLDR : We describe a stablecoin design engineered to effectively manage contagious chain forks.

Co-authored by @edmundedgar and @josojo

Why its useful to develop forkable stablecoins

There are two major benefits to developing and adapting forkable stablecoins:

1. Forks may break stablecoins, or if forks can’t happen that weakens Ethereum’s security
   Economic forks are challenging for stablecoins collateralized by crypto-native assets: The value of the collateral is approximately split among two chains, while for each chain the face value of the stable asset they represent appears on both. A chaotic situation arises where depending on the ultimate ratio of the collateral value, the value of the stablecoin might double (if collateral on both chains preserve enough value to avoid liquidation) or disappear altogether (if neither does). If we expect only one fork to avoid liquidation, a user putting up collateral must account for the prospect that the part of their value they hold on the losing chain will be liquidated.
   The result is that a fork will potentially do lethal damage to stablecoins as currently designed. Alternatively, it may be the fact that this damage would occur makes contentious forks impossible, which weakens the security of the chain, underpinned as it is by subjectivocracy.

2. Enable a more secure oracle for the stablecoin:
   If a stablecoin can actually handle forks in a relatively clean manner, this would allow for deploying them on forkable systems: This opens the door for new, more secure oracle designs that use subjectivocracy. Elsewhere we discuss how these new oracles could be enshrined into a forkable L2. These new oracles would then improve the stablecoin itself, as oracles are a fundamental building block for stablecoins.

We propose a design that rebases the stablecoin token on each side of the fork in line with the collateral, preserving the total value of the stablecoin and avoiding instant liquidations after the fork.

Description of the design

Assumptions:
For this write-up, we assume that there is an oracle for the stablecoin that provides the price between the forked collateral. In the system, we propose here whereby the forkable stablecoin and its collateral are living on a forkable L2, the price ratio can be determined on L1 via an auction/trading without further assumptions on a working oracle.
Solution
The proposed stable token works quite similarly to RAI or DAI. Stable tokens, called forkable DAI (FAI), are created by opening CDP positions, and interest is paid through a slight, continuous change in the FAI token’s value compared to the dollar.

If the chain is forked, each child chain will receive the collateral ratio price via the oracle. The FAI value will be rebased based on the forked collateral ratio. For example, if the ratio split between the branches is 30% to 70%, on the 30% branch, the FAI will be rebased to hold only 30% of its value, and the remaining 70% will be held on the other branch. If the overall market cap of the underlying token of the chain (the sum of both child tokens) does not change during the forking process, all CDPs should be well covered on both chains.

After the fork, each FAI holder has the option to reunite their split FAI value by trading FAI^1 from the first branch for FAI^2 from the second branch. This ensures that the promise to each customer to hold roughly $1 of value is honored during the forking process. Subsequently, although the value of the collateral is likely to change both in absolute terms and in relation to the collateral on the other fork, the value of each fork of the stablecoin should hold its (rebased) value by the normal mechanism.

Risks and limitations

• If a user has locked their FAI in a long-term commitment contract and cannot exchange it from a losing branch, they may effectively lose value. For example, if a branch initially holds 5% of the overall market capitalization and is later abandoned, causing its newly underlying token to be worth 0, then the CDPs can no longer remain active and the FAI will be liquidated. This results in a 5% loss of value for the user since the original value of FAI was rebased by 5% during the forking process. The remaining 5% of the value will be lost once the claim is available to the customer, as all CDPs will be liquidated, and the collateral on that fork will be rendered worthless. This loss scenario only occurs when a minority fork initially has value but is later completely abandoned. Historical data from forks such as ETHC, ETHW, and BCH show that they usually retain some valuation for a considerable amount of time, allowing stablecoin owners ample time to leave the fork with the correct valuation of their stablecoins. This risk can also be mitigated by setting a minimal cut-off beyond which all value should be assigned to the majority fork. In the past stablecoins have survived the creation of minority forks worth 5% or so of the value of the majority fork without major disruption for a reasonable time frame.

• Although this system protects the value of a stablecoin held by a user, some contracts that expect to have entire face value in the stablecoin token will need to handle additional complexity. For instance, if an unforkable real-world asset is priced in the stablecoin, the price denominated in the stablecoin will change. We can make this process easier for contracts to handle by giving the stablecoin the ability to report the price at which it was rebased.

Overall we think that this stablecoin design is very promising as it is the first stable coin design that is forkable and allows subjectivocracy to protect the oracle and thereby eliminate one major risk factor of usual stablecoin designs. We are curious about your input or other forkable stablecoin designs from the community!

1 post – 1 participant

Read full topic