Beam 2021 Week #19 - Epoch: BeamX

Covering May 4th - May 10th 2021

May 10

Download Beam Android Wallet | Beam iOS Wallet | Beam Desktop Wallet

Beam News

With the Hardfork height set for 1,280,000 the Beam machine pushes on, with a lot of exciting news and updates on the horizon.

This week we will take a look at some progress regarding one of the key aspects of the confidential DeFi ecosystem. Namely, bridges.

Beam Bridges

One of the big missions for Beam is to not only to provide privacy for those within the Beam ecosystem, but to that of other ecosystems. For this reason, bridges between Beam and Ethereum (along with other chains, e.g., Polkadot and BSC), has been one of the primary focusses for the R&D team. For a bridge to be most useful and censorship resistant, there is a real need for decentralisation.

In order for trustless bridges to function between Beam and other blockchains there is a need to see what is happening on the other chain. To transfer assets from Ethereum for example, there is a need to implement POW verification logic (Ethash) in a Beam Shader. As it turns out, even the verification of Ethash is a complex task for a smart contract. Let’s dive in and talk a little on the challenges, and the solution Beam is implementing.

Why is Ethash verification hard for contracts?

One of the major difficulties comes with the need for the ever changing mining parameters to be both known and proven. These change roughly every 5 days (known as epochs), and as of today are roughly 70MB in size. This requires several seconds of computation, even when performed natively, something unrealistic for contracts given their memory and run time limitations. A variety of ways to get around this were explored, coming to what we see as the optimal solution for Beam.

The solution:

For the contract to function as intended they need to attain (and prove) that a subset of elements is a part of the original set. In steps the Merkle multi-element proof. This enables a verifier to prove both the original data set size, and the positions of the various elements in its subset. This provides a minimal set of hashes, enabling the verifier to calculate the Merkle root only once. This comes with some pros and cons versus other approaches, briefly outlined below.

Pros:

No need for specialised support functions in the Beam virtual machine. Thus keeping it simple, and avoiding extra attack vectors
The header verification is reasonably fast

Cons:

To invoke the contract the prover needs to generate and process the DAG
The proof size is considerably large

This solution is a very practical one for Beam. Although the proof size is considerable, it is in no way prohibitive. With the current Beam block size limit being 1MB, it is still possible to verify tens of Ethereum headers at once. The verification time is fast, even faster than normal verification with a pre prepared cache. This approach to Beam bridges presents an optimal solution to a very difficult challenge. These bridges will enable assets from chains such as Ethereum to be represented on Beam, allowing for private transactions, and to take part in the confidential DeFi ecosystem coming with the BeamX launch.