Skip to main content

Interhead Hydra: Two Heads are Better than One

  • Conference paper
  • First Online:
Mathematical Research for Blockchain Economy (MARBLE 2022)

Abstract

Distributed ledger are maintained through consensus protocols which have inherent limitations to their scalability. Layer-2 protocols operate on channels and allow parties to interact with another without going through the consensus protocol albeit relying on its security as fall-back. Channels can be concatenated into networks using techniques such as Hash Timelock Contracts (HTLC) to execute payments or virtual state channels as introduced by Dziembowski et al. [CCS’18] to execute state machines across a path of channels. This is realized by utilizing intermediaries, which are the parties on the channel path between both endpoints, who have to pay collateral to ensure security of the constructions. Dziembowski et al. [Eurocrypt’19] introduced multi-party state channels based on a virtual channel construction and more recently Hydra heads [FC’21] is a channel construction that allows multiple parties the execution of Constraint Emitting Machines (CEM). While existing protocols such as HTLCs can be extended such that two parties can interact with another across channels, there are no dedicated constructions that utilize multi-party channels and similarly allow more than two parties to interact across a network of channels. This work addresses this gap by extending Hydra and introducing the Interhead construction that allows for the iterative creation of virtual Hydra heads. Our construction is the first that (1) supports and utilizes multi-party channels and (2) allows for collateral to be paid by multiple intermediaries.

This work was supported by JST CREST JPMJCR2113 and JSPS KAKENHI 21H04879.

This is a preview of subscription content, log in via an institution to check access.

Access this chapter

Subscribe and save

Springer+ Basic
EUR 32.99 /Month
  • Get 10 units per month
  • Download Article/Chapter or Ebook
  • 1 Unit = 1 Article or 1 Chapter
  • Cancel anytime
Subscribe now

Buy Now

Chapter
USD 29.95
Price excludes VAT (USA)
  • Available as PDF
  • Read on any device
  • Instant download
  • Own it forever
eBook
USD 149.00
Price excludes VAT (USA)
  • Available as EPUB and PDF
  • Read on any device
  • Instant download
  • Own it forever
Softcover Book
USD 199.99
Price excludes VAT (USA)
  • Compact, lightweight edition
  • Dispatched in 3 to 5 business days
  • Free shipping worldwide - see info
Hardcover Book
USD 199.99
Price excludes VAT (USA)
  • Durable hardcover edition
  • Dispatched in 3 to 5 business days
  • Free shipping worldwide - see info

Tax calculation will be finalised at checkout

Purchases are for personal use only

Institutional subscriptions

Similar content being viewed by others

Notes

  1. 1.

    https://ycharts.com/indicators/ethereum_average_transaction_fee.

References

  1. Canetti, R. (2004). Universally composable signature, certification, and authentication. In Proceedings. 17th IEEE Computer Security Foundations Workshop (pp. 219–233). IEEE.

    Google Scholar 

  2. Chakravarty, M. M., Chapman, J., MacKenzie, K., Melkonian, O., Jones, M. P., & Wadler, P. (2020). The extended utxo model. In 4th Workshop on Trusted Smart Contracts.

    Google Scholar 

  3. Chakravarty, M. M., Chapman, J., MacKenzie, K., Melkonian, O., Müller, J., Jones, M. P., Vinogradova, P., & Wadler, P. (2020). Native custom tokens in the extended utxo model. In International Symposium on Leveraging Applications of Formal Methods (pp. 89–111). Springer.

    Google Scholar 

  4. Chakravarty, M. M., Coretti, S., Fitzi, M., Gazi, P., Kant, P., Kiayias, A., & Russell, A. (2021). Hydra: Fast isomorphic state channels. In International Conference on Financial Cryptography and Data Security. Springer.

    Google Scholar 

  5. Croman, K., Decker, C., Eyal, I., Gencer, A. E., Juels, A., Kosba, A., Miller, A., Saxena, P., Shi, E., Sirer, E. G., et al. (2016). On scaling decentralized blockchains. In International Conference on Financial Cryptography and Data Security (pp. 106–125). Springer.

    Google Scholar 

  6. Decker, C., & Wattenhofer, R. (2015). A fast and scalable payment network with bitcoin duplex micropayment channels. In Symposium on Self-Stabilizing Systems (pp. 3–18). Springer.

    Google Scholar 

  7. Dziembowski, S., Eckey, L., Faust, S., Hesse, J., & Hostáková, K. (2019). Multi-party virtual state channels. In Annual International Conference on the Theory and Applications of Cryptographic Techniques (pp. 625–656). Springer.

    Google Scholar 

  8. Dziembowski, S., Eckey, L., Faust, S., & Malinowski, D. (2017). Perun: Virtual payment hubs over cryptocurrencies. In Perun: Virtual Payment Hubs over Cryptocurrencies. IEEE.

    Google Scholar 

  9. Dziembowski, S., Faust, S., & Hostáková, K. (2018). General state channel networks. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security (pp. 949–966). ACM.

    Google Scholar 

  10. EthHub. (2021). Sidechains. https://docs.ethhub.io/ethereum-roadmap/layer-2-scaling/sidechains/.

  11. Itakura, K., & Nakamura, K. (1983). A public-key cryptosystem suitable for digital multisignatures. NEC Research & Development, 71, 1–8.

    Google Scholar 

  12. Jourenko, M., Larangeira, M., & Tanaka, K. (2020). Lightweight virtual payment channels. Cryptology ePrint Archive, Report 2020/998. https://eprint.iacr.org/2020/998.

  13. Jourenko, M., Larangeira, M., & Tanaka, K. (2021). Payment trees: Low collateral payments for payment channel networks. In International Conference on Financial Cryptography and Data Security. Springer.

    Google Scholar 

  14. Katz, J., Maurer, U., Tackmann, B., & Zikas, V. (2013). Universally composable synchronous computation. In Theory of Cryptography Conference (pp. 477–498). Springer.

    Google Scholar 

  15. Kiayias, A., & Litos, O. S. T. (2019). A composable security treatment of the lightning network. IACR Cryptology ePrint Archive, 2019, 778.

    Google Scholar 

  16. Kiayias, A., Zhou, H. S., & Zikas, V. (2016). Fair and robust multi-party computation using a global transaction ledger. In M. Fischlin & J. S. Coron (Eds.), Advances in Cryptology-EUROCRYPT 2016 (pp. 705–734). Berlin Heidelberg, Berlin, Heidelberg: Springer.

    Chapter  Google Scholar 

  17. Mealy, G. H. (1955). A method for synthesizing sequential circuits. The Bell System Technical Journal, 34(5), 1045–1079.

    Article  Google Scholar 

  18. Micali, S., Ohta, K., & Reyzin, L. (2001). Accountable-subgroup multisignatures. In Proceedings of the 8th ACM Conference on Computer and Communications Security (pp. 245–254).

    Google Scholar 

  19. Miller, A., Bentov, I., Bakshi, S., Kumaresan, R., & McCorry, P. (2019). Sprites and state channels: Payment networks that go faster than lightning. In I. Goldberg, T. Moore (Eds.), FC 2019. LNCS (vol. 11598, pp. 508–526). Heidelberg: Springer. https://doi.org/10.1007/978-3-030-32101-7_30.

  20. Nakamoto, S. (2008). Bitcoin: A peer-to-peer electronic cash system.

    Google Scholar 

  21. PDecker, C., Russel, R., & Osuntokun, O. (2017). eltoo: A simple layer2 protocol for bitcoin. See https://blockstream.com/eltoo.pdf.

  22. Poon, J., & Dryja, T. (2016). The bitcoin lightning network: Scalable off-chain instant payments. See https://lightning.network/lightning-network-paper.pdf.

  23. Richards, S., & Wackerow, P. (2021). Plasma. https://ethereum.org/en/developers/docs/scaling/plasma/.

  24. Richards, S., & Wackerow, P. (2021). Sidechains. https://ethereum.org/en/developers/docs/scaling/sidechains/.

Download references

Author information

Authors and Affiliations

Authors

Corresponding author

Correspondence to Maxim Jourenko .

Editor information

Editors and Affiliations

Appendices

A In-Depth Background

We provide an in-depth description of the Interhead CEM in Appendix C. In the following we provide additional background relevant to it (Fig. 8).

1.1 A.1 EUTxO\(_{\textsf{MA}}\)

The EUTxO model is extended by EUTxO\(_{\textsf{MA}}\) [3] to add multi-assets support. A EUTxO\(_{\textsf{MA}}\) is defined as a EUTxO but allows the value field to carry non-fungible tokens in addition to fungible coins. Moreover a transaction in the EUTxO\(_{\textsf{MA}}\) model has two more entries, i.e. it is of form (I, O, \(\textsf{forge}\), \(\textsf{fpss}\), S) where \(\textsf{forge}\) is a token bundle that can define a positive amount of token in case they are minted, or a negative amount of token in case they are burned. Moreover, \(\textsf{fpss}\) is a forging policy script taking the validation context \(\sigma \) as input and evaluates whether the transaction including its \(\textsf{forge}\) field is admissible. In the remainder we assume EUTxO\(_{MA}\), however we continue using the term EUTxO for brevity.

Fig. 8
figure 8

Illustration of State Transition S \(\rightarrow \) \(S'\) on input (i, aux). The box below a state displays information on the transaction constraints for the transaction that performed the state transition. The box to the right of the state displays an overview of the value field of the EUTxO that represents the state. Transaction fields that are empty or implicit from context are grayed out or omitted for simplification

1.2 A.2 Thread Token

A design pattern that allows to enforce that a given CEM (1) started in a valid initial state and (2) is unique compared to other instances of similar CEMs is using thread token. The validator of an initial state requires creation of a thread token with respective forging policy script. The token will be kept in all EUTxO value fields through a run of the CEM until it reaches a final state in which it is forced to be burned.

B Hydra-Specific Concepts

1.1 B.1 General Purpose Token

Hydra heads are limited in that it is not possible to forge and burn arbitrary token. Special purpose token, such as thread token, can only be forged within a specific context specified within its forging policy script. A transaction forging such a token cannot be included in an enforceable state as this would result in the token being forged within a Hydra CEM state transition which would likely violate its forging policy script. A possible workaround is as follows: A generalized token is forged in an arbitrary context and as of such can be forged during any state transition of a Hydra head. Generalized token can be created either as fungible or non-fungible token. A CEM that makes use of token to perform functionality does not forge or burn the token, but instead takes the required amount of token as input when required, and releases the token in the CEM’s final state at latest.

1.2 B.2 The Multi-Threaded CEM

We extend the notion of thread token by allowing CEMs to hold multiple thread token. A CEM can spawn threads to be executed in parallel by having a transaction contain multiple EUTxO in its outputs, each representing a separate CEM state and holding at least one thread token. In turn, multiple threads can be merged into a single thread by having a transaction spending multiple EUTxO representing CEM states, consuming their thread token and defining one EUTxO in its output that contains all thread token in its value field. We use multithreading in two cases. For one, we use multiple threads–one thread per identity–to efficiently collect EUTxO that are to be moved to the virtual head. Note that this is similar to how the Hydra CEM collects EUTxO [4] to be moved into a head. Second, we initially spawn one thread in each head, i.e. each instance of a Interhead CEM has exactly two initial states containing one thread token each. If the Interhead resolves optimistically, the CEM remains separate and the threads are never merged. However, in case of a dispute or a lack of collaboration, when the Interhead is converted into a regular Hydra head, the threads will be merged.

C The CEM Construction

In the following we provide details of the CEM by describing each state as well as the constraints provided by each verifier. With this implementation we explicitly assume that the protocol is executed within Hydra heads and moreover maintains a virtual Hydra head which is opened on the ledger in case of dispute. We illustrate key parts of the CEM using Figs. 9 and 11. Moreover, due to space constraints we do not formally define each verifier’s behaviour but describe it on a high level only.

1.1 C.1 Parameters

The parameters under which the Interhead CEM is executed are negotiated among all participants and intermediaries in the beginning. We structure the data stored within the CEMs state in data \(\delta ^v\) that is required for opening the virtual head on the ledger, data \(\delta _c\) that is common to the two partial CEMs in both \(H_0\) and \(H_1\) as well as data \(\delta _b\) that is only relevant in each individual head \(H_b\).

First, \(\delta ^v\) is a tuple of form \((K_{\textsf{agg}}\), \(\eta \), \(h_{\textsf{MT}}\), n, T, \(\textsf{cid}_0\), \(\textsf{cid}_1)\) where the first four parameter are the virtual head’s state and \(\textsf{cid}_b\) is a non-fungible token \(t_{s,b}\) in head \(H_b\) which is used as a unique identifier for the CEM half. These parameter are not derived during execution of the CEM, but represent a commitment from the Interhead participants to create a virtual head with the respective parameters and token. For one, \(\delta ^v\) is used to ensure that always the same virtual head is created, even if only data from one partial CEM is available which is the case when the CEM enters the punish phase. The token \(t_{s,b}\) is stored to ensure that the Interhead CEM instance is unique and that both partial CEMs are tied to another, i.e. no Interhead halve can be merged with another similar Interhead instance. Note that the EUTxO contained in \(\eta \) are not allowed to contain non-fungible token.

Second, \(\delta _{\textsf{c}}\) consists of tuple \((K_{agg,i}, h_{MT,i}, n_i, T_o, T_c)\) which contains data on the intermediaries, i.e. their aggregate verification key \(K_{agg,i}\), the head of the Merkle tree containing all individual verification keys \(h_{MT,i}\) and the number of intermediaries \(n_i\). Moreover it contains points in time \(T_o\), \(T_c\) \(\in \) \(\mathbb {N}\) specifying the end of the orderly and conversion time phases respectively. Verifier ensure that a transition happens within the orderly timezone by ensuring that for the transition’s time frame \([r_\textsf{min}, r_\textsf{max}]\) holds that \(r_\textsf{max}\) \(\le \) \(T_o\). Similarly verifier ensure that a transaction is within the conversion time frame by checking that \(T_0\) < \(r_{\textsf{min}}\) < \(r_{\textsf{max}}\) \(\le \) \(T_c\). Lastly a transition happens in the punish phase if \(r_{\textsf{min}}\) > \(T_c\).

Lastly, \(\delta _b\) consists of tuple \((b, K_{agg,b}, \eta _b, h_{MT,b}, n_b, \textsf{col}_b)\) where b \(\in \) \(\{0\), \(1\}\) is a bit identifying the order of both partial CEMs, \(K_{agg,b}\) is an aggregate verification key, \(\eta _b\) is a commitment of the EUTxO that the parties will move to the virtual head and it must hold that \(\eta \) \(=\) \(\eta _0\) \(\cup \) \(\eta _1\), \(h_{MT,b}\) is the root of the Merkle tree consisting of the individual verification keys of \(G_b\), \(n_b\) \(=\) \(|G_b|\) is the number of participants joining from \(H_b\), and \(\textsf{col}_b\) is the collateral required to be paid by the intermediaries. Note that \(\textsf{col}_b\) has to be at least as large as the amount of coins contained in the EUTxO in \(\eta _{1-b}\). The quantity and type of fungible token submitted in the collateral has to match the number of token submitted by the participants.

1.2 C.2 The Orderly Phase

The Initial State. The initial state is created in both heads \(H_b\) with parameter \(\delta ^v\), \(\delta _c\), \(\delta _b\) and is illustrated in Fig. 9. Each participant and intermediary verify that the parameter are as negotiated and, moreover, the intermediaries ensure that both initial states match and can be converted during the conversion phase in case of dispute. The transaction that sets up the initial state is signed using the aggregate verification keys of the participants in the respective head as well as the intermediaries. A party does only sign the transaction after positively verifying its correctness. The initial state requires that a non-fungible token as an ID, as well as a set of participation tokens [4] are provided. We require one participation token for each participant and each intermediary. These token ensure that each participant and each intermediary perform a commitment to the head and that all commitments can happen in parallel. The transition creates \(n_b\) \(+\) \(n_i\) separate outputs, each containing one participation token and can be spent by exactly one participant and intermediary respectively.

Commiting EUTxO. Similar to Hydra heads, all participants and intermediaries commit a set of EUTxO each to the Interhead which is done in parallel. Each participant and intermediary create one commit transaction that spends a participation token and several of their EUTxO within its inputs and stores information about them within its state \(U_{i, b}\).

Fig. 9
figure 9

Transition from initial to open state limited to the orderly phase

The Sync Open State. If all parties created a commit transaction, they can be spent by the sync-open transaction as shown in Fig. 9. The sync-open state verifies that the set of EUTxO \(\eta \) \(=\) \((U_{1,b}, \dots , U_{n_b, b})\) committed by the participants, matches their original commitment, i.e. \(\eta = \delta _b.\eta _b\). Moreover, it verifies that the collateral EUTxO \(\eta _b^c\) \(=\) \((U^c_{1,b}, \dots , U^c_{n_i, b})\) that are committed by the intermediaries contain a sufficient number of coins and fungible token. We store \(\delta _b^\textsf {open}\) in the CEMs state which equals \(\delta _b\) but we replace \(\delta _b.\textsf{col}_b\) with \(\eta _b^c\).

Aborting. Creation of the Interhead can be aborted by a transition from the initial state to the final state. The final state makes the EUTxO that were committed available on the ledger.

Fig. 10
figure 10

First step of the optimistic closure during the orderly phase

The Pending State. The pending state can be reached from the sync-open and is shown in Fig. 10. The pending state is used to give an opportunity for honest parties to either confirm head closure or to proceed to the conversion phase instead–in case a de-sync attempt was detected. The transition requires a final-annotated snapshot which transforms the EUTxO sets \(\eta _b\) and \(\eta _b^c\) into \(\eta '_b\). The final snapshot \(\eta '_b\) contains two components. For one, it contains a partition of the EUTxO within the whole Interhead namely the EUTxO that will be made in head \(H_b\) upon closure. Moreover, it contains EUTxO that pay back the intermediaries’ collateral. Note that the amount of coins that are paid back to the intermediaries within head \(H_b\) might be less than what was paid by the intermediaries upon opening the head, for instance, if participants from \(H_{1-b}\) performed payments to participants in head \(H_{b}\). However, as the coins within the partial CEM is constant, the participants’ coins will be taken from the coins submitted as collateral. However, in that case, this difference in coins will be available as additional collateral in \(H_{1-b}\). Each intermediary has to ensure that the sum of collateral paid back to them in both heads is equal to the collateral they originally paid into creating the Interhead.

The Final State. In addition to aborting opening the Interhead, the final state can be reached from the pending state by a confirmation of the intermediaries. Similarly to the abort case, the UTxO sets are made available within the transaction’s outputs. However, this time the EUTxO that are made available are taken from the final snapshot \(\eta '_b\).

1.3 C.3 The Conversion Phase

The conversion phase can conclude in two ways. For one, any intermediary can convert the Interhead CEM into a regular Hydra CEM. This requires that both partial CEMs are decommitted into a common enforceable state or the ledger respectively. This can happen by means of incremental decommits or closure of Hydra heads within time \(T^{\textsf{max}}\). Note that no other state transitions are permitted within the Interhead CEM but conversion to a regular Hydra head. All transitions can be performed by an intermediary only, but now do not require a signature corresponding to the intermediaries’ aggregate verification key \(K_{\textsf{agg},i}\). For another, if the conversion has not been performed, in case no honest intermediary exists, the CEM transitions into the punish phase.

Fig. 11
figure 11

Merging of both partial CEMs within the same enforceable state or the ledger. Transition can be performed from any combination of sync-open and pending states. Intermediaries’ collateral is unlocked

Abort. If there are any participants or intermediaries that have not yet committed EUTxO to the ledger, opening the Interhead can be aborted similarly to the way it is done during the orderly phase. However, if all participants and intermediaries committed EUTxO, aborting requires to transition into the pending state instead, because a de-sync attempt might have happened. Note that if the abort is permissible but the CEM transitioned into the pending state, it will be performed after during the punish phase.

The Merged State. Conversion to a regular CEM is by means of the merged state as shown in Fig. 11. Both partial CEMs can be merged, either from the open-sync state or the analogous pending state and any combination of both. The merge state requires that two generalized thread token are present and match \(\delta ^v.\textsf{cid}_0\) and \(\delta ^v.\textsf{cid}_1\). This ensures that only the intended partial CEMs can be merged as both non-fungible thread token are unique. Moreover, it is verified that the EUTxO sets match the initial commitment, i.e. \(\delta ^v.\eta \) \(=\) \(\delta _0.\eta _0\) \(\cup \) \(\delta _1.\eta _1\). This ensures that, in case all participants of one head as well as all intermediaries are corrupted, it is not possible for them to commit less EUTxO than required for the virtual Hydra head. The transaction releases all generalized token within its outputs, but similarly to the initial state it takes one thread token as well as \(\delta ^v.n\) participation token for all participants across both heads as input. Lastly, the CEM has one output for each set of EUTxO committed by the intermediaries to release their collateral in the same manner it is released in the final state. Note that from this point on, only information in \(\delta ^v\) is required and the remainder is removed from the state. Any participant can perform a transition into the open state of a regular Hydra CEM. We do not limit this transition to the conversion phase s.t. it can be performed indefinitely after start of the conversion phase. The state is directly derived from the data in \(\delta ^v\), i.e. \(K_{\textsf{agg}}\) \(=\) \(\delta ^v.K_{\textsf{agg}}\), \(\eta \) \(=\) \(\delta ^v.\eta \), \(h_{\textsf{MT}}\) \(=\) \(\delta ^v.h_{\textsf{MT}}\), n \(=\) \(\delta ^v.n\), T \(=\) \(\delta ^v.T\).

1.4 C.4 The Punish Phase

The purpose of the last phase is to allow any honest party to open the virtual Hydra head between all participants, even in the case that all other parties are corrupted. The Interhead CEM transitions into a Hydra CEM without the need of merging both partial CEMs. To ensure that this is possible, the coins and fungible token that are necessary for opening the Hydra head are taken from the collateral of the intermediaries who will lose it in the process. All transitions in this phase can be performed by any participant or intermediary.

The Punished State. If the CEM is in the sync-open state when entering the punish phase the CEM will transition into a regular Hydra CEM via the punish state. This conversion can be performed within the same enforceable state in which the partial CEM is executed and thus requires no incremental decommit and neither closure of the Hydra head. The transitions from and to the punished state are similar to those to and from the merged state with the exception that we only verify correctness of the data from the local Hydra head, i.e. \(\delta _b.\eta \) and \(\delta ^v.\textsf{cid}\). We re-use the existing thread token \(t_{s,b}\) for the Hydra CEM. The collateral of the intermediaries is not made available through the transaction’s outputs but used to finance conversion to the open state.

Open Ends. If the Partial CEM is in the initial state it can be aborted with a transition to the final state. Moreover, if the CEM was in the pending state it can now safely transition to the final state as no de-sync occured. Lastly, the transition from the merged state to the open state of a Hydra CEM is open ended and thus can be performed in the punish phase as well.

Rights and permissions

Reprints and permissions

Copyright information

© 2023 The Author(s), under exclusive license to Springer Nature Switzerland AG

About this paper

Check for updates. Verify currency and authenticity via CrossMark

Cite this paper

Jourenko, M., Larangeira, M., Tanaka, K. (2023). Interhead Hydra: Two Heads are Better than One. In: Pardalos, P., Kotsireas, I., Guo, Y., Knottenbelt, W. (eds) Mathematical Research for Blockchain Economy. MARBLE 2022. Lecture Notes in Operations Research. Springer, Cham. https://doi.org/10.1007/978-3-031-18679-0_11

Download citation

Publish with us

Policies and ethics