The first layer options (L1) will always be limited in the amount of transactions processed in a given period of time, that is, their scalability, preventing the growth of the ecosystem.
If decentralization is not to be sacrificed, performance (scalability) will never be enough to allow large numbers of people to use a consensual distributed network.
In a previous article I explained in detail the challenge of scalability within the blockchain trilemma.
The solution may be to create a second layer (L2) on top of the first. The first layer is what we call blockchain, which is the most secure and decentralized network but with the lowest performance.
Above L1, it is possible to create a nearly independent network. The L2 is designed to scale as high as possible and make transactions fast and inexpensive.
Because the security of the first layer is guaranteed by distributed consensus, we say that transactions are processed on-chain, on the main blockchain. Users will be able to transfer funds to the second layer, where transactions are processed off-chain, that is, off the blockchain. So the first layer does not constantly check the transactions that take place in the second layer, but at certain times.
The Heads of Hydra
After about 5 years of research, IOHK published the article Hydra.
Hydra is the second layer solution, on an extended UTxO model that allows fragmentation of the delegation space without the need to fragment the general ledger.
Ouroboros Hydra breaks new ground in PoS scalability.
To participate in the second layer, each pool must create a new Hydra head. Adding more pools means that more heads can be added. Therefore, by adding new heads to the protocol, almost linear scaling can be achieved, more easily than adding additional hardware.
Hydra will guarantee low latency, and minimal data storage per node. Also, you can run smart contracts, so developers can easily create DApps, and use micropayments, voting, and other functionalities.
Hydra uses status 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.
You can imagine a smart contract as a program, or sequence of certain operations, that are executed conditionally, that is, an operation is only performed if an expected event has occurred. The smart contract is in a certain state at any time, which gradually changes conditionally as long as it is active, and events trigger the changes.
Hydra can adopt the first coat solution. The eUTxO model and the entire first layer smart contract infrastructure can be used within Hydra, which uses isomorphic multi-party state channels, which means that the channels use the underlying ledger programming language, inheriting the scripting language from Cardano blockchain commands.
Hydra transactions work directly with UTxO to change ownership. A smart contract, which is implemented on the blockchain, can be executed as is in Hydra’s head and there is no data conversion.
Ethereum uses Solidity to write a smart contract on the first layer. When the contract is to be transferred to the second layer it must be converted, since the second layer cannot work directly with Solidity.
To enable conversion, the Solidity smart contract must adapt. The blockchain scripting language and the second layer differ significantly. So conversion is necessary.
In Hydra, no conversion is needed as both layers can use the same scripting system.
Once a state channel is closed, the main state can be easily absorbed by the first layer. It’s an easy and straightforward task, as the same smart contract code is used both on and off the chain. It is even possible to create a smart contract on Hydra without registering with the blockchain. Blockchain, you can take over the smart contract and continue on-chain execution.
Any pool can initiate the creation of the Hydra head, asking a group of pools to join. Each part establishes a channel with all the other parts. If it is not possible for some reason, the creation of the head is aborted.
The parties exchange public key material through established channels, which is used for authentication of head-related on-chain transactions, as only primary members can. The material is also used for event confirmation, based on multiple signatures within the header.
The main initiator establishes the head by sending an initial transaction to the blockchain. Special tokens are created and assigned to all members of the head. Therefore, the public keys of the members can be bound with the tokens.
At this point, the state machine gets involved and takes care of the safe transfer of UTxO from the blockchain to the head. The first state is Initial. At this point, all members of the head can assign UTxOs to the head. If any member does not submit the confirmation transaction, the status changes directly from Initial to Final and the head will not be opened.
Suppose all members succeeded in submitting the commit transaction. In this case, the UTxOs are locked within the blockchain, leaving the main members to work with them. Members of the head can start using UTxO within the head once the state machine changes the state to Open. From that moment, the UTxO begins to evolve outside the chain, that is to say in layer 2.
At any moment, any part can initiate the closure of the head. The state machine changes the state to Close. There is a challenge period during which the parties provide their Final status, which is their UTxO set. After the challenge period elapses, the state machine changes the state to Final.
Similarly, as in the beginning, the state machine is responsible for the safe transfer of the UTxO set, which corresponds to the final state of the head, back to the blockchain, that is to layer 1.
Mithril
Mithril is the cryptographic construction that allows thin clients (such as wallets that are not nodes), to obtain data from the blockchain, without downloading all its content. Synchronizing the blockchain is an intensive operation, because it is an information base that is constantly growing. It is a protocol, which acts as a threshold signature scheme based on participation, being transparent, secure and lightweight.
The main problem is to extract only a certain part of the information from the network, for a thin client (without downloading the entire blockchain).
For certain messages or actions, it is important that a particular number of stakeholders provide their cryptographic signatures. The consensus protocol determines how the individual nodes assess the current state of the accounting system and has three main responsibilities, performing a leader check and deciding if a block should be produced, handling chain selection, and verifying produced blocks.
The larger the number of participants, the more complex it becomes to efficiently add their signatures.
Given the time it takes to validate a particular message, and the resource usage during chain synchronization, it is vital to provide a solution that makes aggregating multiple signatures fast and efficient without compromising security features.
The following properties are crucial for the schema:
- It must contain the threshold behavior of a cryptographic signature, which means that it is possible to produce a valid signature, only if a certain relationship of holders of funds is read, expressed in terms of delegation,
- As a Multisignature, the pre-signature fragments can be independently verified, and then added publicly to the final signature, and
- The final signature, of a constant size, is logarithmically verifiable, dependent on the total number of coin holders.
To conclude this article, I would like to present some of Charles Hoskinson’s ideas on offline transactions: Proof of Secure Erasure.
