From 1d68e33a01be85122b547f1727ec8b6f5392b2fe Mon Sep 17 00:00:00 2001 From: Noon van der Silk Date: Fri, 20 Dec 2024 23:01:52 +0000 Subject: [PATCH] input-output-hk -> cardano-scaling --- docs/adr/2021-06-09_005-use-io-sim-classes.md | 2 +- docs/adr/2022-03-17_015-admin-api.md | 4 ++-- docs/adr/2022-03-23_016-keep-rejected-adr.md | 2 +- docs/adr/2022-04-13_018-single-state.md | 4 ++-- docs/adr/2022-12-06_022-model-based-testing.md | 2 +- docs/adr/2023-06-19_024-event-sourced-persistence.md | 4 ++-- docs/adr/2023-09-09_027-network-resilience.md | 2 +- docs/adr/2023-12-06_030-use-cbor-for-tx.md | 4 ++-- docs/benchmarks/index.md | 2 +- docs/docs/configuration.md | 4 ++-- docs/docs/dev/architecture/networking.md | 2 +- docs/docs/dev/index.md | 2 +- docs/docs/dev/rollbacks/index.md | 2 +- docs/docs/faqs.md | 2 +- docs/docs/how-to/operating-hydra.md | 4 ++-- docs/docs/installation.md | 2 +- docs/docs/known-issues.md | 2 +- 17 files changed, 23 insertions(+), 23 deletions(-) diff --git a/docs/adr/2021-06-09_005-use-io-sim-classes.md b/docs/adr/2021-06-09_005-use-io-sim-classes.md index 927682f4884..7c1c2a3d81b 100644 --- a/docs/adr/2021-06-09_005-use-io-sim-classes.md +++ b/docs/adr/2021-06-09_005-use-io-sim-classes.md @@ -16,7 +16,7 @@ Although we try to contain the use of IO at the outskirt of the Hydra node using Testing asynchronous and concurrent code is notoriously painful -The ouroboros consensus test suite and [hydra-sim](https://github.com/input-output-hk/hydra-sim) simulation have demonstrated the effectiveness of abstracting concurrent primitives through the use of typeclasses (MTL-style pattern) and being able to run these as pure code, harvesting and analysing produced execution traces. +The ouroboros consensus test suite and [hydra-sim](https://github.com/cardano-scaling/hydra-sim) simulation have demonstrated the effectiveness of abstracting concurrent primitives through the use of typeclasses (MTL-style pattern) and being able to run these as pure code, harvesting and analysing produced execution traces. There are other such libraries, e.g. [concurrency](https://hackage.haskell.org/package/concurrency) and [dejafu](https://hackage.haskell.org/package/dejafu), as well as the venerable [exceptions](https://hackage.haskell.org/package/exceptions) (for abstracting exception throwing). diff --git a/docs/adr/2022-03-17_015-admin-api.md b/docs/adr/2022-03-17_015-admin-api.md index ad85df1a9e1..d0ec2147562 100644 --- a/docs/adr/2022-03-17_015-admin-api.md +++ b/docs/adr/2022-03-17_015-admin-api.md @@ -18,7 +18,7 @@ Proposed * Having static network configuration is probably not sustainable in the long run, even if we don't add any fancy multihead capabilities to the node, as it would make it significantly harder to have automated creation of Heads. * There's been an [attempt](https://github.com/cardano-scaling/hydra/pull/222) at providing a file-based network configuration but this was deemed unconvincing * [Hydra paper (sec. 4, p. 13)](https://eprint.iacr.org/2020/299.pdf) explicitly assumes the existence of a _setup_ phase - * This _setup_ is currently left aside, e.g. exchange of keys for setting up multisig and identifying peers. The [hydra-node](https://github.com/input-output-hk/hydra/blob/abailly-iohk/admin-api-adr/hydra-node/exe/hydra-node/Main.hs#L41) executable is statically configured and those things are assumed to be known beforehand + * This _setup_ is currently left aside, e.g. exchange of keys for setting up multisig and identifying peers. The [hydra-node](https://github.com/cardano-scaling/hydra/blob/abailly-iohk/admin-api-adr/hydra-node/exe/hydra-node/Main.hs#L41) executable is statically configured and those things are assumed to be known beforehand ## Decision @@ -41,7 +41,7 @@ The following picture sketches the proposed architectural change: * This API is an interface over a specific _resource_ controlled by the Hydra node, namely its knowledge of other peers with which new _Head_s can be opened. As such a proper REST interface (_not_ RPC-in-disguise) seems to make sense here, rather than stream/event-based [duplex communication channels](/adr/3) * We can easily extend such an API with WebSockets to provide notifications (e.g. peers connectivity, setup events...) * *Why a separate component?* - * We could imagine extending the existing [APIServer](https://github.com/input-output-hk/hydra/blob/9129c7c013fe2cdc77db048a54981e1ace0843b8/hydra-node/src/Hydra/API/Server.hs) interface with new messages related to this network configuration, however this seems to conflate different responsibilities in a single place: Configuring and managing the Hydra node itself, and configuring, managing, and interacting with the Head itself + * We could imagine extending the existing [APIServer](https://github.com/cardano-scaling/hydra/blob/9129c7c013fe2cdc77db048a54981e1ace0843b8/hydra-node/src/Hydra/API/Server.hs) interface with new messages related to this network configuration, however this seems to conflate different responsibilities in a single place: Configuring and managing the Hydra node itself, and configuring, managing, and interacting with the Head itself * "Physical" separation of endpoints makes it easier to secure a very sensitive part of the node, namely its administration, e.g by ensuring this can only be accessed through a specific network interface, without relying on application level authentication mechanisms ## Consequences diff --git a/docs/adr/2022-03-23_016-keep-rejected-adr.md b/docs/adr/2022-03-23_016-keep-rejected-adr.md index 0c19b9d5727..c324d335b35 100644 --- a/docs/adr/2022-03-23_016-keep-rejected-adr.md +++ b/docs/adr/2022-03-23_016-keep-rejected-adr.md @@ -14,7 +14,7 @@ Accepted We have started using _Architecture Decision Records_ as our primary way to document the most important design decisions we take while developing Hydra Node, and this has proved effective in fostering fruitful discussions about major architecture changes. -During the course of this project, we have sometimes had debates on various topics leading to rejection of [some ADRs](https://github.com/input-output-hk/hydra/pull/230). It could be the case that a previously rejected proposal turns out to be interesting, either because the context and situation have changed enough to reevaluate a proposal, or as background for some new proposal. +During the course of this project, we have sometimes had debates on various topics leading to rejection of [some ADRs](https://github.com/cardano-scaling/hydra/pull/230). It could be the case that a previously rejected proposal turns out to be interesting, either because the context and situation have changed enough to reevaluate a proposal, or as background for some new proposal. ## Decision diff --git a/docs/adr/2022-04-13_018-single-state.md b/docs/adr/2022-04-13_018-single-state.md index 84d77a05b54..be7098c30d5 100644 --- a/docs/adr/2022-04-13_018-single-state.md +++ b/docs/adr/2022-04-13_018-single-state.md @@ -16,7 +16,7 @@ Superseded by [ADR 23](/adr/23) and [ADR 26](/adr/26) 1. A `HeadState tx` provided by the `HydraHead tx m` handle interface and part of the `Hydra.Node` module. It provides the basis for the main `hydra-node` business logic in `Hydra.Node.processNextEvent` and `Hydra.HeadLogic.update` [Creation](https://github.com/cardano-scaling/hydra/blob/a98e2907c4e425de2736782793383aad63132c14/hydra-node/src/Hydra/Node.hs#L256-L257), [Usage](https://github.com/cardano-scaling/hydra/blob/a98e2907c4e425de2736782793383aad63132c14/hydra-node/src/Hydra/Node.hs#L174) 2. `SomeOnChainHeadState` is kept in the `Hydra.Chain.Direct` to keep track of the latest known head state, including notable transaction outputs and information how to spend it (e.g. scripts and datums) - [Code](https://github.com/input-output-hk/hydra/blob/a98e2907c4e425de2736782793383aad63132c14/hydra-node/src/Hydra/Chain/Direct.hs#L156-L162), [Usage 1](https://github.com/input-output-hk/hydra/blob/a98e2907c4e425de2736782793383aad63132c14/hydra-node/src/Hydra/Chain/Direct.hs#L449), [Usage 2](https://github.com/input-output-hk/hydra/blob/a98e2907c4e425de2736782793383aad63132c14/hydra-node/src/Hydra/Chain/Direct.hs#L414), [Usage 3](https://github.com/input-output-hk/hydra/blob/a98e2907c4e425de2736782793383aad63132c14/hydra-node/src/Hydra/Chain/Direct.hs#L349-L352) + [Code](https://github.com/cardano-scaling/hydra/blob/a98e2907c4e425de2736782793383aad63132c14/hydra-node/src/Hydra/Chain/Direct.hs#L156-L162), [Usage 1](https://github.com/cardano-scaling/hydra/blob/a98e2907c4e425de2736782793383aad63132c14/hydra-node/src/Hydra/Chain/Direct.hs#L449), [Usage 2](https://github.com/cardano-scaling/hydra/blob/a98e2907c4e425de2736782793383aad63132c14/hydra-node/src/Hydra/Chain/Direct.hs#L414), [Usage 3](https://github.com/cardano-scaling/hydra/blob/a98e2907c4e425de2736782793383aad63132c14/hydra-node/src/Hydra/Chain/Direct.hs#L349-L352) (There are other unrelated things kept in memory like the event history in the API server or a peer map in the network heartbeat component.) * The interface between the `Hydra.Node` and a `Hydra.Chain` component consists of - constructing certain Head protocol transactions given a description of it (`PostChainTx tx`): @@ -27,7 +27,7 @@ Superseded by [ADR 23](/adr/23) and [ADR 26](/adr/26) ```hs type ChainCallback tx m = OnChainTx tx -> m () ``` -* Given by the usage sites above, the `Hydra.Chain.Direct` module requires additional info to do both, construct protocol transactions with `postTx` as well as observe potential `OnChainTx` ([here](https://github.com/input-output-hk/hydra/blob/a98e2907c4e425de2736782793383aad63132c14/hydra-node/src/Hydra/Chain/Direct.hs#L333-L336)). Hence we see that, operation of the `Hydra.Chain.Direct` component (and likely any implementing the interface fully) is **inherently stateful**. +* Given by the usage sites above, the `Hydra.Chain.Direct` module requires additional info to do both, construct protocol transactions with `postTx` as well as observe potential `OnChainTx` ([here](https://github.com/cardano-scaling/hydra/blob/a98e2907c4e425de2736782793383aad63132c14/hydra-node/src/Hydra/Chain/Direct.hs#L333-L336)). Hence we see that, operation of the `Hydra.Chain.Direct` component (and likely any implementing the interface fully) is **inherently stateful**. * We are looking at upcoming features to [handle rollbacks](https://github.com/cardano-scaling/hydra/issues/185) and dealing with [persisting the head state](https://github.com/cardano-scaling/hydra/issues/187). - Both could benefit from the idea, that the `HeadState` is just a result of pure `Event` processing (a.k.a event sourcing). - Right now the `HeadState` kept in `Hydra.Node` alone, is not enough to fully describe the state of the `hydra-node`. Hence it would not be enough to just persist all the `Event`s and replaying them to achieve persistence, nor resetting to some previous `HeadState` in the presence of a rollback. diff --git a/docs/adr/2022-12-06_022-model-based-testing.md b/docs/adr/2022-12-06_022-model-based-testing.md index e58846989e7..bd3867612d5 100644 --- a/docs/adr/2022-12-06_022-model-based-testing.md +++ b/docs/adr/2022-12-06_022-model-based-testing.md @@ -13,7 +13,7 @@ Accepted ## Context - We have been experimenting with [quickcheck-dynamic](https://hackage.org/packages/quickcheck-dynamic) for a while, leading to the implementation of basic [Model-Based tests](https://github.com/cardano-scaling/hydra/blob/master/hydra-node/test/Hydra/ModelSpec.hs) for the Hydra Head Protocol -- These tests fill a gap in our testing strategy, between [BehaviorSpec](https://github.com/input-output-hk/hydra/blob/master/hydra-node/test/Hydra/BehaviorSpec.hs) tests which test a "network" of nodes but only at the level of the off-chain Head logic, and [EndToEndSpec](https://github.com/input-output-hk/hydra/blob/master/hydra-cluster/test/Test/EndToEndSpec.hs) tests which test a full blown network of nodes interconnected through real network connections and to a real cardano-node: +- These tests fill a gap in our testing strategy, between [BehaviorSpec](https://github.com/cardano-scaling/hydra/blob/master/hydra-node/test/Hydra/BehaviorSpec.hs) tests which test a "network" of nodes but only at the level of the off-chain Head logic, and [EndToEndSpec](https://github.com/cardano-scaling/hydra/blob/master/hydra-cluster/test/Test/EndToEndSpec.hs) tests which test a full blown network of nodes interconnected through real network connections and to a real cardano-node: - The former are fast but do not test the complete lifecycle of a Head. Furthermore, they are only unit tests so do not provide coverage into various corner cases that could arise in practice - The latter exercise the full lifecycle but are very slow and brittle - Because they run in [io-sim](https://github.com/input-output-hk/io-sim), those Model-based tests are fast and robust as they don't depend on system interactions. Moreover, decoupling the _System-under-Test_ from `IO` makes it easy to simulate an environment that deviates from the "happy path" such as delays from the network, filesystem errors, or even adversarial behaviour from the node, or the chain. diff --git a/docs/adr/2023-06-19_024-event-sourced-persistence.md b/docs/adr/2023-06-19_024-event-sourced-persistence.md index 9fd2e4c4081..8173c9a3ebc 100644 --- a/docs/adr/2023-06-19_024-event-sourced-persistence.md +++ b/docs/adr/2023-06-19_024-event-sourced-persistence.md @@ -13,7 +13,7 @@ Accepted ## Context - The state of a Hydra Head is currently persisted as a whole upon each `NewState` _outcome_ from the `update` function: The new state is serialised and the `state` file is overwritten with the corresponding bytes. While this is a straightforward strategy to implement, it has a huge impact on the performance of a Hydra Head as serialising a large data structure like the `HeadState` and completely overwriting a file is costly - - We revisited our benchmarks and [found](https://github.com/input-output-hk/hydra/issues/186#issuecomment-1584292265) that persistence was the major bottleneck when measuring roundtrip confirmation time,e g. the time it takes from a client's perspective to submit a transaction and observe in a `ConfirmedSnapshot` + - We revisited our benchmarks and [found](https://github.com/cardano-scaling/hydra/issues/186#issuecomment-1584292265) that persistence was the major bottleneck when measuring roundtrip confirmation time,e g. the time it takes from a client's perspective to submit a transaction and observe in a `ConfirmedSnapshot` - Furthermore, the way we currently handle changes to the `HeadState` in the hydra-node, while conceptually being an `Effect` is handled differently from other `Effect`s: The state is updated transactionally through a dedicated `modifyHeadState` function in the core loop of processing events, and _then_ effects are processed. ## Decision @@ -55,4 +55,4 @@ sequenceDiagram - Instead of having the `HeadLogic` emits directly a `ClientEffect`, the latter could be the result of a client-centric _interpretation_ of a `StateChanged`. - Pushing this a little further, we could maintain a _Query Model_ for clients with a dedicated [Query API](https://github.com/cardano-scaling/hydra/discussions/686) to ease implementation of stateless clients. -- Calling `StateChanged` an _event_ while treating it in the code alongside _effects_ might introduce some confusion as we already use the word [Event](https://github.com/input-output-hk/hydra/blob/45913954eb18ef550a31017daa443cee6720a00c/hydra-node/src/Hydra/HeadLogic.hs#L64) to designate the inputs (a.k.a. commands) to the Head logic state machine. We might want at some later point to unify the terminology. +- Calling `StateChanged` an _event_ while treating it in the code alongside _effects_ might introduce some confusion as we already use the word [Event](https://github.com/cardano-scaling/hydra/blob/45913954eb18ef550a31017daa443cee6720a00c/hydra-node/src/Hydra/HeadLogic.hs#L64) to designate the inputs (a.k.a. commands) to the Head logic state machine. We might want at some later point to unify the terminology. diff --git a/docs/adr/2023-09-09_027-network-resilience.md b/docs/adr/2023-09-09_027-network-resilience.md index 9106a8ccf8b..fa2a86d8da4 100644 --- a/docs/adr/2023-09-09_027-network-resilience.md +++ b/docs/adr/2023-09-09_027-network-resilience.md @@ -43,7 +43,7 @@ Therefore, the scope of this ADR is to address only point 1. above: Ensure broad withOuroborosNetwork (contramap Network tracer) localhost peers ``` - * This has the nice property that we can basically swap the lower layers should we need to, for example to use [UDP](https://github.com/input-output-hk/hydra/blob/abailly-iohk/multi-node-udp/hydra-node/src/Hydra/Network/UDP.hs), or add other layers for example to address specific head instances in presence of [multiple heads](https://github.com/input-output-hk/hydra/blob/abailly-iohk/multi-node-udp/hydra-node/src/Hydra/Network/MultiHead.hs#L26) + * This has the nice property that we can basically swap the lower layers should we need to, for example to use [UDP](https://github.com/cardano-scaling/hydra/blob/abailly-iohk/multi-node-udp/hydra-node/src/Hydra/Network/UDP.hs), or add other layers for example to address specific head instances in presence of [multiple heads](https://github.com/cardano-scaling/hydra/blob/abailly-iohk/multi-node-udp/hydra-node/src/Hydra/Network/MultiHead.hs#L26) ## Decision diff --git a/docs/adr/2023-12-06_030-use-cbor-for-tx.md b/docs/adr/2023-12-06_030-use-cbor-for-tx.md index 7e8e9e52a61..5897017698a 100644 --- a/docs/adr/2023-12-06_030-use-cbor-for-tx.md +++ b/docs/adr/2023-12-06_030-use-cbor-for-tx.md @@ -12,7 +12,7 @@ Accepted ## Context -* The [Hydra.Ledger.Cardano](https://github.com/input-output-hk/hydra/blob/b2dc5a0da4988631bd2c1e94b66ba6217d5db595/hydra-node/src/Hydra/Ledger/Cardano.hs#L127) module provides `ToJSON/FromJSON` instances for `Tx` and [AlonzoTx](https://github.com/input-output-hk/hydra/blob/b2dc5a0da4988631bd2c1e94b66ba6217d5db595/hydra-node/src/Hydra/Ledger/Cardano/Json.hs#L361) +* The [Hydra.Ledger.Cardano](https://github.com/cardano-scaling/hydra/blob/b2dc5a0da4988631bd2c1e94b66ba6217d5db595/hydra-node/src/Hydra/Ledger/Cardano.hs#L127) module provides `ToJSON/FromJSON` instances for `Tx` and [AlonzoTx](https://github.com/cardano-scaling/hydra/blob/b2dc5a0da4988631bd2c1e94b66ba6217d5db595/hydra-node/src/Hydra/Ledger/Cardano/Json.hs#L361) * We have specified this format as part of [Hydra API](https://github.com/cardano-scaling/hydra/blob/b2dc5a0da4988631bd2c1e94b66ba6217d5db595/hydra-node/json-schemas/api.yaml#L1473) * These instances appear in a few places as part of Hydra API: * In the [ServerOutput](https://github.com/cardano-scaling/hydra/blob/b2dc5a0da4988631bd2c1e94b66ba6217d5db595/hydra-node/src/Hydra/API/ServerOutput.hs#L51) sent by the node to clients @@ -22,7 +22,7 @@ Accepted * In the [Network.Message](https://github.com/cardano-scaling/hydra/blob/b2dc5a0da4988631bd2c1e94b66ba6217d5db595/hydra-node/src/Hydra/Network/Message.hs#L20) exchanged between the nodes * In the [ClientInput](https://github.com/cardano-scaling/hydra/blob/b2dc5a0da4988631bd2c1e94b66ba6217d5db595/hydra-node/src/Hydra/API/ClientInput.hs#L9) from clients submitting `NewTx` commands * In the [HTTPServer](https://github.com/cardano-scaling/hydra/blob/b2dc5a0da4988631bd2c1e94b66ba6217d5db595/hydra-node/src/Hydra/API/HTTPServer.hs#L297) API -* Note that in the latter 2 cases, the hydra-node _accepts_ a hex-CBOR-encoded _JSON string_ to represent a transaction and this particular case is handled directly in the [FromJSON](https://github.com/input-output-hk/hydra/blob/b2dc5a0da4988631bd2c1e94b66ba6217d5db595/hydra-node/src/Hydra/Ledger/Cardano/Json.hs#L388) instance for transactions where 3 different representations are even accepted: +* Note that in the latter 2 cases, the hydra-node _accepts_ a hex-CBOR-encoded _JSON string_ to represent a transaction and this particular case is handled directly in the [FromJSON](https://github.com/cardano-scaling/hydra/blob/b2dc5a0da4988631bd2c1e94b66ba6217d5db595/hydra-node/src/Hydra/Ledger/Cardano/Json.hs#L388) instance for transactions where 3 different representations are even accepted: * JSON object detailing the transaction * A JSON string representing CBOR-encoding of a transaction * Or a `TextEnvelope` which wraps the CBOR transaction in a simple JSON object diff --git a/docs/benchmarks/index.md b/docs/benchmarks/index.md index 49bc04ac0ea..edfcc96dfbd 100644 --- a/docs/benchmarks/index.md +++ b/docs/benchmarks/index.md @@ -7,4 +7,4 @@ sidebar_position: 1 This section provides up-to-date data regarding the known limitations of the Hydra Head on-chain protocol. Cardano transactions and blocks are subject to constraints on transaction size, execution cost, and the number of inputs and outputs. These constraints are determined by network parameters and significantly influence the capabilities of the Hydra Head protocol, such as the maximum number of parties that can participate, the amount of UTXOs that can be committed, and the extent to which these UTXOs can be fanned out. As on-chain scripts and transactions are further optimized, and as the underlying Cardano blockchain evolves with expanded parameters and enhanced script execution efficiency, these limitations are expected to evolve. -The data in this section is _generated_ through Hydra's [continuous integration (CI)](https://github.com/input-output-hk/hydra/actions/workflows/ci-nix.yaml) process, ensuring that it accurately reflects the current state of the code. +The data in this section is _generated_ through Hydra's [continuous integration (CI)](https://github.com/cardano-scaling/hydra/actions/workflows/ci-nix.yaml) process, ensuring that it accurately reflects the current state of the code. diff --git a/docs/docs/configuration.md b/docs/docs/configuration.md index 1b0d0be5fa0..964860e2993 100644 --- a/docs/docs/configuration.md +++ b/docs/docs/configuration.md @@ -83,7 +83,7 @@ Check the scripts against which a hydra-node was compiled using: hydra-node --script-info ``` -For public [(test) networks](https://book.world.dev.cardano.org/environments.html), we publish Hydra scripts with each new release, listing transaction IDs in the [release notes](https://github.com/input-output-hk/hydra/releases) and [`networks.json`](https://github.com/input-output-hk/hydra/blob/master/networks.json). +For public [(test) networks](https://book.world.dev.cardano.org/environments.html), we publish Hydra scripts with each new release, listing transaction IDs in the [release notes](https://github.com/cardano-scaling/hydra/releases) and [`networks.json`](https://github.com/cardano-scaling/hydra/blob/master/networks.json). To publish scripts yourself, use the `publish-scripts` command: @@ -100,7 +100,7 @@ This command outputs a transaction ID upon success. The provided key should hold The ledger is at the core of a Hydra head. Hydra is currently integrated with Cardano and assumes a ledger configuration similar to layer 1. This translates as a command-line option `--ledger-protocol-parameters`. This defines the updatable protocol parameters such as fees or transaction sizes. These parameters follow the same format as the `cardano-cli query protocol-parameters` output. -We provide existing files in [hydra-cluster/config](https://github.com/input-output-hk/hydra/blob/master/hydra-cluster/config), which can be used as the basis. In particular, the protocol parameters nullify costs inside a head. Apart from that, they are the direct copy of the current mainnet parameters. An interesting point about Hydra's ledger is that while it re-uses the same rules and code as layer 1 (isomorphic), some parameters can be altered. For example, fees can be adjusted, but not parameters controlling maximum value sizes or minimum ada values, as altering these could make a head unclosable. +We provide existing files in [hydra-cluster/config](https://github.com/cardano-scaling/hydra/blob/master/hydra-cluster/config), which can be used as the basis. In particular, the protocol parameters nullify costs inside a head. Apart from that, they are the direct copy of the current mainnet parameters. An interesting point about Hydra's ledger is that while it re-uses the same rules and code as layer 1 (isomorphic), some parameters can be altered. For example, fees can be adjusted, but not parameters controlling maximum value sizes or minimum ada values, as altering these could make a head unclosable. A good rule of thumb is that anything that applies strictly to transactions (fees, execution units, max tx size, etc) is safe to change. But anything that could be reflected in the UTXO is not. diff --git a/docs/docs/dev/architecture/networking.md b/docs/docs/dev/architecture/networking.md index c6b07564860..de266b63a42 100644 --- a/docs/docs/dev/architecture/networking.md +++ b/docs/docs/dev/architecture/networking.md @@ -51,7 +51,7 @@ connections and better fault tolerance. The messages exchanged through the _Hydra networking_ layer between participants are authenticated. Each message is -[signed](https://github.com/input-output-hk/hydra/issues/727) using the Hydra +[signed](https://github.com/cardano-scaling/hydra/issues/727) using the Hydra signing key of the emitting party, which is identified by the corresponding verification key. When a message with an unknown or incorrect signature is received, it is dropped, and a notification is logged. diff --git a/docs/docs/dev/index.md b/docs/docs/dev/index.md index 9835ee68c8e..27afeae4e46 100644 --- a/docs/docs/dev/index.md +++ b/docs/docs/dev/index.md @@ -2,6 +2,6 @@ If you've read the [user manual](../index.md) and want to learn more about the Hydra protocol, its inner workings, and its implementation, you're in the right place. -The developer documentation provides detailed materials that move beyond just _using_ Hydra to _understanding_ it. This section is for anyone looking to gain a comprehensive understanding of the Hydra protocol, including protocol architects interested in developing their own variants and developers contributing to the [reference implementation](https://github.com/input-output-hk/hydra) of Hydra. +The developer documentation provides detailed materials that move beyond just _using_ Hydra to _understanding_ it. This section is for anyone looking to gain a comprehensive understanding of the Hydra protocol, including protocol architects interested in developing their own variants and developers contributing to the [reference implementation](https://github.com/cardano-scaling/hydra) of Hydra. The following sections are more technical and may be less cohesive than the user manual. However, the [architecture](./dev/architecture) and the [specification](./dev/specification) sections are good starting points. diff --git a/docs/docs/dev/rollbacks/index.md b/docs/docs/dev/rollbacks/index.md index ce29ebbd92d..77bacfef5e0 100644 --- a/docs/docs/dev/rollbacks/index.md +++ b/docs/docs/dev/rollbacks/index.md @@ -43,4 +43,4 @@ The consequences of a rollback on the head's state vary depending on when the ro 🛠 Hydra currently handles rollbacks gracefully in simpler cases, such as scenario 1 above. However, in cases where a `CollectCom` transaction rollback occurs, which can easily lead to a head becoming stale due to desynchronization among nodes (where one node resets its state before the rollback and loses track of subsequent events during the head's open phase), the head will need to be closed. ::: -Rollback handling has been partially deactivated in Hydra per [ADR-23](https://github.com/input-output-hk/hydra/blob/master/docs/adr/2023-04-26_023-single-state.md). This section will be updated with a more comprehensive and refined rollback handling approach with issue [#185](https://github.com/input-output-hk/hydra/issues/185). +Rollback handling has been partially deactivated in Hydra per [ADR-23](https://github.com/cardano-scaling/hydra/blob/master/docs/adr/2023-04-26_023-single-state.md). This section will be updated with a more comprehensive and refined rollback handling approach with issue [#185](https://github.com/cardano-scaling/hydra/issues/185). diff --git a/docs/docs/faqs.md b/docs/docs/faqs.md index f7c5e8f02cb..12c61a48484 100644 --- a/docs/docs/faqs.md +++ b/docs/docs/faqs.md @@ -90,7 +90,7 @@ If UTXOs are snapshotted on layer 2, they must be fanned out on layer 1 **exactl ### Examples 1. **Minimum UTXO value (`minUTxOValue = 0`)**: - - Outputs with no 'ada' on layer 2 would be disallowed on layer 1, preventing their fanout. This restriction makes direct fanout impossible for such outputs. Even using partial fanout, as considered in [this feature](https://github.com/input-output-hk/hydra/issues/190), would not permit the fanout of affected UTXOs. + - Outputs with no 'ada' on layer 2 would be disallowed on layer 1, preventing their fanout. This restriction makes direct fanout impossible for such outputs. Even using partial fanout, as considered in [this feature](https://github.com/cardano-scaling/hydra/issues/190), would not permit the fanout of affected UTXOs. 2. **Maximum transaction execution units (`maxTxExecutionUnits(L2) > maxTxExecutionUnits(L1)`)**: - Outputs directed to scripts, which are too costly to validate on layer 1, can still be fanned out but will become unspendable due to exceeding the allowable execution limits on layer 1. diff --git a/docs/docs/how-to/operating-hydra.md b/docs/docs/how-to/operating-hydra.md index 3cdcfa9f31b..9e376a898a1 100644 --- a/docs/docs/how-to/operating-hydra.md +++ b/docs/docs/how-to/operating-hydra.md @@ -17,11 +17,11 @@ We offer sample node configurations that will help you get started with hosting ### Google Cloud with Terraform -This setup includes a [docker-compose.yaml](https://github.com/input-output-hk/hydra/blob/master/sample-node-config/gcp/docker-compose.yaml) file, which serves as a robust template for configuring `cardano-node` and `hydra-node` services. Also, various scripts are provided to help you set up your cluster. +This setup includes a [docker-compose.yaml](https://github.com/cardano-scaling/hydra/blob/master/sample-node-config/gcp/docker-compose.yaml) file, which serves as a robust template for configuring `cardano-node` and `hydra-node` services. Also, various scripts are provided to help you set up your cluster. ## Logs -Following the principles outlined in [ADR-9](/adr/9), the `hydra-node` emits [JSON](https://json.org) formatted logs to the `stdout` stream, with one log item per line. These log entries conform to a specific [JSON schema](https://github.com/input-output-hk/hydra/blob/master/hydra-node/json-schemas/logs.yaml). We deliberately maintain the logging mechanism simple and non-configurable to facilitate the integration of Hydra logs into broader log analysis infrastructures, including custom ELK stacks, third-party services, or Docker sidecars. +Following the principles outlined in [ADR-9](/adr/9), the `hydra-node` emits [JSON](https://json.org) formatted logs to the `stdout` stream, with one log item per line. These log entries conform to a specific [JSON schema](https://github.com/cardano-scaling/hydra/blob/master/hydra-node/json-schemas/logs.yaml). We deliberately maintain the logging mechanism simple and non-configurable to facilitate the integration of Hydra logs into broader log analysis infrastructures, including custom ELK stacks, third-party services, or Docker sidecars. ## Monitoring diff --git a/docs/docs/installation.md b/docs/docs/installation.md index 72d45b8f3db..5cc2f6cae89 100644 --- a/docs/docs/installation.md +++ b/docs/docs/installation.md @@ -22,4 +22,4 @@ We provide statically linked binaries of `hydra-node` and `hydra-tui` for x86_64 ### Build from source -While using Docker is the recommended way to _use_ Hydra, you can also build the `hydra-node` from source. We recommend using [Nix](https://nixos.org/download.html) for this and you can find instructions in our [contributing guidelines](https://github.com/input-output-hk/hydra/blob/master/CONTRIBUTING.md). +While using Docker is the recommended way to _use_ Hydra, you can also build the `hydra-node` from source. We recommend using [Nix](https://nixos.org/download.html) for this and you can find instructions in our [contributing guidelines](https://github.com/cardano-scaling/hydra/blob/master/CONTRIBUTING.md). diff --git a/docs/docs/known-issues.md b/docs/docs/known-issues.md index 39c918ff095..dd96b8b1108 100644 --- a/docs/docs/known-issues.md +++ b/docs/docs/known-issues.md @@ -27,4 +27,4 @@ There is a hard-coded limit on the **mainnet** where only up to 100 ada can be c ### Known bugs -Refer to the project repository issue tracker for [known issues](https://github.com/input-output-hk/hydra/issues?q=is%3Aissue+is%3Aopen+label%3A%22bug+%3Abug%3A%22). If you discover any security-relevant problems, please follow our [security policy](https://github.com/input-output-hk/hydra?tab=security-ov-file#readme). +Refer to the project repository issue tracker for [known issues](https://github.com/cardano-scaling/hydra/issues?q=is%3Aissue+is%3Aopen+label%3A%22bug+%3Abug%3A%22). If you discover any security-relevant problems, please follow our [security policy](https://github.com/cardano-scaling/hydra?tab=security-ov-file#readme).