Harmony as Interoperable Layer-2 for Ethereum
A Technical Deep Dive
TL;DR
- Harmony as a Layer 2 solution has a comparable (if not better) proposition for Ethereum applications when compared to Optimistic and ZK rollups
- Optimistic rollups have longer withdrawal wait times and ZK rollups are yet to be generalize to any EVM computations
- Harmony is fully EVM compatible with Ethereum tooling (Metamask, web3.js/ether.js)
- Harmony’s interoperability solution allows instant settlements and also gas-efficient transactions
Ethereum’s high gas fee and slowness has led to greater advancement of Layer 2 (L2) technologies. Layer 2 refers to a technology that help scale blockchain applications by handling transactions off the main Ethereum chain (Layer 1). A brief and comprehensive list of Layer 2 scaling solutions for Ethereum can be found here. At a very high-level Layer 2 scaling solutions differ with respect:
- Data storage (on-chain/off-chain): whether the data is stored on chain (meaning the transactions that are performed off chain in Layer 2 are recorded in a smart contract on Layer 1) and
- Validity/Fruad: nature of computation (meaning how the validation of the Layer 2 transactions takes place in Layer 1).
Below 2x2 matrix summarizes it pretty well. For example, in optimistic rollup, all the Layer 2 transactions are encoded and stored on-chain (in Layer 1) to ensure data availability (any validator can fetch these transactions and verify that Layer 2 is correctly computing its chain), and the validation happens only in the event of fraud. Whereas, in ZK rollup, the validation happens right away when the Layer 2 data is being to push to Layer 1 (the data is only accepted if the validation succeeds).
In terms of pros/cons of the two approaches:
- Storing data on-chain in the form of encoded transaction which can be replayed (data availability) allows anyone to fully verify the Layer 2 chain (no trust requirement on Layer 2).
- Instant validation vs fraud-based: instant validation, like in zk rollup, is expensive, however allows shorter wait times for withdrawals (~30 mins, includes rollup proving/verification time). The fraud-based validation is less expensive as it accepts any data sent from a Layer 2 bonded validator and allows a fraud-challenge period of 1–2 weeks. However this increases the wait times for withdrawal to 1–2 weeks.
- Harmony as a Layer 2 solution can be roughly categorized as off-chain data and validity proof based system.
- Please refer to Vitalik’s post on rollups for a quantitative comparison.
How does Harmony with its gas-efficient interoperable bridge compares to existing Layer 2s?
Let’s first consider how an user is on-/off-boarded to any Layer 2:
- User deposits his tokens to a Layer 2 smart contract on Layer 1
- User’s tokens are made available in Layer 2, where the user can transact any number of times using any application
- User is done using Layer 2 and can withdraw his tokens back to Layer 1
Harmony deploys a set of bridge contracts on Ethereum which will allow any user to on-/off-board by depositing their Ethereum tokens and get corresponding amount of Harmony tokens for transacting on Harmony chain. When the user is done transacting on Harmony, they can burn their Harmony tokens and submit a withdrawal request to Hamrony’s bridge smart contract on Ethereum. The bridge smart contract will invoke the Harmony’s gas-efficient light client on Ethereum to confirm users’ burn transaciton and allow withdrawal.
Where does Harmony win, in comparison to Layer 2s?
Harmony as Layer 2 (scaling) solution for Ethereum application is a better proposition with generic computation, faster settlement, shorter withdrawal wait times, and gas-efficient interoperability.
Generic computation (in comparison to zk rollups)
Harmony is fully EVM compatible, hence provides an execution environment for any generic EVM computation. In other words, any Ethereum application will be able to run on Harmony without requiring any special computational system or execution environment. This is an important property for any Layer 2 to be successful that they must provide similar (if not better) execution environment as Layer 1.
Faster settlements with shorter wait times for withdrawals (in comparison to optimistic rollups)
Layer 2 solutions provide scalability by rollup (batching) transactions off-chain. By doing so, they are able to provide faster transaction confirmations at lower transaction fees. For instance, Optimism (an optimistic rollup based Layer 2) can confirm a transaction in 300ms at a low cost of $0.001. Similarly, ZkSync (a ZK rollup based Layer 2) can confirm a transaction in 10min at a low cost of $0.001. In comparison, Harmony (as a Layer 2 solution) can confirm transactions in 2s at a very low cost of $0.000001.
Apart from transaction confirmation time and transaction cost, the Layer 1 settlement time (or the withdrawal wait time) is also important. Users of optimistic rollups have rather long wait times of up to 2 weeks and the users of zk rollups have 10-15mins of wait time. In comparison, Harmony’s withdrawal times can vary from few seconds to ~18 hours depending on how far in the current epoch and how cheap the withdrawal cost needs to be.
Gas-efficient interoperability
Harmony deploys a light client smart contract on Ethereum which will keep track of what is going on in the Harmony chain. This light client is kept up-to-date by any relayer that relays the block header information at every checkpoint.
The user withdrawal process is as follows:
- Execute burn transaction
- Compute or obtain proof of burn
- Wait for the relayer to send the next checkpoint block header info to Harmony light client on Ethereum. Self relay is also possible with some extra cost to further speed up the withdrawal.
- Submit the proof of burn to bridge smart contract on Ethereum to successfully withdraw.
About Gas Efficiency of Harmony Light Client
Harmony Light Client is designed to be gas efficient.
Since Harmony is a Proof-of-Stake (PoS) blockchain, verifying a block header only requires checking the signatures of the validators who signed the block. Harmony uses BLS signatures for signing blocks, hence checking the BLS signatures requires executing the BLS pairing functions, which can get really expensive for checking 200+ validator signatures. Fortunately, Harmony aggregates the BLS signatures (a nice property of BLS), hence the light client only has to check 1 signature per block. Furthermore, the validator set does not change within an epoch, which makes the light client even more efficient. Overall, the lightclient has to verify 1 signature every epoch (an epoch contains 32768 blocks or ~18 hours). Hence, for a simple SPV style light client, it will only take downloading (or processing) 1 block per epoch (preferribly the epoch block that contains the election information).
Verification in Harmony light client
When a user claims a Harmony transaction by submitting proof of transaction, the Harmony light client has to perform following two steps:
- Using the block’s transaction root, find the transaction that the user is claiming (aka transaction inclusion proof)
- Make sure that the block that contains the user transaction is a valid block in the Harmony chain (aka block inclusion proof)
The cost of checking 1 involves hashing logarithmic number of transactions in the block, for example, hashing takes 40 gas and for log(1000 transactions), it will need 40*6 = 240 gas. The cost of checking 2 however requires BLS pairing, which is as expensive as ~380K gas.
For reducing the gas required for verifying the block inclusion proof (point 2 above), Harmony light client uses MMR checkpointing approach. All the blocks produced within an epoch are chained together in the form of a Merkle Mountain Range (MMR) by accummulating the block hashes together. This optimization reduces the verification complexity from linear (in terms of number of blocks in the epoch) to logarithmic. For example, 1 epoch contains 32786 blocks and it will only take 11 hashing operations to perform block inclusion verification. If the per hashing operation is 40 gas, the total verification cost is only 40*11=440 gas, when compared to 380K for BLS signature verification.
However, there is a caveat here. The proof of transaction can only be verified by the Harmony light client, after receiving the next checkpoint. In a worst case, this waiting time can be ~18 hours (assuming that the user performed a transaction at the begining of an epoch) and the next checkpointing happens at the end of the epoch. However, the user can always perform an early checkpoint themselves (costing them ~380K gas), in the meanwhile benefiting all the pending verifications along the way. There can be opportunities for designing innovative cost share models for frequent checkpointing.
Where can things go wrong?
For Harmony as a Layer 2 solution to fail, more than 2/3 of the Harmony validators have to stop producing blocks or act dishonestly (produce malicious blocks). A decentralized system like Harmony with 1000 validators, the above assumption is reasonable to make.
Data availability problem
While Harmony is a comparable Layer 2 alternative, it currently does not send its transactions to Ethereum, and hence prevents anyone from replaying the transactions to validate Harmony chain. However, as long as there exists at least one honest relayer, the Harmony light client on Ethereum will have up-to-date block header information of every block produced on Harmony, using which anyone on Ethereum chain can validate that the Harmony transactions are executed honestly. Again this is a reasonable assumption to make, as in any Layer 2 solution, there must exists at least 1 honest relayer (aka a sequencer or aggregator) that periodically sends its data to Layer 1. In future, Harmony will explore the possibility to sending the encoded transactions to Ethereum for explicit data availability.
Final thought
Harmony being fully EVM compatible with Ethereum tooling (MetaMask, web3.js, ether.js) and comparable (if not better) interoperable solution makes it a better Layer 2 (scaling) proposition for Ethereum applications.
