diff --git a/CHANGELOG.md b/CHANGELOG.md index 38f8685887d..75d8bee3f63 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -16,6 +16,10 @@ changes. from a script `UTxO`, and also unlock more involved use-cases, users need to provide additional unsigned transaction that correctly specifies required data (like redeemers, validity ranges etc.) +- Update navigation and re-organized documentation website https://hydra.family + - Updated logos + - Removed localization as it got outdated and on-demand site translation tools exist. + - Add `GET /snapshot/utxo` API endpoint to query confirmed UTxO set on demand. - Always responds with the last confirmed UTxO diff --git a/demo/docker-compose.yaml b/demo/docker-compose.yaml index 9a400598b87..937226990d2 100644 --- a/demo/docker-compose.yaml +++ b/demo/docker-compose.yaml @@ -27,8 +27,6 @@ services: build: context: ../ target: hydra-node - profiles: - - hydra-node volumes: - .:/keys:ro - ./devnet:/devnet @@ -64,8 +62,6 @@ services: build: context: ../ target: hydra-node - profiles: - - hydra-node volumes: - .:/keys:ro - ./devnet:/devnet @@ -101,8 +97,6 @@ services: build: context: ../ target: hydra-node - profiles: - - hydra-node volumes: - .:/keys:ro - ./devnet:/devnet @@ -137,8 +131,6 @@ services: build: context: ../ target: hydra-tui - profiles: - - tui command: [ "--connect", "172.16.238.10:4001" , "--node-socket", "/devnet/node.socket" @@ -156,8 +148,6 @@ services: build: context: ../ target: hydra-tui - profiles: - - tui command: [ "--connect", "172.16.238.20:4001" , "--node-socket", "/devnet/node.socket" @@ -175,8 +165,6 @@ services: build: context: ../ target: hydra-tui - profiles: - - tui command: [ "--connect", "172.16.238.30:4001" , "--node-socket", "/devnet/node.socket" diff --git a/demo/run-docker.sh b/demo/run-docker.sh index 29d44d3168a..3d08a90a0d0 100755 --- a/demo/run-docker.sh +++ b/demo/run-docker.sh @@ -1,7 +1,7 @@ #!/usr/bin/env bash # -# Prepare environment to run the demo cluster, then launches docker-compose demo. -# If there's already a demo running, bail out. +# Prepare environment to run the demo cluster, then launches docker compose +# demo. If there's already a demo running, bail out. set -e SCRIPT_DIR=$(dirname $(realpath $0)) @@ -25,7 +25,7 @@ fi "${SCRIPT_DIR}/prepare-devnet.sh" ${DOCKER_COMPOSE_CMD} up -d cardano-node "${SCRIPT_DIR}/seed-devnet.sh" -${DOCKER_COMPOSE_CMD} --profile hydra-node up -d -echo >&2 -e "\n# Launch TUI on hydra-node-1: ${DOCKER_COMPOSE_CMD} --profile tui run hydra-tui-1" +${DOCKER_COMPOSE_CMD} up -d hydra-node-{1,2,3} +echo >&2 -e "\n# Launch TUI on hydra-node-1: ${DOCKER_COMPOSE_CMD} run hydra-tui-1" echo >&2 -e "\n# Stop the demo: ${DOCKER_COMPOSE_CMD} down\n" -${DOCKER_COMPOSE_CMD} --profile tui run hydra-tui-1 +${DOCKER_COMPOSE_CMD} run hydra-tui-1 diff --git a/docs/README.md b/docs/README.md index 734dfaa1ec1..d936ed30b3d 100644 --- a/docs/README.md +++ b/docs/README.md @@ -42,31 +42,4 @@ nix build .#haddocks -o docs/static/haddock # Translating -Translations of the documentation are provided in the `i18n/{lang}` folder (for example `i18n/fr` for French). Translations of both the content and the various website elements (such as buttons, headers etc...) are needed. To initialize a new language translation (e.g. `fr`), run the following command: - -```console -$ yarn write-translations --locale fr -``` - -This command will pre-generate all the website elements which need to be translated into French (locale `fr`) in JSON files. Translations have to be provided for each items in generated JSON files, mapping ids to messages as such: - -```json -{ - "theme.TOCCollapsible.toggleButtonLabel": { - "message": "Sur cette page", - "description": "The label used by the button on the collapsible TOC component" - } -} -``` - -> Note that only the value of the key `message` needs to be translated, the `description` simply provides context regarding the translated element and is automatically generated. - -In addition content files themselves (markdown) need to be copied under their respective directories, and then translated. Here is a table that summarizes the correspondence between the default website structure and their localized versions: - -| default | translations | -| ---------------- | ------------------------------------------------------------------- | -| `docs/` | `i18n/{lang}/docusaurus-plugin-content-docs/current/` | -| `benchmarks/` | `i18n/{lang}/docusaurus-plugin-content-docs-benchmarks/current/` | -| `core-concepts/` | `i18n/{lang}/docusaurus-plugin-content-docs-core-concepts/current/` | -| `topologies/` | `i18n/{lang}/docusaurus-plugin-content-docs-topologies/current/` | -| `adr/` | `i18n/{lang}/docusaurus-plugin-content-blog/current/` | +While we supported and encouraged contributing translations in the past, we turned off internationalization features as translations inevitably became out-of-date and on-demand translation of website became significantly better with AI language models. Nontheless, if you feel like we should offer translated pages and want to contribute that, please don't hesitate to file an [issue](https://github.com/input-output-hk/hydra/issues/new/choose). diff --git a/docs/adr/2022-03-28_017-udp-networking.md b/docs/adr/2022-03-28_017-udp-networking.md index be0a9f3e041..296e8b1b641 100644 --- a/docs/adr/2022-03-28_017-udp-networking.md +++ b/docs/adr/2022-03-28_017-udp-networking.md @@ -17,7 +17,7 @@ Current Hydra networking layer is based on [Ouroboros network framework](https:/ 2. A Multiplexing connection manager that manages a set of equivalent peers, maintains connectivity, and ensures diffusion of messages to/from all peers, 2. Typed protocols for expressing the logic of message exchanges as a form of _state machine_. -While it's been working mostly fine so far, the abstractions and facilities provided by this network layer are not well suited for Hydra Head networking. Some of the questions and shortcomings are discussed in a document on [Networking Requirements](/core-concepts/architecture/networking), and as the Hydra Head matures it seems time is ripe for overhauling current network implementation to better suite current and future Hydra Head networks needs. +While it's been working mostly fine so far, the abstractions and facilities provided by this network layer are not well suited for Hydra Head networking. Some of the questions and shortcomings are discussed in a document on [Networking Requirements](/docs/dev/architecture/networking), and as the Hydra Head matures it seems time is ripe for overhauling current network implementation to better suite current and future Hydra Head networks needs. ## Decision diff --git a/docs/core-concepts/behavior.md b/docs/core-concepts/behavior.md index 5cea9dc2860..277e1110c43 100644 --- a/docs/core-concepts/behavior.md +++ b/docs/core-concepts/behavior.md @@ -4,6 +4,10 @@ sidebar_position: 4 # API Behavior +:::caution Deprecated +This page will soon move into the [API reference](/api-reference) itself. +::: + This page documents the behavior of a `hydra-node` at the API layer. That is, how the system behaves given [ClientInputs](pathname:///haddock/hydra-node/Hydra-API-ClientInput.html#t:ClientInput) and what [ServerOutputs](pathname:///haddock/hydra-node/Hydra-API-ServerOutput.html#t:ServerOutput) are produced in response to it. See also the [API reference](/api-reference/) for more details about individual API messages. The only discrepancy is http `POST /commit` action which is not a state transition but a user action that submits a commit transaction which should produce `Committed` output. The formalism uses [UML statechart](https://en.wikipedia.org/wiki/UML_state_machine) language where transitions are labeled: `input [condition] / output`. When two outputs (e.g. `A` and `B`) are expected we write `A,B`, while `{A,B}` denotes mutual exclusiveness of outputs. diff --git a/docs/core-concepts/faq/_category_.json b/docs/core-concepts/faq/_category_.json deleted file mode 100644 index cf9c15a9732..00000000000 --- a/docs/core-concepts/faq/_category_.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "label": "F.A.Q.", - "position": 999 -} diff --git a/docs/core-concepts/index.md b/docs/core-concepts/index.md index f48fa77a710..ca6c32eede2 100644 --- a/docs/core-concepts/index.md +++ b/docs/core-concepts/index.md @@ -2,24 +2,7 @@ sidebar_position: 1 --- -# Overview - -Hydra is the layer 2 scalability solution for Cardano, which aims to increase transaction speed through low latency and high throughput and minimize transaction cost. - -[Hydra Head](https://eprint.iacr.org/2020/299.pdf) is the first protocol of the Hydra family and embodies the foundation for more advanced deployment scenarios relying on isomorphic, multi-party state-channels. For an introduction to the protocol also check out these two blog posts - - - [Hydra – Cardano’s solution for ultimate Layer 2 scalability](https://iohk.io/en/blog/posts/2021/09/17/hydra-cardano-s-solution-for-ultimate-scalability/) - - [Implementing Hydra Heads: the first step towards the full Hydra vision ](https://iohk.io/en/blog/posts/2022/02/03/implementing-hydra-heads-the-first-step-towards-the-full-hydra-vision/) - -There are different flavors and extensions of the Hydra Head protocol, but let's start by looking at the full lifecycle of a basic Hydra Head, and how it allows for isomorphic state transfer between layer 1 and layer 2. - -![](./hydra-head-lifecycle.svg) - -A Hydra Head is formed by a group of online and responsive participants. Participants **init**ialize a Head by announcing several parameters on-chain, including the participants list. Then each of the participants **commit**s unspent transaction outputs (UTXOs) from the Cardano main-chain to it, before all the UTXOs are **collect**ed and made available in a Hydra Head as initial state (`U0`). At any moment before collecting, participants can also **abort** the process and recover their funds. - -While open, they can use the Hydra Head via a hydra-node to submit transactions over the Head network. Transactions have the same format and properties as on the main-chain: they are _isomorphic_. When UTXO entries are spent, and new UTXO entries are created in a Hydra Head, all participants are required to acknowledge and agree on the new state in so-called snapshots (`U1..Un`). Snapshots are _not_ posted back onto the layer 1, but are only kept around by the participants. - -Any participant can **close** the Head using a snapshot, when for example they wish to cash out on the mainnet, or if another party misbehaves or stalls the Head's evolution. There is a mechanism to **contest** the final state on the main chain. Ultimately, a **fanout** transaction distributes the final agreed state and makes available on the layer 1 what only existed virtually in the Head. +# Core Concepts ```mdx-code-block import DocCardList from '@theme/DocCardList'; diff --git a/docs/docs/configuration.md b/docs/docs/configuration.md new file mode 100644 index 00000000000..400644a23cf --- /dev/null +++ b/docs/docs/configuration.md @@ -0,0 +1,168 @@ +# Configuration + +Running a Hydra head means running a Hydra node connected to some other Hydra nodes and connected to a Cardano node. + +The entire configuration of the `hydra-node` is provided through command-line options. Options are used to configure various elements of the network, API, chain connection and used ledger. You can use `--help` to get a description of all options: + +```shell +hydra-node --help +``` + +Below we document selected aspects of the configuration. See the [tutorial](./tutorial) for an end-to-end guide or individual _How to_ articles for more details. + +### Cardano Keys + +In a head, every participant is authenticated by two sets of keys. The first are used to identify a participant on the Cardano L1 and hold ADA to pay fees. Every `hydra-node` needs to be given a `--cardano-signing-key` and for each other participant of the head, we need to provide their `--cardano-verification-key`. + +Such a key pair can be generated using the `cardano-cli` as follows: + +```shell +cardano-cli address key-gen \ + --verification-key-file cardano.vk \ + --signing-key-file cardano.sk +``` + +These keys are currently used to authenticate on-chain transactions which drives the execution of the Hydra protocol. They prevent unsolicited actors to fiddle with the head life-cycle (for instance, someone external to the head could otherwise _abort_ an initialised head). While this wouldn't put head participants' funds at risk, it is still an annoyance that one wants to prevent. + +### Hydra keys + +The second set of keys are the so-called Hydra keys, which are used for multi-signing snapshots within a Head. While in the long-run, those keys may be used in an aggregated multi-signature scheme. At present however, Hydra keys are also Ed25519 keys. + +These are similar to cardano keys but are only on the layer 2. New keys can be generated using `hydra-node`: + +``` +hydra-node gen-hydra-key --output-file my-key +``` + +This will create two files, `my-key.sk` and `my-key.vk` containing Hydra keys suitable for use inside a head. + +Alternatively, we provide demo key pairs as `alice.{vk,sk}`, `bob.{vk,sk}` and `carol.{vk,sk}` in our [demo folder](https://github.com/input-output-hk/hydra/tree/master/demo). These should obviously not be used in production. + + +### Contestation Period + +The contestation period is a protocol parameter and given as a number of seconds, for example: + +``` +hydra-node --contestation-period 120s +``` + +Contestation period is used in: + +- Constructing the upper validity bound for `Close` and `Contest` transactions, +- Computing the contestation deadline and therefore the lower validity + bound for `FanOut` transaction. + +This parameter has a default value of _60 seconds_, which should be +enough under normal circumstances, but it needs to be tailored to the +condition of network we are running on since slot lengths and block +production rates are different on different networks. + +:::info Consistent contestation period + +All parties in the hydra head protocol need to configure the same +value for `--contestation-period` otherwise the `Init` transaction +will be ignored. This prevents certain party from stalling/DoS-ing +the head by setting contestation period to unreasonably large values. + +::: + +:::warning Invalid Close and Contest Transactions + +Depending on the contestation period value and the network conditions, +`Close` and `Contest` transactions could become invalid and be +silently rejected by the cardano-node to which they have been +submitted. This can happen, for example, if: +* The network is congested, with lot of transactions waiting to be + included in a block, +* The node's connectivity to the network drops and the transaction is + not propagated to block producers fast enough. + +The hydra-node itself does not currently handle this situation and +therefore each client application needs to put in place some retry +mechanism depending on the time it should "normally" take to have the +transaction. + +::: + +### Reference Scripts + +The `hydra-node` makes use of reference scripts to reduce the size of transactions driving the Head's lifecycle. To reference the right scripts, the `--hydra-scripts-tx-id` needs to be provided. When provided, the `hydra-node` checks whether the right scripts are available at this transaction on-chain. + +You can also check against which scripts a hydra-node was compiled using: + +```shell +hydra-node --script-info +``` + +For public [(test) networks](https://book.world.dev.cardano.org/environments.html), we publish the hydra scripts on each new release and advertise transaction ids on the [release notes](https://github.com/input-output-hk/hydra/releases) and on the repository in [`networks.json`](https://github.com/input-output-hk/hydra/blob/master/networks.json). + +If you want to publish the scripts yourself, you can do so using the `publish-scripts` command: + +```shell +hydra-node publish-scripts \ + --testnet-magic 42 \ + --node-socket /path/to/node.socket \ + --cardano-signing-key cardano.sk +``` + +On success, this commands outputs a transaction id ready to be used. The provided key is expected to hold funds (> 50 ADA), and will be used to create multiple **UNSPENDABLE** UTxO entries on-chain, each carrying a script that can be later referenced by the Hydra node. + +### Ledger Parameters + +At the core of a Hydra head, there's a ledger. At the moment, Hydra is wired only to Cardano and assumes a ledger configuration similar to the one used on the layer 1. This translates as a command-line option `--ledger-protocol-parameters`. This defines the updatable protocol parameters such as fees or transaction sizes. They use the same format as the one used by the cardano-cli (e.g. `cardano-cli query protocol-parameters`'s 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 basis. In particular, the protocol parameters are defined to nullify costs inside a head. Apart from that, they are the direct copy the current mainnet parameters. An interesting point about the Hydra's ledger is that, while it re-uses the same rules and code as the layer 1 (a.k.a. isomorphic), parameters may also be altered to slightly differ from the layer 1. This is the case for fees, but could also be done for script maximum execution budget for instance. However, not all parameters are safe to alter! Changing parameters that control the maximum size of a value (carrying native assets), or the minimum Ada value for a UTxO may render a head "unclosable"! A good rule thumb is that anything that applies strictly to transactions (fees, execution units, max tx size...) is safe to change. But anything that could be reflected in the UTxO is not. + +:::info About Protocol Parameters +Note that many of protocol-parameters are actually irrelevant in the context of Hydra (for example, there's no treasury or stake pool inside a head; consequently, parameters configuring the reward incentive or delegation rules are pointless and unused). +::: + +### Fuel vs. Funds + +All the transactions driving the Head lifecycle (Init, Abort, Close, ...) need to be submitted to the layer 1, and hence they cost money! For that, any UTxO owned by the `--cardano-signing-key` given to the `--hydra-node` will be considered spendable to pay fees or use as collateral for these Hydra protocol transactions. We sometimes this **fuel**. + +Consequently, sending some ADA to the address of this "internal wallet" is required. To get the address for the cardano keys as generated above, one can use for example the cardano-cli: + +```shell +cardano-cli address build --verification-key-file cardano.vk --mainnet +# addr1v92l229athdj05l20ggnqz24p4ltlj55e7n4xplt2mxw8tqsehqnt +``` + + + +While the `hydra-node` needs to pay fees for protocol transactions, any wallet can be used to commit **funds** into an `initializing` Hydra head. The `hydra-node` provides an HTTP endpoint at `/commit`, which allows to specify either: + - a `UTxO` set of outputs to commit (belonging to public keys) or + - a _blueprint_ transaction together with the `UTxO` which resolves it. + +and eventually returns a commit transaction. + +This transaction is already balanced and all fees are paid by the funds held by the `hydra-node`. Hence, an integrated wallet would need to sign this transaction and submit it to the Cardano network. See the [api documentation](pathname:///api-reference/#operation-publish-/commit) for details. + +If the user wants to use some `UTxO` they own and commit it to a `Head` then they need to send the appropriate JSON representation of said `UTxO` to the `/commit` API endpoint. + +Using a _blueprint_ transaction with `/commit` allows for more flexibility since `hydra-node` only adds needed commit transaction data without removing any additional information specified in the _blueprint_ transaction. For example, any present reference inputs, redeemers or validity ranges will be kept. + +> Note: It is important to note that any **outputs** of a blueprint transaction will not be considered, only inputs are used to commit funds to the `Head`. `hydra-node` will also **ignore** any minting or burning specified in the blueprint transaction. + +For more details refere to the [how to](./how-to/commit-blueprint) about committing to a `Head` using blueprint transaction. + +## Connect to Cardano + +The `hydra-node` needs to be connected to the cardano network (unless it runs in [offline mode](./configuration.md#offline-mode)). + +Currently a direct connection to a [`cardano-node`](https://github.com/input-output-hk/cardano-node/) is a pre-requisite and please refer to existing documentation on starting a node, e.g. on [developers.cardano.org](https://developers.cardano.org/docs/get-started/running-cardano) or [use mithril](https://mithril.network/doc/manual/getting-started/bootstrap-cardano-node) to bootstrap the local node. + +To specify how to connect to the local cardano-node, use `--node-socket` and `--testnet-magic`: + +```shell +hydra-node \ + --testnet-magic 42 \ + --node-socket devnet/node.socket \ +``` + +The `hydra-node` is compatible with the Cardano `mainnet` network, and can consequently operate using **real funds**. Please be sure to read the [known issues](/docs/known-issues) to fully understand the limitations and consequences of running Hydra nodes on mainnet. To choose `mainnet`, use `--mainnet` instead of `--testnet-magic`. + +## Offline mode + +TODO integrate https://github.com/input-output-hk/hydra/pull/1414 diff --git a/docs/core-concepts/architecture/architecture-c4.puml b/docs/docs/dev/architecture/architecture-c4.puml similarity index 100% rename from docs/core-concepts/architecture/architecture-c4.puml rename to docs/docs/dev/architecture/architecture-c4.puml diff --git a/docs/core-concepts/architecture/hydra-components.svg b/docs/docs/dev/architecture/hydra-components.svg similarity index 100% rename from docs/core-concepts/architecture/hydra-components.svg rename to docs/docs/dev/architecture/hydra-components.svg diff --git a/docs/core-concepts/architecture/hydra-pull-based-network.jpg b/docs/docs/dev/architecture/hydra-pull-based-network.jpg similarity index 100% rename from docs/core-concepts/architecture/hydra-pull-based-network.jpg rename to docs/docs/dev/architecture/hydra-pull-based-network.jpg diff --git a/docs/core-concepts/architecture/index.md b/docs/docs/dev/architecture/index.md similarity index 77% rename from docs/core-concepts/architecture/index.md rename to docs/docs/dev/architecture/index.md index 8f63aeec154..b78cc08a886 100644 --- a/docs/core-concepts/architecture/index.md +++ b/docs/docs/dev/architecture/index.md @@ -31,6 +31,34 @@ _Network_ component is responsible for all of the communications related to the Messages are exchanged between nodes on different internal transitions and are authenticated using each peer _Hydra Key_: Each message sent is signed by the emitter and the signature is verified by the transmitter. +##### Authentication & Authorization + +The messages exchanged through the _Hydra Network_ layer between +participants are authenticated: Each message is +[signed](https://github.com/input-output-hk/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. + +Messages are however not encrypted and therefore, if confidentiality is +required, some external mechanism needs to be put in place to prevent +other parties from observing the messages exchanged within a Head. + +##### Fault tolerance + +The Hydra Head protocol guarantees safety of all (honest) +participants' funds, but does not in itself guarantee liveness, hence +all parties involved in a Hydra Head must be online and reactive for +the protocol to make progress. + +This implies that, should one or several participants' hydra-node +become _permanently_ unreachable from the others, through a crash, or +a network partition, no more transactions can happen in the Head and +it must be closed. However, the [Hydra network +layer](https://hydra.family/head-protocol/unstable/haddock/hydra-node/Hydra-Node-Network.html) +is tolerant to _transient_ disconnections and (non-Byzantine) crashes. + ### Chain Interaction #### Chain diff --git a/docs/core-concepts/architecture/networking.md b/docs/docs/dev/architecture/networking.md similarity index 100% rename from docs/core-concepts/architecture/networking.md rename to docs/docs/dev/architecture/networking.md diff --git a/docs/docs/haskell_packages.md b/docs/docs/dev/haskell-packages.md similarity index 100% rename from docs/docs/haskell_packages.md rename to docs/docs/dev/haskell-packages.md diff --git a/docs/docs/dev/index.md b/docs/docs/dev/index.md new file mode 100644 index 00000000000..be4c2e961dc --- /dev/null +++ b/docs/docs/dev/index.md @@ -0,0 +1,11 @@ +--- +sidebar_position: 1 +--- + +# About Hydra + +So you already read the [User Manual](../index.md) and still want to learn more about the Hydra protocol, its inner workings and how it is implemented? + +The developer documentation can help you with that. It is a collection of materials expanding on _using_ into _understanding_ Hydra. It is aimed anyone wanting to get a deeper understanding of the Hydra protocol, protocol architects who want to build their own variants and of course developers who contribute to the [reference implementation](https://github.com/input-output-hk/hydra) of Hydra itself. + +Consequently, the following sections are more technical and maybe not as cohesive as the user manual, but the [architecture](./architecture) or the [specification](./specification) should be a good starting point. diff --git a/docs/core-concepts/rollbacks/_category_.json b/docs/docs/dev/rollbacks/_category_.json similarity index 100% rename from docs/core-concepts/rollbacks/_category_.json rename to docs/docs/dev/rollbacks/_category_.json diff --git a/docs/core-concepts/rollbacks/index.md b/docs/docs/dev/rollbacks/index.md similarity index 100% rename from docs/core-concepts/rollbacks/index.md rename to docs/docs/dev/rollbacks/index.md diff --git a/docs/core-concepts/rollbacks/rollbacks-1.jpg b/docs/docs/dev/rollbacks/rollbacks-1.jpg similarity index 100% rename from docs/core-concepts/rollbacks/rollbacks-1.jpg rename to docs/docs/dev/rollbacks/rollbacks-1.jpg diff --git a/docs/core-concepts/rollbacks/rollbacks-2.jpg b/docs/docs/dev/rollbacks/rollbacks-2.jpg similarity index 100% rename from docs/core-concepts/rollbacks/rollbacks-2.jpg rename to docs/docs/dev/rollbacks/rollbacks-2.jpg diff --git a/docs/core-concepts/rollbacks/rollbacks-3.jpg b/docs/docs/dev/rollbacks/rollbacks-3.jpg similarity index 100% rename from docs/core-concepts/rollbacks/rollbacks-3.jpg rename to docs/docs/dev/rollbacks/rollbacks-3.jpg diff --git a/docs/core-concepts/rollbacks/rollbacks-4.jpg b/docs/docs/dev/rollbacks/rollbacks-4.jpg similarity index 100% rename from docs/core-concepts/rollbacks/rollbacks-4.jpg rename to docs/docs/dev/rollbacks/rollbacks-4.jpg diff --git a/docs/core-concepts/specification.md b/docs/docs/dev/specification.md similarity index 96% rename from docs/core-concepts/specification.md rename to docs/docs/dev/specification.md index a78b429a8ed..08a17c90bce 100644 --- a/docs/core-concepts/specification.md +++ b/docs/docs/dev/specification.md @@ -1,5 +1,5 @@ --- -sidebar_position: 6 +sidebar_position: 2 custom_edit_url: https://github.com/input-output-hk/hydra/tree/master/spec --- diff --git a/docs/core-concepts/faq/index.md b/docs/docs/faq.md similarity index 97% rename from docs/core-concepts/faq/index.md rename to docs/docs/faq.md index 18e9a028163..541430ef51a 100644 --- a/docs/core-concepts/faq/index.md +++ b/docs/docs/faq.md @@ -1,7 +1,5 @@ # Frequently Asked Questions -> And their answers! -
When Hydra? @@ -57,7 +55,7 @@ Setting protocol parameters with `fee > 0` will enforce that transactions in the
- Is it possible to us a different protocol parameters in the Hydra Head? + Is it possible to use different protocol parameters in the Hydra Head? In principle, yes! The ledger used for L2 transactions is configurable and can use the same or different protocol parameters as the L1. **But there is a catch!** If UTxOs get snapshotted on the L2, they can only be fanned out on the L1 **exactly** like they were snapshotted. diff --git a/docs/docs/getting-started/demo/without-docker.md b/docs/docs/getting-started-without-docker.md similarity index 91% rename from docs/docs/getting-started/demo/without-docker.md rename to docs/docs/getting-started-without-docker.md index a7efcce5184..dcf68d00c22 100644 --- a/docs/docs/getting-started/demo/without-docker.md +++ b/docs/docs/getting-started-without-docker.md @@ -2,10 +2,9 @@ sidebar_position: 3 --- -# Without Docker +# Getting started without Docker ```mdx-code-block -import TerminalWindow from '@site/src/components/TerminalWindow'; import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem'; ``` @@ -29,12 +28,10 @@ All further commands are written as if executed from the `demo` folder in the pr Allowing the `demo/.envrc` will ensure you have the nix shell environment available whenever you are in the `demo/` directory. To use this, opt-in via `direnv allow` after `cd demo`. ::: -## Setting-up The Chain +## Set up the devnet First, let's prepare and start an ad-hoc, single `cardano-node` devnet using our configuration. Note that this will create a `devnet` directory in your current working directory: - - ``` ./prepare-devnet.sh cd devnet @@ -48,24 +45,16 @@ cardano-node run \ --shelley-vrf-key vrf.skey ``` - - -## Seeding The Network - From the `demo` folder you can use the `seed-devnet.sh` script by passing it the path/command to a cardano-cli and hydra-node executable to use, instead of having it using the Docker container. For example: - - ``` export CARDANO_NODE_SOCKET_PATH=devnet/node.socket ./seed-devnet.sh $(which cardano-cli) $(which hydra-node) ``` - - Note, should you want to use `cabal`, pass the invocation for example like this `"cabal exec hydra-node --"`. -## Setting-up The Hydra Network +## Start Hydra nodes Then, in 3 different terminals, start 3 Hydra nodes from the `demo/` directory: @@ -78,7 +67,6 @@ If you don't see any connected peers in the tui it probably means that your syst - ``` source .env && hydra-node \ @@ -98,11 +86,9 @@ source .env && hydra-node \ --persistence-dir devnet/persistence/alice ``` - - ``` source .env && hydra-node \ @@ -122,11 +108,9 @@ source .env && hydra-node \ --persistence-dir devnet/persistence/bob ``` - - ``` source .env && hydra-node \ @@ -146,7 +130,6 @@ source .env && hydra-node \ --persistence-dir devnet/persistence/carol ``` - @@ -155,7 +138,7 @@ source .env && hydra-node \ If things go well, the nodes should start logging once connected to the chain. -## Running The Clients +## Run Hydra clients Connect to the nodes using hydra-tui. @@ -163,7 +146,6 @@ Connect to the nodes using hydra-tui. - ``` hydra-tui \ @@ -173,11 +155,9 @@ hydra-tui \ --node-socket devnet/node.socket ``` - - ``` hydra-tui \ @@ -187,11 +167,9 @@ hydra-tui \ --node-socket devnet/node.socket ``` - - ``` hydra-tui \ @@ -201,7 +179,6 @@ hydra-tui \ --node-socket devnet/node.socket ``` - diff --git a/docs/docs/getting-started.md b/docs/docs/getting-started.md new file mode 100644 index 00000000000..5d01455eb30 --- /dev/null +++ b/docs/docs/getting-started.md @@ -0,0 +1,89 @@ +# Getting started + +To get started quickly, let's walk you through our standard demo setup consisting of + +- a cluster of three `hydra-node`, directly connected to each other, each having access to one of three Hydra credentials `alice`, `bob`, or `carol`; +- a single `cardano-node` producing blocks used as a (very fast) local `devnet`; +- the `hydra-tui` example clients to interact with the individual Hydra nodes. + +This tutorial will be using [Docker](https://www.docker.com/get-started) to install and the nodes, so make sure to have it installed. If you want to explore alternative ways of running the tools, see this [tutorial variant](./getting-started-without-docker.md) or the [testnet tutorial](./tutorial/index.md) does use pre-built binaries, while documentation pages on [installation](./installation) and [configuration](./configuration) provide more details. + +Also, the `hydra-tui` does use the HTTP/WebSocket API provided by the `hydra-node` behind the scenes. The [testnet tutorial](./tutorial/index.md) will show how to use this API using low-level commands or see the [API reference](/api-reference). + +
+Video demonstration (a bit dated) + + + +
+ +:::caution OS Compatibility +These instructions have been tested only on Linux environments (Ubuntu, NixOS). If you're on Windows or Mac OS X, you might need to adapt to use [Volumes](https://docs.docker.com/storage/volumes/). +::: + +## Preparation + +All commands below are written as if executed from the `demo` folder in the project repository, so make sure to clone the repository, switch into the demo folder and pull the latest docker images: + +```shell +git clone git@github.com:input-output-hk/hydra.git +cd hydra/demo +docker compose pull +``` + +:::info Shortcut +For convenience, we also provide a script `./run-docker.sh`, which combines all following steps. It also performs a few sanity checks to avoid tripping ourselves. +::: + +## Set up the devnet + +Next, we can run prepare the devnet configuration to bootstrap a local Cardano blockchain. Note that, we use a simple variant of Cardano that requires no stake pools whatsoever. + +```shell +./prepare-devnet.sh +``` + +We can now bring the Cardano node up with: + +```shell +docker compose up -d cardano-node +``` + +You can verify that the devnet is up-and-running by checking the logs with: +```shell +docker compose logs cardano-node -f +``` + +You should see traces containing `TraceAdoptedBlock`, which means that the devnet is producing blocks .. nice! + +:::info +Don't wait too long between these two commands. If you get `TraceNoLedgerView` errors from the Cardano node, the genesis start time is too far in the past and you need to update them by running `prepare-devnet.sh` again. +::: + +Next we need to give Alice, Bob, and Carol some UTxOs to commit and some ADA to pay fees. We include a script `seed-devnet.sh` that uses the `cardano-cli` in the already running `cardano-node` container to do that: + +```shell +./seed-devnet.sh +``` + +## Start Hydra nodes + +Finally, now that the on-chain preparations are done, we can bring the Hydra network (all three nodes for Alice, Bob and Carol) up by running: + +```shell +docker compose up -d hydra-node-{1,2,3} +``` + +Using compose, you can start the demo Terminal-based User Interface (a.k.a. `hydra-tui`) to interact with Hydra nodes. There are 3 preconfigured TUI services in the compose definition: `hydra-tui-1`, `hydra-tui-2`, and `hydra-tui-3`. To connect to the first Hydra node in a terminal, run the following command: + +```shell +docker compose run hydra-tui-1 +``` + +This will start a full-blown terminal interface loaded with signing keys corresponding to the first Hydra node. In other terminals, you can start other nodes in a similar fashion targeting `hydra-tui-2` and `hydra-tui-3` services. + +## Use the head + +Using the terminal interface of any node, you can now `[i]nit` the Hydra head and `[c]ommit` pre-distributed funds to it. Note that these steps are near instant as the devnet is producing blocks much faster than a public testnet or the mainnet. After committing from all nodes, the head will automatically open and you can also use the `hydra-tui` or the API to create new transactions and submit them to the Hydra head. + +![](./open-head.png) diff --git a/docs/docs/getting-started/_category_.json b/docs/docs/getting-started/_category_.json deleted file mode 100644 index 3562d433d76..00000000000 --- a/docs/docs/getting-started/_category_.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "label": "Getting Started", - "position": 1 -} diff --git a/docs/docs/getting-started/demo/_category_.json b/docs/docs/getting-started/demo/_category_.json deleted file mode 100644 index a261c72258b..00000000000 --- a/docs/docs/getting-started/demo/_category_.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "label": "Demo", - "position": 4 -} diff --git a/docs/docs/getting-started/demo/index.md b/docs/docs/getting-started/demo/index.md deleted file mode 100644 index 24b13b1a81b..00000000000 --- a/docs/docs/getting-started/demo/index.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -sidebar_position: 1 ---- - -# Demo - -> Our standard demo setup for demonstrating the Hydra Head protocol. - -The demo consists of: - -- a cluster of three Hydra nodes, directly connected to each other, each having access to one of three Hydra credentials `alice`, `bob`, or `carol`; -- a single Cardano node producing blocks used as a local devnet; -- a Prometheus server to gather metrics; -- ad-hoc terminal user interface clients to interact with the individual Hydra nodes; - -```mdx-code-block -import DocCardList from '@theme/DocCardList'; -import {useCurrentSidebarCategory} from '@docusaurus/theme-common'; - - -``` - - - -

- -:::caution Disclaimer -This video demonstrates a basic terminal user interface for the sake of example. Behind the scene, the terminal client relies on a WebSocket API provided by the Hydra nodes which is what applications will likely be using. Said differently, this is one example of possible application (and to be frank, not a very interesting one!) -::: diff --git a/docs/docs/getting-started/demo/with-docker.md b/docs/docs/getting-started/demo/with-docker.md deleted file mode 100644 index c7376b99555..00000000000 --- a/docs/docs/getting-started/demo/with-docker.md +++ /dev/null @@ -1,89 +0,0 @@ ---- -sidebar_position: 2 ---- - -# With Docker - -```mdx-code-block -import TerminalWindow from '@site/src/components/TerminalWindow'; -``` - -We'll be using [Docker](https://www.docker.com/get-started) and [compose](https://www.docker.com/get-started) to get the demo running, so make sure you have them in scope or, jump right away to [Running The Demo: Without Docker](/docs/getting-started/demo/without-docker) if you feel like doing it the hard way. - -:::info Shortcut -For convenience, we also provide a script `./run-docker.sh`, which combines the steps above. It also performs a few sanity checks to avoid tripping ourselves. -::: - -:::info Context -All commands below are written as if executed from the `demo` folder in the project repository, so make sure to clone the repository and `cd demo` before doing anything else. -::: - -:::warning OS Compatibility -These instructions have been tested only on Linux environments (Ubuntu, NixOS). If you're on Windows or Mac OS X, you might need to adapt to use [Volumes](https://docs.docker.com/storage/volumes/). -::: - -## Setting-up The Chain - -To get started, let's pull the necessary images for services defined in the compose file: - -```mdx-code-block - -docker-compose --profile tui --profile hydra-node pull - -``` - -From there, we can run the `./prepare-devnet.sh` script to create an initial configuration for our development network. This creates genesis files needed to bootstrap a Cardano blockchain. Note that, for the demo, we use a simple variant of Cardano that requires no stake pools whatsoever. - -```mdx-code-block - -./prepare-devnet.sh - -``` - -We can now bring the Cardano node up with: - -```mdx-code-block - -docker-compose up -d cardano-node - -``` - -:::caution Caution! -As we use ad-hoc private devnets that start from the genesis block, you need to ensure the devnet configuration is reasonably up to date. If you get `TraceNoLedgerView` errors from the Cardano node, the start times are too far in the past and you should update them by using the `prepare-devnet.sh` script, for example. -::: - -You can verify that the node is up-and-running by checking the logs with `docker-compose logs cardano-node -f`. You should see traces containing `TraceAdoptedBlock`, which means that the devnet is producing blocks .. nice! - -## Seeding The Network - -We include a script `seed-devnet.sh` that uses the `cardano-cli` in the already -running `cardano-node` container to give Alice, Bob, and Carol some UTXO entries -to commit and some fuel UTXO. - -```mdx-code-block - -./seed-devnet.sh - -``` - -## Starting Hydra Nodes - -Finally, now that the on-chain preparations are ready, we can bring the Hydra network (i.e. all three nodes for Alice, Bob and Carol) up by running: - -```mdx-code-block - -docker-compose --profile hydra-node up -d - -``` - -## Running The Clients - -Using compose, you can start the demo Terminal-based User Interface (a.k.a. `hydra-tui`) to interact with Hydra nodes. There are 3 preconfigured TUI services in the compose definition: `hydra-tui-1`, `hydra-tui-2`, and `hydra-tui-3`. To connect to the first Hydra node in a terminal, run the following commands: - -```mdx-code-block - -docker-compose --profile tui run hydra-tui-1 - -``` - -This will start a full-blown terminal interface loaded with signing keys corresponding to the first Hydra node. In other terminals, you can start other nodes in a similar fashion targeting `hydra-tui-2` and `hydra-tui-3` services. diff --git a/docs/docs/getting-started/developing-on-hydra.md b/docs/docs/getting-started/developing-on-hydra.md deleted file mode 100644 index 02abd67a1ad..00000000000 --- a/docs/docs/getting-started/developing-on-hydra.md +++ /dev/null @@ -1,81 +0,0 @@ -# Hydra development - -This guide is meant to be a tutorial on how to develop an application on Hydra. It will assume the reader is already familiar with developing a DApp on Cardano and will focus on the differences between the two. - -## On-chain code - -On-chain code will be exactly the same between Cardano and a hydra head. This is one of the main selling points of the hydra design (heads are also called isomorphic state channels). Note that Hydra Heads now also support validity ranges for L2 transactions through the `Tick` event which contains the current L1 slot. - -## Off-chain code - -Here is where the differences will begin. Currently, there is no [support for the PAB](https://github.com/input-output-hk/hydra/issues/214). When it comes to hydra, the luxaries of the `Contract` monad are not available, so the developer will not have access to similar tools. - -Instead, transactions will need to be constructed and submitted to the Hydra Node in CBOR format. The interface to speak to a Hydra Node is a websocket, and developers must build applications that connect to these websockets in order to send and receive events through them. - -The Hydra node will emit several commands through this websocket: the API is defined [here](/api-reference). -The API reference is divided into two sections: Pub and Sub. -The first one describes the commands that a hydra node will accept, while the second one describes the events that will be emitted through the websocket. - -An important event developers will be interested in is `SnaphotConfirmed`. This event is emitted once all the participants of the head, have seen and signed a transaction submitted by one of them. - -Once a transaction lands inside a snapshot, it is confirmed and there are no chances for it to be rolled back. This is an important distinction from L1: in that case, when a node sees a transaction there is still a chance that it might be rolled back (where the probability of this goes to 0 as more blocks are added), in the hydra world, the only way to make a snapshot is to have every single node in the head approve of it. -This is a synchronous process and requires all the head participants to be online all the time, the tradeoff is that there is no uncertainty or possibility of rollbacks. Once the Hydra Head has been open long enough that the opening transaction has become final, the moment the snapshot is confirmed there is no going back. See also this [feature on the roadmap](https://github.com/input-output-hk/hydra/issues/185). - -For the Pub side of the API, an important endpoint will be `NewTx`. This is used to submit a transaction to the node. There are a couple of ways the transaction can be submitted, but a simple and familiar way should be to build the transaction built with `Cardano.Api`, sign & serialize it to CBOR and submit that through the websocket. - -## Testing - -Testing inside the hydra head can be quite different than for working with the PAB, the reason is you will not have access to EmulatorTrace or a pre-deployed playground environment to test. - -Instead, it is possible to spin up a local cardano devnet, as well as and a cluster of hydra-nodes programmatically and run tests directly on that. -The hydra-cluster package is used within Hydra to do end-to-end tests on the protocol and hence is a nice blueprint for this setup. It's library component provides functions to spin up the required nodes, send API inputs and run assertions on the API output. Should you be missing something or need more configurability, feel free to open a feature request and we are happy to support you. - -A couple of steps are required to set up the initial environment: - -- We want to spin up a local Cardano devnet comprised by a single block producer. This can be done with `withCardanoDevnet` which takes the a working directory where blocks and logs will be stored, as well as a callback that gets access to the `RunningNode`. Note that the devnet will use credentials and configuration from the `hydra-cluster/config/`. - -- In the callback, we can then spin up a cluster of hydra-nodes using `withHydraCluster`. This will require the cardano-node socket, which can be obtained from the running node instance, and a set of cardano and hydra keys which can also be easily generated through helpers exposed by `hydra-cluster`. - -Let's walk through a simple example, with comments explaining the setup we just described. -This test will spin up a single cardano node, and a pair of hydra nodes (Alice and Bob). - -```haskell --- Tracer is an instance of https://hackage.haskell.org/package/contra-tracer and is used by several --- hydra components to deal with logs in a structured way -it "spins up two hydra nodes" -> do - let tracer = stdoutTracer - -- Set a timeout for the whole test to fail - failAfter 60 $ - -- We create a temporary directory to contain all the files required to spin up a node - withTempDir "cardano-node-tmp-dir" $ \tmpDir -> do - -- This starts the cardano devnetas described above - withCardanoDevnet (contramap FromCardanoNode tracer) tmpDir $ \(RunningNode{nodeSocket}) -> do - -- We generate pairs of cardano keys for alice and bob, this pair is a tuple of verification and signing key - aliceKeys <- generate genKeyPair - bobKeys <- generate genKeyPair - - -- Here we generate signing keys for hydra used to sign transactions on layer 2 only - let aliceSk = generateSigningKey "alice" - bobSk = generateSigningKey "bob" - - let cardanoKeys = [aliceKeys, bobKeys] - hydraKeys = [aliceSk, bobSk] - - -- Hydra nodes take an id as one of their arguments, it is used to identify them with the head protocol - let firstNodeId = 0 - - -- This will spin up `n` hydra nodes, where `n` is the length of the cardanoKeys list - -- (which needs to match the length of hydraKeys) - withHydraCluster tracer tmpDir nodeSocket firstNodeId cardanoKeys hydraKeys $ \nodes -> do - pure () -``` - -At this point, we are ready to start sending commands to the `hydra-cluster` programmatically. -Hydra-cluster also exposes a `send` function, which takes an instance of the hydra-node and uses its websocket connection to send commands to the process. -Remember that we must handle the whole head initialisation inside the test as well, so the first step will always be for one of the two nodes to `send` an `Init` command to start the opening of the head. - -Finally, hydra-node exposes several useful functions to wait for output from the hydra nodes themselves, both these functions have a timeout so they will function as assertions from a testing point of view; that is, if the node does not output what we expect within a certain timeframe, an error will be thrown and the whole test will fail. - -Remember the nodes will always produce output in JSON format, so all the assertions will expect some form of `Aeson.Value` to check against. For example, after we submit a transaction to the node, we can use `waitMatch` to parse the `SnaphotConfirmed` event and extract the transactions present in that snapshot to check if it contains the transaction we just sent. - -For more details about the `hydra-cluster` functions (i.e. `waitFor` and `waitMatch`), visit the [haddock](/haddock/hydra-cluster/HydraNode.html) diff --git a/docs/docs/getting-started/glossary.md b/docs/docs/getting-started/glossary.md deleted file mode 100644 index 8f43d96fb5d..00000000000 --- a/docs/docs/getting-started/glossary.md +++ /dev/null @@ -1,52 +0,0 @@ -# Glossary - -### Contestation Period -The time window between closing the head and the last time (deadline) a contest is possible by a head participant. - -### Hydra Head -A running instance of the hydra head protocol. See a reference in [essential cardano](https://www.essentialcardano.io/glossary/hydra-head) for more details. - -### Hydra Network -One or more hydra nodes inter-connected. - -### Hydra Node -Essential building block and executable piece of software that is used to form a Hydra network. - -### Isomorphic -Reuses the existing smart contract system and code for offchain computations. This guarantees that onchain and offchain semantics coincide, leading to significant engineering simplifications. - -### Layer 2 -Layer 2 refers to a secondary framework or protocol that is built on top of an existing blockchain system. See this [page](/core-concepts/layer-two) for more details. - -### Participation Token -An on-chain token that entitles a party to participate in the Hydra head associated with the token. - -### Party -A participant or logical member of a Hydra head, identified by a pair of verification keys one for the Hydra network and another one for the Cardano network. - -### Peer -A member of a Hydra network, identified by an IP address and a TCP port. - -### Fuel UTxO -[UTxO](https://docs.cardano.org/glossary/#utxo) pieces used to pay for Hydra head [transaction](https://docs.cardano.org/glossary/#transaction) [fees](https://docs.cardano.org/glossary/#fee) happening on the base layer (i.e. the Cardano network). - -### Reference script -See this [page](./quickstart#reference-scripts) for more details. - -### Rollback -The manifestation of a chain switch on the base layer, causing the recent history to change. It is a multi-step process between the head and L1. See this [page](/core-concepts/rollbacks) for more details. - -### Signing key -See a reference in [cardano glossary](https://docs.cardano.org/glossary/#keypair) for more details. - -### Snapshot -Some state of a Hydra head; When multi-signed by all parties, a snapshot is said "confirmed". - -### State Channel -A common kind of layer two solution. See this [page](/core-concepts/layer-two#state-channels) for more details. - -### State Thread Token -An on-chain token representing the state of a Hydra head. - -### Verification Key -See a reference in [cardano glossary](https://docs.cardano.org/glossary/#keypair) for more details. diff --git a/docs/docs/getting-started/installation.md b/docs/docs/getting-started/installation.md deleted file mode 100644 index e93b3c30b7f..00000000000 --- a/docs/docs/getting-started/installation.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -sidebar_position: 2 ---- - -# Installation - -```mdx-code-block -import TerminalWindow from '@site/src/components/TerminalWindow'; -``` - -> Where to get Hydra from? - -## Using Docker - -The quickest way to get a hydra-node running is to use our Docker images: - -````mdx-code-block - - -``` -docker pull ghcr.io/input-output-hk/hydra-node -docker run --rm ghcr.io/input-output-hk/hydra-node --help -``` - - -```` - -## Using prebuilt static binaries - -We provide builds for `hydra-node` and `hydra-tui` as statically -linked `x86_64-linux` binaries. These binaries can be found in our CI or -attached to [github releases](https://github.com/input-output-hk/hydra/releases) -starting with version `0.8.1`. - -## Building from source - -While using docker is the recommended way to _use_ Hydra, you can also build the `hydra-node` from source. We do recommend using [nix](https://nixos.org/download.html) for this though and the instructions can be found in our [Contributing Guidelines](https://github.com/input-output-hk/hydra/blob/master/CONTRIBUTING.md). diff --git a/docs/docs/getting-started/quickstart.md b/docs/docs/getting-started/quickstart.md deleted file mode 100644 index 0307d65a5a8..00000000000 --- a/docs/docs/getting-started/quickstart.md +++ /dev/null @@ -1,315 +0,0 @@ ---- -sidebar_position: 3 ---- - -# QuickStart - -```mdx-code-block -import TerminalWindow from '@site/src/components/TerminalWindow'; -``` - -> Your first steps with a `hydra-node`. - -Running a Hydra head means running a Hydra node connected to some other Hydra nodes and connected to a Cardano node. A working [cardano-node](https://github.com/input-output-hk/cardano-node/) is therefore a pre-requisite for running a Hydra head. In this guide, we won't go over details about running a Cardano node and we invite you to look for existing documentation on the matter if need be. - -:::tip cardano-node & cardano-cli -We recommend using containers and the [official Docker image](https://hub.docker.com/r/inputoutput/cardano-node) for running a Cardano node. - -This image contains both `cardano-node` and `cardano-cli`. The latter is handy to run various commands, for example to create addresses and to generate keys. -::: - -## Hydra-node options... - -The entire configuration of the `hydra-node` is provided through command-line options. Options are used to configure various elements of the network, API, chain connection and used ledger. You can use the `--help` option to get a description of all options: - -``` -hydra-node - Implementation of the Hydra Head protocol - -Usage: hydra-node ([-q|--quiet] (-n|--node-id NODE-ID) [-h|--host IP] - [-p|--port PORT] [-P|--peer ARG] [--api-host IP] - [--api-port PORT] [--monitoring-port PORT] - [--hydra-signing-key FILE] [--hydra-verification-key FILE] - [--hydra-scripts-tx-id TXID] [--persistence-dir DIR] - [--mainnet | --testnet-magic NATURAL] [--node-socket FILE] - [--cardano-signing-key FILE] - [--cardano-verification-key FILE] - [--start-chain-from SLOT.HEADER_HASH] - [--contestation-period CONTESTATION-PERIOD] - [--ledger-protocol-parameters FILE] | - COMMAND) [--version] [--script-info] - - Starts a Hydra Node - -Available options: - -q,--quiet Turns off logging. - -n,--node-id NODE-ID The Hydra node identifier used on the Hydra network. - It is important to have a unique identifier in order - to be able to distinguish between connected peers. - -h,--host IP Listen address for incoming Hydra network - connections. (default: 127.0.0.1) - -p,--port PORT Listen port for incoming Hydra network connections. - (default: 5001) - -P,--peer ARG A peer address in the form :, where - can be an IP address, or a host name. Can be - provided multiple times, once for each peer (current - maximum limit is 4 peers). - --api-host IP Listen address for incoming client API connections. - (default: 127.0.0.1) - --api-port PORT Listen port for incoming client API connections. - (default: 4001) - --monitoring-port PORT Listen port for monitoring and metrics via - prometheus. If left empty, monitoring server is not - started. - --hydra-signing-key FILE Hydra signing key used by our hydra-node. - (default: "hydra.sk") - --hydra-verification-key FILE - Hydra verification key of another party in the Head. - Can be provided multiple times, once for each - participant (current maximum limit is 4 ). - --hydra-scripts-tx-id TXID - The transaction which is expected to have published - Hydra scripts as reference scripts in its outputs. - Note: All scripts need to be in the first 10 outputs. - See release notes for pre-published versions. You can - use the 'publish-scripts' sub-command to publish them - yourself. - --persistence-dir DIR The directory where the Hydra Head state is stored.Do - not edit these files manually! - --mainnet Use the mainnet magic id. - --testnet-magic NATURAL Network identifier for a testnet to connect to. We - only need to provide the magic number here. For - example: '2' is the 'preview' network. See - https://book.world.dev.cardano.org/environments.html - for available networks. (default: 42) - --node-socket FILE Filepath to local unix domain socket used to - communicate with the cardano node. - (default: "node.socket") - --cardano-signing-key FILE - Cardano signing key of our hydra-node. This will be - used to authorize Hydra protocol transactions for - heads the node takes part in and any funds owned by - this key will be used as 'fuel'. - (default: "cardano.sk") - --cardano-verification-key FILE - Cardano verification key of another party in the - Head. Can be provided multiple times, once for each - participant (current maximum limit is 4). - --start-chain-from SLOT.HEADER_HASH - The id of the block we want to start observing the - chain from. If not given, uses the chain tip at - startup. Composed by the slot number, a separator - ('.') and the hash of the block header. For example: - 52970883.d36a9936ae7a07f5f4bdc9ad0b23761cb7b14f35007e54947e27a1510f897f04. - --contestation-period CONTESTATION-PERIOD - Contestation period for close transaction in seconds. - If this value is not in sync with other participants - hydra-node will ignore the initial tx. Additionally, - this value needs to make sense compared to the - current network we are running. (default: 60s) - --ledger-protocol-parameters FILE - Path to protocol parameters used in the Hydra Head. - See manual how to configure this. - (default: "protocol-parameters.json") - --version Show version - --script-info Dump script info as JSON - -h,--help Show this help text - -Available commands: - publish-scripts Publish Hydra's Plutus scripts on chain to be used - by the hydra-node as --hydra-script-tx-id. - - ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ - ┃ ⚠ WARNING ⚠ ┃ - ┣═══════════════════════════════════════┫ - ┃ This costs money. About 50 Ada. ┃ - ┃ Spent using the provided signing key. ┃ - ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛ -``` - -:::info Dynamic Configuration - -We realise that the command-line in its current form isn't as user-friendly as it could, and is somewhat cumbersome to use for setting up large clusters. - -There are however plans to make the configuration more user-friendly and configurable dynamically; see [#240](https://github.com/input-output-hk/hydra/issues/240) & [ADR-15](/adr/15) -::: - -## ...and Where to Find Them - -### Cardano Keys - -The previous section describes the various options and elements needed to setup a Hydra node. In this section, we'll show how to obtain some of those elements. First, let's start with the Cardano keys (`--cardano-signing-key` and `--cardano-verification-key`). - -In a head, every participant is authenticated by two sets of keys, one key pair is a plain Ed25519 public/private key pair quite common on Cardano already. Such a key pair can be generated using the `cardano-cli` as follows: - -```mdx-code-block - -cardano-cli address key-gen --verification-key-file cardano.vk --signing-key-file cardano.sk - -``` - -From there, each participant is expected to share their verification key with other participants. To start a node, one will need its **own signing key** and **other participants' verification key**. Those keys are currently used to authenticate on-chain transactions which drives the execution of the Hydra protocol. They prevent unsolicited actors to fiddle with the head life-cycle (for instance, someone external to the head could otherwise _abort_ an initialised head). While this wouldn't put head participants' funds at risk, it is still an annoyance that one wants to prevent. - -### Hydra keys - -The second set of keys are the so-called Hydra keys, which are used for multi-signing snapshots within a Head. While in the long-run, those keys will be key pairs used within MuSig2 aggregated multi-signature scheme. At present however, the aggregated multisig cryptography is [yet to be implemented](https://github.com/input-output-hk/hydra/issues/193) and the Hydra nodes are a naive, but secure multi-signature scheme based on Ed25519 keys. - -These are similar to cardano keys but are used only in the layer 2. We provide demo key pairs as `alice.{vk,sk}`, `bob.{vk,sk}` and `carol.{vk,sk}` in our [demo folder](https://github.com/input-output-hk/hydra/tree/master/demo). - -Alternatively, unique keys can be generated using `hydra-node`: - -```mdx-code-block - -hydra-node gen-hydra-key --output-file my-key - -``` - -This will create two files, `my-key.sk` and `my-key.vk` containing Hydra keys suitable for use inside a head. - -### Contestation Period - -Contestation period is an argument to the hydra-node, expressed as a number of seconds, for example: - -``` -$ hydra-node ... --contestation-period 120s -``` - -Contestation period is used in: - -- Constructing the upper validity bound for `Close` and `Contest` transactions, -- Computing the contestation deadline and therefore the lower validity - bound for `FanOut` transaction. - -This parameter has a default value of _60 seconds_, which should be -enough under normal circumstances, but it needs to be tailored to the -condition of network we are running on since slot lengths and block -production rates are different on different networks. - -:::info Consistent contestation period - -All parties in the hydra head protocol need to configure the same -value for `--contestation-period` otherwise the `Init` transaction -will be ignored. This prevents certain party from stalling/DoS-ing -the head by setting contestation period to unreasonably large values. - -::: - -:::warning Invalid Close and Contest Transactions - -Depending on the contestation period value and the network conditions, -`Close` and `Contest` transactions could become invalid and be -silently rejected by the cardano-node to which they have been -submitted. This can happen, for example, if: -* The network is congested, with lot of transactions waiting to be - included in a block, -* The node's connectivity to the network drops and the transaction is - not propagated to block producers fast enough. - -The hydra-node itself does not currently handle this situation and -therefore each client application needs to put in place some retry -mechanism depending on the time it should "normally" take to have the -transaction. - -::: - -### Reference Scripts - -Hydra makes use of reference scripts to reduce the size of transactions driving the Head's lifecycle. In principle, reference scripts will be published with each release and the corresponding transaction id will be advertised in the release notes. However, if you do want to play around with this and provide alternative versions, you can do so by first publishing the scripts yourself via the `publish-scripts` command: - -```mdx-code-block - -hydra-node publish-scripts --testnet-magic 42 --node-socket /path/to/node.socket --cardano-signing-key cardano.sk - -``` - -On success, this commands outputs a transaction id ready to be used. The provided key is expected to hold funds (> 50 ADA), and will be used to create multiple **UNSPENDABLE** UTxO entries on-chain, each carrying a script that can be later referenced by the Hydra node. - -### Ledger Parameters - -At the core of a Hydra head, there's a ledger. At the moment, Hydra is wired only to Cardano and assumes a ledger configuration similar to the one used on the layer 1. This translates as a command-line option `--ledger-protocol-parameters`. This defines the updatable protocol parameters such as fees or transaction sizes. They use the same format as the one used by the cardano-cli (e.g. `cardano-cli query protocol-parameters`'s 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 basis. In particular, the protocol parameters are defined to nullify costs inside a head. Apart from that, they are the direct copy the current mainnet parameters. An interesting point about the Hydra's ledger is that, while it re-uses the same rules and code as the layer 1 (a.k.a. isomorphic), parameters may also be altered to slightly differ from the layer 1. This is the case for fees, but could also be done for script maximum execution budget for instance. However, not all parameters are safe to alter! Changing parameters that control the maximum size of a value (carrying native assets), or the minimum Ada value for a UTxO may render a head "unclosable"! A good rule thumb is that anything that applies strictly to transactions (fees, execution units, max tx size...) is safe to change. But anything that could be reflected in the UTxO is not. - -:::info About Protocol Parameters -Note that many of protocol-parameters are actually irrelevant in the context of Hydra (for example, there's no treasury or stake pool inside a head; consequently, parameters configuring the reward incentive or delegation rules are pointless and unused). -::: - -### Fuel - -Finally, one last bit necessary to get Hydra nodes up and running is to add funds to their "internal wallet". All the transactions driving the Head lifecycle (Init, Abort, Close, ...) need to be submitted to the layer 1, and hence they cost money! - -For that, any funds owned by the `--cardano-signing-key` given to the `--hydra-node` will be considered spendable to pay fees or use as collateral for these Hydra protocol transactions. Consequently, sending some ADA-only funds to the address of this "internal wallet" is required. To get the address for the cardano keys as generated above, one can use for example the cardano-cli: - - - -```sh -cardano-cli address build --verification-key-file cardano.vk --mainnet -# addr1v92l229athdj05l20ggnqz24p4ltlj55e7n4xplt2mxw8tqsehqnt -``` - - - -## External commits - -While the `hydra-node` holds funds to fuel protocol transactions, any wallet can be used to commit funds into an `initializing` Hydra head. The `hydra-node` provides an HTTP endpoint at `/commit`, which allows to specify either: - - a `UTxO` set of outputs to commit (belonging to public keys) or - - a _blueprint_ transaction together with the `UTxO` which resolves it. - -and eventually returns a commit transaction. - -This transaction is already balanced and all fees are paid by the funds held by the `hydra-node`. Hence, an integrated wallet would need to sign this transaction and submit it to the Cardano network. See the [api documentation](pathname:///api-reference/#operation-publish-/commit) for details. - -If the user wants to use some `UTxO` they own and commit it to a `Head` then they need to send the appropriate JSON representation of said `UTxO` to the `/commit` API endpoint. - -Using a _blueprint_ transaction with `/commit` allows for more flexibility since `hydra-node` only adds needed commit transaction data without removing any additional information specified in the _blueprint_ transaction. For example, any present reference inputs, redeemers or validity ranges will be kept. - -> Note: It is important to note that any **outputs** of a blueprint transaction will not be considered, only inputs are used to commit funds to the `Head`. `hydra-node` will also **ignore** any minting or burning specified in the blueprint transaction. - -You can take a look at the small example on how to commit to a `Head` using blueprint transaction [here](/docs/blueprint_transaction.md) - -## Generating transactions for the WebSocket API - -To perform a transaction within an initialized Head via the WebSocket API of Hydra Node, use the commands below and send the output to the node: - -```bash title="Transaction building" -cardano-cli transaction build-raw \ - --babbage-era \ - --tx-in 09d34606abdcd0b10ebc89307cbfa0b469f9144194137b45b7a04b273961add8#687 \ - --tx-out addr1vx8apm8x8rla2w6tk7dxnwrlxkmeuera4x4tw5j695xhxeq4wawpz+7620669 \ - --fee 0 \ - --out-file tx.json - -cardano-cli transaction sign \ - --tx-body-file tx.json \ - --signing-key-file cardano.sk \ - --out-file signed-tx.json - -echo "{ \"tag\": \"NewTx\", \"transaction\": $(cat signed-tx.json | jq ".cborHex") }" -{ "tag": "NewTx", "transaction": "84a3008182582009d34606abdcd0b10ebc89307cbfa0b469f9144194137b45b7a04b273961add81902af0181a200581d618fd0ece638ffd53b4bb79a69b87f35b79e647da9aab7525a2d0d7364011a0074483d0200a10081825820c736d40ee64c031851af26007c00a3b6fcbebccfd333a8ee6f14983f9be5331c58404bae506f5235778ec65eca6fdfcf6ec61ab93420b91e0b71ca82d437904f860e999372cf00252246ca77012e19c344b3af60df9f853af53fc86835f95a119609f5f6" } -``` - -The `--tx-in` value is a UTxO obtained from the `GET /snapshot/utxo` request. For example: - -```json title="Example response of GET /snapshot/utxo" -{ - "09d34606abdcd0b10ebc89307cbfa0b469f9144194137b45b7a04b273961add8#687": { - "address": "addr1w9htvds89a78ex2uls5y969ttry9s3k9etww0staxzndwlgmzuul5", - "value": { - "lovelace": 7620669 - } - } -} -``` - -## Example Setup - -### Google Cloud w/ Terraform - -We provide sample node configurations that will help you get started hosting a Hydra node on virtual machines in the Cloud in the [`sample-node-config/` directory](https://github.com/input-output-hk/hydra/tree/master/sample-node-config/gcp/). In particular, this setup contains a [docker-compose.yaml](https://github.com/input-output-hk/hydra/blob/master/sample-node-config/gcp/docker-compose.yaml) specification which gives a good template for configuring cardano-node + hydra-node services. It also offers various useful scripts to setup your cluster. - -> Note: This setup is meant to configure your cluster for devnet network. If you want to run the node on mainnet check out _Running on Mainnet_ paragraph. - -## Running on Mainnet - -Hydra node is compatible with the mainnet network. To choose this network you need to specify `--mainnet` flag for the network id in the hydra-node arguments. We publish the hydra scripts on each new release and you can find them on the [release page](https://github.com/input-output-hk/hydra/releases) (look for section _Hydra Scripts_). - -Please be sure to read the [relevant section](/docs/known-issues) section to fully understand the limitations and consequences of running Hydra nodes on mainnet. diff --git a/docs/docs/blueprint_transaction.md b/docs/docs/how-to/commit-blueprint.md similarity index 97% rename from docs/docs/blueprint_transaction.md rename to docs/docs/how-to/commit-blueprint.md index af32a00e943..9161794fd86 100644 --- a/docs/docs/blueprint_transaction.md +++ b/docs/docs/how-to/commit-blueprint.md @@ -1,10 +1,10 @@ --- -sidebar_position: 99 +sidebar_position: 1 --- -# Commit using blueprint transaction +# Commit using a blueprint - This is a small walk-through on how to use `cardano-cli` to assemble everything needed to commit funds to a `Head` using blueprint transaction. + This is a small walk-through on how to use `cardano-cli` to assemble everything needed to commit funds to a `Head` using a so-called blueprint transaction. Example assumes you have the hydra-node repo at your disposal together with `hydra-node`, `hydra-tui`, `cardano-cli` and `curl` binaries. diff --git a/docs/docs/getting-started/operating-hydra.md b/docs/docs/how-to/operating-hydra.md similarity index 86% rename from docs/docs/getting-started/operating-hydra.md rename to docs/docs/how-to/operating-hydra.md index afb5a9b3819..90c4a5b08c7 100644 --- a/docs/docs/getting-started/operating-hydra.md +++ b/docs/docs/how-to/operating-hydra.md @@ -2,7 +2,7 @@ sidebar_position: 6 --- -# Operating a Hydra Node +# Operate a Hydra Node ```mdx-code-block import TerminalWindow from '@site/src/components/TerminalWindow'; @@ -10,6 +10,14 @@ import TerminalWindow from '@site/src/components/TerminalWindow'; This page aims at helping Hydra users troubleshoot issues when running their own instances of `hydra-node` and participate in a Hydra Head. +## Example Setup + +We provide sample node configurations that will help you get started hosting a Hydra node on virtual machines in the Cloud in the [`sample-node-config/` directory](https://github.com/input-output-hk/hydra/tree/master/sample-node-config/). + +### Google Cloud w/ Terraform + +This setup contains a [docker-compose.yaml](https://github.com/input-output-hk/hydra/blob/master/sample-node-config/gcp/docker-compose.yaml) which gives a good template for configuring cardano-node + hydra-node services. It also offers various useful scripts to setup your cluster. + ## Logs Following [ADR-9](/adr/9) design principles, the `hydra-node` provides [JSON](https://json.org) formatted logs on the `stdout` stream, one line per log item. The log items follow a [JSON schema](https://github.com/input-output-hk/hydra/blob/master/hydra-node/json-schemas/logs.yaml). This logging capability is kept voluntarily simple and non configurable in order to ease integration of Hydra logging into more general log analysis infrastructure, whether a custom ELK stack, third-party services, docker sidecars... diff --git a/docs/docs/how-to/submit-transaction.md b/docs/docs/how-to/submit-transaction.md new file mode 100644 index 00000000000..947aa2e379f --- /dev/null +++ b/docs/docs/how-to/submit-transaction.md @@ -0,0 +1,56 @@ +--- +sidebar_position: 2 +--- + +# Submit a transaction + +To submit a transaction to an already open Head, you need to use `NewTx` command of the WebSocket API. + +First, let's query the UTxO available in the head: + +``` +curl localhost:4001/snapshot/utxo | jq +``` + +An example response could look like: + +```json title="Example response of GET /snapshot/utxo" +{ + "8690d7618bb88825d6ec7cfbe2676779b8f4633cb137a1c12cd31b4c53f90f32#0": { + "address": "addr_test1vrdhewmpp96gv6az4vymy80hlw9082sjz6rylt2srpntsdq6njxxu", + "datum": null, + "datumhash": null, + "inlineDatum": null, + "referenceScript": null, + "value": { + "lovelace": 100000000 + } + } +} +``` + +Assuming the single utxo is owned by `some-payment-key.sk` and we want to send all of it to some other address, we can use the `cardano-cli` (or your favorite transaction builder) to construct and sign a transaction: + +```shell title="Transaction building" +cardano-cli transaction build-raw \ + --babbage-era \ + --tx-in 8690d7618bb88825d6ec7cfbe2676779b8f4633cb137a1c12cd31b4c53f90f32#0 \ + --tx-out addr_test1vp5cxztpc6hep9ds7fjgmle3l225tk8ske3rmwr9adu0m6qchmx5z+100000000 \ + --fee 0 \ + --out-file tx.json + +cardano-cli transaction sign \ + --tx-body-file tx.json \ + --signing-key-file some-payment-key.sk \ + --out-file tx-signed.json + +cat tx-signed.json | jq -c '{tag: "NewTx", transaction: .}' +``` + +This will output a message that can be submitted to a websocket connection to `hydra-node`. Using `websocat` and assuming the `hydra-node` runs on the default port `4001` we can submit with: + +```shell +cat tx-signed.json | jq -c '{tag: "NewTx", transaction: .}' | websocat "ws://127.0.0.1:4001?history=no" +``` + +The transation will now be validated by all connected `hydra-node`s and either result in a `TxInvalid` message with a reason, or a `TxValid` message and a `SnapshotConfirmed` with the new UTxO available in the head shortly after. diff --git a/docs/docs/getting-started/index.md b/docs/docs/index.md similarity index 63% rename from docs/docs/getting-started/index.md rename to docs/docs/index.md index fc813273ac5..9c46cff72e9 100644 --- a/docs/docs/getting-started/index.md +++ b/docs/docs/index.md @@ -1,20 +1,12 @@ ---- -sidebar_position: 1 ---- +# Welcome -# Getting Started - -Hydra is the layer-two scalability solution for Cardano, which aims to increase +Hydra is a layer-two scalability solution for Cardano, which aims to increase the speed of transactions (low latency, high throughput) and minimize transaction cost. -This repository contains the implementation for the Hydra [Head -protocol](https://eprint.iacr.org/2020/299.pdf). Most prominently, it contains a -`hydra-node`, which runs a simplified (coordinated) Hydra Head protocol, -connects to other `hydra-node`s, interfaces the Cardano blockchain and provides an -API to clients such as the included example terminal user interface `hydra-tui`. +This is the user manual for `hydra-node`, an implementation of the Hydra Head protocol, as originally published [here](https://eprint.iacr.org/2020/299.pdf). The `hydra-node` interfaces the Cardano blockchain, connects to other `hydra-node`s on a dedicated overlay network, runs a simplified (coordinated) Hydra Head protocol, and provides an API to clients. -:::warning Mainnet Availability +:::warning Mainnet Availability disclaimer The Hydra Head protocol version 0.10.0 or newer is compatible with the Cardano mainnet, which means it is possible to run a `hydra-node` on mainnet using real @@ -36,15 +28,9 @@ on hydra.family and Hydra Github Repository is available on an ‘AS IS’ and AVAILABLE’ basis, without any representations or warranties of any kind. All implied terms are excluded to the fullest extent permitted by law. For details, see also sections 7, 8 and 9 of the [Apache 2.0 License][license]. - ::: -[known-issues]: ../known-issues -[license]: https://github.com/input-output-hk/hydra/blob/master/LICENSE +Now, without further ado, read more about the protocol [on the next page](./protocol-overview) or jump right in to [getting started using a local devnet](./getting-started). -```mdx-code-block -import DocCardList from '@theme/DocCardList'; -import {useCurrentSidebarCategory} from '@docusaurus/theme-common'; - - -``` +[known-issues]: ./known-issues.md +[license]: https://github.com/input-output-hk/hydra/blob/master/LICENSE diff --git a/docs/docs/installation.md b/docs/docs/installation.md new file mode 100644 index 00000000000..df81be60b1b --- /dev/null +++ b/docs/docs/installation.md @@ -0,0 +1,22 @@ +--- +sidebar_position: 2 +--- + +# Installation + +### Docker + +The quickest way to get a `hydra-node` installed and running is to use our Docker images: + +```shell +docker pull ghcr.io/input-output-hk/hydra-node +docker run --rm ghcr.io/input-output-hk/hydra-node --help +``` + +### Prebuilt binaries + +We provide statically linked (as much as possible) binaries of `hydra-node` and `hydra-tui` for x86_64 Linux and ARM64 MacOS platforms as attachment of our [github releases](https://github.com/input-output-hk/hydra/releases). + +### Build from source + +While using docker is the recommended way to _use_ Hydra, you can also build the `hydra-node` from source. We do recommend using [nix](https://nixos.org/download.html) for this and the instructions can be found in our [Contributing Guidelines](https://github.com/input-output-hk/hydra/blob/master/CONTRIBUTING.md). diff --git a/docs/docs/known-issues.md b/docs/docs/known-issues.md index c00e24debb3..026a48d244a 100644 --- a/docs/docs/known-issues.md +++ b/docs/docs/known-issues.md @@ -1,96 +1,33 @@ # Known issues & limitations -Please be aware of the following limitations before running hydra-node -on the Cardano `--mainnet`; as an incredibly technical project, Hydra -in its current form requires an elevated level of understanding of the -underlying infrastructure. Without the expertise required to operate a -hydra-node, users may put their funds at risk if they are unfamiliar -with the implementation and usage process. +Please be aware of the following known issues and limitations before running `hydra-node` on the Cardano `--mainnet`; as an incredibly technical project, Hydra in its current form requires an elevated level of understanding of the underlying infrastructure. Without the expertise required to operate a `hydra-node`, users may put their funds at risk if they are unfamiliar with the implementation and usage process. -### Head protocol +### Head protocol limits -#### Layer-1/Layer-2 +As transaction sizes and execution budgets are limited on Cardano: -The current transaction size on mainnet is limited to 16KB, a limitation which has the following consequences: +- The protocol can only handle a maximum number of participants in a Head (see [cost of collectcom transaction](/benchmarks/transaction-cost/#cost-of-collectcom-transaction)). Upon startup, the `hydra-node` will inform you of the current configured maximum when trying to configure too many peers. -- The protocol can only handle a maximum number of participants in a - Head (see [cost of collectcom - transaction](/benchmarks/transaction-cost/#cost-of-collectcom-transaction)). Upon - startup, the `hydra-node` will inform you of the current - configured maximum when trying to configure too many peers. +It's currently possible to be denied access to funds by other protocol participants at various stages in a Hydra Head because of the complexity or size of the UTxO being committed or created while the Head is open: -It's currently possible to be denied access to funds by other protocol -participants at various stages in a Hydra Head because of the -complexity or size of the UTxO being committed or created while the -Head is open: - -- The head cannot be _finalized_ if holding more than ~60 assets - (see [cost of fanout - transaction](https://hydra.family/head-protocol/benchmarks/transaction-cost/#cost-of-fanout-transaction) - for latest numbers), although it can be _closed_ +- The head cannot be _finalized_ if holding more than ~80 assets (see [cost of fanout transaction](https://hydra.family/head-protocol/benchmarks/transaction-cost/#cost-of-fanout-transaction) for latest numbers), although it can be _closed_ - Tokens minted and not burnt in an _open_ head will prevent it from being _finalized_ -- If one or more participants commit UTxO too large to be processed - together in a `CollectCom` or `Abort` transaction, the Head will - be stuck in the _initialising_ stage -- Committing reference scripts from L1 to a Head is problematic and - the hydra-node will prevent this should a client try to do - so. Note that a `Commit` transaction could perfectly be crafted - outside of the hydra-node and would therefore put the Head in an - uncloseable state -- Using reference scripts on the L2 is non problematic as they will - be committed back on the L1 along with all the other UTxO +- If one or more participants commit UTxO too large to be processed together in a `CollectCom` or `Abort` transaction, the Head will be stuck in the _initialising_ stage -There are couple of items in the roadmap around reducing the risk of losing funds in a Hydra Head: +There are couple of items in the roadmap around reducing the risk of locking up funds in a Hydra Head: +- [Directly open heads](https://github.com/input-output-hk/hydra/issues/1329) - [Always abortable Head](https://github.com/input-output-hk/hydra/issues/699) - [Limit size/complexity of UTxOs in the Head](https://github.com/input-output-hk/hydra/issues/698) - [Only sign closable snapshots](https://github.com/input-output-hk/hydra/issues/370) -#### Networking - -##### Authentication & Authorization - -The messages exchanged through the _Hydra Network_ layer between -participants are authenticated: Each message is -[signed](https://github.com/input-output-hk/hydra/issues/727) using -the [Hydra signing key](/docs/getting-started/glossary#signing-key) of the emitting party which is identified by -the corresponding [verification key](/docs/getting-started/glossary#verification-key). When a message with an unknown -or incorrect signature is received, it is dropped and a notification -is logged. - -Messages are however not encrypted and therefore, if confidentiality is -required, some external mechanism needs to be put in place to prevent -other parties from observing the messages exchanged within a Head. - -##### Fault tolerance - -The Hydra Head protocol guarantees safety of all (honest) -participants' funds, but does not in itself guarantee liveness, hence -all parties involved in a Hydra Head must be online and reactive for -the protocol to make progress. - -This implies that, should one or several participants' hydra-node -become _permanently_ unreachable from the others, through a crash, or -a network partition, no more transactions can happen in the Head and -it must be closed. However, the [Hydra network -layer](https://hydra.family/head-protocol/unstable/haddock/hydra-node/Hydra-Node-Network.html) -is tolerant to _transient_ disconnections and (non-Byzantine) crashes. - -### hydra-node - -Independently from the Head protocol itself, the way the hydra-node is -implemented has the following consequences: +### Training wheels - There is a hard-coded limit on **mainnet** network where you can only commit up to 100 ADA into the Hydra head. This is only a safety precaution and is going to be increased as we gain more experience in running Hydra heads on the mainnet. + +### Known bugs -### hydra-tui - -- TUI crashes when user tries to post a new transaction without any UTXO remaining. - -- Recipient addresses to send money to in the TUI are inferred from - the current UTXO set. If a party does not commit a UTXO or consumes - all its UTXO in a Head, it won't be able to send or receive anything - anymore. +Refer also 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) with the code. Should you discover any security relevant problems, please follow our [security policy](https://github.com/input-output-hk/hydra?tab=security-ov-file#readme). diff --git a/docs/docs/open-head.png b/docs/docs/open-head.png new file mode 100644 index 00000000000..4c18090f140 Binary files /dev/null and b/docs/docs/open-head.png differ diff --git a/docs/docs/protocol-overview.md b/docs/docs/protocol-overview.md new file mode 100644 index 00000000000..4d40a201561 --- /dev/null +++ b/docs/docs/protocol-overview.md @@ -0,0 +1,18 @@ +# Protocol overview + +Hydra is the layer 2 scalability solution for Cardano, which aims to increase transaction speed through low latency and high throughput and minimize transaction cost. + +[Hydra Head](https://eprint.iacr.org/2020/299.pdf) is the first protocol of the Hydra family and embodies the foundation for more advanced deployment scenarios relying on isomorphic, multi-party state-channels. For an introduction to the protocol also check out these two blog posts + + - [Hydra – Cardano’s solution for ultimate Layer 2 scalability](https://iohk.io/en/blog/posts/2021/09/17/hydra-cardano-s-solution-for-ultimate-scalability/) + - [Implementing Hydra Heads: the first step towards the full Hydra vision ](https://iohk.io/en/blog/posts/2022/02/03/implementing-hydra-heads-the-first-step-towards-the-full-hydra-vision/) + +There are different flavors and extensions of the Hydra Head protocol, but let's start by looking at the full lifecycle of a basic Hydra Head, and how it allows for isomorphic state transfer between layer 1 and layer 2. + +![](./hydra-head-lifecycle.svg) + +A Hydra Head is formed by a group of online and responsive participants. Participants **init**ialize a Head by announcing several parameters on-chain, including the participants list. Then each of the participants **commit**s unspent transaction outputs (UTXOs) from the Cardano main-chain to it, before all the UTXOs are **collect**ed and made available in a Hydra Head as initial state (`U0`). At any moment before collecting, participants can also **abort** the process and recover their funds. + +While open, they can use the Hydra Head via a hydra-node to submit transactions over the Head network. Transactions have the same format and properties as on the main-chain: they are _isomorphic_. When UTXO entries are spent, and new UTXO entries are created in a Hydra Head, all participants are required to acknowledge and agree on the new state in so-called snapshots (`U1..Un`). Snapshots are _not_ posted back onto the layer 1, but are only kept around by the participants. + +Any participant can **close** the Head using a snapshot, when for example they wish to cash out on the mainnet, or if another party misbehaves or stalls the Head's evolution. There is a mechanism to **contest** the final state on the main chain. Ultimately, a **fanout** transaction distributes the final agreed state and makes available on the layer 1 what only existed virtually in the Head. diff --git a/docs/docs/tutorial/index.md b/docs/docs/tutorial/index.md index f0c28f46764..25bc1b17584 100644 --- a/docs/docs/tutorial/index.md +++ b/docs/docs/tutorial/index.md @@ -1,8 +1,4 @@ ---- -sidebar_position: 2 ---- - -# Tutorial +# Open a head on testnet This tutorial will show you how to use `hydra-node` on the `preprod` Cardano network to open a layer-two state channel between two actors using the Hydra @@ -384,11 +380,7 @@ With all these parameters defined, we now pick a HYDRA_VERSION of the Head proto want to use. This is defined by the `hydra-node --HYDRA_VERSION` itself and the `--hydra-scripts-tx-id` which point to scripts published on-chain. -For all [released](https://github.com/input-output-hk/hydra/releases) HYDRA_VERSIONs -of the `hydra-node` and common Cardano networks, the scripts do get -pre-published and we can just use them. See the [user -manual](../getting-started/quickstart#reference-scripts) for more information -how to publish scripts yourself. +For all [released](https://github.com/input-output-hk/hydra/releases) HYDRA_VERSIONs of the `hydra-node` and common Cardano networks, the scripts do get pre-published and we can just use them. See the [user manual](../configuration#reference-scripts) for more information how to publish scripts yourself. Let's start the `hydra-node` with all these parameters now: @@ -644,7 +636,7 @@ will print the `NewTx` command to copy paste into an already open websocket connection: ```shell -cat tx-signed.json | jq -c '{tag: "NewTx", transaction: .cborHex}' +cat tx-signed.json | jq -c '{tag: "NewTx", transaction: .}' ``` The transation will be validated by both `hydra-node`s and either result in a diff --git a/docs/docusaurus.config.js b/docs/docusaurus.config.js index 0fc89fe15d1..aeca7090141 100644 --- a/docs/docusaurus.config.js +++ b/docs/docusaurus.config.js @@ -33,11 +33,6 @@ const config = { }, ], - i18n: { - defaultLocale: "en", - locales: ["en", "fr", "ja", "es"], - }, - presets: [ [ "classic", @@ -46,6 +41,8 @@ const config = { docs: { editUrl, editLocalizedFiles: true, + sidebarPath: require.resolve("./sidebars.js"), + sidebarCollapsible: false, }, blog: { path: "adr", @@ -125,6 +122,11 @@ const config = { "@docusaurus/plugin-client-redirects", { redirects: [ + // Docs restructuring (2024-05-08) + { + from: "/core-concepts/specification", + to: "/docs/dev/specification", + }, // Use cases section re-organized (2023-07-25) { from: "/use-cases/poker-game", @@ -159,44 +161,35 @@ const config = { }, items: [ { - to: "/docs/getting-started", + to: "/docs", label: "User Manual", position: "left", }, { - to: "/api-reference", - label: "API Reference", + to: "/docs/dev", + label: "Developer Documentation", position: "left", }, { to: "/core-concepts", label: "Core Concepts", - position: "left", - }, - { - to: "/benchmarks", - label: "Benchmarks", - position: "left", + position: "right", }, { to: "/topologies", label: "Topologies", - position: "left", + position: "right", }, { to: "/use-cases", label: "Use Cases", - position: "left", + position: "right", }, { href: "https://github.com/input-output-hk/hydra", label: "GitHub", position: "right", }, - { - type: "localeDropdown", - position: "right", - }, ], }, footer: { @@ -241,7 +234,7 @@ const config = { items: [ { label: "Haskell Packages", - to: "/docs/haskell_packages", + to: "/docs/dev/haskell-packages", }, { label: "Monthly reports", diff --git a/docs/i18n/es/code.json b/docs/i18n/es/code.json deleted file mode 100644 index 57de3770460..00000000000 --- a/docs/i18n/es/code.json +++ /dev/null @@ -1,295 +0,0 @@ -{ - "theme.ErrorPageContent.title": { - "message": "Esta página se ha bloqueado", - "description": "The title of the fallback page when the page crashed" - }, - "theme.ErrorPageContent.tryAgain": { - "message": "Inténtelo de nuevo", - "description": "The label of the button to try again when the page crashed" - }, - "theme.NotFound.title": { - "message": "Página no encontrada", - "description": "The title of the 404 page" - }, - "theme.NotFound.p1": { - "message": "No pudimos encontrar lo que buscas.", - "description": "The first paragraph of the 404 page" - }, - "theme.NotFound.p2": { - "message": "Comuníquese con el propietario del sitio que lo asoció a la URL original e infórmele que su vínculo/enlace está roto.", - "description": "The 2nd paragraph of the 404 page" - }, - "theme.AnnouncementBar.closeButtonAriaLabel": { - "message": "Cerrar", - "description": "The ARIA label for close button of announcement bar" - }, - "theme.BackToTopButton.buttonAriaLabel": { - "message": "Volver arriba", - "description": "The ARIA label for the back to top button" - }, - "theme.blog.archive.title": { - "message": "Archivo", - "description": "The page & hero title of the blog archive page" - }, - "theme.blog.archive.description": { - "message": "Archivo", - "description": "The page & hero description of the blog archive page" - }, - "theme.blog.paginator.navAriaLabel": { - "message": "Paginación de la lista de artículos del blog.", - "description": "The ARIA label for the blog pagination" - }, - "theme.blog.paginator.newerEntries": { - "message": "Nuevas publicaciones", - "description": "The label used to navigate to the newer blog posts page (previous page)" - }, - "theme.blog.paginator.olderEntries": { - "message": "Artículos anteriores", - "description": "The label used to navigate to the older blog posts page (next page)" - }, - "theme.blog.post.readingTime.plurals": { - "message": "Un minuto de lectura|{readingTime} minutos de lectura", - "description": "Pluralized label for \"{readingTime} min read\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" - }, - "theme.blog.post.readMoreLabel": { - "message": "Más información sobre {title}", - "description": "The ARIA label for the link to full blog posts from excerpts" - }, - "theme.blog.post.readMore": { - "message": "Seguir leyendo", - "description": "The label used in blog post item excerpts to link to full blog posts" - }, - "theme.blog.post.paginator.navAriaLabel": { - "message": "Paginación de los artículos del blog.", - "description": "The ARIA label for the blog posts pagination" - }, - "theme.blog.post.paginator.newerPost": { - "message": "Siguiente", - "description": "The blog post button label to navigate to the newer/previous post" - }, - "theme.blog.post.paginator.olderPost": { - "message": "Anterior", - "description": "The blog post button label to navigate to the older/next post" - }, - "theme.blog.sidebar.navAriaLabel": { - "message": "Navegación por los últimos artículos del blog.", - "description": "The ARIA label for recent posts in the blog sidebar" - }, - "theme.blog.post.plurals": { - "message": "Un artículo \"{count} artículos", - "description": "Pluralized label for \"{count} posts\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" - }, - "theme.blog.tagTitle": { - "message": "Un resultado etiquetado con « {tagName} »|{nPosts} etiquetados con « {tagName} »", - "description": "The title of the page for a blog tag" - }, - "theme.tags.tagsPageLink": { - "message": "Ver todas las etiquetas", - "description": "The label of the link targeting the tag list page" - }, - "theme.CodeBlock.copyButtonAriaLabel": { - "message": "Copiar el código", - "description": "The ARIA label for copy code blocks button" - }, - "theme.CodeBlock.copied": { - "message": "Copiado", - "description": "The copied button label on code blocks" - }, - "theme.CodeBlock.copy": { - "message": "Copiar", - "description": "The copy button label on code blocks" - }, - "theme.colorToggle.ariaLabel": { - "message": "Cambiar entre modo claro y oscuro (tema actual: {mode})", - "description": "The ARIA label for the navbar color mode toggle" - }, - "theme.colorToggle.ariaLabel.mode.dark": { - "message": "Modo oscuro", - "description": "The name for the dark color mode" - }, - "theme.colorToggle.ariaLabel.mode.light": { - "message": "Modo claro", - "description": "The name for the light color mode" - }, - "theme.docs.DocCard.categoryDescription": { - "message": "un elemento|{count} elementos", - "description": "The default description for a category card in the generated index about how many items this category includes" - }, - "theme.docs.sidebar.expandButtonTitle": { - "message": "Mostrar menú lateral", - "description": "The ARIA label and title attribute for expand button of doc sidebar" - }, - "theme.docs.sidebar.expandButtonAriaLabel": { - "message": "Mostrar menú lateral", - "description": "The ARIA label and title attribute for expand button of doc sidebar" - }, - "theme.docs.paginator.navAriaLabel": { - "message": "Paginación de documentos", - "description": "The ARIA label for the docs pagination" - }, - "theme.docs.paginator.previous": { - "message": "Anterior", - "description": "The label used to navigate to the previous doc" - }, - "theme.docs.paginator.next": { - "message": "Siguiente", - "description": "The label used to navigate to the next doc" - }, - "theme.docs.sidebar.collapseButtonTitle": { - "message": "Ocultar menú lateral", - "description": "The title attribute for collapse button of doc sidebar" - }, - "theme.docs.sidebar.collapseButtonAriaLabel": { - "message": "Ocultar menú lateral", - "description": "The title attribute for collapse button of doc sidebar" - }, - "theme.DocSidebarItem.toggleCollapsedCategoryAriaLabel": { - "message": "Abrir/Cerrar categoría '{label}'", - "description": "The ARIA label to toggle the collapsible sidebar category" - }, - "theme.docs.tagDocListPageTitle.nDocsTagged": { - "message": "Un documento etiquetado|{count} documentos etiquetados", - "description": "Pluralized label for \"{count} docs tagged\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" - }, - "theme.docs.tagDocListPageTitle": { - "message": "{nDocsTagged} con \"{tagName}\"", - "description": "The title of the page for a docs tag" - }, - "theme.docs.versionBadge.label": { - "message": "Version: {versionLabel}" - }, - "theme.common.editThisPage": { - "message": "Editar esta página", - "description": "The link label to edit the current page" - }, - "theme.docs.versions.unreleasedVersionLabel": { - "message": "Esta es la documentación para la próxima versión {versionLabel} de {siteTitle}.", - "description": "The label used to tell the user that he's browsing an unreleased doc version" - }, - "theme.docs.versions.unmaintainedVersionLabel": { - "message": "Esta es la documentación para {siteTitle} {versionLabel} que ya no se mantiene activamente.", - "description": "The label used to tell the user that he's browsing an unmaintained doc version" - }, - "theme.docs.versions.latestVersionSuggestionLabel": { - "message": "Para obtener documentación actualizada, consulte {latestVersionLink} ({versionLabel}).", - "description": "The label used to tell the user to check the latest version" - }, - "theme.docs.versions.latestVersionLinkLabel": { - "message": "última versión", - "description": "The label used for the latest version suggestion link label" - }, - "theme.common.headingLinkTitle": { - "message": "Enlace directo al título", - "description": "Title for link to heading" - }, - "theme.lastUpdated.atDate": { - "message": " el {date}", - "description": "The words used to describe on which date a page has been last updated" - }, - "theme.lastUpdated.byUser": { - "message": " por {user}", - "description": "The words used to describe by who the page has been last updated" - }, - "theme.lastUpdated.lastUpdatedAtBy": { - "message": "Última actualización{atDate}{byUser}", - "description": "The sentence used to display when a page has been last updated, and by who" - }, - "theme.navbar.mobileSidebarSecondaryMenu.backButtonLabel": { - "message": "← Volver al menú principal", - "description": "The label of the back button to return to main menu, inside the mobile navbar sidebar secondary menu (notably used to display the docs sidebar)" - }, - "theme.navbar.mobileVersionsDropdown.label": { - "message": "Versiones", - "description": "The label for the navbar versions dropdown on mobile view" - }, - "theme.common.skipToMainContent": { - "message": "Ir al contenido principal", - "description": "The skip to content label used for accessibility, allowing to rapidly navigate to main content with keyboard tab/enter navigation" - }, - "theme.TOCCollapsible.toggleButtonLabel": { - "message": "En esta página", - "description": "The label used by the button on the collapsible TOC component" - }, - "theme.tags.tagsListLabel": { - "message": "Etiquetas:", - "description": "The label alongside a tag list" - }, - "theme.navbar.mobileLanguageDropdown.label": { - "message": "Idiomas", - "description": "The label for the mobile language switcher dropdown" - }, - "theme.SearchBar.seeAll": { - "message": "Ver todos los resultados ({count})" - }, - "theme.SearchBar.label": { - "message": "Buscar en", - "description": "The ARIA label and placeholder for search button" - }, - "theme.SearchPage.documentsFound.plurals": { - "message": "Un documento encontrado | {count} documentos encontrados", - "description": "Pluralized label for \"{count} documents found\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" - }, - "theme.SearchPage.existingResultsTitle": { - "message": "Resultados de la búsqueda « {query} »", - "description": "The search page title for non-empty query" - }, - "theme.SearchPage.emptyResultsTitle": { - "message": "Buscar en la documentación", - "description": "The search page title for empty query" - }, - "theme.SearchPage.inputPlaceholder": { - "message": "Introduzca su búsqueda aquí", - "description": "The placeholder for search page input" - }, - "theme.SearchPage.inputLabel": { - "message": "Buscar", - "description": "The ARIA label for search page input" - }, - "theme.SearchPage.algoliaLabel": { - "message": "Búsqueda por Algolia", - "description": "The ARIA label for Algolia mention" - }, - "theme.SearchPage.noResultsText": { - "message": "No se han encontrado resultados", - "description": "The paragraph for empty search result" - }, - "theme.SearchPage.fetchingNewResults": { - "message": "Cargando nuevos resultados...", - "description": "The paragraph for fetching new search results" - }, - "theme.tags.tagsPageTitle": { - "message": "Etiquetas", - "description": "The title of the tag list page" - }, - "homepage.tagline": { - "message": "Manual del usuario, conceptos clave y referencia API" - }, - "homepage.featureList.secure.title": { - "message": "Seguridad", - "description": "Hydra heads' first highlight: security." - }, - "homepage.featureList.secure.tagline": { - "message": "Mantén el control y gasta sólo lo que hayas acordado expresamente.", - "description": "Tagline for the 'secure' property." - }, - "homepage.featureList.fast.title": { - "message": "Rápido", - "description": "Hydra heads' second highlight: swiftness." - }, - "homepage.featureList.fast.tagline": { - "message": "Confirme las transacciones casi al instante.", - "description": "Tagline for the 'fast' property." - }, - "homepage.featureList.isomorphic.title": { - "message": "Isomorfo", - "description": "Hydra heads' third highlight: isomorphism." - }, - "homepage.featureList.isomorphic.tagline": { - "message": "Aproveche las capacidades, interfaces y seguridades de la capa uno de Cardano.", - "description": "Tagline for the 'isomorphic' property." - }, - "homepage.gettingStarted": { - "message": "Primeros pasos - 5min ⏱️", - "description": "'Getting Started' button in the home header." - } -} diff --git a/docs/i18n/es/docusaurus-plugin-content-blog/options.json b/docs/i18n/es/docusaurus-plugin-content-blog/options.json deleted file mode 100644 index 3b483c2a876..00000000000 --- a/docs/i18n/es/docusaurus-plugin-content-blog/options.json +++ /dev/null @@ -1,14 +0,0 @@ -{ - "title": { - "message": "Decisiones de arquitectura", - "description": "The title for the blog used in SEO" - }, - "description": { - "message": "Documentación técnica resumida de las principales decisiones relativas al desarrollo del nodo Hydra.", - "description": "The description for the blog used in SEO" - }, - "sidebar.title": { - "message": "Decisiones de arquitectura", - "description": "The label for the left sidebar" - } -} diff --git a/docs/i18n/es/docusaurus-plugin-content-docs-benchmarks/current.json b/docs/i18n/es/docusaurus-plugin-content-docs-benchmarks/current.json deleted file mode 100644 index 2e8b68341db..00000000000 --- a/docs/i18n/es/docusaurus-plugin-content-docs-benchmarks/current.json +++ /dev/null @@ -1,6 +0,0 @@ -{ - "version.label": { - "message": "Siguiente", - "description": "The label for version current" - } -} diff --git a/docs/i18n/es/docusaurus-plugin-content-docs-core-concepts/current.json b/docs/i18n/es/docusaurus-plugin-content-docs-core-concepts/current.json deleted file mode 100644 index 2e8b68341db..00000000000 --- a/docs/i18n/es/docusaurus-plugin-content-docs-core-concepts/current.json +++ /dev/null @@ -1,6 +0,0 @@ -{ - "version.label": { - "message": "Siguiente", - "description": "The label for version current" - } -} diff --git a/docs/i18n/es/docusaurus-plugin-content-docs-topologies/current.json b/docs/i18n/es/docusaurus-plugin-content-docs-topologies/current.json deleted file mode 100644 index 2e8b68341db..00000000000 --- a/docs/i18n/es/docusaurus-plugin-content-docs-topologies/current.json +++ /dev/null @@ -1,6 +0,0 @@ -{ - "version.label": { - "message": "Siguiente", - "description": "The label for version current" - } -} diff --git a/docs/i18n/es/docusaurus-plugin-content-docs/current.json b/docs/i18n/es/docusaurus-plugin-content-docs/current.json deleted file mode 100644 index b00ac783c05..00000000000 --- a/docs/i18n/es/docusaurus-plugin-content-docs/current.json +++ /dev/null @@ -1,14 +0,0 @@ -{ - "version.label": { - "message": "Siguiente", - "description": "The label for version current" - }, - "sidebar.defaultSidebar.category.Getting Started": { - "message": "Primeros pasos", - "description": "The label for category Getting Started in sidebar defaultSidebar" - }, - "sidebar.defaultSidebar.category.Demo": { - "message": "Demo", - "description": "The label for category Demo in sidebar defaultSidebar" - } -} diff --git a/docs/i18n/es/docusaurus-theme-classic/footer.json b/docs/i18n/es/docusaurus-theme-classic/footer.json deleted file mode 100644 index 3a917a7015d..00000000000 --- a/docs/i18n/es/docusaurus-theme-classic/footer.json +++ /dev/null @@ -1,54 +0,0 @@ -{ - "link.title.Contributing": { - "message": "Contribuir", - "description": "The title of the footer links column with title=Contributing in the footer" - }, - "link.title.Community": { - "message": "Comunidad", - "description": "The title of the footer links column with title=Community in the footer" - }, - "link.title.More": { - "message": "Más", - "description": "The title of the footer links column with title=More in the footer" - }, - "link.item.label.Coding Standards": { - "message": "Estándares de programación", - "description": "The label of footer link with label=Coding Standards linking to https://github.com/input-output-hk/hydra/wiki/Coding-Standards" - }, - "link.item.label.Architectural Decision Records": { - "message": "Decisiones de arquitectura", - "description": "The label of footer link with label=Architectural Decision Records linking to /adr" - }, - "link.item.label.Testing Strategy": { - "message": "Control de calidad", - "description": "The label of footer link with label=Testing Strategy linking to https://github.com/input-output-hk/hydra/wiki/Testing-Strategy" - }, - "link.item.label.Discord (#ask-hydra)": { - "message": "Discord (#ask-hydra)", - "description": "The label of footer link with label=Discord (#ask-hydra) linking to https://discord.gg/Qq5vNTg9PT" - }, - "link.item.label.Github Discussions": { - "message": "Discusiones en Github", - "description": "The label of footer link with label=Github Discussions linking to https://github.com/input-output-hk/hydra/discussions" - }, - "link.item.label.Stack Exchange": { - "message": "Stack Exchange", - "description": "The label of footer link with label=Stack Exchange linking to https://cardano.stackexchange.com/questions/tagged/hydra" - }, - "link.item.label.Haskell Packages": { - "message": "Librerías de Haskell", - "description": "The label of footer link with label=Haskell Packages linking to /docs/haskell_packages" - }, - "link.item.label.Logbook": { - "message": "Bitácora", - "description": "The label of footer link with label=Logbook linking to https://github.com/input-output-hk/hydra/wiki/Logbook" - }, - "link.item.label.Input Output (Blog)": { - "message": "Input Output (Blog)", - "description": "The label of footer link with label=Input Output (Blog) linking to https://iohk.io/en/blog" - }, - "copyright": { - "message": "Copyright © 2022 Input Output
Sitio realizado con Docusaurus", - "description": "The footer copyright" - } -} diff --git a/docs/i18n/es/docusaurus-theme-classic/navbar.json b/docs/i18n/es/docusaurus-theme-classic/navbar.json deleted file mode 100644 index 86e899f0325..00000000000 --- a/docs/i18n/es/docusaurus-theme-classic/navbar.json +++ /dev/null @@ -1,34 +0,0 @@ -{ - "title": { - "message": "Hydra: Head Protocol", - "description": "The title in the navbar" - }, - "item.label.User Manual": { - "message": "Manuel de usuario", - "description": "Navbar item with label User Manual" - }, - "item.label.Core Concepts": { - "message": "Conceptos principales", - "description": "Navbar item with label Core Concepts" - }, - "item.label.Topologies": { - "message": "Topologias", - "description": "Navbar item with label Topologies" - }, - "item.label.Benchmarks": { - "message": "Benchmarks", - "description": "Navbar item with label Benchmarks" - }, - "item.label.API Reference": { - "message": "API de referencia", - "description": "Navbar item with label API Reference" - }, - "item.label.GitHub": { - "message": "GitHub", - "description": "Navbar item with label GitHub" - }, - "item.label.Use Cases": { - "message": "Casos de uso", - "description": "Navbar item with label Use Cases" - } -} diff --git a/docs/i18n/fr/code.json b/docs/i18n/fr/code.json deleted file mode 100644 index 16da612fb20..00000000000 --- a/docs/i18n/fr/code.json +++ /dev/null @@ -1,295 +0,0 @@ -{ - "theme.ErrorPageContent.title": { - "message": "Cette page a planté.", - "description": "The title of the fallback page when the page crashed" - }, - "theme.ErrorPageContent.tryAgain": { - "message": "Réessayer", - "description": "The label of the button to try again when the page crashed" - }, - "theme.NotFound.title": { - "message": "Page introuvable", - "description": "The title of the 404 page" - }, - "theme.NotFound.p1": { - "message": "Nous n'avons pas trouvé ce que vous recherchez.", - "description": "The first paragraph of the 404 page" - }, - "theme.NotFound.p2": { - "message": "Veuillez contacter le propriétaire du site qui vous a lié à l'URL d'origine et leur faire savoir que leur lien est cassé.", - "description": "The 2nd paragraph of the 404 page" - }, - "theme.AnnouncementBar.closeButtonAriaLabel": { - "message": "Fermer", - "description": "The ARIA label for close button of announcement bar" - }, - "theme.BackToTopButton.buttonAriaLabel": { - "message": "Revenez en haut", - "description": "The ARIA label for the back to top button" - }, - "theme.blog.archive.title": { - "message": "Archive", - "description": "The page & hero title of the blog archive page" - }, - "theme.blog.archive.description": { - "message": "Archive", - "description": "The page & hero description of the blog archive page" - }, - "theme.blog.paginator.navAriaLabel": { - "message": "Pagination de la liste des articles du blog", - "description": "The ARIA label for the blog pagination" - }, - "theme.blog.paginator.newerEntries": { - "message": "Nouvelles entrées", - "description": "The label used to navigate to the newer blog posts page (previous page)" - }, - "theme.blog.paginator.olderEntries": { - "message": "Anciennes entrées", - "description": "The label used to navigate to the older blog posts page (next page)" - }, - "theme.blog.post.readingTime.plurals": { - "message": "Une minute de lecture|{readingTime} minutes de lecture", - "description": "Pluralized label for \"{readingTime} min read\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" - }, - "theme.blog.post.readMoreLabel": { - "message": "En savoir plus sur {title}", - "description": "The ARIA label for the link to full blog posts from excerpts" - }, - "theme.blog.post.readMore": { - "message": "Lire plus", - "description": "The label used in blog post item excerpts to link to full blog posts" - }, - "theme.blog.post.paginator.navAriaLabel": { - "message": "Pagination des articles du blog", - "description": "The ARIA label for the blog posts pagination" - }, - "theme.blog.post.paginator.newerPost": { - "message": "Suivant", - "description": "The blog post button label to navigate to the newer/previous post" - }, - "theme.blog.post.paginator.olderPost": { - "message": "Précédent", - "description": "The blog post button label to navigate to the older/next post" - }, - "theme.blog.sidebar.navAriaLabel": { - "message": "Navigation article de blog récent", - "description": "The ARIA label for recent posts in the blog sidebar" - }, - "theme.blog.post.plurals": { - "message": "Un article|{count} articles", - "description": "Pluralized label for \"{count} posts\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" - }, - "theme.blog.tagTitle": { - "message": "Un résultat étiquetté avec « {tagName} »|{nPosts} étiquettés avec « {tagName} »", - "description": "The title of the page for a blog tag" - }, - "theme.tags.tagsPageLink": { - "message": "Voir tous les tags", - "description": "The label of the link targeting the tag list page" - }, - "theme.CodeBlock.copyButtonAriaLabel": { - "message": "Copier le code", - "description": "The ARIA label for copy code blocks button" - }, - "theme.CodeBlock.copied": { - "message": "Copié", - "description": "The copied button label on code blocks" - }, - "theme.CodeBlock.copy": { - "message": "Copier", - "description": "The copy button label on code blocks" - }, - "theme.colorToggle.ariaLabel": { - "message": "Basculer entre thème clair ou sombre (theme actuel: {mode})", - "description": "The ARIA label for the navbar color mode toggle" - }, - "theme.colorToggle.ariaLabel.mode.dark": { - "message": "Thème sombre", - "description": "The name for the dark color mode" - }, - "theme.colorToggle.ariaLabel.mode.light": { - "message": "Thème clair", - "description": "The name for the light color mode" - }, - "theme.docs.DocCard.categoryDescription": { - "message": "un élément|{count} éléments", - "description": "The default description for a category card in the generated index about how many items this category includes" - }, - "theme.docs.sidebar.expandButtonTitle": { - "message": "Afficher le menu latéral", - "description": "The ARIA label and title attribute for expand button of doc sidebar" - }, - "theme.docs.sidebar.expandButtonAriaLabel": { - "message": "Afficher le menu latéral", - "description": "The ARIA label and title attribute for expand button of doc sidebar" - }, - "theme.docs.paginator.navAriaLabel": { - "message": "Pagination des documents", - "description": "The ARIA label for the docs pagination" - }, - "theme.docs.paginator.previous": { - "message": "Précédent", - "description": "The label used to navigate to the previous doc" - }, - "theme.docs.paginator.next": { - "message": "Suivant", - "description": "The label used to navigate to the next doc" - }, - "theme.docs.sidebar.collapseButtonTitle": { - "message": "Cacher le menu latéral", - "description": "The title attribute for collapse button of doc sidebar" - }, - "theme.docs.sidebar.collapseButtonAriaLabel": { - "message": "Cacher le menu latéral", - "description": "The title attribute for collapse button of doc sidebar" - }, - "theme.DocSidebarItem.toggleCollapsedCategoryAriaLabel": { - "message": "Ouvrir/Fermer la catégorie '{label}'", - "description": "The ARIA label to toggle the collapsible sidebar category" - }, - "theme.docs.tagDocListPageTitle.nDocsTagged": { - "message": "Un document étiquetté|{count} documents étiquettés", - "description": "Pluralized label for \"{count} docs tagged\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" - }, - "theme.docs.tagDocListPageTitle": { - "message": "{nDocsTagged} avec \"{tagName}\"", - "description": "The title of the page for a docs tag" - }, - "theme.docs.versionBadge.label": { - "message": "Version: {versionLabel}" - }, - "theme.common.editThisPage": { - "message": "Éditer cette page", - "description": "The link label to edit the current page" - }, - "theme.docs.versions.unreleasedVersionLabel": { - "message": "Ceci est la documentation de la prochaine version {versionLabel} de {siteTitle}.", - "description": "The label used to tell the user that he's browsing an unreleased doc version" - }, - "theme.docs.versions.unmaintainedVersionLabel": { - "message": "Ceci est la documentation de {siteTitle} {versionLabel} qui n'est plus activement maintenue.", - "description": "The label used to tell the user that he's browsing an unmaintained doc version" - }, - "theme.docs.versions.latestVersionSuggestionLabel": { - "message": "Pour une documentation à jour, consultez la {latestVersionLink} ({versionLabel}).", - "description": "The label used to tell the user to check the latest version" - }, - "theme.docs.versions.latestVersionLinkLabel": { - "message": "dernière version", - "description": "The label used for the latest version suggestion link label" - }, - "theme.common.headingLinkTitle": { - "message": "Lien direct vers le titre", - "description": "Title for link to heading" - }, - "theme.lastUpdated.atDate": { - "message": " le {date}", - "description": "The words used to describe on which date a page has been last updated" - }, - "theme.lastUpdated.byUser": { - "message": " par {user}", - "description": "The words used to describe by who the page has been last updated" - }, - "theme.lastUpdated.lastUpdatedAtBy": { - "message": "Dernière mise à jour{atDate}{byUser}", - "description": "The sentence used to display when a page has been last updated, and by who" - }, - "theme.navbar.mobileSidebarSecondaryMenu.backButtonLabel": { - "message": "← Retour au menu principal", - "description": "The label of the back button to return to main menu, inside the mobile navbar sidebar secondary menu (notably used to display the docs sidebar)" - }, - "theme.navbar.mobileVersionsDropdown.label": { - "message": "Versions", - "description": "The label for the navbar versions dropdown on mobile view" - }, - "theme.common.skipToMainContent": { - "message": "Aller au contenu principal", - "description": "The skip to content label used for accessibility, allowing to rapidly navigate to main content with keyboard tab/enter navigation" - }, - "theme.TOCCollapsible.toggleButtonLabel": { - "message": "Sur cette page", - "description": "The label used by the button on the collapsible TOC component" - }, - "theme.tags.tagsListLabel": { - "message": "Étiquettes :", - "description": "The label alongside a tag list" - }, - "theme.navbar.mobileLanguageDropdown.label": { - "message": "Langues", - "description": "The label for the mobile language switcher dropdown" - }, - "theme.SearchBar.seeAll": { - "message": "Voir tous les résultats ({count})" - }, - "theme.SearchBar.label": { - "message": "Chercher", - "description": "The ARIA label and placeholder for search button" - }, - "theme.SearchPage.documentsFound.plurals": { - "message": "Un document trouvé|{count} documents trouvés", - "description": "Pluralized label for \"{count} documents found\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" - }, - "theme.SearchPage.existingResultsTitle": { - "message": "Résultats de recherche pour « {query} »", - "description": "The search page title for non-empty query" - }, - "theme.SearchPage.emptyResultsTitle": { - "message": "Rechercher dans la documentation", - "description": "The search page title for empty query" - }, - "theme.SearchPage.inputPlaceholder": { - "message": "Indiquez votre recherche ici", - "description": "The placeholder for search page input" - }, - "theme.SearchPage.inputLabel": { - "message": "Chercher", - "description": "The ARIA label for search page input" - }, - "theme.SearchPage.algoliaLabel": { - "message": "Recherche par Algolia", - "description": "The ARIA label for Algolia mention" - }, - "theme.SearchPage.noResultsText": { - "message": "Aucun résultat trouvé", - "description": "The paragraph for empty search result" - }, - "theme.SearchPage.fetchingNewResults": { - "message": "Chargement de nouveaux résultats...", - "description": "The paragraph for fetching new search results" - }, - "theme.tags.tagsPageTitle": { - "message": "Étiquettes", - "description": "The title of the tag list page" - }, - "homepage.tagline": { - "message": "Manuel utilisateur, concepts clés et référence d'API" - }, - "homepage.featureList.secure.title": { - "message": "Sécurisé", - "description": "Hydra heads' first highlight: security." - }, - "homepage.featureList.secure.tagline": { - "message": "Gardez le contrôle et ne dépensez que ce pour quoi vous avez expressément donné votre accord.", - "description": "Tagline for the 'secure' property." - }, - "homepage.featureList.fast.title": { - "message": "Rapide", - "description": "Hydra heads' second highlight: swiftness." - }, - "homepage.featureList.fast.tagline": { - "message": "Confirmez les transactions au sein de façon quasi-instantanée.", - "description": "Tagline for the 'fast' property." - }, - "homepage.featureList.isomorphic.title": { - "message": "Isomorphique", - "description": "Hydra heads' third highlight: isomorphism." - }, - "homepage.featureList.isomorphic.tagline": { - "message": "Tirez parti des aptitudes, interfaces et sécurités du ledger Cardano.", - "description": "Tagline for the 'isomorphic' property." - }, - "homepage.gettingStarted": { - "message": "Prise en main - 5min ⏱️", - "description": "'Getting Started' button in the home header." - } -} diff --git a/docs/i18n/fr/docusaurus-plugin-content-blog/options.json b/docs/i18n/fr/docusaurus-plugin-content-blog/options.json deleted file mode 100644 index 222c7a8b7c9..00000000000 --- a/docs/i18n/fr/docusaurus-plugin-content-blog/options.json +++ /dev/null @@ -1,14 +0,0 @@ -{ - "title": { - "message": "Décisions Architecturales", - "description": "The title for the blog used in SEO" - }, - "description": { - "message": "Documentation technique succincte des décisions majeurs relatives au développement du noeud Hydra.", - "description": "The description for the blog used in SEO" - }, - "sidebar.title": { - "message": "Décisions Architecturales", - "description": "The label for the left sidebar" - } -} diff --git a/docs/i18n/fr/docusaurus-plugin-content-docs-benchmarks/current.json b/docs/i18n/fr/docusaurus-plugin-content-docs-benchmarks/current.json deleted file mode 100644 index d964b7fa610..00000000000 --- a/docs/i18n/fr/docusaurus-plugin-content-docs-benchmarks/current.json +++ /dev/null @@ -1,6 +0,0 @@ -{ - "version.label": { - "message": "Suivant", - "description": "The label for version current" - } -} diff --git a/docs/i18n/fr/docusaurus-plugin-content-docs-core-concepts/current.json b/docs/i18n/fr/docusaurus-plugin-content-docs-core-concepts/current.json deleted file mode 100644 index d964b7fa610..00000000000 --- a/docs/i18n/fr/docusaurus-plugin-content-docs-core-concepts/current.json +++ /dev/null @@ -1,6 +0,0 @@ -{ - "version.label": { - "message": "Suivant", - "description": "The label for version current" - } -} diff --git a/docs/i18n/fr/docusaurus-plugin-content-docs-topologies/current.json b/docs/i18n/fr/docusaurus-plugin-content-docs-topologies/current.json deleted file mode 100644 index d964b7fa610..00000000000 --- a/docs/i18n/fr/docusaurus-plugin-content-docs-topologies/current.json +++ /dev/null @@ -1,6 +0,0 @@ -{ - "version.label": { - "message": "Suivant", - "description": "The label for version current" - } -} diff --git a/docs/i18n/fr/docusaurus-plugin-content-docs/current.json b/docs/i18n/fr/docusaurus-plugin-content-docs/current.json deleted file mode 100644 index 49fdaeb09af..00000000000 --- a/docs/i18n/fr/docusaurus-plugin-content-docs/current.json +++ /dev/null @@ -1,14 +0,0 @@ -{ - "version.label": { - "message": "Suivant", - "description": "The label for version current" - }, - "sidebar.defaultSidebar.category.Getting Started": { - "message": "Prise en main", - "description": "The label for category Getting Started in sidebar defaultSidebar" - }, - "sidebar.defaultSidebar.category.Demo": { - "message": "Démo", - "description": "The label for category Demo in sidebar defaultSidebar" - } -} diff --git a/docs/i18n/fr/docusaurus-plugin-content-docs/current/getting-started/_category_.json b/docs/i18n/fr/docusaurus-plugin-content-docs/current/getting-started/_category_.json deleted file mode 100644 index 062399566e7..00000000000 --- a/docs/i18n/fr/docusaurus-plugin-content-docs/current/getting-started/_category_.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "label": "Prise en main", - "position": 1 -} diff --git a/docs/i18n/fr/docusaurus-plugin-content-docs/current/getting-started/demo/_category_.json b/docs/i18n/fr/docusaurus-plugin-content-docs/current/getting-started/demo/_category_.json deleted file mode 100644 index e834ed3253e..00000000000 --- a/docs/i18n/fr/docusaurus-plugin-content-docs/current/getting-started/demo/_category_.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "label": "Démo", - "position": 4 -} diff --git a/docs/i18n/fr/docusaurus-plugin-content-docs/current/getting-started/demo/index.md b/docs/i18n/fr/docusaurus-plugin-content-docs/current/getting-started/demo/index.md deleted file mode 100644 index 80de1f4ed30..00000000000 --- a/docs/i18n/fr/docusaurus-plugin-content-docs/current/getting-started/demo/index.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -sidebar_position: 1 ---- - -# Démo - -> Ce document détaille les étapes nécessaires pour faire tourner une Hydra Head dans un environment de démo, avec Docker. - -La démo comprend: - -- un cluster de trois noeuds Hydra, connectés point-à-point, et ayant chacun une identité (`alice`, `bob`, `carol`) associée à une paire de clés publique/privée; -- un noeud Cardano, en mode BFT, produisant des blocs et formant a lui seul un réseau Cardano pour le développement local ; -- un serveur Prometheus pour des métriques ; -- une interface utilisateur dans le terminal pour se connecter et opérer chaque noeud Hydra. - -```mdx-code-block -import DocCardList from '@theme/DocCardList'; -import {useCurrentSidebarCategory} from '@docusaurus/theme-common'; - - -``` - - - -

- -:::caution Avant-propos -Cette vidéo montre une interface utilisateur au sein d'un terminal. En coulisse, l'application cliente se connecte à un noeud Hydra local au moyen d'une WebSocket comme n'importe quelle application cliente souhaitant intéragir avec un noeud Hydra le ferait. Autrement dit, bien qu'il ne s'agisse pas d'un exemple des plus palpitants, c'est néanmoins un exemple possible et plausible d'application cliente. -::: diff --git a/docs/i18n/fr/docusaurus-plugin-content-docs/current/getting-started/demo/with-docker.md b/docs/i18n/fr/docusaurus-plugin-content-docs/current/getting-started/demo/with-docker.md deleted file mode 100644 index 0f8b273d961..00000000000 --- a/docs/i18n/fr/docusaurus-plugin-content-docs/current/getting-started/demo/with-docker.md +++ /dev/null @@ -1,85 +0,0 @@ ---- -sidebar_position: 2 ---- - -# Via Docker - -```mdx-code-block -import TerminalWindow from '@site/src/components/TerminalWindow'; -``` - -Nous utiliserons [Docker](https://www.docker.com/get-started) et [compose](https://www.docker.com/get-started) pour cette démo, assurez-vous de les avoir disponibles dans votre terminal de commandes. Si vous ne souhaitez pas utiliser ou installer Docker, vous pouvez directement vous rendre sur [Démo: Sans Docker](/docs/getting-started/demo/without-docker) et mettre les mains dans le cambouis. - -:::info Shortcut -Toutes ces étapes sont combinées dans un unique script `./run-docker.sh`. Ce script contient aussi quelques petites vérifications pour éviter de vous tirer une balle dans le pied avec certaines commandes. -::: - -:::info Contexte -Toutes les commandes ci-dessous supposent qu'elles sont éxecutées depuis le dossier `demo/`, à la racine du dépôt. Vous aurez donc besoin de cloner le dépôt et de `cd demo` avant d'aller plus loin. -::: - -:::warning (in)compatibilité du système d'exploitation -Les instructions fournies ci-après ont été testées pour des environnements Linux récents (Ubuntu, ArchLinux, NixOS...). Si vous êtes sur Windows ou MacOS vous aurez sans doute besoin d'ajuster certaines commandes liées aux [volumes](https://docs.docker.com/storage/volumes/). -::: - -## Mise en place du réseau - -Pour commencer, récupérez les images des différents services définis dans le fichier compose: - -```mdx-code-block - -docker-compose --profile tui --profile hydra-node pull - -``` - -Ensuite, vous pouvez exécuter le script `./prepare-devnet.sh` pour créer les fichiers nécessaires à la configuration du réseau local (a.k.a devnet). Le script génère une configuration _genesis_ Cardano (qui fixe les paramètres du protocole). Notez que dans le cadre de cette démo, la configuration du réseau n'utilise pas de _stake pool_ et ne requiert qu'un unique noeud pour fonctionner. - -```mdx-code-block - -./prepare-devnet.sh - -``` - -C'est tout. Il est maintenant possible de démarrer le cardano node via: - -```mdx-code-block - -docker-compose up -d cardano-node - -``` - -:::caution Avertissement! -Le noeud Cardano crée un "réseau" privé et local qui démarre depuis un bloc _genesis_. Pour démarrer, la configuration du noeud doit être à jour (comprendre, récente). Si au démarrage, le noeud Cardano retourne `TraceNoLedgerView`, alors c'est que l'heure de démarrage indiquée dans la configuration génésis est trop loin dans le passé: il faut en ce cas générer la configuration à nouveau via `prepare-devnet.sh`. -::: - -## Générer des fonds - -Parmi les fichiers, vous trouverez un script `./seed-devnet.sh` qui s'occupe de générer ces UTxOs pour chaque participant en utilisant la `cardano-cli`. - -```mdx-code-block - -./seed-devnet.sh - -``` - -## Démarrage des nœuds Hydra - -Enfin, maintenant que les préparations en chaîne sont prêtes, nous pouvons mettre en place le réseau Hydra (c'est-à-dire les trois nœuds pour Alice, Bob et Carol) en exécutant: - -```mdx-code-block - -docker-compose --profile hydra-node up -d - -``` - -## Utiliser l'interface client - -À l'aide de compose, vous pouvez démarrer les interfaces clientes (a.k.a `hydra-tui`) pour interagir avec chaque noeud Hydra. Le fichier compose contient déjà trois services pré-configurés: `hydra-tui-1`, `hydra-tui-2`, and `hydra-tui-3`. Pour démarrer le premier client, utilisez simplement: - -```mdx-code-block - -docker-compose --profile tui run hydra-tui-1 - -``` - -Cette commande lance une interface utilisateur dans le terminal, configurée avec les clés du premier noeud (i.e. Alice). Dans d'autres terminaux, vous pouvez lancer de la même façon `hydra-tui-2` et `hydra-tui-3`. diff --git a/docs/i18n/fr/docusaurus-plugin-content-docs/current/getting-started/index.md b/docs/i18n/fr/docusaurus-plugin-content-docs/current/getting-started/index.md deleted file mode 100644 index dde7642ad96..00000000000 --- a/docs/i18n/fr/docusaurus-plugin-content-docs/current/getting-started/index.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -sidebar_position: 1 ---- - -# Prise en main - -```mdx-code-block -import DocCardList from '@theme/DocCardList'; -import {useCurrentSidebarCategory} from '@docusaurus/theme-common'; - - -``` diff --git a/docs/i18n/fr/docusaurus-plugin-content-docs/current/haskell_packages.md b/docs/i18n/fr/docusaurus-plugin-content-docs/current/haskell_packages.md deleted file mode 100644 index 39becfb56c4..00000000000 --- a/docs/i18n/fr/docusaurus-plugin-content-docs/current/haskell_packages.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -sidebar_position: 99 ---- - -# Bibliothèques Haskell - -Le projet est organisé en différente bibliothèques de code. Parmi celles-ci, certaines remplissent des fonctions spécifiques au projet et sont donc difficilement réutilisables dans un autre contexte; mais d'autres sont suffisamment génériques ou détachées du projet pour être utilisées telles quelles au sein d'autres projets Haskell. Dans un cas comme dans l'autre toutefois, nous mettons à disposition une [documentation Haddock](https://www.haskell.org/haddock/). Les listes ci-après fournissent un résumé sommaire des bibliothèques disponibles et de leur contenu. - -## Bibliothèques publiques / réutilisables - -| Nom | Description | -| --- | --- | -| [plutus-merkle-tree](/haddock/plutus-merkle-tree/index.html) | Implémentation des arbres de Merkle, compatible avec les scripts Plutus | -| [plutus-cbor](/haddock/plutus-cbor/index.html) | Implementation du format d'encodage CBOR, compatible avec les scripts Plutus | -| [hydra-prelude](/haddock/hydra-prelude/index.html) | Un remplacement de la Prelude de base Haskell, basée sur relude | -| [hydra-cardano-api](/haddock/hydra-cardano-api/index.html) | Une sur-couche de la `cardano-api`, avec de nouveaux utilitaires et specialisée à une seule ère (Alonzo) | - -## Bibliothèques internes - -| Nom | Description | -| --- | --- | -| [hydra-node](/haddock/hydra-node/index.html) | Le coeur du noeud Hydra | -| [hydra-node tests](/haddock/hydra-node/tests/index.html) | Des utilitaires pour tester le noeud Hydra | -| [hydra-tui](/haddock/hydra-tui/index.html) | L'interface utilisateur dans le terminal pour la démo des noeuds Hydra | -| [hydra-plutus](/haddock/hydra-plutus/index.html) | Le code Plutus des contrats / scripts Hydra | -| [hydra-cluster](/haddock/hydra-cluster/index.html) | Tests d'intégration et utilitaires pour démarrer un noeud Cardano local | \ No newline at end of file diff --git a/docs/i18n/fr/docusaurus-theme-classic/footer.json b/docs/i18n/fr/docusaurus-theme-classic/footer.json deleted file mode 100644 index 4384abf282f..00000000000 --- a/docs/i18n/fr/docusaurus-theme-classic/footer.json +++ /dev/null @@ -1,54 +0,0 @@ -{ - "link.title.Contributing": { - "message": "Contribuer", - "description": "The title of the footer links column with title=Contributing in the footer" - }, - "link.title.Community": { - "message": "Communauté", - "description": "The title of the footer links column with title=Community in the footer" - }, - "link.title.More": { - "message": "Divers", - "description": "The title of the footer links column with title=More in the footer" - }, - "link.item.label.Coding Standards": { - "message": "Conventions de programmation", - "description": "The label of footer link with label=Coding Standards linking to https://github.com/input-output-hk/hydra/wiki/Coding-Standards" - }, - "link.item.label.Architectural Decision Records": { - "message": "Décisions Architecturales", - "description": "The label of footer link with label=Architectural Decision Records linking to /adr" - }, - "link.item.label.Testing Strategy": { - "message": "Contrôle qualité", - "description": "The label of footer link with label=Testing Strategy linking to https://github.com/input-output-hk/hydra/wiki/Testing-Strategy" - }, - "link.item.label.Discord (#ask-hydra)": { - "message": "Discord (#ask-hydra)", - "description": "The label of footer link with label=Discord (#ask-hydra) linking to https://discord.gg/Qq5vNTg9PT" - }, - "link.item.label.Github Discussions": { - "message": "Github Discussions", - "description": "The label of footer link with label=Github Discussions linking to https://github.com/input-output-hk/hydra/discussions" - }, - "link.item.label.Stack Exchange": { - "message": "Stack Exchange", - "description": "The label of footer link with label=Stack Exchange linking to https://cardano.stackexchange.com/questions/tagged/hydra" - }, - "link.item.label.Haskell Packages": { - "message": "Bibliothèques Haskell", - "description": "The label of footer link with label=Haskell Packages linking to /docs/haskell_packages" - }, - "link.item.label.Logbook": { - "message": "Journal de bord", - "description": "The label of footer link with label=Logbook linking to https://github.com/input-output-hk/hydra/wiki/Logbook" - }, - "link.item.label.Input Output (Blog)": { - "message": "Input Output (Blog)", - "description": "The label of footer link with label=Input Output (Blog) linking to https://iohk.io/en/blog" - }, - "copyright": { - "message": "Copyright © 2022 Input Output
Site réalisé avec Docusaurus", - "description": "The footer copyright" - } -} diff --git a/docs/i18n/fr/docusaurus-theme-classic/navbar.json b/docs/i18n/fr/docusaurus-theme-classic/navbar.json deleted file mode 100644 index 4bca11201f6..00000000000 --- a/docs/i18n/fr/docusaurus-theme-classic/navbar.json +++ /dev/null @@ -1,34 +0,0 @@ -{ - "title": { - "message": "Hydra: Head Protocol", - "description": "The title in the navbar" - }, - "item.label.User Manual": { - "message": "Manuel Utilisateur", - "description": "Navbar item with label User Manual" - }, - "item.label.Core Concepts": { - "message": "Concepts clés", - "description": "Navbar item with label Core Concepts" - }, - "item.label.Topologies": { - "message": "Topologies", - "description": "Navbar item with label Topologies" - }, - "item.label.Benchmarks": { - "message": "Benchmarks", - "description": "Navbar item with label Benchmarks" - }, - "item.label.API Reference": { - "message": "Référence d'API", - "description": "Navbar item with label API Reference" - }, - "item.label.GitHub": { - "message": "GitHub", - "description": "Navbar item with label GitHub" - }, - "item.label.Use Cases": { - "message": "Cas d'usages", - "description": "Navbar item with label Use Cases" - } -} diff --git a/docs/i18n/ja/code.json b/docs/i18n/ja/code.json deleted file mode 100644 index 3e3bcb06c94..00000000000 --- a/docs/i18n/ja/code.json +++ /dev/null @@ -1,295 +0,0 @@ -{ - "homepage.tagline": { - "message": "ユーザーマニュアル、コアコンセプト、APIリファレンス" - }, - "homepage.gettingStarted": { - "message": "はじめに - 5分 ⏱️", - "description": "'Getting Started' button in the home header." - }, - "homepage.featureList.secure.title": { - "message": "安全", - "description": "Hydra heads' first highlight: security." - }, - "homepage.featureList.secure.tagline": { - "message": "Hydra Headの参加者は、明示的に同意していない資金を失うことはありません。", - "description": "Tagline for the 'secure' property." - }, - "homepage.featureList.fast.title": { - "message": "高速", - "description": "Hydra heads' second highlight: swiftness." - }, - "homepage.featureList.fast.tagline": { - "message": "Hydra Head内で実行されるトランザクションは、ほぼ即時決済が可能です。", - "description": "Tagline for the 'fast' property." - }, - "homepage.featureList.isomorphic.title": { - "message": "同型", - "description": "Hydra heads' third highlight: isomorphism." - }, - "homepage.featureList.isomorphic.tagline": { - "message": "Cardanoのメイン台帳の堅牢な機能、インターフェース、安全性を利用することができます。", - "description": "Tagline for the 'isomorphic' property." - }, - "theme.ErrorPageContent.title": { - "message": "このページはクラッシュしました.", - "description": "The title of the fallback page when the page crashed" - }, - "theme.ErrorPageContent.tryAgain": { - "message": "再試行", - "description": "The label of the button to try again when the page crashed" - }, - "theme.NotFound.title": { - "message": "ページが見つかりません", - "description": "The title of the 404 page" - }, - "theme.NotFound.p1": { - "message": "お探しのページが見つかりませんでした。", - "description": "The first paragraph of the 404 page" - }, - "theme.NotFound.p2": { - "message": "このページにリンクしているサイトの所有者に連絡をしてリンクが壊れていることを伝えてください。", - "description": "The 2nd paragraph of the 404 page" - }, - "theme.AnnouncementBar.closeButtonAriaLabel": { - "message": "閉じる", - "description": "The ARIA label for close button of announcement bar" - }, - "theme.BackToTopButton.buttonAriaLabel": { - "message": "トップページに戻る", - "description": "The ARIA label for the back to top button" - }, - "theme.blog.archive.title": { - "message": "アーカイブ", - "description": "The page & hero title of the blog archive page" - }, - "theme.blog.archive.description": { - "message": "アーカイブ", - "description": "The page & hero description of the blog archive page" - }, - "theme.blog.paginator.navAriaLabel": { - "message": "ブログ記事一覧のナビゲーション", - "description": "The ARIA label for the blog pagination" - }, - "theme.blog.paginator.newerEntries": { - "message": "新しい記事", - "description": "The label used to navigate to the newer blog posts page (previous page)" - }, - "theme.blog.paginator.olderEntries": { - "message": "過去の記事", - "description": "The label used to navigate to the older blog posts page (next page)" - }, - "theme.blog.post.readingTime.plurals": { - "message": "約{readingTime}分", - "description": "Pluralized label for \"{readingTime} min read\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" - }, - "theme.blog.post.readMoreLabel": { - "message": "{title}の続きを読む", - "description": "The ARIA label for the link to full blog posts from excerpts" - }, - "theme.blog.post.readMore": { - "message": "もっと見る", - "description": "The label used in blog post item excerpts to link to full blog posts" - }, - "theme.blog.post.paginator.navAriaLabel": { - "message": "ブログ記事のナビゲーション", - "description": "The ARIA label for the blog posts pagination" - }, - "theme.blog.post.paginator.newerPost": { - "message": "新しい記事", - "description": "The blog post button label to navigate to the newer/previous post" - }, - "theme.blog.post.paginator.olderPost": { - "message": "過去の記事", - "description": "The blog post button label to navigate to the older/next post" - }, - "theme.blog.sidebar.navAriaLabel": { - "message": "Blog recent posts navigation", - "description": "The ARIA label for recent posts in the blog sidebar" - }, - "theme.blog.post.plurals": { - "message": "{count}件", - "description": "Pluralized label for \"{count} posts\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" - }, - "theme.blog.tagTitle": { - "message": "「{tagName}」タグの記事が{nPosts}あります", - "description": "The title of the page for a blog tag" - }, - "theme.tags.tagsPageLink": { - "message": "全てのタグを見る", - "description": "The label of the link targeting the tag list page" - }, - "theme.CodeBlock.copyButtonAriaLabel": { - "message": "クリップボードにコードをコピー", - "description": "The ARIA label for copy code blocks button" - }, - "theme.CodeBlock.copied": { - "message": "コピーしました", - "description": "The copied button label on code blocks" - }, - "theme.CodeBlock.copy": { - "message": "コピー", - "description": "The copy button label on code blocks" - }, - "theme.colorToggle.ariaLabel": { - "message": "Switch between dark and light mode (currently {mode})", - "description": "The ARIA label for the navbar color mode toggle" - }, - "theme.colorToggle.ariaLabel.mode.dark": { - "message": "ダークモード", - "description": "The name for the dark color mode" - }, - "theme.colorToggle.ariaLabel.mode.light": { - "message": "ライトモード", - "description": "The name for the light color mode" - }, - "theme.docs.DocCard.categoryDescription": { - "message": "{count} items", - "description": "The default description for a category card in the generated index about how many items this category includes" - }, - "theme.docs.sidebar.expandButtonTitle": { - "message": "サイドバーを開く", - "description": "The ARIA label and title attribute for expand button of doc sidebar" - }, - "theme.docs.sidebar.expandButtonAriaLabel": { - "message": "サイドバーを開く", - "description": "The ARIA label and title attribute for expand button of doc sidebar" - }, - "theme.docs.paginator.navAriaLabel": { - "message": "ドキュメントのナビゲーション", - "description": "The ARIA label for the docs pagination" - }, - "theme.docs.paginator.previous": { - "message": "前へ", - "description": "The label used to navigate to the previous doc" - }, - "theme.docs.paginator.next": { - "message": "次へ", - "description": "The label used to navigate to the next doc" - }, - "theme.docs.sidebar.collapseButtonTitle": { - "message": "サイドバーを隠す", - "description": "The title attribute for collapse button of doc sidebar" - }, - "theme.docs.sidebar.collapseButtonAriaLabel": { - "message": "サイドバーを隠す", - "description": "The title attribute for collapse button of doc sidebar" - }, - "theme.DocSidebarItem.toggleCollapsedCategoryAriaLabel": { - "message": "Toggle the collapsible sidebar category '{label}'", - "description": "The ARIA label to toggle the collapsible sidebar category" - }, - "theme.docs.tagDocListPageTitle.nDocsTagged": { - "message": "One doc tagged|{count} docs tagged", - "description": "Pluralized label for \"{count} docs tagged\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" - }, - "theme.docs.tagDocListPageTitle": { - "message": "{nDocsTagged} with \"{tagName}\"", - "description": "The title of the page for a docs tag" - }, - "theme.docs.versionBadge.label": { - "message": "Version: {versionLabel}" - }, - "theme.common.editThisPage": { - "message": "このページを編集", - "description": "The link label to edit the current page" - }, - "theme.docs.versions.unreleasedVersionLabel": { - "message": "これはリリース前の{siteTitle} {versionLabel}のドキュメントです。", - "description": "The label used to tell the user that he's browsing an unreleased doc version" - }, - "theme.docs.versions.unmaintainedVersionLabel": { - "message": "これは{siteTitle} {versionLabel}のドキュメントで現在はアクティブにメンテナンスされていません。", - "description": "The label used to tell the user that he's browsing an unmaintained doc version" - }, - "theme.docs.versions.latestVersionSuggestionLabel": { - "message": "最新のドキュメントは{latestVersionLink} ({versionLabel}) を見てください。", - "description": "The label used to tell the user to check the latest version" - }, - "theme.docs.versions.latestVersionLinkLabel": { - "message": "最新バージョン", - "description": "The label used for the latest version suggestion link label" - }, - "theme.common.headingLinkTitle": { - "message": "見出しへの直接リンク", - "description": "Title for link to heading" - }, - "theme.lastUpdated.atDate": { - "message": "{date}に", - "description": "The words used to describe on which date a page has been last updated" - }, - "theme.lastUpdated.byUser": { - "message": "{user}が", - "description": "The words used to describe by who the page has been last updated" - }, - "theme.lastUpdated.lastUpdatedAtBy": { - "message": "{atDate}{byUser}最終更新", - "description": "The sentence used to display when a page has been last updated, and by who" - }, - "theme.navbar.mobileSidebarSecondaryMenu.backButtonLabel": { - "message": "← メインメニューへ戻る", - "description": "The label of the back button to return to main menu, inside the mobile navbar sidebar secondary menu (notably used to display the docs sidebar)" - }, - "theme.navbar.mobileVersionsDropdown.label": { - "message": "Versions", - "description": "The label for the navbar versions dropdown on mobile view" - }, - "theme.common.skipToMainContent": { - "message": "メインコンテンツまでスキップ", - "description": "The skip to content label used for accessibility, allowing to rapidly navigate to main content with keyboard tab/enter navigation" - }, - "theme.TOCCollapsible.toggleButtonLabel": { - "message": "On this page", - "description": "The label used by the button on the collapsible TOC component" - }, - "theme.tags.tagsListLabel": { - "message": "タグ:", - "description": "The label alongside a tag list" - }, - "theme.navbar.mobileLanguageDropdown.label": { - "message": "Languages", - "description": "The label for the mobile language switcher dropdown" - }, - "theme.SearchBar.seeAll": { - "message": "See all {count} results" - }, - "theme.SearchBar.label": { - "message": "検索", - "description": "The ARIA label and placeholder for search button" - }, - "theme.SearchPage.documentsFound.plurals": { - "message": "{count}件のドキュメントが見つかりました", - "description": "Pluralized label for \"{count} documents found\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" - }, - "theme.SearchPage.existingResultsTitle": { - "message": "『{query}』の検索結果", - "description": "The search page title for non-empty query" - }, - "theme.SearchPage.emptyResultsTitle": { - "message": "ドキュメントを検索", - "description": "The search page title for empty query" - }, - "theme.SearchPage.inputPlaceholder": { - "message": "ここに検索するキーワードを入力してください", - "description": "The placeholder for search page input" - }, - "theme.SearchPage.inputLabel": { - "message": "検索", - "description": "The ARIA label for search page input" - }, - "theme.SearchPage.algoliaLabel": { - "message": "Algoliaで検索", - "description": "The ARIA label for Algolia mention" - }, - "theme.SearchPage.noResultsText": { - "message": "検索結果が見つかりませんでした", - "description": "The paragraph for empty search result" - }, - "theme.SearchPage.fetchingNewResults": { - "message": "新しい検索結果を取得しています...", - "description": "The paragraph for fetching new search results" - }, - "theme.tags.tagsPageTitle": { - "message": "タグ", - "description": "The title of the tag list page" - } -} diff --git a/docs/i18n/ja/docusaurus-plugin-content-blog/options.json b/docs/i18n/ja/docusaurus-plugin-content-blog/options.json deleted file mode 100644 index 6624524759e..00000000000 --- a/docs/i18n/ja/docusaurus-plugin-content-blog/options.json +++ /dev/null @@ -1,14 +0,0 @@ -{ - "title": { - "message": "Architectural Decision Records", - "description": "The title for the blog used in SEO" - }, - "description": { - "message": "Lightweight technical documentation for the Hydra node software.", - "description": "The description for the blog used in SEO" - }, - "sidebar.title": { - "message": "Architectural Decision Records", - "description": "The label for the left sidebar" - } -} diff --git a/docs/i18n/ja/docusaurus-plugin-content-docs-benchmarks/current.json b/docs/i18n/ja/docusaurus-plugin-content-docs-benchmarks/current.json deleted file mode 100644 index dd30528de7f..00000000000 --- a/docs/i18n/ja/docusaurus-plugin-content-docs-benchmarks/current.json +++ /dev/null @@ -1,6 +0,0 @@ -{ - "version.label": { - "message": "Next", - "description": "The label for version current" - } -} diff --git a/docs/i18n/ja/docusaurus-plugin-content-docs-benchmarks/current/index.md b/docs/i18n/ja/docusaurus-plugin-content-docs-benchmarks/current/index.md deleted file mode 100644 index 0df0dd2d4c7..00000000000 --- a/docs/i18n/ja/docusaurus-plugin-content-docs-benchmarks/current/index.md +++ /dev/null @@ -1,17 +0,0 @@ ---- -sidebar_label: "ベンチマーク" -sidebar_position: 1 ---- - -# ベンチマークと制限事項 - -この項目では、Hydra Head オンチェーンプロトコルの既知の制限に関する最新データを提供します。Cardano のトランザクション（およびブロック）には、トランザクションサイズ、実行コスト、Input と Output の数に制限があり、これらはネットワークパラメータに依存し Head プロトコルの機能に影響を及ぼします。Head に参加できるパーティーの数、Head にコミットできる UTxO の数、ファンアウトできる数はオンチェーンスクリプトとトランザクションが成熟し、最適化され、基礎となるカルダノチェーンが、より多くのパラメータとより効率的なスクリプトの実行によって進化すると、これらの制限は変更されることになります。 - -これらのページで提供されるデータは、Hydra の [統合プロセス](https://github.com/input-output-hk/hydra/actions/workflows/ci-nix.yaml)によって生成されるため、コードの現在の状態を反映することが保証されています。 - -```mdx-code-block -import DocCardList from '@theme/DocCardList'; -import {useDocsSidebar} from '@docusaurus/theme-common/internal'; - - docId != "index")}/> -``` diff --git a/docs/i18n/ja/docusaurus-plugin-content-docs-core-concepts/current.json b/docs/i18n/ja/docusaurus-plugin-content-docs-core-concepts/current.json deleted file mode 100644 index dd30528de7f..00000000000 --- a/docs/i18n/ja/docusaurus-plugin-content-docs-core-concepts/current.json +++ /dev/null @@ -1,6 +0,0 @@ -{ - "version.label": { - "message": "Next", - "description": "The label for version current" - } -} diff --git a/docs/i18n/ja/docusaurus-plugin-content-docs-core-concepts/current/faq/_category_.json b/docs/i18n/ja/docusaurus-plugin-content-docs-core-concepts/current/faq/_category_.json deleted file mode 100644 index 2444901f5e5..00000000000 --- a/docs/i18n/ja/docusaurus-plugin-content-docs-core-concepts/current/faq/_category_.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "label": "よくある質問", - "position": 999 -} diff --git a/docs/i18n/ja/docusaurus-plugin-content-docs-core-concepts/current/faq/index.md b/docs/i18n/ja/docusaurus-plugin-content-docs-core-concepts/current/faq/index.md deleted file mode 100644 index a76e7070a6e..00000000000 --- a/docs/i18n/ja/docusaurus-plugin-content-docs-core-concepts/current/faq/index.md +++ /dev/null @@ -1,47 +0,0 @@ -# よくある質問 - -> And their answers! - -
- Hydraはいつ? - - ロードマップ はGithubで公開されています。タブには、さまざまな角度から表示するための複数のセクションがあることに注意してください（リリースパッケージ、クォーターなど） - -
- -
- Hydraラヘッドプロトコルは、どのような場合に適していますか？ - - Hydraヘッドプロトコルは、既知の参加者がネットワーク構築に合意するほど互いをよく知っているが、メインチェーンでの紛争を解決する可能性に裏打ちされた資産を確保する方法がないために、資金管理について十分に信頼していない状況に適しています。 -
- -
- ヘッド内でPlutusのスクリプトを実行できますか？ - - はい!　ヘッド参加者間で実行されるトランザクションは、本格的なAlonzoトランザクションです。これらはスクリプトを持ち、レイヤー1トランザクションとまったく同じ方法でUTxOを使用します。ちなみに、各HydraノードはCardano元帳を実行し、元帳の状態を維持しています。しかし、現在のチェーン上のインタラクションでPABに依存しているDAppsは、Plutusコントラクトの実行をヘッド内で実行することに関しては不十分です。実際PABは、カルダノレイヤー1に密接に結合しています。これは、ノードからクライアントへのミニプロトコル(チェーン同期、状態クエリー、tx送信)を使用してチェーンと対話するCardanoクライアントです。Hydraノードはこのようなプロトコルを (まだ) 公開していないため, PABとの互換性がありません。 -
- -
- サードパーティがウォレットの所有者に代わってHydraノードを実行することは可能ですか（例：マネージドHydraヘッドの実行） - - 可能です！これは、たとえば、Bitcoin Lightningの [Phoenix] (https://phoenix.acinq.co/) に似ています。非カストディアンの管理されたlightningノードです。エンドユーザーはキーと資金を完全に管理できますが、基盤となるインフラストラクチャはユーザーに代わって管理されます (提供された料金) しかし、これはサービス・プロバイダーとユーザーとの間にある種の信頼関係を意味します。実際、ユーザーはサービス・プロバイダーを暗黙的に信頼して、たとえばヘッドの競合やクローズを適切に処理します。 -
- -
- HydraヘッドとHydraノードの関係は？ - - これは (少なくとも*) 1 対 多 の関係です。各HydraヘッドはいくつかのHydraノードで構成されています。現在、拡張目標としてヘッドあたり最大100ノードを目指しています。ヘッドは独立しており、独立したネットワークを形成します。無限に多くのヘッドを並列に動かすことができます。 - - _ (*) Hydraノードが複数のヘッドをサポートするようにして、多 対 多 の関係にすることができます。_ -
- -
- Hydraヘッドのプロトコルはサイドチェーンなのですか？ - - いいえ、違います。実は、ヘッドをサイドチェーンと見なすには、次の2つの決定的な事実があります。 - - 1. Hydraのデータ可用性は保証されていません。別の言い方をすると、トランザクションは (a) 先頭の参加者についてのみ知られており、 (b) 処理されるとすぐに一般的に忘れられます。実際、Hydraヘッドにはブロックがなく、参加者が履歴を保持したり、ヘッドの外のユーザーが利用できるようにしたりする動機もありません。 - - 2. ヘッドネットワークは静的で、新しい参加者は参加できず、前もって決定しておく必要があります。そのため、ネットワークは非常に孤立またはプライベートであり、どのピアからも到達できません。Hydraヘッドは、実際にはよく知られた参加者同士の集合チャンネルとなります。 - -
diff --git a/docs/i18n/ja/docusaurus-plugin-content-docs-core-concepts/current/hydra-head-lifecycle.svg b/docs/i18n/ja/docusaurus-plugin-content-docs-core-concepts/current/hydra-head-lifecycle.svg deleted file mode 100644 index f8b033c68aa..00000000000 --- a/docs/i18n/ja/docusaurus-plugin-content-docs-core-concepts/current/hydra-head-lifecycle.svg +++ /dev/null @@ -1 +0,0 @@ - \ No newline at end of file diff --git a/docs/i18n/ja/docusaurus-plugin-content-docs-core-concepts/current/hydra-pull-based-network.jpg b/docs/i18n/ja/docusaurus-plugin-content-docs-core-concepts/current/hydra-pull-based-network.jpg deleted file mode 100644 index a9823d587d1..00000000000 Binary files a/docs/i18n/ja/docusaurus-plugin-content-docs-core-concepts/current/hydra-pull-based-network.jpg and /dev/null differ diff --git a/docs/i18n/ja/docusaurus-plugin-content-docs-core-concepts/current/index.md b/docs/i18n/ja/docusaurus-plugin-content-docs-core-concepts/current/index.md deleted file mode 100644 index 063c7e3da8a..00000000000 --- a/docs/i18n/ja/docusaurus-plugin-content-docs-core-concepts/current/index.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -sidebar_position: 1 ---- - -# 概要 - -Hydraは、Cardanoのレイヤー2スケーラビリティ・ソリューションで、低遅延と高スループットによる取引速度の向上と取引コストの最小化を目的としています。 - -[Hydra Head](https://eprint.iacr.org/2020/299.pdf) は Hydraファミリーの最初のプロトコルであり、同型のマルチパーティステートチャネルに依存する、より高度な展開シナリオの基礎を具現化するものです。Hydra Headプロトコルには様々な種類と拡張がありますが、まずは基本的な Hydra Head のライフサイクル全体と、Layer 1 と Layer 2 の間の同型の状態遷移をどのように実現するかを見ていきましょう。 - -![](./hydra-head-lifecycle.svg) - -Hydra Headは、オンラインで応答性の高い参加者のグループによって形成されます。参加者は、参加者リストを含むいくつかのパラメータをオンチェーンで告知することによってHeadを初期化(initial)します。その後、参加者はCardanoメインチェーンからの未使用トランザクションOutput（UTXO）をHeadにコミット(Commit)し、すべてのUTXOが収集(Collect)されると初期状態（`U0`）としてHydra Headで利用できるようになります。回収前の任意の時点で、参加者はプロセスを中止して資金を回収することもできます。 - -開いている間は、Hydraノードを介してHydraヘッドを使用し、ヘッドネットワーク上でトランザクションを送信することができます。トランザクションの形式とプロパティはメインチェーンと同じです。 これらは「同型」です。UTXOエントリが消費され、新しいUTXOエントリがHydra Head に作成されると、すべての参加者はいわゆるスナップショット (`U1..Un`) で新しい状態を確認し、合意する必要があります。 - -参加者は誰でも、合意された状態を使用してヘッドを閉じることができます。たとえば、メインネットでキャッシュアウトしたい場合、または別のパーティがヘッドの進化を誤動作または停止させた場合です。メインチェーンの最終状態に異議(Contest)を唱えるメカニズムがあります。最終的に、ファンアウト(Fanout)トランザクションは、最終的に合意された状態を配布し、実質的にヘッドにのみ存在していたものをレイヤー1で利用できるようにします。 - -```mdx-code-block -import DocCardList from '@theme/DocCardList'; -import {useDocsSidebar} from '@docusaurus/theme-common/internal'; - - docId != "index")}/> -``` diff --git a/docs/i18n/ja/docusaurus-plugin-content-docs-core-concepts/current/layer-two.md b/docs/i18n/ja/docusaurus-plugin-content-docs-core-concepts/current/layer-two.md deleted file mode 100644 index 4d6f64c5325..00000000000 --- a/docs/i18n/ja/docusaurus-plugin-content-docs-core-concepts/current/layer-two.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -sidebar_position: 2 ---- - -# レイヤー2ソリューション - -> レイヤー2とはどういう意味ですか？レイヤー2ソリューションにはどのような種類がありますか？ - -ブロックチェーン業界では、既存のプロトコル（レイヤー1）をオーバーレイして、基盤となるプロトコルに対して追加機能または性能上の利点を提供するソリューションを指す場合、**レイヤー2**ソリューションと呼んでいます。本質的には、それらは他のアプリケーションを可能にするためにプロトコルの上に構築された汎用的な目的のソリューションで、レイヤ1プロトコルと異なるトレードオフを持つ分散型アプリケーションを開発するためのフレームワークを提供します。 - -## ステートチャネル - -Hydra Headプロトコルはレイヤー2のソリューションで、**ステートチャネル**に属し、それ自体が**ペイメントチャネル**の子孫になります。ペイメントチャネルは、2つ以上の当事者が、基礎となるブロックチェーンにすべてのトランザクションをコミットすることなく、特定のオフチェーンプロトコルに従って資金を交換することを可能にします。これは歴史的に、パーミッションレス台帳のスケーラビリティの問題に対する答えとして生まれた最初のレイヤー2ソリューションの一種です（その結果、最も研究されているソリューションの一種でもあります）。 - -ステートチャネルは、従来の決済チャネルの概念を拡張し、オフチェーンチャネル上でスマートコントラクトをサポートします。このようなセットアップでは、1つまたは複数のパーティはもはや純粋な取引支払いに制限されることなく、オフチェーンで複雑なロジックを扱う本格的なスクリプト検証を実行し、後で結果をレイヤー1にコミットするだけでよいのです。 - -#### 事例 - -- Lightning (Bitcoin); -- Perun (Ethereum, Polkadot, Cosmos); -- Sprites (Ethereum); -- 私達のお気に入りである: **Hydra: Head** (Cardano)! - -## サイドチェーン - -**サイドチェーン** を使用すると、独自のコンセンサスルールのセットを使用して、アセットをレイヤー1プロトコルから新しいチェーンに転送できます。通常、サイドチェーンは、より単純でより効率的なコンセンサスメカニズムを提供します。これにより、スケーラビリティが向上するか、レイヤー1で採用するのが難しい新機能の実装が容易になります。サイドチェーンは通常、ルートに少数のアクターまたは委員会のみが関与しています。 - -ただし、サイドチェーンは「適切なチェーン」であり、ブロックはバリデーターによって生成され、通常はスマートコントラクト機能を備えています。したがって、ステートチャネルとは異なり、データの可用性と、チェーンの検証と観察に参加する方法を提供します（ステートチャネルでは、チャネルの参加者だけが、チャネルで何が起こっているかについて信頼できるビューを持っています。 ）。サイドチェーンに入るには、通常、レイヤー1でアセットを焼き付けるかロックして、サイドチェーンネットワークで同等のアセットを受け取ります。 - -#### 事例 - -- Liquid Network (Bitcoin); -- RSK (Bitcoin); -- Polygon (Ethereum); -- Milkomeda (Cardano). - -## ロールアップ - -レイヤー2ソリューションのもう1つの主要なタイプは、ロールアップです。これらは、トランザクションの実行をオフチェーンに移動して、レイヤー1での実行の表現をはるかにコンパクトに保つ​​方法を提供します。ロールアップは通常、検証可能なブレッドクラムを定期的に残しながら、高可用性と高い計算機能をオフチェーンで提供する中央アクターによって駆動されます。オンチェーン（ロールアップ）。 - -一般に、ロールアップには、楽観的またはゼロ知識の2つのフレーバーがあります。前者では、ロールアップは楽観的にチェーンに投稿され、検証は独立したバリデーターによって事後的に行われます。意見の相違がある場合、紛争はチェーン上で解決され、ロールアップ発行者は経済的影響に耐えます。ゼロ知識アプローチでは、実行の簡潔な証明がオフチェーンで計算され、ロールアップと一緒に公開され、オンチェーンバリデーターによって制御されます（したがって、ロールアップの正当な実行が強制されます） - -#### 事例 - -- Arbitrum (Ethereum); -- Optimism (Ethereum); -- Hermez (Ethereum); -- ZKSync (Ethereum). diff --git a/docs/i18n/ja/docusaurus-plugin-content-docs-core-concepts/current/networking.md b/docs/i18n/ja/docusaurus-plugin-content-docs-core-concepts/current/networking.md deleted file mode 100644 index 036a6c5cc26..00000000000 --- a/docs/i18n/ja/docusaurus-plugin-content-docs-core-concepts/current/networking.md +++ /dev/null @@ -1,87 +0,0 @@ ---- -sidebar_position: 4 ---- - -# Hydraネットワーキング - -このドキュメントでは、HydraNetworkingLayerについて詳しく説明します。ヘッドを開くことができるHydraノードで構成されるネットワーク。 - -:::warning - -🛠 このドキュメントは進行中の作業です。ネットワーキングの現在の状況は理想的とは言えません。これは、開始して機能するものを用意するための方法にすぎません。ネットワークをより動的にすることによって状況を改善する[提案](https://github.com/input-output-hk/hydra/pull/237)があります。 -::: - -# 質問 - -* トランスポート層のトポロジーはどのようなものが想定されますか？ - * 接続されたピアは、ヘッドパーティのサブセット/スーパーセット/アイデンティティセットですか？ -* TCPが提供する配信順序と信頼性の保証は必要ですか？ - * TCPは、ノード間の全二重ストリーム指向の持続的接続です。 - * 私たちのネットワーク層は、UDPに適していると思われる非同期メッセージパッシングに基づいています -* ノードがファイアウォールを介して到達可能であることに注意する必要がありますか？ - * Hydraノードのニーズに合わせてファイアウォールやNATを設定する責任をエンドユーザーに負わせることができます。 - * エンドユーザーよりも、企業・法人・団体のプレーヤーが使いやすいかもしれません。 -* Headにプライバシーは必要ですか？ - * Txの詳細は外部のオブザーバーには不透明であり、Headのファンアウトの最終結果のみが観察可能であるべきです -* ピア/パーティをどのように知る/発見しますか？ - * この論文では、以下のような_Setup_フェーズが存在することを仮定しています。 - > Head-Protocolインスタンスを生成するために、イニシエータは参加者のリスト、使用する（多重）署名スキームのパラメータなどのプロトコルパラメータを発表して、参加者のセット${p1,...,pn}$（自分がその一人である）を招待する。 - > その後、各パーティは他のすべてのパーティとペア認証されたチャネルを確立します。 - * 参加者のリストは正確には何ですか？少なくとも、お互いを区別するために、各参加者を特定する必要があるようですが、どのようにしたらよいでしょうか。いくつかの命名スキーム？IP：ポートアドレス？公開鍵？証明書？ - * 「ペアワイズ認証チャネル」とは正確には何ですか？これらは実際のTCP/TLS接続ですか？それとも、レイヤー4（トランスポート）またはレイヤー5（セッション）ソリューションですか？ -* ネットワークプロトコルをどの程度オープンにしたいですか？ - * 現在、メッセージのCBORエンコーディングでOuroborosスタックを使用しています。これにより、他のツールをHydraネットワークに含めることがやや困難になります。 - -# 調査 - -## Ouroboros - -2022-02-14にネットワークチームとミーティングを行い、OuroborosネットワークスタックがHydraにどのように適合するかを調査しました。 -Neil Daviesがいくつかの興味深い数字を挙げて、議論はすぐにパフォーマンスに基づいて導き出されました。 - -* 世界一周: 600ms -* 1大陸での遅延: 50-100ms -* データセンターでの遅延: 2-3ms -* ノードが配置されている場所では、1秒未満のラウンドトリップで問題ありません。 -* TCP接続の基本的な信頼性は距離とともに低下します: - * DC内接続は永続的に持続可能 - * DC外接続: TCPのCnxを永遠に稼働させ続けることは難しく、中間ノードがダウンして経路が変更された場合、経路の再設定に90秒かかります。 - * れは、接続数が増えると、常に少なくとも1つの接続がダウンする可能性が高くなることを意味します。 -* ヘッドを閉じるには、ネットワーク接続から切り離す必要があります=>TCPcnxが消える=/=>ヘッドを閉じる -* カルダノネットワーク内では、単一の空のブロックの伝播には400msかかります（10Kノードに到達するため） - * ouroborosネットワークは数千の接続に耐える必要があります（システムレベルの制限がいくつかあります） -* Hydraネットワークのモデリング - * ネットワークの性能をモデル化するための論理的枠組み CDFとメッセージが全ノードに現れるまでの時間を関連付ける（これは[hydra-sim](https://github.com/input-output-hk/hydra-sim)で行われていることです。 - * 例えば、Snocket = PTP connection with ordered guaranteed messages delivery のような、我々が期待するセマンティクスを持つレイヤーを定義することができます。Hydraにそれが必要でしょうか？ -* [ワイヤーガード](https://wireguard.io)はいかがでしょうか。欠点もありますが、とても面白いアプローチです。 - * グローバルアドレス指定なし - * 1つのethインターフェース/接続があります - * プラス面として、IPアドレスの変更を透過的に管理します - * ファイアウォールに対応しないため、各ノードでNATを設定する必要があります。 - -## カルダノネットワーク - -カルダノネットワークの仕組みやウロボロスの使い方についての詳しい注意点は、[このWikiページ](https://github.com/input-output-hk/hydra.wiki/blob/master/Networking.md#L1)をご覧ください。 - -* Cardanoは、数千のノードにまたがるグローバルネットワークであり、ノードの出入りとトポロジは大きく異なります。その主な目的はブロックの伝播です。コンセンサスルールに従って一部のノードによって生成されたブロックは、20秒未満でネットワーク内のすべてのノードに到達する必要があります。 -* ノードは他のすべてのノードに接続することはできないため、ブロックの拡散は、ブロック交換を行う限られたピアのセットに接続する、何らかの形のゴシップ_によって行われます。 -* ノードはピアや他のノードからの敵対的な振る舞いに耐性を持つ必要があり、そのため取り込みたいデータの量と速度を制御する必要があり、そのため「プルベース」のメッセージングレイヤーが必要となります。 -* プロデューサー・ノードは署名鍵にアクセスする必要があるため、安全性を高め、DoSやその他の悪意のある行為のリスクを減らすために、通常、リレー・ノードの後ろで実行されます。 -* ノードはADSLやケーブルボックス、ファイヤーウォールなどの背後にあり、ノードを直接アドレス指定できないような複雑なネットワーク環境で動作することが想定されるため、ノードが外部から到達可能なリレーノードへの接続を「開始」し、「プルベース」のメッセージングが必要になります。 - -# 導入事例 - -## 現在の状態 - -* Hydraのノードは、Point-to-point(例えばTCP)接続を使用してペア接続されたピアネットワークを形成します。これらの接続は、常に稼働していることが期待されます。 - * ノードは基盤となるネットワーク抽象化として[Ouroboros](https://github.com/input-output-hk/ouroboros-network/)を使用します。これは、`Snocket`と呼ばれる信頼性の高いポイント・ツー・ポイントのストリームベースの通信抽象化により、ピアとの接続を管理することを担います。 - * すべてのメッセージは、PTP接続を使用してピアにブロードキャストされます - * Hydraプロトコルの性質上、ピアとの接続がないため、Headの進行が妨げられます。 -* `hydra-node`すべてのピアとの間でしかヘッドを開くことができません。これは、ノードは事前に開きたいピアとヘッドのトポロジーを知っておく必要があることを意味します。 -* 接続されたノードは、ハートビートと交換されたメッセージの監視を通じて基本的な障害検出を実装します - -## ゴシップ拡散ネットワーク - -次の図は、IOGのネットワーキングエンジニアとの話し合いから得られた、Hydraのプルベースのメッセージングシステムの1つの可能な実装です。 - -![Hydra pull-based network](./hydra-pull-based-network.jpg) diff --git a/docs/i18n/ja/docusaurus-plugin-content-docs-core-concepts/current/rollbacks/_category_.json b/docs/i18n/ja/docusaurus-plugin-content-docs-core-concepts/current/rollbacks/_category_.json deleted file mode 100644 index 8e9dd392e9d..00000000000 --- a/docs/i18n/ja/docusaurus-plugin-content-docs-core-concepts/current/rollbacks/_category_.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "label": "ロールバック処理", - "position": 4 -} diff --git a/docs/i18n/ja/docusaurus-plugin-content-docs-core-concepts/current/rollbacks/index.md b/docs/i18n/ja/docusaurus-plugin-content-docs-core-concepts/current/rollbacks/index.md deleted file mode 100644 index 60c68ceab9d..00000000000 --- a/docs/i18n/ja/docusaurus-plugin-content-docs-core-concepts/current/rollbacks/index.md +++ /dev/null @@ -1,49 +0,0 @@ -# ロールバック処理 - -ロールバックは、カルダノチェーンの動作に不可欠な要素です。Cardanoの上に構築され、その動作をチェーンと同期させるアプリケーションは、時折そのようなロールバックを観察する覚悟が必要であり、Hydraもその例外ではありません。 - -この短い文書では、ロールバックとは何か、ロールバックはどこから発生するのか、そしてHydra headがそれらをどのように処理するのかについて説明します。 - -## ロールバックとは？ - -ロールバックは、Cardanoチェーンまたはその他の真に分散化されたブロックチェーンで発生します。これは、本質的に非同期であるためです。各ノードには、他のノードと通信したり既知のブロックに関するメッセージを交換したりすることで更新されるチェーンの状態に関する独自のビューがあり、このプロセスには時間がかかります。新しいブロックが生成された場合、これは有効または無効であるかもしれません。そしてチェーンの状態は最終的な整合性があり、すべてのノードはいくつかのブロックが処理された後にのみチェーンの状態に同意します。 - -実際にはロールバックは誤った名称であり、フォークについて話す必要があります。Hydra Headを実行している3つのノードの視点からこれが何を意味するかを見てみましょう。次の図は、レイヤー1チェーンの各ノードのビューを表しています。 - -![](rollbacks-1.jpg) - -**_immutable part_** は、現在の _tip_ から過去に`k`ブロック（メインネットでは`k`は2160）であり、すべてのノードで同一であることが保証されています。ここで、ノード2はノード1と同じ新しいブロックを受け取りますが、ノード3は異なるブロックを受け取ります。最終的にノード3のチェーンは他のチェーンより短いので、より長いチェーンに取って代わられ、_ロールバック_ されることになります。 - -次の図では、ノードのダイレクトチェーンオブザーバーで何が起こるかを詳しく説明します。 - -![](rollbacks-2.jpg) - -新しいブロックが利用可能になると、`ChainSync` クライアントは新しいブロックごとに `RollForward` メッセージを受信します。これはチェーンがロールバックされたスロットとブロックハッシュを特定するものです (図では一つの数字として抽象化されています)。そして `RollForward` メッセージを通して新しいブロックの受信を再開します。 - -## どのようにHydraノードに影響しますか？ - -トランザクションがチェーン上で観察されると、最初に初期化してからコミットを収集し、 CollectComトランザクションを通じてヘッドを開き、最終的にそれを閉じてヘッドの最後のUTxOをファンアウトすることにより、ヘッドの状態を変更する可能性があるため、ロールバックには問題があります。 - -次の図は、潜在的に競合する`Commit`トランザクションにつながるロールバックの問題を示しています。 - -![](rollbacks-3.jpg) - -ヘッドがロールバックを適切に処理しない場合、ヘッドに参加している他のノードとの間で矛盾した状態になる危険があります。したがって、ダイレクトチェーンコンポーネントのレベルで観察されたロールバックは、HeadLogicがその状態をリセットしてレイヤー1で起こったものと一致させるために、HeadLogicに伝搬されることが重要である。 - -ヘッドの状態に対するロールバックの結果は、ヘッドがどの時点でロールバックされるかに応じて異なります。 -1. ヘッドが開いている前または後にロールバックが発生した場合。例えば `CollectCom` トランザクションの前か `Close` トランザクションの後なら、状況は比較的簡単です。ロールバックされたトランザクションが監視される前の時点にヘッドの状態をリセットできます。 -2. ヘッドが開いているときに発生した場合。例えば `CollectCom` トランザクションがロールバックされた場合、ノードは既にピアとのメッセージ交換を開始しており、その状態はもはやチェーンだけに依存しているため、ヘッドが開いている間にそれが起こると、より大きな問題になります。 - -## どのように扱いますか？ - -:::warning - -🛠 Hydra は現在、例えば上記のケース1のような単純なケースではロールバックを適切に処理しますが、CollectCom が起こったときに賢いことをしようとしないため、ヘッドが簡単に古くなってしまう可能性があります。あるノードが他のノードから非同期になっているため(Collectcom トランザクションのロールバックを観察し、その前に状態をリセットしたため、ヘッドが開いていた間に起こったすべてのことを見失い)、ヘッドを閉じる必要があります。 -::: - -次のシーケンス図に示すように、ロールバックはヘッドで非常に簡単な方法で処理されます。 - -![](rollbacks-4.jpg) - -* 関連するトランザクションが観測されると、例えば上図のケースでは `OnInit` や `OnCommit` が発生し、以前の状態にリンクされた新しい `HeadState` を生成します。 -* ロールバックが発生すると、 `HeadLogic` に `Rollback` イベントが通知され、ロールバックが必要なステップ数が伝えられます。`HeadLogic` レイヤーは `Point Block` がオンチェーンで詳細を気にする必要はなく、以前の状態に簡単に「ロールバック」できる一連の状態を保存するだけです。 \ No newline at end of file diff --git a/docs/i18n/ja/docusaurus-plugin-content-docs-core-concepts/current/rollbacks/rollbacks-1.jpg b/docs/i18n/ja/docusaurus-plugin-content-docs-core-concepts/current/rollbacks/rollbacks-1.jpg deleted file mode 100644 index 1be7eb02ceb..00000000000 Binary files a/docs/i18n/ja/docusaurus-plugin-content-docs-core-concepts/current/rollbacks/rollbacks-1.jpg and /dev/null differ diff --git a/docs/i18n/ja/docusaurus-plugin-content-docs-core-concepts/current/rollbacks/rollbacks-2.jpg b/docs/i18n/ja/docusaurus-plugin-content-docs-core-concepts/current/rollbacks/rollbacks-2.jpg deleted file mode 100644 index 1f37e8f6da5..00000000000 Binary files a/docs/i18n/ja/docusaurus-plugin-content-docs-core-concepts/current/rollbacks/rollbacks-2.jpg and /dev/null differ diff --git a/docs/i18n/ja/docusaurus-plugin-content-docs-core-concepts/current/rollbacks/rollbacks-3.jpg b/docs/i18n/ja/docusaurus-plugin-content-docs-core-concepts/current/rollbacks/rollbacks-3.jpg deleted file mode 100644 index 8cf9194a136..00000000000 Binary files a/docs/i18n/ja/docusaurus-plugin-content-docs-core-concepts/current/rollbacks/rollbacks-3.jpg and /dev/null differ diff --git a/docs/i18n/ja/docusaurus-plugin-content-docs-core-concepts/current/rollbacks/rollbacks-4.jpg b/docs/i18n/ja/docusaurus-plugin-content-docs-core-concepts/current/rollbacks/rollbacks-4.jpg deleted file mode 100644 index 1c5c6ce97a2..00000000000 Binary files a/docs/i18n/ja/docusaurus-plugin-content-docs-core-concepts/current/rollbacks/rollbacks-4.jpg and /dev/null differ diff --git a/docs/i18n/ja/docusaurus-plugin-content-docs-topologies/current.json b/docs/i18n/ja/docusaurus-plugin-content-docs-topologies/current.json deleted file mode 100644 index dd30528de7f..00000000000 --- a/docs/i18n/ja/docusaurus-plugin-content-docs-topologies/current.json +++ /dev/null @@ -1,6 +0,0 @@ -{ - "version.label": { - "message": "Next", - "description": "The label for version current" - } -} diff --git a/docs/i18n/ja/docusaurus-plugin-content-docs-topologies/current/_category_.json b/docs/i18n/ja/docusaurus-plugin-content-docs-topologies/current/_category_.json deleted file mode 100644 index 69275474e27..00000000000 --- a/docs/i18n/ja/docusaurus-plugin-content-docs-topologies/current/_category_.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "label": "Topologies", - "position": 1 -} diff --git a/docs/i18n/ja/docusaurus-plugin-content-docs-topologies/current/basic/basic-hydra-head.jpg b/docs/i18n/ja/docusaurus-plugin-content-docs-topologies/current/basic/basic-hydra-head.jpg deleted file mode 100644 index 91155dca4ac..00000000000 Binary files a/docs/i18n/ja/docusaurus-plugin-content-docs-topologies/current/basic/basic-hydra-head.jpg and /dev/null differ diff --git a/docs/i18n/ja/docusaurus-plugin-content-docs-topologies/current/basic/index.md b/docs/i18n/ja/docusaurus-plugin-content-docs-topologies/current/basic/index.md deleted file mode 100644 index 39f6170865f..00000000000 --- a/docs/i18n/ja/docusaurus-plugin-content-docs-topologies/current/basic/index.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -sidebar_label: '基本的なHydra Head' -sidebar_position: 2 ---- - -# 基本的なHydra Head - -:hammer_and_wrench: この資料は、現在作成中のものです。 - -このドキュメントでは、基本的なHydraHeadの展開アーキテクチャについて説明します。これは、この章で説明されている他のトポロジへの参照として機能し、以下に概略的に示されています。 - -```mdx-code-block -

- Basic Hydra Head -

-``` - -Hydra Headの基本的なセットアップはいくつかの`hydra-node`で構成されており、それぞれが`caradano-node`（写真にはありません）を介してCardanoネットワークに接続されています。Hydra クライアント (`hydra-tui` など) は、オフチェーンネットワークを使用して Hydra Head を開くために、通常はローカル接続で `hydra-node` に接続することになります。 この画像は、2つの異なる`Hydraノード`の間に開かれた2つのヒドラヘッド（青と緑）を示しており、線はHydraネットワーク接続を示し、円は _HydraHead_ の状態と資格情報を表します。いわゆる`HydraHeadParty`によって要約されます。 - -画像には示されていませんが、同じ`hydra-node`で開いている複数の論理`Hydra Head`があります。これは最終的にサポートされ、`hydra-node`プロセス間のネットワーク接続の再利用を可能にする可能性が非常に高いです。 - -青または緑の各ヘッドは独立して進行でき、各ヘッドのそれぞれのハイドラパーティすべての署名が必要です。つまり、緑色のヘッドに2つの署名、青色のヘッドに4つの署名があります。 diff --git a/docs/i18n/ja/docusaurus-plugin-content-docs-topologies/current/index.md b/docs/i18n/ja/docusaurus-plugin-content-docs-topologies/current/index.md deleted file mode 100644 index 48acba391e3..00000000000 --- a/docs/i18n/ja/docusaurus-plugin-content-docs-topologies/current/index.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -sidebar_label: 'トポロジー' -sidebar_position: 1 ---- - -# トポロジー - -Hydra Headは、[コアコンセプト](/core-concepts) ページで説明されているように、よく定義されたレイヤ2コンセンサスプロトコルです。しかしこれは物語の終わりではなく、このプロトコルをどう使うか、どのようなトポロジーが可能かを実際に定義していません。トポロジーとは、Hydraノード、例えばプロトコルを実装した実際のソフトウェアが、どのように相互接続できるかを意味しています。 - -より多くのユーザがHydraの上にソリューションを実装するにつれて、このトポロジーの「カタログ」は、新規参入者が正しい展開モデル、例えば彼らのユースケースに最も適したものを見つけて構築するのに役立つよう拡張されていくでしょう。 - - -```mdx-code-block -import DocCardList from '@theme/DocCardList'; -import {useDocsSidebar} from '@docusaurus/theme-common/internal'; - - docId != "index")}/> -``` diff --git a/docs/i18n/ja/docusaurus-plugin-content-docs-topologies/current/star-shaped/index.md b/docs/i18n/ja/docusaurus-plugin-content-docs-topologies/current/star-shaped/index.md deleted file mode 100644 index 5373135afa6..00000000000 --- a/docs/i18n/ja/docusaurus-plugin-content-docs-topologies/current/star-shaped/index.md +++ /dev/null @@ -1,58 +0,0 @@ ---- -sidebar_label: 'スター型ヘッドネットワーク' -sidebar_position: 3 ---- - -# スター型ヘッドネットワーク - -:hammer_and_wrench: この資料は、現在作成中のものです。 - -このドキュメントでは、いわゆるスター型のHydraネットワークの動作について詳しく説明します。 - -## 概要 - -スター型のHydraネットワーク、より正確にはスター型のヘッドネットワークは次のもので構成されます。 - -* ダウンタイムの少ない「Head-as-a-service」を提供する中央サーバーノード。おそらくこのサービスをホストするのに十分なリソースを持つ企業または組織が運営しています。 -* クライアントノード。DAppインスタンス、またはモバイル/パーソナルウォレットで、常にオンラインであるとは限らず、行ったり来たりする可能性があります。 - -![Star-shaped Heads Network](./star-shaped-general.jpg) - -クライアントノードは、L2ソリューションを使って全てのHydraの安全性を保証しながら、常にオンラインの「フル」Hydraノードを操作するという運用上の負担を負わずに（例えば、ノードの組み込み版や軽量版を使って）効率的に、低コストで相互作用できるようにしたいと思っています。その数は100台、1000台と多いかもしれませんが、常にすべてが同時に稼動しているわけではありません。 - -クライアントノードはサーバーとペアヘッド(例えば _チャネル_ )を確立します。このセットアップは通常のマルチパーティヘッドよりも簡単です。 サーバーは既知のIDを持ち、 このドキュメントの範囲外である特定のサービスを使用してヘッドをセットアップするときに、クライアントは必要なパラメータ(キー、IP)を 常にサーバーに提供することができます。 - -クライアントノードが「その」ヘッドに投稿するトランザクションは、サーバーによって、サーバーが維持する他のヘッドに反映される必要があります。 - -_質問_: -* ペアワイズヘッドの「持続時間」が変化することは想定されているのでしょうか。例えば、クライアントが来てヘッドを開き、いくつかのことを行いそれを閉じた場合、同じサーバーによって維持されている他のヘッドは開いたままですか？ -* サーバーは、ペアワイズヘッドごとにHydraヘッドの基本的な安全性を維持することをどのように保証しますか？ - * この図が示唆するのは、_ハッシュタイムロックコントラクト_ ([HTLC](https://docs.lightning.engineering/the-lightning-network/multihop-payments/hash-time-lock-contract-htlc)) を使用することで、サーバーがトランザクションをその宛先に適切にルーティングしなかった場合に、クライアントが常にUTxOを取り戻せるようにすることです。 -* どのようなトランザクションをサポートする必要がありますか？　HTLCは、支払いスタイルのトランザクションには適していますが、たとえばDAppには適していません。そうでない場合は、それらを適応させる必要があります。 - * サーバーが1つのヘッド内のトランザクションを適切なヘッドに「ルーティング」できるという暗黙の前提があるようです。これは、サーバーがヘッドに投稿されたUTxOのアドレスを「理解」していることを意味します。 - -## オンチェーントランザクション - -以下のトランザクション図は、アリス、ボブの間の2つのペアワイズヘッドのライフサイクルを表しています。 - -![Star-shaped Network On-Chain](./star-shaped-txs.png) - -_備考_: - -* これは、一方のヘッドで起こったトランザクションがもう一方のヘッドに反映され、その結果、最終的なUTxO `c` が（強く）一貫していると仮定しています。 - * つまり、両方のヘッドが同じ $U_0$ セットから始まる必要がありますが、これはどのように実行できるかわかりません（図では赤で囲んでいます）。 - * 最終的なUTxOセットの整合性が取れていれば、どのようなパーティでもFanoutが可能です。つまり、1つの`ν_head`がぶら下がったまま、既にあるUTxO（図ではグレーアウトしたトランザクション）を再現するように使用不可能になる可能性があるのです。 -* ヘッドのライフサイクルは結びついています。一方が閉じられると、もう一方も閉じられます。サーバーはそれが事実であることを確認します。 - -## オフチェーントランザクション - -次の図は、トランザクションの伝播を確実にするために、様々な「ノード」間で交換されるメッセージのシーケンスを表しています。 - -![Star-shaped Network Off-Chain Protocol](./off-chain-protocol.png) - -_備考_: - -* サーバは2つのノード `M(A)` と `M(B)` で表現されます。 -* `Alice`が自分のノードで発行した `newTx` は、サーバによって `Bob` のノードにも `newTx` として伝搬されます。 -* この図は、サーバーが`Alice` と `Bob` のどちらかまたは両方に保証を提供するために投稿する必要のある追加のトランザクション（たとえば、ヘッド内のHTLCトランザクション）を表すものではありません。 -* スナップショットの一貫性を確保するため、サーバーは常にリーダーでありスナップショットの発信をトリガーするものと仮定します。 diff --git a/docs/i18n/ja/docusaurus-plugin-content-docs-topologies/current/star-shaped/off-chain-protocol.png b/docs/i18n/ja/docusaurus-plugin-content-docs-topologies/current/star-shaped/off-chain-protocol.png deleted file mode 100644 index b2e83bd77d2..00000000000 Binary files a/docs/i18n/ja/docusaurus-plugin-content-docs-topologies/current/star-shaped/off-chain-protocol.png and /dev/null differ diff --git a/docs/i18n/ja/docusaurus-plugin-content-docs-topologies/current/star-shaped/off-chain-protocol.uml b/docs/i18n/ja/docusaurus-plugin-content-docs-topologies/current/star-shaped/off-chain-protocol.uml deleted file mode 100644 index 0c2fbbed767..00000000000 --- a/docs/i18n/ja/docusaurus-plugin-content-docs-topologies/current/star-shaped/off-chain-protocol.uml +++ /dev/null @@ -1,22 +0,0 @@ -@startuml -actor Alice - -Alice -> "Node A": newTx -"Node A" -> "Node A": reqTx -"Node A" -> "Node S(A)": reqTx -"Node S(A)" -> "Node S(B)": newTx -"Node S(B)" -> "Node S(B)": reqTx -"Node S(B)" -> "Node B": reqTx -"Node S(B)" -> "Node S(B)": reqSn -"Node S(B)" -> "Node B": reqSn -"Node B" -> "Node S(B)": ackSn -"Node S(B)" -> "Node S(B)": ackSn -"Node S(B)" -> "Node S(A)": SnapshotConfirmed - -"Node S(A)" -> "Node S(A)": reqSn -"Node S(A)" -> "Node A": reqSn -"Node S(A)" -> "Node S(A)": ackSn -"Node S(A)" -> "Node A": ackSn -"Node A" -> "Node S(A)": ackSn -"Node A" -> Alice: SnapshotConfirmed -@enduml diff --git a/docs/i18n/ja/docusaurus-plugin-content-docs-topologies/current/star-shaped/star-shaped-general.jpg b/docs/i18n/ja/docusaurus-plugin-content-docs-topologies/current/star-shaped/star-shaped-general.jpg deleted file mode 100644 index 9cc6878dc2a..00000000000 Binary files a/docs/i18n/ja/docusaurus-plugin-content-docs-topologies/current/star-shaped/star-shaped-general.jpg and /dev/null differ diff --git a/docs/i18n/ja/docusaurus-plugin-content-docs-topologies/current/star-shaped/star-shaped-txs.png b/docs/i18n/ja/docusaurus-plugin-content-docs-topologies/current/star-shaped/star-shaped-txs.png deleted file mode 100644 index 509935ae112..00000000000 Binary files a/docs/i18n/ja/docusaurus-plugin-content-docs-topologies/current/star-shaped/star-shaped-txs.png and /dev/null differ diff --git a/docs/i18n/ja/docusaurus-plugin-content-docs-topologies/current/star-shaped/start-shaped-network.dot b/docs/i18n/ja/docusaurus-plugin-content-docs-topologies/current/star-shaped/start-shaped-network.dot deleted file mode 100644 index b46ab7f8036..00000000000 --- a/docs/i18n/ja/docusaurus-plugin-content-docs-topologies/current/star-shaped/start-shaped-network.dot +++ /dev/null @@ -1,144 +0,0 @@ -digraph starshaped { - rankdir = LR; - - { node [ "shape" = "record" ]; - init_s_a [ label = "Init S+A | S" ]; - init_s_b [ label = "Init S+B | S" ]; - - commit_a [ label = "Commit | A" ]; - commit_b [ label = "Commit | B" ]; - commit_s1 [ label = "Commit | S" ]; - commit_s2 [ label = "Commit | S" ]; - - collect_com_1 [ label = "CollectCom | S" ]; - collect_com_2 [ label = "CollectCom | S" ]; - - close_1 [ label = "Close | A" ]; - close_2 [ label = "Close | S" ]; - - fanout_1 [ label = "Fan-out | A" ]; - fanout_2 [ label = "Fan-out | S", style = filled, fillcolor = "lightgray" ]; - } - - { node [ label = "", "shape" = "circle", width = "0.1" ]; - initial_s1 [ xlabel = "ν_initial" ]; - initial_s2 [ xlabel = "ν_initial" ]; - initial_a [ xlabel = "ν_initial" ]; - initial_b [ xlabel = "ν_initial" ]; - - committed_s1 [ xlabel = "∅" ]; - committed_s2 [ xlabel = "∅" ]; - committed_a [ xlabel = "a" ]; - committed_b [ xlabel = "b" ]; - - ν_commit_s1 [ xlabel = "∅" ]; - ν_commit_s2 [ xlabel = "∅" ]; - ν_commit_a [ xlabel = "a" ]; - ν_commit_b [ xlabel = "b" ]; - - c [ xlabel = "c" ]; - - head_s1 [ xlabel = "ν_head (1)" ]; - head_s2 [ xlabel = "ν_head (2)" ]; - - head_s1_open [ xlabel = "ν_head [a]" ]; - head_s2_open [ xlabel = "ν_head [b]" ]; - - head_s1_closed [ xlabel = "ν_head [c]" ]; - head_s2_closed [ xlabel = "ν_head [c]" ]; -} - -subgraph cluster_1 { - label = "off-chain head 1"; - - { node [ label = "", "shape" = "circle", width = "0.1" ]; - U_1_0_a [xlabel = "[a,b]", color = red, fontcolor = red]; - U_1_c [xlabel = "c"]; - } - - { node [ "shape" = "record" ]; - tx_1_1 [ label = "tx_1 | X"]; - tx_1_2 [ label = "tx_2 | X"]; - tx_1_3 [ label = "tx_3 | X"]; - } - - U_1_0_a -> tx_1_1; - tx_1_1 -> tx_1_2; - tx_1_2 -> tx_1_3; - tx_1_3 -> U_1_c; - -} - -subgraph cluster_2 { - label = "off-chain head 2"; - - { node [ label = "", "shape" = "circle", width = "0.1" ]; - U_2_0_b [xlabel = "[a,b]", fontcolor = red, color = red]; - U_2_c [xlabel = "c"]; - } - - { node [ "shape" = "record" ]; - tx_2_1 [ label = "tx_1 | X"]; - tx_2_2 [ label = "tx_2 | X"]; - tx_2_3 [ label = "tx_3 | X"]; - } - - U_2_0_b -> tx_2_1 -> tx_2_2 -> tx_2_3 -> U_2_c; -} - -tx_1_1 -> tx_2_1 [ style = dashed ]; -tx_2_2 -> tx_1_2 [ style = dashed ]; -tx_2_3 -> tx_1_3 [ style = dashed ]; - - init_s_a -> initial_s1 [ arrowhead = none ]; - init_s_a -> initial_a [ arrowhead = none ]; - init_s_a -> head_s1 [ arrowhead = none ]; - - init_s_b -> initial_s2 [ arrowhead = none ]; - init_s_b -> initial_b [ arrowhead = none ]; - init_s_b -> head_s2 [ arrowhead = none ]; - - initial_s1 -> commit_s1; - committed_s1 -> commit_s1; - commit_s1 -> ν_commit_s1 [ arrowhead = none ]; - - initial_s2 -> commit_s2; - committed_s2 -> commit_s2; - commit_s2 -> ν_commit_s2 [ arrowhead = none ]; - - initial_a -> commit_a; - committed_a -> commit_a; - commit_a -> ν_commit_a [ arrowhead = none ]; - - initial_b -> commit_b; - committed_b -> commit_b; - commit_b -> ν_commit_b [ arrowhead = none ]; - - - ν_commit_a -> collect_com_1; - ν_commit_s1 -> collect_com_1; - head_s1 -> collect_com_1; - collect_com_1 -> head_s1_open [ arrowhead = none ]; - - ν_commit_b -> collect_com_2; - ν_commit_s2 -> collect_com_2; - head_s2 -> collect_com_2; - collect_com_2 -> head_s2_open [ arrowhead = none ]; - - head_s1_open -> U_1_0_a [ style = dotted ]; - head_s2_open -> U_2_0_b [ style = dotted ]; - - U_1_c -> close_1 [ style = dotted ]; - U_2_c -> close_2 [ style = dotted ]; - head_s1_open -> close_1; - head_s2_open -> close_2; - close_1 -> head_s1_closed [ arrowhead = none ]; - close_2 -> head_s2_closed [ arrowhead = none ]; - - close_1 -> close_2 [ style = dashed ]; - - head_s1_closed -> fanout_1; - fanout_1 -> c [ arrowhead = none ]; - - head_s2_closed -> fanout_2; -} diff --git a/docs/i18n/ja/docusaurus-plugin-content-docs/current.json b/docs/i18n/ja/docusaurus-plugin-content-docs/current.json deleted file mode 100644 index 6599c766bc0..00000000000 --- a/docs/i18n/ja/docusaurus-plugin-content-docs/current.json +++ /dev/null @@ -1,14 +0,0 @@ -{ - "version.label": { - "message": "次へ", - "description": "The label for version current" - }, - "sidebar.defaultSidebar.category.Getting Started": { - "message": "はじめに", - "description": "The label for category Getting Started in sidebar defaultSidebar" - }, - "sidebar.defaultSidebar.category.Demo": { - "message": "デモ", - "description": "The label for category Demo in sidebar defaultSidebar" - } -} diff --git a/docs/i18n/ja/docusaurus-plugin-content-docs/current/getting-started/_category_.json b/docs/i18n/ja/docusaurus-plugin-content-docs/current/getting-started/_category_.json deleted file mode 100644 index d182f9eec5e..00000000000 --- a/docs/i18n/ja/docusaurus-plugin-content-docs/current/getting-started/_category_.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "label": "はじめに", - "position": 1 -} diff --git a/docs/i18n/ja/docusaurus-plugin-content-docs/current/getting-started/demo/_category_.json b/docs/i18n/ja/docusaurus-plugin-content-docs/current/getting-started/demo/_category_.json deleted file mode 100644 index a261c72258b..00000000000 --- a/docs/i18n/ja/docusaurus-plugin-content-docs/current/getting-started/demo/_category_.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "label": "Demo", - "position": 4 -} diff --git a/docs/i18n/ja/docusaurus-plugin-content-docs/current/getting-started/demo/index.md b/docs/i18n/ja/docusaurus-plugin-content-docs/current/getting-started/demo/index.md deleted file mode 100644 index f5ebd593e49..00000000000 --- a/docs/i18n/ja/docusaurus-plugin-content-docs/current/getting-started/demo/index.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -sidebar_position: 1 ---- - -# デモ - -> Hydra Headプロトコルのデモを行うための標準的なデモセットアップです。 - -デモの構成: - -- 互いに直接接続された3つのHydraノードからなるクラスタで、それぞれが3つのHydraクレデンシャル `alice`, `bob`, `carol` のいずれかにアクセス -- ローカル開発ネットとして稼働する単一のブロック生成カルダノノード -- メトリクス収集用Prometheusサーバー -- 個々のHydraノードと対話するためのアドホック端末ユーザーインターフェイスクライアント - -```mdx-code-block -import DocCardList from '@theme/DocCardList'; -import {useCurrentSidebarCategory} from '@docusaurus/theme-common'; - - -``` - - - -

- -:::caution Disclaimer -このビデオは、例として基本的なターミナルユーザーインターフェイスを実演しています。裏側では、端末クライアントはHydraノードによって提供されるWebSocket APIに依存しており、これはアプリケーションが使用する可能性が高いものです。 -::: diff --git a/docs/i18n/ja/docusaurus-plugin-content-docs/current/getting-started/demo/with-docker.md b/docs/i18n/ja/docusaurus-plugin-content-docs/current/getting-started/demo/with-docker.md deleted file mode 100644 index e9643706f3d..00000000000 --- a/docs/i18n/ja/docusaurus-plugin-content-docs/current/getting-started/demo/with-docker.md +++ /dev/null @@ -1,87 +0,0 @@ ---- -sidebar_position: 2 ---- - -# Docker で使用 - -```mdx-code-block -import TerminalWindow from '@site/src/components/TerminalWindow'; -``` - -この項では [Docker](https://www.docker.com/get-started) と [compose](https://www.docker.com/get-started) を使ってデモを実行します。高度な方法で実行したい場合は [Docker を使用しないデモの実行](/docs/getting-started/demo/without-docker) へ移動してください。 - -:::info Shortcut -便宜上、上記の手順をまとめたスクリプト `./run-docker.sh` を用意しており、サニティーチェックを行うことができます。 -::: - -:::info Context -以下のコマンドはすべて、プロジェクトリポジトリの `demo` フォルダから実行されるものとして書かれています。したがって、何かをする前にリポジトリをクローンして `cd demo` を実行して該当ディレクトリにポインターを合わせてください。 -::: - -:::warning OS Compatibility -この手順は、Linux 環境（Ubuntu、NixOS）のみで検証しています。Windows や Mac OS X の場合は、[Volumes](https://docs.docker.com/storage/volumes/)を使用するする必要があるかもしれません。 -::: - -## ネットワークの設定 - -まずは、compose ファイルに定義されているサービスに必要なイメージを取得しましょう。 - -```mdx-code-block - -docker-compose --profile tui --profile hydra-node pull - -``` - -ここから、`./prepare-devnet.sh`スクリプトを実行して、開発用ネットワークの初期設定を作成することができます。 これは、Cardano ブロックチェーンを起動するために必要なジェネシスファイルを作成します。なお、今回のデモでは、ステークプールを一切必要としないシンプルな構成を使用しています。 - -```mdx-code-block - -./prepare-devnet.sh - -``` - -前置きは以上です。これで、ネットワークを立ち上げることができます。 - -```mdx-code-block - -docker-compose up -d cardano-node - -``` - -:::caution Caution! -genesis ブロックから始まるアドホックなプライベート開発ネットを使用するため、開発ネットの設定が最新であることを都度確認する必要があります。 Cardano ノードから `TraceNoLedgerView` エラーが発生した場合、開始時刻が過去になっているため、 `prepare-devnet.sh` スクリプトを使って更新する必要があります。 -::: - -`docker-compose logs cardano-node -f` を使用してログをチェックすることで、ノードが稼働中であることを確認できます。 `TraceAdoptedBlock`を含むトレースが表示されるはずです。これは、devnet がブロックを生成していることを意味します。 - -## ネットワークの構築 - -同梱スクリプトの `./seed-devnet.sh` は、すでに実行中の `cardano-node` コンテナにある `cardano-cli` を使って、アリス、ボブ、キャロルにコミットする いくつかの UTXO エントリと燃料の UTXO を渡します。 - -```mdx-code-block - -./seed-devnet.sh - -``` - -## Hydra ノードの開始 - -最後に、オンチェーンの準備が整ったので、次のコマンドを実行して Hydra ネットワーク (つまり、アリス、ボブ、キャロルの 3 つのノードすべて) を立ち上げることができます。 - -```mdx-code-block - -docker-compose --profile hydra-node up -d - -``` - -## クライアントの実行 - -compose を使うと、Hydra ノードと対話するためのデモ用ターミナルベースユーザーインターフェイス (別名 `hydra-tui`) を起動することができます。 compose の定義には、`hydra-tui-1`, `hydra-tui-2`, `hydra-tui-3` という 3 つの TUI サービスがあらかじめ設定されています。ターミナルで最初の Hydra ノードに接続するために、以下のコマンドを実行します。 - -```mdx-code-block - -docker-compose --profile tui run hydra-tui-1 - -``` - -これは、最初の Hydra ノードに対応する署名キーをロードした本格的なターミナルインタフェースを開始するものです。他の端末では、`hydra-tui-2`と`hydra-tui-3`のサービスをターゲットとして、同様の方法で他のノードを起動することができます。 diff --git a/docs/i18n/ja/docusaurus-plugin-content-docs/current/getting-started/demo/without-docker.md b/docs/i18n/ja/docusaurus-plugin-content-docs/current/getting-started/demo/without-docker.md deleted file mode 100644 index 6259b1c9373..00000000000 --- a/docs/i18n/ja/docusaurus-plugin-content-docs/current/getting-started/demo/without-docker.md +++ /dev/null @@ -1,185 +0,0 @@ ---- -sidebar_position: 3 ---- - -# 実行ファイルで使用(Dockerなし) - -```mdx-code-block -import TerminalWindow from '@site/src/components/TerminalWindow'; -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; -``` - -> Dockerコンテナなしで、実行ファイルとスクリプトでデモを実行します。 - -## 準備 - -スコープに「cardano-node」、「hydra-node」、および「hydra-tui」実行可能ファイルがあることを確認してください。 次のいずれかを実行できます - - - `nix develop .#demo` を使用するか、 - - `cabal build` と `cabal exec` を実行します (さらに引数を渡す前に `--` を忘れないでください)。 - -:::info tmux ユーザー向けのヒント -`demo` nix shell には、以下のすべてのコマンドを実行する複数のウィンドウとペインで新しい `tmux` セッションを開始する `run-hydra-demo` スクリプトがあります! -::: - -以降のすべてのコマンドは、プロジェクト リポジトリの `demo` フォルダから実行されるかのように記述されるため、続行する前に必ず `cd demo` を実行してください。 - -:::info nix-direnv ユーザー向けのヒント -`demo/.envrc` を許可すると、`demo/` ディレクトリにいるときはいつでも nix シェル環境を利用できるようになります。 これを使用するには、`cd demo` の後に `direnv allow` でオプトインします。 -::: - -## ネットワークの設定 - -まず、単一の `cardano-node` 開発ネット を用意し、この設定を使って起動します。カレントディレクトリに `devnet` ディレクトリが作成されることに注意してください。 - -````mdx-code-block - - -``` -./prepare-devnet.sh -cd devnet -mkdir ipc -cabal exec cardano-node -- run \ - --config cardano-node.json \ - --topology topology.json \ - --database-path db \ - --socket-path node.socket \ - --shelley-operational-certificate opcert.cert \ - --shelley-kes-key kes.skey \ - --shelley-vrf-key vrf.skey -``` - - -```` - -## Seeding The Network - -You can use the `seed-devnet.sh` script by passing it the path/command to a cardano-cli and hydra-node executable to use, instead of having it using the Docker container. For example: - - - - -``` -export CARDANO_NODE_SOCKET_PATH=devnet/node.socket -./seed-devnet.sh $(which cardano-cli) $(which hydra-node)" -``` - - - -Note, should you want to use `cabal`, pass the invocation for example like this `"cabal exec hydra-node --"`. - -## Setting-up The Hydra Network - -次に、3つの異なる端末で、`demo/` ディレクトリから3つの Hydra ノードを起動します。 - - -:::info Note -We are trying to force ipv4 addresses by using `--peer 127.0.0.1`. -If you don't see any connected peers in the tui it probably means that your system is configured to use ipv6. -::: - -````mdx-code-block - - - - - -``` -source .env && hydra-node \ - --node-id 1 --port 5001 --api-port 4001 --monitoring-port 6001 \ - --peer 127.0.0.1:5002 \ - --peer 127.0.0.1:5003 \ - --hydra-signing-key alice.sk \ - --hydra-verification-key bob.vk \ - --hydra-verification-key carol.vk \ - --cardano-signing-key devnet/credentials/alice.sk \ - --cardano-verification-key devnet/credentials/bob.vk \ - --cardano-verification-key devnet/credentials/carol.vk \ - --ledger-protocol-parameters devnet/protocol-parameters.json \ - --testnet-magic 42 \ - --node-socket devnet/node.socket -``` - - - - - - - -``` -source .env && hydra-node \ - --node-id 2 --port 5002 --api-port 4002 --monitoring-port 6002 \ - --peer 127.0.0.1:5001 \ - --peer 127.0.0.1:5003 \ - --hydra-signing-key bob.sk \ - --hydra-verification-key alice.vk \ - --hydra-verification-key carol.vk \ - --cardano-signing-key devnet/credentials/bob.sk \ - --cardano-verification-key devnet/credentials/alice.vk \ - --cardano-verification-key devnet/credentials/carol.vk \ - --ledger-protocol-parameters devnet/protocol-parameters.json \ - --testnet-magic 42 \ - --node-socket devnet/node.socket -``` - - - - - - - -``` -source .env && hydra-node \ - --node-id 3 --port 5003 --api-port 4003 --monitoring-port 6003 \ - --peer 127.0.0.1:5001 \ - --peer 127.0.0.1:5002 \ - --hydra-signing-key carol.sk \ - --hydra-verification-key alice.vk \ - --hydra-verification-key bob.vk \ - --cardano-signing-key devnet/credentials/carol.sk \ - --cardano-verification-key devnet/credentials/alice.vk \ - --cardano-verification-key devnet/credentials/bob.vk \ - --ledger-protocol-parameters devnet/protocol-parameters.json \ - --testnet-magic 42 \ - --node-socket devnet/node.socket -``` - - - - - - -```` - -うまくいけば、チェーンに接続されたノードはログ収集を開始します。 - -## ネットワークの構築 - -Dockerコンテナを使用する代わりに、使用するcardano-cli実行可能ファイルへのパスを渡すことで、`seed-devnet.sh`スクリプトを使用できます。 例えば： - - -```mdx-code-block - -./seed-devnet.sh $(which cardano-cli) - -``` - -## クライアントの実行 -hydra-tuiを使ってノードに接続します。例えば、アリスのハイドラノードと彼女のオンチェーンクレデンシャルを使用する場合。 - -````mdx-code-block - - -``` -cabal exec hydra-tui -- \ - --connect 0.0.0.0:4001 \ - --cardano-signing-key devnet/credentials/alice.sk \ - --testnet-magic 42 \ - --node-socket devnet/node.socket -``` - - -```` - -ポート `4001` を `4002` または `4003` に置き換えて他の2ノードに接続し、 `alice.sk` をそれぞれ `bob.sk` または `carol.sk` に置き換えてください。 diff --git a/docs/i18n/ja/docusaurus-plugin-content-docs/current/getting-started/index.md b/docs/i18n/ja/docusaurus-plugin-content-docs/current/getting-started/index.md deleted file mode 100644 index 63b7cbf4d40..00000000000 --- a/docs/i18n/ja/docusaurus-plugin-content-docs/current/getting-started/index.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -sidebar_position: 1 ---- - -# はじめに - -```mdx-code-block -import DocCardList from '@theme/DocCardList'; -import {useCurrentSidebarCategory} from '@docusaurus/theme-common'; - - -``` diff --git a/docs/i18n/ja/docusaurus-plugin-content-docs/current/getting-started/installation.md b/docs/i18n/ja/docusaurus-plugin-content-docs/current/getting-started/installation.md deleted file mode 100644 index b70030ce925..00000000000 --- a/docs/i18n/ja/docusaurus-plugin-content-docs/current/getting-started/installation.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -sidebar_position: 2 ---- - -# インストール - -```mdx-code-block -import TerminalWindow from '@site/src/components/TerminalWindow'; -``` - -> ハイドラの入手先は？ - -## Dockerの使用 -hydra-nodeを動かす一番迅速な方法は、専用のDockerイメージを使うことです。 - -````mdx-code-block - - -``` -docker pull ghcr.io/input-output-hk/hydra-node -docker run --rm ghcr.io/input-output-hk/hydra-node --help -``` - - -```` - -## ソースからの構築 - -docker を使用することが Hydra を _use_ するための推奨される方法ですが、ソースから `hydra-node` をビルドすることもできます。 ただし、これには [nix](https://nixos.org/download.html) を使用することをお勧めします。手順については、[寄稿ガイドライン](https://github.com/input-output-hk/hydra/blob/master/CONTRIBUTING.md) を参照してください。 diff --git a/docs/i18n/ja/docusaurus-plugin-content-docs/current/getting-started/quickstart.md b/docs/i18n/ja/docusaurus-plugin-content-docs/current/getting-started/quickstart.md deleted file mode 100644 index 9d3e13bf7f4..00000000000 --- a/docs/i18n/ja/docusaurus-plugin-content-docs/current/getting-started/quickstart.md +++ /dev/null @@ -1,197 +0,0 @@ ---- -sidebar_position: 3 ---- - -# クイックスタート - -```mdx-code-block -import TerminalWindow from '@site/src/components/TerminalWindow'; -``` - -> `hydra-node`を使用した最初のステップ。 - -Hydra ヘッドを動かすということは、他の複数の Hydra ノードに接続され、Cardano ノードに接続された Hydra ノードを動かすということです。したがって、 [cardano-node](https://github.com/input-output-hk/cardano-node/) の実行は Hydra ヘッドを動かすための前提条件となります。このガイドでは、Cardano ノードの実行に関する詳細については説明しませんので、必要であれば、この件に関する既存のドキュメントを探してください。 - -:::tip cardano-node & cardano-cli -Cardano ノードの実行には、コンテナや[公式 Docker イメージ](https://hub.docker.com/r/inputoutput/cardano-node)の使用を推奨しています。 - -このイメージには `cardano-node` と `cardano-cli` の両方が含まれています。`cardano-cli`は様々なコマンドを実行するのに便利で、例えばアドレスの作成や鍵の生成を行うことができます。 -::: - -## Hydra-node のオプション... - -`hydra-node` の構成全体は、コマンドライン オプションを使用して提供されます。 オプションは、ネットワーク、API、チェーン接続、および使用される台帳のさまざまな要素を構成するために使用されます。 `--help` オプションを使用して、すべてのオプションの説明を取得できます。 - -``` -hydra-node - Implementation of the Hydra Head protocol - -Usage: hydra-node ([-q|--quiet] (-n|--node-id NODE-ID) [-h|--host IP] - [-p|--port PORT] [-P|--peer ARG] [--api-host IP] - [--api-port PORT] [--monitoring-port PORT] - [--hydra-signing-key FILE] [--hydra-verification-key FILE] - [--hydra-scripts-tx-id TXID] [--persistence-dir DIR] - [--mainnet | --testnet-magic NATURAL] [--node-socket FILE] - [--cardano-signing-key FILE] - [--cardano-verification-key FILE] - [--start-chain-from SLOT.HEADER_HASH] - [--contestation-period CONTESTATION-PERIOD] - [--ledger-protocol-parameters FILE] | - COMMAND) [--version] [--script-info] - - Starts a Hydra Node - -Available options: - -q,--quiet Turns off logging. - -n,--node-id NODE-ID The Hydra node identifier used on the Hydra network. - It is important to have a unique identifier in order - to be able distinguish between connected peers. - -h,--host IP Listen address for incoming Hydra network - connections. (default: 127.0.0.1) - -p,--port PORT Listen port for incoming Hydra network connections. - (default: 5001) - -P,--peer ARG A peer address in the form :, where - can be an IP address, or a host name. Can be - provided multiple times, once for each peer (current - maximum limit is 4 peers). - --api-host IP Listen address for incoming client API connections. - (default: 127.0.0.1) - --api-port PORT Listen port for incoming client API connections. - (default: 4001) - --monitoring-port PORT Listen port for monitoring and metrics via - prometheus. If left empty, monitoring server is not - started. - --hydra-signing-key FILE Hydra signing key used by our hydra-node. - (default: "hydra.sk") - --hydra-verification-key FILE - Hydra verification key of another party in the Head. - Can be provided multiple times, once for each - participant (current maximum limit is 4 ). - --hydra-scripts-tx-id TXID - The transaction which is expected to have published - Hydra scripts as reference scripts in its outputs. - Note: All scripts need to be in the first 10 outputs. - See release notes for pre-published versions. You can - use the 'publish-scripts' sub-command to publish them - yourself. - --persistence-dir DIR The directory where the Hydra Head state is stored.Do - not edit these files manually! - --mainnet Use the mainnet magic id. - --testnet-magic NATURAL Network identifier for a testnet to connect to. We - only need to provide the magic number here. For - example: '2' is the 'preview' network. See - https://book.world.dev.cardano.org/environments.html - for available networks. (default: 42) - --node-socket FILE Filepath to local unix domain socket used to - communicate with the cardano node. - (default: "node.socket") - --cardano-signing-key FILE - Cardano signing key of our hydra-node. This will be - used to authorize Hydra protocol transactions for - heads the node takes part in and any funds owned by - this key will be used as 'fuel'. - (default: "cardano.sk") - --cardano-verification-key FILE - Cardano verification key of another party in the - Head. Can be provided multiple times, once for each - participant (current maximum limit is 4). - --start-chain-from SLOT.HEADER_HASH - The id of the block we want to start observing the - chain from. If not given, uses the chain tip at - startup. Composed by the slot number, a separator - ('.') and the hash of the block header. For example: - 52970883.d36a9936ae7a07f5f4bdc9ad0b23761cb7b14f35007e54947e27a1510f897f04. - --contestation-period CONTESTATION-PERIOD - Contestation period for close transaction in seconds. - If this value is not in sync with other participants - hydra-node will ignore the initial tx. Additionally, - this value needs to make sense compared to the - current network we are running. (default: 60s) - --ledger-protocol-parameters FILE - Path to protocol parameters used in the Hydra Head. - See manual how to configure this. - (default: "protocol-parameters.json") - --version Show version - --script-info Dump script info as JSON - -h,--help Show this help text - -Available commands: - publish-scripts Publish Hydra's Plutus scripts on chain to be used - by the hydra-node as --hydra-script-tx-id. - - ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ - ┃ ⚠ WARNING ⚠ ┃ - ┣═══════════════════════════════════════┫ - ┃ This costs money. About 50 Ada. ┃ - ┃ Spent using the provided signing key. ┃ - ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛ -``` - -:::info Dynamic Configuration - -現在のコマンドラインは、ユーザーフレンドリーとは言い難く、大規模なクラスタのセットアップにはやや使いにくいということは認識しています。 - -しかし、より使いやすく、動的に設定できるようにする計画があります。[#240](https://github.com/input-output-hk/hydra/issues/240) & [ADR-15](/adr/15) を参照してください。 -::: - -## 詳細について - -### カルダノ鍵(キー) - -前の項目では、Hydra ノードのセットアップに必要なさまざまなオプションと要素について説明しました。この項目では、取得方法についてその一部をご紹介します。まず、Cardano キーファイル(`--cardano-signing-key` と `--cardano-verification-key`)からです。 - -ヘッド内において、参加者は 2 組の鍵で認証されます。 1 組の鍵ペアは、Cardano ですでに一般的な Ed25519 の公開鍵/秘密鍵ペアです。このような鍵ペアは `cardano-cli` を用いて以下のように生成することができます。 - -```mdx-code-block - -cardano-cli address key-gen --verification-key-file cardano.vk --signing-key-file cardano.sk - -``` - -各参加者は自分の検証キーを他の参加者と共有することになります。 ノードを起動するには、**自分の署名キー**と**他の参加者の検証キー**が必要です。これらの鍵は現在、Hydra プロトコルの実行を促すオンチェーン・トランザクションの認証に使用されています。これは、望まれないアクターがヘッドのライフサイクルをいじくり回すのを防ぐためです（たとえば、ヘッドの外部の誰かが、初期化されたヘッドを中止させることができるのです）。これはヘッド参加者の資金を危険にさらすものではありませんが、それでも防ぎたい厄介なものです。 - -### Hydra 鍵(キー) - -2 つ目のキーセットは、いわゆる Hydra キーで、Head 内のスナップショットのマルチシグネチャに使用されるものです。長期的には、これらの鍵は MuSig2 アグリゲーション・マルチシグネチャ方式で使用されるキーペアとなる予定です。しかし、現時点では、集約型マルチシグネチャ暗号は[未実装](https://github.com/input-output-hk/hydra/issues/193)で、Hydra ノードは Ed25519 鍵に基づく安全なマルチシグネチャ方式となります。 - -これらはカルダノキーに似ていますが、混同しないでください。したがって、基本的にキーマテリアルで直接構成される別の基本的なディスク上の表現を使用します（カルダノキーは通常、テキストエンベロープに CBOR エンコードされて保存されます）。デモ用の鍵ペアは、 `alice.{vk,sk}`、 `bob.{vk,sk}` 、 `carol.{vk,sk}` を [demo folder](https://github.com/input-output-hk/hydra/tree/master/demo)に用意しています。 現在、参加者はその中から 1 つを選び、Cardano の鍵と同様の方法で、検証鍵を仲間と共有し、署名鍵を彼らに使うことが期待されている。 (TODO: システムのエントロピーを利用して新しいものを生成する簡単な方法を提供すべきである) - -### 元帳パラメーター - -ヒドラの頭の中核には台帳があります。 現時点では、Hydra は Cardano にのみ接続されており、レイヤー 1 で使用されているものと同様のレジャー構成を想定しています。これは、コマンドライン オプション `--ledger-protocol-parameters` として変換されます。 これにより、料金やトランザクション サイズなどの更新可能なプロトコル パラメーターが定義されます。 これらは、cardano-cli で使用される形式と同じ形式を使用します (例: `cardano-cli query protocol-parameters`の出力)。 - -[hydra-cluster/config](https://github.com/input-output-hk/hydra/blob/master/hydra-cluster/config)に既存のファイルを提供しており、これをベースに利用することができます。特に、ヘッド内のコストを無効化するためのプロトコルパラメータが定義されています。それとは別に、現在のメインネットのパラメータもそのままコピーしています。ヒドラの台帳の面白いところは、レイヤー 1 と同じルールやコードを再利用している（いわゆる同型）にもかかわらず、パラメーターがレイヤー 1 とは若干異なるように変更されている点です。これは料金の場合ですが、例えばスクリプトの最大実行予算などでも可能です。ただし、すべてのパラメータが安全に変更できるわけではありません。値の最大サイズ（ネイティブアセットを運ぶ）を制御するパラメータや、UTxO の最小 Ada 値を変更すると、ヘッドが「closable」になってしまう可能性があります。経験則から言うと、取引に厳密に適用されるもの（手数料、実行単位、最大 TX サイズ...）は変更しても安全である。しかし、UTxO に反映される可能性があるものは、そうではありません。 - -:::info About Protocol Parameters -ほとんどのプロトコルパラメータは、まず第一に Genesis パラメータであるため、2 つのファイルの間に少し重複があることに注意してください。さらに、これらのパラメーターの多くは、Hydra のコンテキストでは実際には無関係です（たとえば、Head の中に金庫やステークプールがないため、報酬インセンティブまたは委任ルールを構成するパラメーターは使用できません）。 -::: - -### Fuel - -Finally, one last bit necessary to get Hydra nodes up and running is to add funds to their "internal wallet". All the transactions driving the Head lifecycle (Init, Commit, Close, ...) need to be submitted to the layer 1, and hence they cost money! - -For that, any funds owned by the `--cardano-signing-key` given to the `--hydra-node` will be considered spendable to pay fees or use as collateral for these Hydra protocol transactions. Consequently, sending some ADA-only funds to the address of the this "internal wallet" is required. To get the address for the cardano keys as generated above, one can use for example the cardano-cli: - - - -```sh -cardano-cli address build --verification-key-file cardano.vk --mainnet -# addr1v92l229athdj05l20ggnqz24p4ltlj55e7n4xplt2mxw8tqsehqnt -``` - - - -## External commits - -While the `hydra-node` holds funds to fuel protocol transactions, any wallet can be used to commit funds into an `initializing` Hydra head. The `hydra-node` provides an HTTP endpoint at `/commit`, which allows to specify multiple UTxO (belonging to public key or script address) and returns a draft transaction. This transaction is already balanced and all fees are paid by the funds held by the `hydra-node`, but is missing witnesses for the public key outputs to commit. Hence, an integrated wallet would need to sign this transaction and submit it to the Cardano network. See the [api documentation](pathname:///api-reference/#operation-publish-/commit) for details. - -## セットアップ例 - -### Google クラウドと Terraform - -クラウド上の仮想マシン上で Hydra ノードをホストするためのサンプルノード構成を[sample-node-config/](https://github.com/input-output-hk/hydra/tree/master/sample-node-config/gcp/)ディレクトリに提供しています。 特に、このセットアップには [docker-compose.yaml](https://github.com/input-output-hk/hydra/blob/master/sample-node-config/gcp/docker-compose.yaml) という仕様があり、cardano-node + hydra-node サービスを設定するための良いテンプレートが提供されています。また、クラスタをセットアップするための様々な便利なスクリプトも提供されています。 - -## Running on Mainnet - -Hydra node is compatible with the mainnet network. To choose this network you need to specify `--mainnet` flag for the network id in the hydra-node arguments. We publish the hydra scripts on each new release and you can find them on the [release page](https://github.com/input-output-hk/hydra/releases) (look for section _Hydra Scripts_). - -Please be sure to read the [relevant section](/docs/known-issues) section to fully understand the limitations and consequences of running Hydra nodes on mainnet. diff --git a/docs/i18n/ja/docusaurus-plugin-content-docs/current/haskell_packages.md b/docs/i18n/ja/docusaurus-plugin-content-docs/current/haskell_packages.md deleted file mode 100644 index 1bf1e2db34b..00000000000 --- a/docs/i18n/ja/docusaurus-plugin-content-docs/current/haskell_packages.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -sidebar_position: 99 ---- - -# Haskellパッケージ - -Hydraプロジェクトは、プロトコルのさまざまな部分を満たす複数のHaskellパッケージに分かれています。一部のパッケージは内部的でHydraプロジェクト専用ですが、汎用的なものもあり、同様の問題に直面している他のプロジェクトに役立つ可能性もあります。 いずれにしても [Haddock](https://www.haskell.org/haddock/) ドキュメントに全てを公開します。 - -## 公開パッケージ - -| パッケージ | 概要 | -| --- | --- | -| [plutus-merkle-tree](/haddock/plutus-merkle-tree/index.html) | オンチェーンPlutusバリデータと互換性があるマークルツリーの実装 | -| [plutus-cbor](/haddock/plutus-cbor/index.html) | オンチェーンPlutusバリデータと互換性のあるCBORエンコーダの実装 | -| [hydra-prelude](/haddock/hydra-prelude/index.html) | 他のHydraパッケージで使用されるカスタムHydra導入部 | -| [hydra-cardano-api](/haddock/hydra-cardano-api/index.html) | 期間特化型と追加ユーティリティを持つ `cardano-api` ラッパー| - -## 内部パッケージ - -| パッケージ | 概要 | -| --- | --- | -| [hydra-node](/haddock/hydra-node/index.html) | Hydraノード | -| [hydra-node tests](/haddock/hydra-node/tests/index.html) | Hydraノードのテストコード | -| [hydra-tui](/haddock/hydra-tui/index.html) | Hydraノードを管理するためのターミナルユーザーインターフェイス（TUI） | -| [hydra-plutus](/haddock/hydra-plutus/index.html) | Hydra Plutusコントラクト | -| [hydra-cluster](/haddock/hydra-cluster/index.html) | CardanoとHydraノードのローカルクラスタを用いた統合テストパッケージ | \ No newline at end of file diff --git a/docs/i18n/ja/docusaurus-plugin-content-docs/current/hydra-head-lifecycle.svg b/docs/i18n/ja/docusaurus-plugin-content-docs/current/hydra-head-lifecycle.svg deleted file mode 100644 index f8b033c68aa..00000000000 --- a/docs/i18n/ja/docusaurus-plugin-content-docs/current/hydra-head-lifecycle.svg +++ /dev/null @@ -1 +0,0 @@ - \ No newline at end of file diff --git a/docs/i18n/ja/docusaurus-theme-classic/footer.json b/docs/i18n/ja/docusaurus-theme-classic/footer.json deleted file mode 100644 index 306d4559b4d..00000000000 --- a/docs/i18n/ja/docusaurus-theme-classic/footer.json +++ /dev/null @@ -1,54 +0,0 @@ -{ - "link.title.Contributing": { - "message": "貢献", - "description": "The title of the footer links column with title=Contributing in the footer" - }, - "link.title.Community": { - "message": "コミュニティ", - "description": "The title of the footer links column with title=Community in the footer" - }, - "link.title.More": { - "message": "その他", - "description": "The title of the footer links column with title=More in the footer" - }, - "link.item.label.Coding Standards": { - "message": "コーディング規約", - "description": "The label of footer link with label=Coding Standards linking to https://github.com/input-output-hk/hydra/wiki/Coding-Standards" - }, - "link.item.label.Architectural Decision Records": { - "message": "アーキテクチャデシジョンレコード", - "description": "The label of footer link with label=Architectural Decision Records linking to /adr" - }, - "link.item.label.Testing Strategy": { - "message": "テスト戦略", - "description": "The label of footer link with label=Testing Strategy linking to https://github.com/input-output-hk/hydra/wiki/Testing-Strategy" - }, - "link.item.label.Discord (#ask-hydra)": { - "message": "Discord (#ask-hydra)", - "description": "The label of footer link with label=Discord (#ask-hydra) linking to https://discord.gg/Qq5vNTg9PT" - }, - "link.item.label.Github Discussions": { - "message": "Githubディスカッション", - "description": "The label of footer link with label=Github Discussions linking to https://github.com/input-output-hk/hydra/discussions" - }, - "link.item.label.Stack Exchange": { - "message": "Stack Exchange", - "description": "The label of footer link with label=Stack Exchange linking to https://cardano.stackexchange.com/questions/tagged/hydra" - }, - "link.item.label.Haskell Packages": { - "message": "Haskellパッケージ", - "description": "The label of footer link with label=Haskell Packages linking to /docs/haskell_packages" - }, - "link.item.label.Logbook": { - "message": "Logbook", - "description": "The label of footer link with label=Logbook linking to https://github.com/input-output-hk/hydra/wiki/Logbook" - }, - "link.item.label.Input Output (Blog)": { - "message": "Input Output (ブログ)", - "description": "The label of footer link with label=Input Output (Blog) linking to https://iohk.io/en/blog" - }, - "copyright": { - "message": "Copyright © 2022 Input Output
Built with Docusaurus", - "description": "The footer copyright" - } -} diff --git a/docs/i18n/ja/docusaurus-theme-classic/navbar.json b/docs/i18n/ja/docusaurus-theme-classic/navbar.json deleted file mode 100644 index 6dc5bf8a61f..00000000000 --- a/docs/i18n/ja/docusaurus-theme-classic/navbar.json +++ /dev/null @@ -1,30 +0,0 @@ -{ - "title": { - "message": "Hydra: Head Protocol", - "description": "The title in the navbar" - }, - "item.label.User Manual": { - "message": "ユーザーズマニュアル", - "description": "Navbar item with label User Manual" - }, - "item.label.Core Concepts": { - "message": "コアコンセプト", - "description": "Navbar item with label Core Concepts" - }, - "item.label.Topologies": { - "message": "トポロジー", - "description": "Navbar item with label Topologies" - }, - "item.label.Benchmarks": { - "message": "ベンチマーク", - "description": "Navbar item with label Benchmarks" - }, - "item.label.API Reference": { - "message": "APIリファレンス", - "description": "Navbar item with label API Reference" - }, - "item.label.GitHub": { - "message": "GitHub", - "description": "Navbar item with label GitHub" - } -} diff --git a/docs/sidebars.js b/docs/sidebars.js new file mode 100644 index 00000000000..09a4f689fe3 --- /dev/null +++ b/docs/sidebars.js @@ -0,0 +1,97 @@ +module.exports = { + userDocumentation: [ + { + type: "doc", + label: "Welcome", + id: "index", + }, + { + type: "doc", + id: "protocol-overview", + label: "Protocol overview", + }, + "known-issues", + { + type: "html", + value: "Tutorials", + defaultStyle: true, + className: "sidebar-header", + }, + { + type: "doc", + id: "getting-started", + label: "Getting started", + }, + { + type: "doc", + id: "tutorial/index", + label: "Open a head on testnet", + }, + { + type: "html", + value: "Documentation", + defaultStyle: true, + className: "sidebar-header", + }, + { + type: "doc", + id: "installation", + label: "Installation", + }, + { + type: "doc", + id: "configuration", + label: "Configuration", + }, + { + type: "category", + label: "How to ...", + // collapsed: true, + // collapsible: true, + items: [ + { + type: "autogenerated", + dirName: "how-to", + }, + ], + }, + { + type: "doc", + id: "faq", + label: "FAQ", + }, + { + type: "html", + value: "Reference", + defaultStyle: true, + className: "sidebar-header", + }, + { + type: "link", + href: "https://github.com/input-output-hk/hydra/releases", + label: "Release notes", + }, + { + type: "link", + href: "/api-reference", + label: "API reference", + }, + { + type: "link", + href: "/benchmarks", + label: "Benchmarks", + }, + ], + + developerDocumentation: [ + { + type: "autogenerated", + dirName: "dev", + }, + { + type: "link", + href: "/adr", + label: "Architecture Decision Records", + }, + ], +}; diff --git a/docs/src/css/custom.css b/docs/src/css/custom.css index 15b7326e2d7..aed525fbcc6 100644 --- a/docs/src/css/custom.css +++ b/docs/src/css/custom.css @@ -26,6 +26,11 @@ background-color: rgba(0, 0, 0, 0.3); } +/* Custom sidebar section headers */ +.sidebar-header { + opacity: 0.9; +} + /* Ensure footer is drawn over api reference side bar. */ .footer { z-index: 20; @@ -91,7 +96,7 @@ } } -svg.architecture{ +svg.architecture { width: 100% !important; height: 100% !important; } diff --git a/docs/standalone/audit-guidelines.md b/docs/standalone/audit-guidelines.md index 8ae1d0b0502..337f106172a 100644 --- a/docs/standalone/audit-guidelines.md +++ b/docs/standalone/audit-guidelines.md @@ -117,7 +117,7 @@ This sections gives a detailed description of the artifacts mentioned above in t The Hydra Head protocol implementation derives from [Hydra: Fast Isomorphic State Channels](https://eprint.iacr.org/2020/299.pdf) in several ways. Especially some simplifications have been introduced and generalizations removed. -The [Hydra Head specification](/core-concepts/specification) captures these deviations and also includes the "formal notation" of the actual transaction constraints (which are foregone in the original paper). Also, it details the L2 protocol logic for the **Coordinated** Head protocol - which is implemented in V1. +The [Hydra Head specification](/docs/dev/specification) captures these deviations and also includes the "formal notation" of the actual transaction constraints (which are foregone in the original paper). Also, it details the L2 protocol logic for the **Coordinated** Head protocol - which is implemented in V1. ### Artifact 2: Hydra Head Protocol Implementation @@ -140,4 +140,4 @@ Hydra plutus mutation based testing can be found in the [hydra-node module](http Hydra node chain layer code can be found in the [hydra-node module](https://github.com/input-output-hk/hydra/tree/master/hydra-node/src/Hydra/Chain) in src/Hydra/Chain/Direct/ -Hydra node chain layer tests can be found in the [hydra-node module](https://github.com/input-output-hk/hydra/tree/master/hydra-node/test/Hydra/Chain) in test/Hydra/Chain/Direct/ \ No newline at end of file +Hydra node chain layer tests can be found in the [hydra-node module](https://github.com/input-output-hk/hydra/tree/master/hydra-node/test/Hydra/Chain) in test/Hydra/Chain/Direct/ diff --git a/hydra-node/src/Hydra/Node.hs b/hydra-node/src/Hydra/Node.hs index c66e4b742b3..45b5b3822bd 100644 --- a/hydra-node/src/Hydra/Node.hs +++ b/hydra-node/src/Hydra/Node.hs @@ -4,7 +4,7 @@ -- | Top-level module to run a single Hydra node. -- -- Checkout [Hydra --- Documentation](https://hydra.family/head-protocol/core-concepts/architecture) +-- Documentation](https://hydra.family/head-protocol/dev/architecture) -- for some details about the overall architecture of the `Node`. module Hydra.Node where