The scalability in the blockchain is determined by the speed of processing transactions per second (TPS) and the cost of the same (network fee).
The transaction processing of the first layer (L1) is limited in the amount of scarce resources, that is, its scalability, preventing the growth of the ecosystem.
The first layer is what we call blockchain, which is the most secure and decentralized network, but with the lowest performance.
If decentralization is not sacrificed, performance will never be sufficient to allow large numbers of people to use a consensual distributed network.
The L2 is designed to scale, making transactions fast and inexpensive. It is almost like a parallel network.
What is Arbitrum?
Arbitrum, with its ArbOS protocol that runs on the Ethereum blockchain, allows moving the execution of smart contracts outside of L1, in such a way that participants can trust some chosen validators (also known as managers).
In a network like Ethereum, which is based on PoW, this is extremely important as executing contracts is expensive and requires a lot of resources. That means fewer resources to mine blocks. Thus, validators lack the incentive to validate costly transactions at the expense of block production.
By moving expensive calculations off the main chain and by only maintaining cheap state transitions on L1, Arbitrum can ease the network on one important factor: it revalidates only basic transactions.
To take advantage of Arbitrum’s fast transactions and low fees, an Ethereum user must submit their ETH or ERC20 token to the Arbitrum deposit contract. Once the deposit transaction is confirmed, the user can access their coins from the Arbitrum ecosystem.
It is important to differentiate between the Arbitrum and Ethereum ecosystem. Projects currently running on Ethereum are not automatically included in Arbitrum. Developers have to build their application on Arbitrum if they want it to work there.
Furthermore, it does so by providing incentives for Arbitrum managers to behave honestly in such a way that having at least one honest (and available!) Manager is sufficient for a contract to make legitimate progress.
Note that Arbitrum does not actually relieve the network of daily traffic per se, as any contract transitions still need to be posted to the chain, and the establishment of an Arbitrum virtual machine (A-VM) also requires transactions.
However, it achieves its purpose as it dramatically reduces the complexity of the L1 network without compromising too much
What is Hydra?
Hydra uses state channels, which extends the concept of pay channels as it has scheduling functionality. The parties maintain state channels, which can be agreed without interaction with the first layer.
So Hydra not only deals with the transfer of funds, but also the execution of smart contracts. For example, it is possible to create a smart contract on the first layer, and transfer it to the Hydra head where it can be executed.
With Hydra, the channel is multipartite, isomorphic, and comes with great security.
The multi-party channel is a relationship between 2 or more participants.
“Isomorphism” means that transactions running on a head can be mapped to L1 transactions and vice versa.
That’s different from Arbitrum as it requires Solidity contracts to be recompiled into Arbitrum Virtual Machine bytecode. And such a VM is “only” capable of executing contracts.
A Hydra head, by contrast, can process full-blown Cardano transactions, with native assets, metadata, scripts, and more.
It means Hydra bosses can take advantage of proven L1 ledger rules, providing strong guarantees of correctness. In addition, it greatly facilitates interoperability and maintenance of L2 as L1 changes.
A head is like a mini blockchain, with faster consensus.
With a dedicated virtual machine and compiler built from scratch, Arbitrum tackles a risky challenge for a financial system. Surely the team has extensively tested its components, but given the history of previous smart contract failures in the space, the likelihood of errors remains.
In fact, Arbitrum really only moves contract executions on L2 (but not traffic), whereas Hydra moves actual traffic off L1. Execution of the contract in Arbitrum will not be faster than in L1, and transitions are still subject to the settlement times of L1.
On a Hydra head, trades settle much faster than on the underlying L1.
State channels are generally bad for platforms with a global state like Ethereum, because in the event of a dispute, the entire channel state must be on-chain for verification. This is not the case in Hydra.
First of all, thanks to the eUTxO model, there is no mutable global state that contracts modify. In Cardano, there are only static validators that operate on eUTxO, this means that Cardano scripts can be validated in isolation.
Second, a Hydra head only advances if all participants have explicitly agreed to progress, money that has not been agreed to move cannot be moved. Disputes in Hydra can be resolved fully automatically and there is no need to inflate L1 with large state dumps.
At Arbitrum, dispute resolution is more involved. Because the state of the VM can be advanced by any of the VM administrators, a dispute requires Layer 1 mediation and several steps to determine who is honest.
On the bright side, a virtual machine can thrive with just one honest node.
Like I said, Arbitrum’s main goal is to alleviate L1 from costly contract executions. This circumvents a problem known as “The Verifier’s Dilemma”: verifying contracts requires a lot of resources and validators may not have a strong incentive to verify contracts. This can therefore lead to attacks in which attackers submit arbitrarily complex contractual transactions to keep other validators unnecessarily busy and in the meantime gain an advantage in mining blocks.
How does Cardano handle that?
- Proof of stake (no mining!)
- Guarantees
Alonzo expands the transactions to include a new component called “collateral inputs” (or simply collateral). These are special inputs that pools can collect in case they are provided with a transaction with scripts that are not validated to compensate for the resources involved.
While this may sound a bit scary, remember that Cardano scripts can be fully validated statically, even before being posted to the network. Therefore, in practice, well-designed wallets will not post badly scripted transactions and attackers will be financially punished.
Final Words
To conclude, both solutions are quite different because they also address different problems.
Hydra is a good option for cheap off-network transactions, while Arbitrum really is a way to move contract execution out of layer 1.
While state channels are heavily criticized in the PoW space, their trade-offs in the PoS lands are quite different, and with Hydra, the researchers found a sweet spot between simplicity, efficiency, and strong security guarantees, and it is very well suited to the UTXO model.
Hydra heads are just a first step on Cardano’s scalability roadmap, necessary if we want the ecosystem to grow.
Sources: Offchain Labs Dev Center , Hydra: Fast Isomorphic State Channels, Interhead Hydra: Two Heads are Better than One