Beam 2021 Week #19 - Epoch: BeamX
Beam 2021 Week #19 - Epoch: BeamX
Covering May 4th - May 10th 2021
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.
Community
A happy Star Wars day to Beamers across the globe
Feedback on UI for the upcoming mobile wallet releases
Join in the fun with the BOC crew, take home some $RAYS, and help craft the platform for future Beamers!!
Sign up, stay tuned, and see you all next week!