The write up focuses on one of the approaches to two-way bridge. Vitalik mentions that a replication of Eth1 data voting maintained by miners could be a source of
This article investigates the major properties of two-way bridged system driven by miners voting rather than in-depth technical details like a particular approach to Eth1-side storage of
eth2_data. It also assumes Eth1 clients use a full version of beacon chain client.
For the sake of simplicity, beacon chain data placed on Eth1 is denoted as
eth2_datawhatever structure and fields it would have.
- On the way to Eth1 finality: On the way to Eth1 finality
Copy of Eth1Data poll
Miner maintains a beacon chain client and queries it for
eth2_dataupon block creation. A reference point for the query could be timestamp of a block at the beginning of the voting period. An
eth2_datasample that collects
BLOCKS_PER_ETH2_VOTING_PERIOD * VOTING_MULTIPLIERvotes is getting published on Eth1.
Miners are allowed to vote for
eth2_datapublished previously to cope with failures of various kinds, whether they are caused by malicious behavior or by software errors.
Picking up parameter values
Voting threshold set to
BLOCKS_PER_ETH2_VOTING_PERIOD/2 + 1wouldn’t work for the period of any length. As it would reduce an adversary power limitation by up to
10%and would make bridge vulnerable to
41%attacks (exact value depends on the length of the period but never reaches desirable
To make this solution viable, we have to favor safety over liveness and pick satisfying
VOTING_MULTIPLIER > 1/2. Parameters calculation comes up with the following values (link to the calculation sheet).
Given parameter values, we can outline meanings of properties that Eth2 voting process got if it would follow this scheme.
Property Value Safety Fault Tolerance
Liveness Fault Tolerance
Chance of Safety Violation
Chance of Liveness Violation
Blocks to finality
1069..2953blocks* (4.2 to 11.5 hours)
* Blocks to finality is a sum of
BLOCKS_PER_ETH2_VOTING_PERIODwith values from the previous write up where
1929are evaluations of the new proposal and the status quo, respectively.
To reduce risks, Vitalik suggests setting the length of the voting period to one week. The table below shows the meanings of properties for the one-week voting period.
Property Value* Safety Fault Tolerance
Liveness Fault Tolerance
Chance of Safety Violation
Chance of Liveness Violation
Blocks to finality 1 week
* Values are based on 1 week tab of the calculation sheet.
- Time to finality limitation. A thousand blocks to finality seems to be the best that this solution can give. The reduction of this number either reduces safety and liveness fault tolerance or increases the chance of failure of one or the other. You may check the calculation sheet for details.
- Liveness weakening. Liveness fault tolerance of the voting process is less than Eth1 fault tolerance.
Instead of passing through a voting process Eth1 starts to invalidate blocks containing invalid
eth2_data. Validity conditions for the data are as follow:
- The checkpoint must be finalized and belong to the canonical view of beacon chain.
- Eth1 block must belong to the canonical view of Eth1 chain.
- The checkpoint must be either equal to or descendant of the previous one.
- Eth1 block must be either equal to or descendant of the previous one.
- Beacon chain validators must vote for Eth1 block only if it contains
eth2_datasatisfying condition 1.
It worth noting that condition 1 opens a room for racing where Eth1 block could be deemed invalid due to Eth2 network latency. It will likely mean that Eth2 experiences networking issues. Possible mitigation would be to take a distance from beacon chain head.
Safety and Liveness
For the rest of this section, we assume safety and liveness of
Eth1Datavoting are tight with corresponding beacon chain properties. As we’ve discussed previously, the status quo doesn’t hold this. But there is a solution addressing that problem.
If a client follows the protocol supporting the above conditions, then the following statements are true:
- Neither finalized checkpoint nor finalized block can’t be reverted on Eth1 chain.
- There is no possibility to finalize two conflicting Eth1 blocks as long as beacon chain has no safety failure.
- With honest majority of miners it is possible to keep
eth2_dataup-to-date as long as beacon chain has no liveness failure.
Statement 1 directly follows from conditions 3 and 4. To prove statement 2, suppose two conflicting Eth1 blocks were finalized. Two cases are making it possible:
- beacon chain validators polled a pair of inconsistent Eth1 blocks (Figure 1a)
- blocks are finalized by controversial beacon chain forks (Figure 1b)
The first case means the broken
Eth1Datavoting process. The second implies that the canonical view of beacon chain contains two conflicting finalized checkpoints. Either of these two is a safety failure in beacon chain and contradicts the second part of statement 2.
While the first case can be remedied by condition 4, the second one looks more severe since it could cause a split in Eth1.
Liveness statement (statement 3) can be proved in a similar way to statement 2. If
eth2_datahadn’t been updated for a significant amount of time, it would mean that either
Eth1Datavoting was stuck or Eth1 liveness was violated. Both the former and the latter contradict statement 3.
Instant finality approach has two options affecting the security of the bridged system:
- Only miners run beacon chain clients. In this case, regular users can’t check conditions 1 and 3 and are sharing security between honest majority of miners and beacon chain. Therefore, making issuance reduction unattainable.
- All Eth1 users run beacon chain clients. Users running beacon chain clients can’t be forced through incorrect beacon chain forks if they check the conditions. According to this, beacon chain becomes the only supplier of Eth1 security.
These two options are not mutually exclusive and could become a pair of subsequent milestones within the same roadmap.
Suppose there is a split in beacon chain, and there are two forks in Eth1 supporting a pair of corresponding beacon chain forks. Then the following scenario is possible:
- Beacon chain fork
BC_1processes a portion of deposits from
- One may do a sequence of
1 ETHdeposits on
Eth1_2to increment the deposit counter.
- After that, deposits from step 1 can be replayed on
Conditions 2 and 5 establish a one-to-one relationship between particular Eth1 and beacon chain forks, preventing inconsistent read and bounce attack scenarios.
One of the potential problems with this scheme lies in the field of software errors. Suppose there is a consensus break between two major beacon chain clients, which means that the canonical view of beacon chain differs for those two. Then miners relying on this pair of clients would disagree about their view of Eth1 chain. Which, in turn, reduces the pace of honest blocks in Eth1 and increases its vulnerability to 51% attacks.
One could describe a simple model representing the influence of beacon chain software errors on Eth1 safety and liveness. Eth1 guarantees safety and liveness if
(1 - γ)(1 - δ)α > β, where
βare total mining rates of honest and malicious miners, respectively,
0 < δ < 1is a parameter proportional to network latency. And
0 < γ < 1is the probability of invalidating Eth1 block due to the failure of beacon chain software,
γis proportional to the number of different clients used by beacon chain validators and inversely proportional to their maturity.
One of the approaches to reduce
γis to set up a cluster of beacon chain clients and follow a conservative strategy of updating
eth2_dataonly when the majority of cluster participants agree on the new portion of data. This approach will work with honest miners. But in a more realistic rationale majority model, there is a centralization risk caused by replacing locally maintained cluster by a public provider of
- Cost of issuance reduction. The cost of the desired issuance reduction is to obligate regular users to run beacon chain client software.
- Centralization risk. Rationale miners and regular users tend to use public services to query beacon chain data.